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@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