Bug 63717

Summary: nss_ldap: it should search files first, but it searches LDAP
Product: [Retired] Red Hat Linux Beta Reporter: Tommy McNeely <tommy.mcneely>
Component: authconfigAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: high    
Version: alpha 3CC: frederik, jim, j, kendal.montgomery, mattdm, minfrin, nicku, nphilipp, rla
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-07 11:57:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 63631    
Bug Blocks:    
Attachments:
Description Flags
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible
none
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible none

Description Tommy McNeely 2002-04-17 20:23:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.9 sun4u)

Description of problem:
Using pam_ldap (for authentication and user information), the nsswitch.conf says
to search "files nisplus ldap" .. but it searches LDAP first (or doesnt stop
when it gets a result in files).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Setup LDAP authentication server (currently using NativeLDAP Phase2 on
Solaris 9 with iDS 5.x and compatibility information for auto* maps, but also
happens to redhat's included open_ldap server)
2. run authconfig and choose LDAP on both screens and fill in proper ldap server
info.
3. run "id mailman" (some user in the local passwd file) or just sit and wait
for one of the many crons to run...
	

Actual Results:  it makes an ldap bind and query for every user.. even local
ones... if the LDAP server is down or not responding, then it hangs completely
and you cannot even login as a local user (such as root)

Expected Results:  it should see the users information in the local /etc/passwd
/etc/group type files and not even touch ldap. amd therefore if LDAP was down,
you could still login as a local user (root).

Additional info:

-- below are exerpts from the /usr/iplanet/ds5/nosun-slapd/logs/access file

[17/Apr/2002:13:56:26 -0600] conn=167774 fd=40 slot=40 connection from
192.168.0.10 to 192.168.0.5
[17/Apr/2002:13:56:26 -0600] conn=167774 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
[17/Apr/2002:13:56:26 -0600] conn=167774 op=0 RESULT err=0 tag=120 nentries=0
etime=0
[17/Apr/2002:13:56:26 -0600] conn=167774 SSL 128-bit RC4
[17/Apr/2002:13:56:26 -0600] conn=167774 op=1 BIND dn="" method=128 version=3
[17/Apr/2002:13:56:26 -0600] conn=167774 op=1 RESULT err=0 tag=97 nentries=0
etime=0 dn=""
[17/Apr/2002:13:56:26 -0600] conn=167774 op=2 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(uid=rpcuser)" attrs=ALL
[17/Apr/2002:13:56:26 -0600] conn=167774 op=2 RESULT err=0 tag=101 nentries=0
etime=0
[17/Apr/2002:13:56:26 -0600] conn=167774 op=3 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(&(objectClass=posixGroup)(memberUid=rpcuser))" attrs="cn
userPassword memberUid uniqueMember gidNumber"
[17/Apr/2002:13:56:26 -0600] conn=167774 op=3 RESULT err=0 tag=101 nentries=0
etime=0


[17/Apr/2002:13:56:30 -0600] conn=167778 fd=91 slot=91 connection from
192.168.0.10 to 192.168.0.5
[17/Apr/2002:13:56:30 -0600] conn=167778 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
[17/Apr/2002:13:56:30 -0600] conn=167778 op=0 RESULT err=0 tag=120 nentries=0
etime=0
[17/Apr/2002:13:56:31 -0600] conn=167778 SSL 128-bit RC4
[17/Apr/2002:13:56:31 -0600] conn=167778 op=1 BIND dn="" method=128 version=3
[17/Apr/2002:13:56:31 -0600] conn=167778 op=1 RESULT err=0 tag=97 nentries=0
etime=1 dn=""
[17/Apr/2002:13:56:31 -0600] conn=167778 op=2 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(uid=nscd)" attrs=ALL
[17/Apr/2002:13:56:31 -0600] conn=167778 op=2 RESULT err=0 tag=101 nentries=0
etime=0
[17/Apr/2002:13:56:31 -0600] conn=167778 op=3 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(&(objectClass=posixGroup)(memberUid=nscd))" attrs="cn
userPassword memberUid uniqueMember gidNumber"
[17/Apr/2002:13:56:31 -0600] conn=167778 op=3 RESULT err=0 tag=101 nentries=0
etime=0
[17/Apr/2002:13:56:31 -0600] conn=167778 op=4 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(uid=nscd)" attrs=ALL
[17/Apr/2002:13:56:31 -0600] conn=167778 op=4 RESULT err=0 tag=101 nentries=0
etime=0
[17/Apr/2002:13:56:31 -0600] conn=167778 op=5 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(&(objectClass=posixGroup)(memberUid=nscd))" attrs="cn
userPassword memberUid uniqueMember gidNumber"
[17/Apr/2002:13:56:31 -0600] conn=167778 op=5 RESULT err=0 tag=101 nentries=0
etime=0


[17/Apr/2002:13:56:40 -0600] conn=167780 fd=37 slot=37 connection from
192.168.0.10 to 192.168.0.5
[17/Apr/2002:13:56:40 -0600] conn=167780 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
[17/Apr/2002:13:56:40 -0600] conn=167780 op=0 RESULT err=0 tag=120 nentries=0
etime=0
[17/Apr/2002:13:56:41 -0600] conn=167780 SSL 128-bit RC4
[17/Apr/2002:13:56:41 -0600] conn=167780 op=1 BIND dn="" method=128 version=3
[17/Apr/2002:13:56:41 -0600] conn=167780 op=1 RESULT err=0 tag=97 nentries=0
etime=1 dn=""
[17/Apr/2002:13:56:41 -0600] conn=167780 op=2 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(uid=xfs)" attrs=ALL
[17/Apr/2002:13:56:41 -0600] conn=167780 op=2 RESULT err=0 tag=101 nentries=0
etime=0
[17/Apr/2002:13:56:41 -0600] conn=167780 op=3 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(&(objectClass=posixGroup)(memberUid=xfs))" attrs="cn
userPassword memberUid uniqueMember gidNumber"
[17/Apr/2002:13:56:41 -0600] conn=167780 op=3 RESULT err=0 tag=101 nentries=0
etime=0

Comment 1 Tommy McNeely 2002-04-17 20:25:41 UTC
oops... wrong category.... I think this is more of a nss_ldap than a pam
issue... authentication works fine.

Comment 2 Tommy McNeely 2002-04-17 20:28:11 UTC
*** I have not changed these files other than choosing LDAP during setup

[tommy@kyle tommy]$ cat /etc/nsswitch.conf      
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
#	nisplus or nis+		Use NIS+ (NIS version 3)
#	nis or yp		Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files nisplus ldap
shadow:     files nisplus ldap
group:      files nisplus ldap

#hosts:     db files nisplus nis dns
hosts:      files nisplus dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files     

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files nisplus ldap
rpc:        files
services:   files nisplus ldap

netgroup:   files nisplus ldap

publickey:  nisplus

automount:  files nisplus ldap
aliases:    files nisplus

[tommy@kyle tommy]$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/bin/bash
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/bin/false
ntp:x:38:38::/etc/ntp:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/dev/null
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
named:x:25:25:Named:/var/named:/bin/false
amanda:x:33:6:Amanda user:/var/lib/amanda:/bin/bash
pvm:x:24:24::/usr/share/pvm3:/bin/bash
apache:x:48:48:Apache:/var/www:/bin/false
gdm:x:42:42::/var/gdm:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
ident:x:98:98:pident user:/:/sbin/nologin
radvd:x:75:75:radvd user:/:/bin/false
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
squid:x:23:23::/var/spool/squid:/dev/null
pcap:x:77:77::/var/arpwatch:/sbin/nologin
junkbust:x:73:73::/etc/junkbuster:/bin/bash
mailman:x:41:41:GNU Mailing List Manager:/var/mailman:/bin/false
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash
ldap:x:55:55:LDAP User:/var/lib/ldap:/bin/false
postfix:x:89:89::/var/spool/postfix:/bin/true
[tommy@kyle tommy]$ 




Let me know if you need any more information... this affects RH7.2 as well
btw...

Comment 3 Tommy McNeely 2002-04-17 20:47:22 UTC
bug # 63631 may have something to do with this one... although it is in
authconfig.. maybe once that is fixed this will resolve itself?

Tommy McNeely


Comment 4 Tommy McNeely 2002-04-17 21:18:22 UTC
this bug is very close to a duplicate of # 63631 ... 

63131 - add an option to the system-auth so that if the ldap server is down it
"can" failover to files

63717 - it should look in local files FIRST per the /etc/nsswitch.conf file


so they are basically the same but diffrent :)

