----- "Tim Dunphy" bluethundr@gmail.com 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