<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>