[17/Apr/2002:15:12:48 -0600] conn=168288 op=2 SRCH base="dc=redneck,dc=nu"
scope=2 filter="(&(objectClass=posixGroup)(memberUid=root))" attrs="cn
userPassword memberUid uniqueMember gidNumber"

on a side note.. why does it request userPassword.. if my ldap server was going
to give that back, I might as well just run NIS :)

Tommy


Comment 5 Nils Philippsen 2002-08-14 09:26:59 UTC
I just confirmed (i.e. had to unintentionally realize) that this bug still
exists (or exists again), ticked up version to limbo, ticked up priority because
this can cause a DOS situation.

Comment 6 Need Real Name 2002-08-14 13:27:09 UTC
Its quite a pain in the ass that a problem with the connection to the
LDAP-auth-server causes one to reboot the system with "linux 1".

This should really be fixed!!!

Comment 7 Keith Winston 2003-01-06 14:15:30 UTC
I just wanted to confirm that this still exist in the Red Hat 8.0 production
release.  I unfortunately ran into it testing an openldap configuration.

I am using the Red Hat openldap server on a Red Hat 8.0 server, my client is a
Red Hat 8.0 laptop.  Once everything was set up, the authentication worked fine.
 However, I took my laptop to work and could not login as any local user
including root.  I have to boot into runlevel 1 and edit the file to remove the
LDAP entries.

