Bug 84309 - nscd uses different object types to query user information than nss_ldap
nscd uses different object types to query user information than nss_ldap
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2003-02-14 03:50 EST by Henning Schmiedehausen
Modified: 2007-03-27 00:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-06 01:46:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Henning Schmiedehausen 2003-02-14 03:50:29 EST
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:

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 ---
host <ip-address>
base o=intermeta.de
ldap_version 3
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

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.
Comment 1 Ulrich Drepper 2004-10-06 01:46:39 EDT
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.)
Comment 2 Henning Schmiedehausen 2004-10-06 03:44:16 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.