Red Hat Bugzilla – Bug 115181
[authconfig] pam rejects logins when ldap not running
Last modified: 2007-11-30 17:10:36 EST
Description of problem: If LDAP authentication is selected using authconfig, the default settings added to '/etc/pam.d/system-auth' causes logins from local users to be rejected with the message "incorrect password". This becomes a serious issue for crisis management because in the event of a failure, 'root' cannot log in to fix the problem without physical access (or at least serial console access and a means to reboot the system remotely in 'single' mode). Background Information: The 'PAM_AUTHINFO_UNAVAIL' flag was added to 'pam_ldap.so' to inform pam of errors unrelated to config errors (supposed to improve module stacking). A flag was recently added to allow PAM to ignore the flag so that it can grant authorization based on files. General Solution: Add the option 'authinfo_unavailable=ignore' to the file '/etc/pam.d/system-auth' at the end of the options in square brackets on the line that invokes 'pam_ldap.so'. That option has the effect of preventing PAM from rejecting logins solely based on the availability of LDAP for local users. Why open another bugzilla report? This bug was fixed by the update to 'pam_ldap.so', however adding the option to 'authconfig' to be written to '/etc/pam.d/system-auth' by default now will help a lot of people out who are using LDAP for the first time and aren't even aware of this issue until a failure occurs. Most administrators will probably only run 'authconfig' once or twice during the lifetime of the installation (and usually because they are initially unaware of or inexperienced with PAM configuration and the '/etc/nsswitch.conf' file). Although I feel that administrators learn a lot from dealing with issues like these (by reading manuals, release files, bug reports, etc.), this change would save a lot of time and resources and drastically reduce downtime when dealing with LDAP-related issues.
Are you referring to situations where a user with a given name appears both in local files and in a directory server? The system can't distinguish between the two in situations like that, and things will break. The problems are a) you can then have multiple crypted passwords, but the libc interface for looking up information about a user given the account name can only return one b) the account UIDs can differ, but only one will be honored c) applications which iterate over all known users will see the user twice, even if the two records of the user account are identical The combination of these breaks things, badly, and shouldn't be allowed to happen. Typically you want root to be locally-defined.
Only three (non-system) users are defined on my test box (and exclusively in each category): root uid=0 , gid=0 (files) baddog uid=500, gid=500 (files) test uid=501, gid=501 (ldap) Also, '/etc/nsswitch.conf' has "files ldap" specified for each in passwd, shadow, and group. The expected behavior is: When LDAP is running, files are checked first and if the user is not found, LDAP is checked. When LDAP is not running, only the files are checked. The actual behavior while LDAP is running is: Files are checked first, then LDAP is consulted. If the user does not exist in LDAP, LDAP is ignored and whatever is in files takes precedence. The actual behavior while LDAP is not running is: Files are checked first, then LDAP is consulted. Failure to contact LDAP results in a fallthrough with default=bad (response is "invalid password") An obvious solution (eliminating the problem and increasing security) is not to allow the LDAP authentication server to authenticate users via LDAP. Unfortunately, here's what happens: Management wants to try LDAP but doesn't want it running on the server because it makes them nervous. The admin runs it on his workstation, tests it, migrates some users over to it, tests it some more, migrates data over to it for testing, etc. Then after 187 days of uptime, the admin reboots his workstation and: Doesn't realize he forgot to set LDAP to restart on boot Can't find his boot disk and forgot the GRUB password Users can't log in, management calls it a failure... This might be just a little over-dramatic, but you might suggest that this summarized my experience with NIS on Linux back in the 1996. Our NIS servers ran on Sun until June 2000. The best reading on the issue seems to be on the Netsys mailing list archives starting with the following post on June 7, 2002: http://www.netsys.com/pamldap/2002/06/msg00013.html) Luke Howard suggested setting "bind_policy soft" in '/etc/ldap.conf' but this does not seem to work (problem with nss_ldap). The most workable solution seems to be the 'pam_ldap.so' configuration option ("authinfo_unavail=ignore"). Since 'authconfig' writes this file and sets this option, it seems like the most natural place to fix it. The only exception is if this fix causes a security issue. In which case another workaround/solution needs to be found. Again, this is basically a perceptual problem that I see being faced by administrators who are inexperienced with directory services or have gained most of their experience with NIS on other platforms. In the rush to migrate to LDAP on Linux, many are too busy trying to figure out how to implement the hiearchies and schemas to implement the features that management wants instead of studying the system. I hope I've answered your question (plus some). Hopefully someone can comment on the potential security risks of adding the pam_ldap option we're talking about.
Apologies for the typos and other mistakes I didn't catch in editing. To clarify, I meant to say that the LDAP authentication server shouldn't be an LDAP client itself. Of course 'authconfig' overwrites the '/etc/pam.d/system-auth' file where the 'pam_ldap.so' configuration option is set, and not 'pam_ldap.so' itself.
I concur with what Brian has claimed. I'm experiencing the same problem and have yet to see a resolution. When will a fix be available? I would not want to edit the system-auth file by hand, then later down the road use authconfig and overwrite my changes, having forgotten weeks,months,years after that I had to change system- auth to add the option authinfo_unavail=ignore for pam_ldap so that local users can still login when the LDAP server is down.
I'll point out that at least for my company, nothing you do on the PAM problem will fix the. Our problem is that until you change the nsswitch.conf file so that you remove: group: files ldap and change it to: group: files You can't login. I've been reading the same thread on netsys that Brian has. Having our LDAP server be a machine you can't log into, is a serious problem. So far the best solution I can cup up with is this: I can't track down any documentation on the allowed configuration items for /etc/ldap.conf. It appears that RH is not outputting all of the current configuration options. As of nss_ldap-191, you can add bind_policy soft, and bind_timelimit 2 to /etc/ldap.conf. The best documentation I've found is to go get the tarball directly from the URL listed in the rpm, and read it. At this point, if I then add the LDAP server to /etc/hosts, I can still log in. With the bind_policy, bind_timelimit and the hard coded IP in /etc/hosts, I can actually make this work so I can log in, into a machine that has LDAP configured but is disconnected.