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
Steps to Reproduce:
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
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.