Please fix this, it is not safe to use LDAP if you can't fall back to your local
user accounts!


Comment 8 Stephen Walton 2003-01-23 05:07:23 UTC
I am quite interested in this bug;  I was all jazzed to use OpenLDAP for
authorization on my new server but this seems like a show stopper.  In fact I
thought I was doing something very wrong.  I also agree with the comment that
given the password handling, LDAP appears to offer no advantages over NIS at
present.

Is this problem possibly related to bug 80061?  It appears to me that there are
two different ldap.conf files;  one is /etc/ldap.conf and is part of the
nss_ldap RPM, the other is /etc/openldap/ldap.conf and is part of the openldap
RPM.  'strings /usr/lib/libldap.so.2.0.16' seems to confirm it only uses the
latter, while 'strings /usr/lib/libnss_ldap.so' implies it checks both.

Comment 9 Richard Allbery 2003-02-01 00:23:07 UTC
We have also been trying to implement LDAP authentication as well.  We are
running into many of the same problems mentioned above.  I was in fact able to
get around the DOS problem if LDAP is down by adding the following in the
/etc/nsswitch.conf file:

passwd:     files [UNAVAIL=return] ldap
shadow:     files [UNAVAIL=return] ldap
group:      files [UNAVAIL=return] ldap

Then in /etc/pam.d/system-auth we added the pam_localuser.so line.
 
account     required      /lib/security/pam_unix.so
account     sufficient    /lib/security/pam_localuser.so debug
account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/pam_ldap.so

Everything worked fine except ... we have a group setup in LDAP that was not
local to the system.  If we created a directory giving it the external group
owner and then tried to create a file in that directory, permission was denied.
 The only way we found to resolve that problem was to remove the
[UNAVAIL=return] line out of the /etc/nsswitch.conf file which of course breaks
being able to log into the box if the machine is off the network or can't reach
the LDAP server.

Another very annoying problem we ran into was tripwire fails with a 
Software interrupt forced exit: Segmentation Fault.  If you take the ldap stuff
out of /etc/nsswitch.conf tripwire will run just fine.  Doing an strace you can
see tripwire try to resolve group number to name information via the
nsswitch.conf file and then blows up.  Also, as near as I can tell the tripwire
problem seems to be related to RH 7.3 and RH 8.0 as we have LDAP working on 7.2
and 7.1 boxes.  I then tried to download the latest version of tripwire but it
would not build on RH 8.0.

If anybody knows how to get LDAP all up and running on 8.0 I sure would like to
hear from you.  I've about exhausted all my resources.  Thanks.


Comment 10 Tommy McNeely 2003-02-06 21:11:40 UTC
This is still broken in the phoebe2 beta... I think this needs bumped to a
higher priority ??



