[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

local accounts unavailable during ldap issue



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]