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).
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.
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
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
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:
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:
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.