Bug 86606 - LDAP server failure causes complete root lockout
LDAP server failure causes complete root lockout
Status: CLOSED DUPLICATE of bug 63717
Product: Red Hat Linux
Classification: Retired
Component: pam_ldap (Show other bugs)
9
All Linux
high Severity medium
: ---
: ---
Assigned To: Akira Yamata
:
Depends On:
Blocks: 77575
  Show dependency treegraph
 
Reported: 2003-03-26 07:59 EST by Graham Leggett
Modified: 2007-03-27 00:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Graham Leggett 2003-03-26 07:59:24 EST
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 08:45:59 EDT
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 08:49:56 EDT
Severity "normal" -- no data loss here (in contrast to data _access_ that is ;-). 
Comment 4 Nils Philippsen 2003-06-30 08:56:15 EDT
Reassign bug to akira (SRPM owner).
Comment 5 Graham Leggett 2003-06-30 10:14:31 EDT
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 16:16:36 EDT
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 09:20:36 EDT

*** This bug has been marked as a duplicate of 63717 ***
Comment 8 Red Hat Bugzilla 2006-02-21 13:52:18 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.