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 77575 - Can't login if LDAP server cannot be contacted
Summary: Can't login if LDAP server cannot be contacted
Status: CLOSED DUPLICATE of bug 55193
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: AfterStep-APPS
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
Depends On: 86606
TreeView+ depends on / blocked
Reported: 2002-11-09 16:16 UTC by Brett Boren
Modified: 2015-01-08 00:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:50:06 UTC

Attachments (Terms of Use)

Description Brett Boren 2002-11-09 16:16:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021017

Description of problem:
Even with accounts (root) that exist only on the client system, I cannot login
if the LDAP server can't be contacted.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Setup a client machine with some user(s) in /etc/passwd that don't appear in
LDAP (such as root) 
2.Reboot the machine but make it unable to contact the configured LDAP server
(unplug the path cable)
3.Try to login as one of the /etc/passwd users 

Actual Results:  - PAM throws an error about can't bind to LDAP server and no
matter what you do you cannot get logged into that system until a connection to
the LDAP server is restored

Expected Results:  It should allow user defined locally to login even if the
remote users can't. I have to reboot the machine into single user mode, change
the authentication mechanism and reboot to be able to come up and login as root
in multiuser mode

Additional info:

Comment 1 redbugs 2003-07-10 20:37:55 UTC
This is the same bug as 86606.

As I mentioned there, the problem is the naive reference to "sufficient" for
both pam_ldap and pam_unix in /etc/pam.d/system-auth.

This pam setup generates bogus errors when users log in with uids that exist in
LDAP but not in /etc/passwd, and causes total system lockout (forcing reboot
into single user mode and elimination of ldap authentication) if the LDAP server
fails for any reason.

So this is either a pam bug or a authconfig bug or a pam_ldap bug, but not an
LDAP bug really...  best to leave this classification, though, since it is
stalling LDAP adoption at several sites (two that I know of personally, perhaps
many more?).

Comment 2 redbugs 2003-07-10 21:30:07 UTC
I have spotted quite a few related problems while browsing Bugzilla.  For
example in 72179, the LDAP server crashed because of the ldconfig bug in the SSL
update, but that problem was magnified by the resulting inability to log in.  I
think 89592 is also related, and several more that I didn't note the numbers on.  

There is a patch submitted in 55193, which is a straight dup of thisbug , just
as 86606 is.  But I'm not sure that solution is optimal...  I changed the line

account required /lib/security/$ISA/


account sufficient /lib/security/$ISA/

in /etc/pam.d/system-auth instead and that seems to fix the problem for me.  So
far, at least - I tested this on Red Hat 9 a few minutes ago, but I haven't
aggressively tested for any authentication problems this might cause in other

Comment 3 Brad Smith 2003-07-22 23:26:37 UTC
I actually had a student in one of my rh300 classes solve this problem. 

The reason local users are logged out when the ldap server cannot be contacted
is because of this line in /etc/pam.d/system-auth, which is generated by
authoconfig when the user chooses ldap as their authentication method (thus I've
opened up a new bug #100504 under authconfig)

account [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/$ISA/

This line should read: 

account [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore authinfo_unavail=ignore] /lib/security/$ISA/

The addition of 'authinfo_unavail=ignore' to the line will cause to
return an 'ignore' value instead of the default 'bad' when it cannot contact the

Comment 4 Brett Boren 2003-07-25 12:42:47 UTC

*** This bug has been marked as a duplicate of 55193 ***

Comment 5 Red Hat Bugzilla 2006-02-21 18:50:06 UTC
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.