Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 86606

Summary: LDAP server failure causes complete root lockout
Product: [Retired] Red Hat Linux Reporter: Graham Leggett <minfrin>
Component: pam_ldapAssignee: Akira Yamata <akira>
Severity: medium Docs Contact:
Priority: high    
Version: 9CC: nphilipp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:52:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 77575    

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 and 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.