Solaris client, behavior differences?
for pam config always read the man page:
$ man pam_ldap
the most interesting part in pam.conf is:
*login** auth requisite* pam_authtok_get.so.1
*login** auth required** pam_dhkeys.so.1
*login** auth required** pam_unix_cred.so.1
*login** auth binding*** pam_unix_auth.so.1 server_policy
*login** auth required** pam_ldap.so.1
for ssh add a additional section where you replace 'login' with 'other'.
The search limit configuration in 389 DS is similar to the SunDS 5.x server.
at least a "getent passwd <ldapusername>" should return the entry. Perhaps you should configure on the DS389 VLV's with the Solaris /usr/lib/ldap/idsconfig script. If you adapt the DS version check, this script works also for 389DS.
Am 03.05.12, schrieb Rafael Hinojosa <firstname.lastname@example.org>:Hi,*
My*colleague*and I are working on migrating from Sun One Directory Server to 389 Directory Server. *We have successfully configured 389 Directory Server on Centos 5.7. *We've been able to successfully setup Multi-Master Replication and have joined (or at least it appears to) a Solaris 10 Client. *
Here is a quick breakdown of what we're observing...
Solaris 10 host, as a 389 Client...... can perform ldapsearch (using both directory manager & proxyagent bindDNs). **It will return all entries (when using directory manager as the bindDN) or a limited amount (2000, when search using proxyagent bindDN), as specified by the configuration.*
... using ldaplist requires an escaped wild card to list most of the DB, again I'm assuming it is inheriting the proxyagent limits. *...*executing*"getent passwd" or "getent group" returns ONLY the local users & groups.*
Solaris 10 host, as a Sun One Client...... using ldapsearch exhibits the same behavior.... using ldaplist requires no wild card, we can simply execute "ldaplist passwd" and get, surprisingly, all entries in the DB. *
... can execute "getent passwd" or "getent group" and see all LDAP users and groups.*
Is this normal or have we screwed up some config somewhere? *
We have yet to move on to tackling the PAM stack since we're trying to see if this config is viable. *
At the moment, as a local user on this 389 Client, we cannot su to another LDAP user. *It just says sorry, /var/adm/messages just reads "su : [auth.crit] 'su <USER>' failed for <LOCAL USER> on..."
We can su to another LDAP user as root w/o the need to specify a passwd, which I'm assuming is the only reason that works. *
My colleague is going to work on finding a viable PAM config. * Any clues, leads, or references you can provide us for either*anomalies*would be greatly*appreciated.*
Thank you for your time,*
Rafael A. HinojosaTechnical Support AnalystCore*Technologies**- *Instructional*&*Information Technology Services
Haverford College *- *370 Lancaster Ave. *- *Haverford, PA 19041-1392
Office : (610) 896-1312Direct : (610) 772-1593Fax : (610) email@example.com
389 users mailing list