From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030731 Mozilla Firebird/0.6.1 Description of problem: Seen on both RH-7.3 and RH-8.0 stations: When using LDAP authentication, there is a root login failure when the LDAP server is down or when there is no connection to the LDAP server. The user root is NOT in the LDAP database but in /etc/passwd. "nsswitch.conf" says: passwd: files ldap shadow: files ldap group: files ldap Despite these entries, when logging in as root, the machine queries the LDAP server while it should not do that, it first has to look in "files". But more severe is that when the LDAP is down, the machine becomes fully inaccessible. A reboot "init=/bin/sh" is necessary to switch off LDAP auth in order to get root access to the machine. Richard Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. stop the connection to the LDAP server 2. login as root on console: failure 3. start the connection to the LDAP server 4. login as root: success Additional info:
Btw: this works around the problem, but IMHO the entries in nsswitch.conf file should be followed, the "files" should preceed over "ldap". in /etc/pam.d/system-auth, add "authinfo_unavail=ignore" option: Original line: ###account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_ldap.so New line: account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore authinfo_unavail=ignore] /lib/security/pam_ldap.so
This work around did not work for me. In addition I had to insert the following line between "account .. pam_unix.so" and "account .. pam_ldap.so": account sufficient /lib/security/$ISA/pam_localuser.so Shouldn't this be reported under authconfig instead of nss_ldap?
I should have checked before comenting on this bug. Bug 118239 offers the same fix in a more detailed way. Also the same bug seems to have been reported many times: #55193 #63631 #63717 #77575 #86606 Still present in Fedora Core 2 test 2
*** This bug has been marked as a duplicate of 55193 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.