Bug 115181 - [authconfig] pam rejects logins when ldap not running
[authconfig] pam rejects logins when ldap not running
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2004-02-08 02:17 EST by Brian Beaudoin
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-17 09:59:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brian Beaudoin 2004-02-08 02:17:53 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.
Comment 1 Nalin Dahyabhai 2004-02-09 17:00:55 EST
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.
Comment 2 Brian Beaudoin 2004-02-09 21:18:56 EST
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.
Comment 3 Brian Beaudoin 2004-02-09 21:26:58 EST
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.
Comment 4 Jason Sauve 2004-07-19 13:02:15 EDT
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.
Comment 5 Kirby C. Bohling 2004-07-19 21:35:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.