xinetd app LDAP errors when LDAP server is down for non-LDAP user

[James Smallacombe]

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!