Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 84309 - nscd uses different object types to query user information than nss_ldap
Summary: nscd uses different object types to query user information than nss_ldap
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.3
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-14 08:50 UTC by Henning Schmiedehausen
Modified: 2016-11-24 15:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-06 05:46:39 UTC


Attachments (Terms of Use)

Description Henning Schmiedehausen 2003-02-14 08:50:29 UTC
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.

Comment 1 Ulrich Drepper 2004-10-06 05:46:39 UTC
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 07:44:16 UTC
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.