----- "Tim Dunphy" <[email protected]> wrote: > ldapsearches on the client were working just as they were > before and getents on the client were not. But I was seeing a new > error in the logs at this point: > > Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SRCH > base="ou=staff,dc=summitnjhome,dc=com" scope=2 deref=0 > filter="(objectClass=posixAccount)" > Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory loginShell gecos > description objectClass > Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SEARCH RESULT > tag=101 err=32 nentries=0 text=
[...] > Here's > what one of the user accounts looks like: > > 43 > uid=bluethundr,cn=summitnjops,ou=staff,ou=Group,dc=summitnjhome,dc=com This account isn't under the searchbase of the search performed above. [...] > This command does find the bluethundr account: > > ldapsearch -xH 'ldap://LBSD2.summitnjhome.com' -D > 'cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com' -w 'secret' -b > 'dc=summitnjhome,dc=com' '(uid=bluethundr)' You're using a different search base than you configured your nss_ldap client. > (currently I'm not using TLS until I get this mess sorted out) > > And I am using this /etc/ldap.conf on the client which as I've > mentioned is centos 5.5 > > host 192.168.1.44 > base ou=staff,ou=Group,dc=summitnjhome,dc=com > sudoers_base ou=staff,ou=Group,dc=summitnjhome,dc=com > binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com > bindpw secret > scope sub > pam_password exop > nss_base_passwd ou=staff,dc=summitnjhome,dc=com > nss_base_shadow ou=staff,dc=summitnjhome,dc=com Compare your 'base' and 'sudoers_base' to the 'nss_base_passwd' ... Don't test with something that is similar, copy/paste the correct values from your configuration to test with ldapsearch etc., otherwise you are wasting your time "testing". Regards, Buchan
