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: Always 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:
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?).
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/pam_unix.so to: account sufficient /lib/security/$ISA/pam_unix.so 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 applications.
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/pam_ldap.so This line should read: account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore authinfo_unavail=ignore] /lib/security/$ISA/pam_ldap.so The addition of 'authinfo_unavail=ignore' to the line will cause pam_ldap.so to return an 'ignore' value instead of the default 'bad' when it cannot contact the server.
*** This bug has been marked as a duplicate of 55193 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.