Description of problem: Redhat v7.3 box configured to authenticate against LDAP server. If the LDAP server either goes down, or is hosed (as openldap v2.0.27 does regularly), all attempts to login as root are denied. The only workaround is to boot box into single user mode, and use authconfig to switch off LDAP authentication. It would seems that the pam configs that are shipped with pam_ldap are broken during a failure situation. Discussion on the pam_ldap lists suggest that pam is attempting to determine group membership, and since the LDAP server is unavailable, pam then denies the request. It should never ever ever be possible to lock the admin out of a box in the case of temporary LDAP server failure when the login credentials for the root user are stored in flat files /etc/password. Version-Release number of selected component (if applicable): pam_ldap latest config in Redhat v7.3 How reproducible: Steps to Reproduce: Actual results: Expected results: Additional info:
Problem still persists, as I just had to find out the hard way... This is especially onerous on systems that are usually accessed remotely.
Severity "normal" -- no data loss here (in contrast to data _access_ that is ;-).
Reassign bug to akira (SRPM owner).
Data loss and machine lockout are just as severe as the other. In remote situations, system lockout and data loss are one and the same thing. As a result of this bug, and as a result of the fact that Redhat hasn't done anything about it for months, we shelved plans to roll out a Redhat based network based on LDAP authentication, as we have no confidence in it's reliablity.
I can reliably reproduce this situation on Red Hat 7.2, 7.3, 8.0, and 9.0. Isn't it great how us users help out with the diagnostics? :^) This is a very high impact problem for co-lo servers and remote data gatherers with extremely long duty cycles. It has stopped our migration to LDAP competely at this point... a rarely occuring problem with extreme consequences can be worse than a frequently occurring one with trivial consequences, neh? The simplest way to reproduce this error is to log in as root to a working server running a slave LDAP daemon (a slurp-fed slapd) and kill the local slapds (If you want a really hideous crash, you can manually edit the /etc/passwd and /etc/shadow files to remove the entries for user ldap - that does the daemon up a treat). Once you do this, you will no longer be able to log in even using uids that exist in /etc/passwd and do not exist in LDAP (such as root, for example, or whatever local maintenance uids you normally use). The problem appears to be in the file /etc/pam.d/system-auth. The designation of both pam_unix.so and pam_ldap.so as "sufficient" is naive; there needs to be a more rigorous designation for both, to prevent this bug and also to prevent spurious errors from pam when a user exists only in one of these sources.
*** This bug has been marked as a duplicate of 63717 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.