<span class="gmail_quote"></span>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. <br>
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. <br>
<br>
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)<br>
NSS
Queried
Successful | Comments<br>
LDAP LDAP
? Login?
|<br>-----------------------------------------------------------------------------|--------------------<br>root
login No
No
Yes
| pam_unix indirectly
querying ldap via nss?<br>ldap login
No
Yes
No
| "illegal user" without nss.<br>root
login Yes
Yes
No
| queries ldap before giving prompt; ssh timeout.<br>ldap
login
Yes Yes
Yes
|
obvious. (only with correct servers in ldap.conf, ofcourse)<br>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. <br>
<br>
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.<br>
<br>
Here is what my /etc/pam.d/system-auth file looks like:<br>
#%PAM-1.0<br>
# This file is auto-generated.<br>
# User changes will be destroyed the next time authconfig is run.<br>
auth required /lib/security/$ISA/pam_env.so debug<br>
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok audit<br>
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass debug<br>
auth required /lib/security/$ISA/pam_deny.so debug<br>
<br>
account required /lib/security/$ISA/pam_unix.so debug<br>
account sufficient /lib/security/$ISA/pam_localuser.so<br>
account required /lib/security/$ISA/pam_ldap.so<br>
<br>
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=<br>
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok shadow<br>
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok<br>
password required /lib/security/$ISA/pam_deny.so<br>
<br>
session requisite /lib/security/$ISA/pam_mkhomedir.so<br>
session required /lib/security/$ISA/pam_limits.so<br>
session required /lib/security/$ISA/pam_unix.so<br>
session optional /lib/security/$ISA/pam_ldap.so<br>
<br>
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. <br>
<br>-- <br>Thanks,<br><span class="sg">Jon</span><br>