|Summary:||LDAP server failure causes complete root lockout|
|Product:||[Retired] Red Hat Linux||Reporter:||Graham Leggett <minfrin>|
|Component:||pam_ldap||Assignee:||Akira Yamata <akira>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 18:52:18 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Graham Leggett 2003-03-26 12:59:24 UTC
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:
Comment 1 Nils Philippsen 2003-06-30 12:45:59 UTC
Problem still persists, as I just had to find out the hard way... This is especially onerous on systems that are usually accessed remotely.
Comment 3 Nils Philippsen 2003-06-30 12:49:56 UTC
Severity "normal" -- no data loss here (in contrast to data _access_ that is ;-).
Comment 4 Nils Philippsen 2003-06-30 12:56:15 UTC
Reassign bug to akira (SRPM owner).
Comment 5 Graham Leggett 2003-06-30 14:14:31 UTC
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.
Comment 6 redbugs 2003-07-10 20:16:36 UTC
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.
Comment 7 Nils Philippsen 2003-07-13 13:20:36 UTC
*** This bug has been marked as a duplicate of 63717 ***
Comment 8 Red Hat Bugzilla 2006-02-21 18:52:18 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.