local accounts unavailable during ldap issue

[Jon Miller]

Hopefully this is a easy/common problem which I've simply not hit upon yet.
I have several RHEL 3.0 machines which have setup to authenticate to a pair
of openldap servers. Normally things are fine, but lately we've had some
issues with our LDAP servers where a query would hang in the middle. Even
worse, the replication server too displayed the same behavior. Ouch, no
logins.
Ideally this scenario would only affect employees logging into the servers
since our applications use locally setup accounts. However, this is not the
case and our LDAP issue can actually affect local account authentication as
well.

Let me jump straight into a quick test case matrix: ( here, I have changed
my /etc/ldap.conf to point to a couple of bogus servers which are merely
running netcat to simulate a "hung" ldap query)
                       NSS     Queried        Successful      | Comments
                       LDAP    LDAP ?        Login?            |
-----------------------------------------------------------------------------|--------------------
root login         No         No               Yes                | pam_unix
indirectly querying ldap via nss?
ldap  login        No        Yes               No                 | "illegal
user" without nss.
root login         Yes       Yes               No                 | queries
ldap before giving prompt; ssh timeout.
ldap login        Yes        Yes              Yes                | obvious.
(only with correct servers in ldap.conf, ofcourse)
legend: "NSS LDAP": No means I only left "files" for the various dbs(passwd,
shadow, group). Yes means "ldap" is listed second in the /etc/nsswitch.conf.


The case I am interested in solving is the third. While trying to ssh into
the machine, you are never prompted a password because it is busy querying
LDAP. Compare that with my first test case with ldap left out of the
nsswitch.conf and the root login succeeds without _ever_ attempting to query
our LDAP server.

Here is what my /etc/pam.d/system-auth file looks like:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so debug
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
audit
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
debug
auth        required      /lib/security/$ISA/pam_deny.so debug

account     required      /lib/security/$ISA/pam_unix.so  debug
account     sufficient    /lib/security/$ISA/pam_localuser.so
account     required      /lib/security/$ISA/pam_ldap.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok
shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     requisite     /lib/security/$ISA/pam_mkhomedir.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so

I have methodically tested various scenarios and at this point believe
pam_unix is, one way or another, querying LDAP during it's
pam_sm_authenticate routine. But I have yet to either prove or disprove that
theory. I have the latest (RHEL 3.0) pam-0.75-69 rpm on the machine.

-- 
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20061016/eacb1001/attachment.htm>