[06/Feb/2003:11:24:47 -0700] conn=1239137 fd=68 slot=68 connection from
129.147.29.68 to 129.147.28.6
[06/Feb/2003:11:24:47 -0700] conn=1239137 op=0 BIND dn="" method=128 version=3
[06/Feb/2003:11:24:47 -0700] conn=1239137 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn=""
[06/Feb/2003:11:24:47 -0700] conn=1239137 op=1 SRCH base="dc=sun,dc=com" scope=2
filter="(uid=nscd)" attrs=ALL
[06/Feb/2003:11:24:47 -0700] conn=1239137 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[06/Feb/2003:11:24:47 -0700] conn=1239137 op=2 SRCH base="dc=sun,dc=com" scope=2
filter="(&(objectClass=posixGroup)(memberUid=nscd))" attrs="cn userPassword
memberUid uniqueMember gidNumber"
[06/Feb/2003:11:24:50 -0700] conn=1239137 op=2 RESULT err=0 tag=101 nentries=0
etime=3
[06/Feb/2003:11:24:50 -0700] conn=1239137 op=3 SRCH base="dc=sun,dc=com" scope=2
filter="(uid=nscd)" attrs=ALL
[06/Feb/2003:11:24:50 -0700] conn=1239137 op=3 RESULT err=0 tag=101 nentries=0
etime=0
[06/Feb/2003:11:24:50 -0700] conn=1239137 op=4 SRCH base="dc=sun,dc=com" scope=2
filter="(&(objectClass=posixGroup)(memberUid=nscd))" attrs="cn userPassword
memberUid uniqueMember gidNumber"
[06/Feb/2003:11:24:50 -0700] conn=1239137 op=4 RESULT err=0 tag=101 nentries=0
etime=0
[06/Feb/2003:12:02:23 -0700] conn=1239137 op=-1 fd=68 closed - B1


Tommy McNeely


Comment 11 Richard Allbery 2003-03-18 02:06:31 UTC
Turning on nscd resolved the above mentioned Tripwire problem.

Comment 13 Nils Philippsen 2003-07-13 13:17:53 UTC
Still present in current Rawhide.

Comment 14 Nils Philippsen 2003-07-13 13:20:38 UTC
*** Bug 86606 has been marked as a duplicate of this bug. ***

Comment 15 Nils Philippsen 2003-07-13 13:55:37 UTC
I just changed my /etc/pam.d/system.auth as described in
http://www.netsys.com/nssldap/2002/06/msg00024.html which fixes the issue of not
being able to login if the LDAP server isn't accessible (I tried it with local
login, ssh login, X login, with and without nscd).

The problem of it touching LDAP even for local users is apparently because it
tries to check whether local users are memebers of LDAP groups... I don't know
how this should be handled though, I guess there isn't a "one size fits all"
solution. I guess experimenting with timeout and bind_timeout values in
/etc/ldap.conf can be helpful.

Changing the component to authconfig, because this is where the incorrect
system-auth entry came from.

Comment 16 Nils Philippsen 2003-07-13 13:58:02 UTC
Created attachment 92900 [details]
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible

Comment 17 Nils Philippsen 2003-07-22 12:55:24 UTC
Created attachment 93041 [details]
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible

Fixed patch, cf: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89592

Comment 18 Nils Philippsen 2003-07-25 08:12:55 UTC
Vah type. Rather cf: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63631

Comment 19 Nils Philippsen 2003-07-25 08:14:55 UTC
That should read "Bah, typo...". One of these fridays.

Comment 20 Brian Beaudoin 2004-02-08 05:08:28 UTC
Change the line in /etc/pam.d/system-auth from:

    account     [default=bad success=ok user_unknown=ignore \
     service_err=ignore system_err=ignore] \
     /lib/security/$ISA/pam_ldap.so

to:

    account     [default=bad success=ok user_unknown=ignore \
     service_err=ignore system_err=ignore authinfo_unavail=ignore] \
     /lib/security/$ISA/pam_ldap.so

The problem is, if 'authconfig' is run again it removes the
'authinfo_unavail=ignore' (and according to the comments at the top,
any changes are erased when 'authconfig' is run).

I first noticed this problem using NIS with Red Hat 4.2 (and for
safety's sake I had decided against using directory services until I
required some of the features available through LDAP.

No clue why this isn't automatically added - security reason?

Comment 21 Matthew Miller 2004-03-30 15:05:14 UTC
This is also related to bug #55193....

Comment 22 Tomas Mraz 2004-12-07 11:57:30 UTC
The original issue with nss not stopping search even if found in files
should be resolved in current releases.

The problem with logging in not working is duplicate of bug #55193.