We're having a pretty severe issue of a server/client app that is running out of xinetd generating nss_ldap errors when the primary LDAP server is down. The thing is, the user that this application (nagios nrpe) runs as exists in every host's /etc/passwd (and group) file and NOT in the Directory Server, just for this reason. I am wondering if this is a pam issue, but I admit I do not know to what extent that service users consult pam. Here is the error: Aug 2 12:03:18 host01 xinetd[32012]: nss_ldap: failed to bind to LDAP server ldap://ldap_1.domain/: Can't contact LDAP server Aug 2 12:03:18 host01 xinetd[32012]: nss_ldap: reconnected to LDAP server ldap://ldap_2.domain/ Aug 2 12:03:18 host01 nrpe[32012]: Error: Could not complete SSL handshake.5 Again /etc/xinetd.d/nrpe is configured to run this client as a user that exists in local auth, not LDAP. Why would it need to contact the LDAP server at all? We do not use LDAP for name resolution, that is all done in DNS and /etc/resolv.conf. We ONLY use it for user authentication. We used authconfig to set this up on the clients. I am wondering if the PAM stack in /etc/pam.d/system-auth, which gets modified by authconfig for LDAP has anything to do with it. The one thing that caught my eye was this: account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so The UID of the daemon user is ABOVE 500. Would changing it to one below 500 fix the problem? Thanks in advance!