From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020918 Description of problem: nscd changes the ldap object type that is queried for authenticating an user. This might be related to the Bug # 83031 (in fact it might be the same bug), but I can track it down to the specific problem. Version-Release number of selected component (if applicable): nscd: 2.2.5-42 nss_ldap: 189-4 How reproducible: Always Steps to Reproduce: 1. Set up a box which authenticates users against an LDAP server. In my case this is an Iplanet Directory Server which serves objects of the following type: top,person,organizationalPerson,inetorgperson,posixaccount The clients use the nsswitch.conf to query password, shadow and group from "files ldap" in /etc/ldap.conf I have --- cut --- host <ip-address> base o=intermeta.de ldap_version 3 binddn bindpw rootbinddn <my root-bind-dn> The rest of the system uses pam with system-auth 2. Now try to log in e.g. by secure shell. 3. Try again with nscd running. Actual Results: With nscd running, I see the following queries on the LDAP server: [14/Feb/2003:09:40:24 +0100] conn=322575 op=1 SRCH base="o=intermeta.de" scope=2 filter="(&(objectclass=shadowAccount)(uid=henning))" [14/Feb/2003:09:40:24 +0100] conn=322575 op=1 RESULT err=0 tag=101 nentries=0 etime=0 Expected Results: Without nscd running, I see these queries [14/Feb/2003:09:38:49 +0100] conn=322554 op=4 SRCH base="o=intermeta.de" scope=2 filter="(&(objectclass=posixAccount)(uid=henning))" [14/Feb/2003:09:38:49 +0100] conn=322554 op=4 RESULT err=0 tag=101 nentries=1 etime=0 Additional info: Things like "finger <user>" and "id" still work with nscd running. So it seems that nscd only uses shadowAccount objects for authentication. This is a bug, nscd should also use posixAccounts for this. I do put this on "high" Prority because not running nscd poses a serious performance problem for us and changing the ldap objects is out of the question.
This is nothing nscd is responsible for. If anything, it's the NSS module used. I doubt there is any such problem these days. Update to the latest nss_ldap code (and latest glibc code, 2.3.3-65 or later, for best nscd compatibility with it) and retest. If there is an issue with LDAP lookups, file it against nss_ldap. I'm closing the bug since the info here is too old. Reopen and reassign if necessary. (And note: don't use the nscd component. It should never have existed which is why nobody noticed this bug.)
Having the bug lying around for 20 months without doing anything wasn't too helpful, either. I will not upgrade to "latest and greatest", I will stick with release versions (RHEL 3 and Fedora 1/2) and retest.