Hi,

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.

Regards, 
Carsten

Am 03.05.12, schrieb Rafael Hinojosa  <rhino...@haverford.edu>:
> 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, 
> 
> 
> --Raf
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> -- 
> 
> 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
> rhino...@haverford.edu
> 
> 
> 
> 
> 
> 
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Reply via email to