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
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):
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:
The clients use the nsswitch.conf to query password, shadow and group
from "files ldap"
in /etc/ldap.conf I have
--- cut ---
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
[14/Feb/2003:09:40:24 +0100] conn=322575 op=1 RESULT err=0 tag=101 nentries=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
[14/Feb/2003:09:38:49 +0100] conn=322554 op=4 RESULT err=0 tag=101 nentries=1
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.