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 <rhinojos(a)haverford.edu>:
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. Hinojosa
Technical Support Analyst
Core Technologies - Instructional & Information Technology Services
Haverford College - 370 Lancaster Ave. - Haverford, PA 19041-1392
Office : (610) 896-1312
Direct : (610) 772-1593
Fax : (610) 896-1429