Scope of HowTo:
LDAP has to wind through various gears and all have to turn correctly or connections break. This HowTo will help you troubleshoot LDAP errors. This HowTo is known to work with CentOS/RHEL 6.4 with OpenLDAP 2.4
LDAP and Queries
If the LDAP server can’t be directly queried, then there’s no point at looking at other parts of the system until we’ve validated first the gears turns correctly here.
Query the LDAP server on both the loopback interface and the interface everything else is trying to speak to the LDAP server:
ldapsearch -h 127.0.0.1 -x -LLL -b 'ou=Users,dc=f1linux,dc=com' -s sub -W -D 'cn=Manager,dc=f1linux,dc=com' 'uid=someUser'
ldapsearch -h 10.10.5.3 -x -LLL -b 'ou=Users,dc=f1linux,dc=com' -s sub -W -D 'cn=Manager,dc=f1linux,dc=com' 'uid=someUser'
Use the OpenSSL client to test connectivity:
openssl s_client -connect someHost.yourCompany.com:636 -tls1
The solution to TLS errors (other than to fix them if they’re even correctible) is to add the following to the [PAM] section of /etc/sssd/sssd.conf:
[PAM] ldap_tls_reqcert = never
And restart the sssd daemon:
service sssd restart
The following link is also quite instructive:
SSSD LDAP Connectivity Errors
Calls for authentication wind through the sss LDAP interface.
if you run either:
getent passwd|grep someUserName
or better still, query the sssd daemon directly- NOTE That it’s sss and NOT sssd:
getent passwd -s sss someUser
And if nothing comes back from the LDAP query, only one of (2) possibilities exist:
Case 1: Authentication Calls *NOT* winding Through sss LDAP interface:
tail -fn 20 /var/log/secure
Nov 11 19:56:12 someHost login: pam_unix(login:auth): check pass; user unknown Nov 11 19:56:12 someHost login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= Nov 11 19:56:12 someHost login: pam_succeed_if(login:auth): error retrieving information about user Nov 11 19:56:14 someHost login: FAILED LOGIN 1 FROM (null) FOR , User not known to the underlying authentication module
If the LDAP queries are NOT winding through the sss LDAP interface (case 1), check the following:
Validate the sources of authentication are being consulted by the system are the ones you believe are, in fact, being consulted.
Verify sssd is up and running
service sssd status
/etc/sssd/sssd.conf has (correct) domain information in the [PAM] section and that [SSSD] section specifies “pam” as a source.
Check for a TLS/SSL issue: flip the value of tls in the [PAM] section of /etc/sssd/sssd.conf:
# ldap_id_use_start_tls = True ldap_id_use_start_tls = False
/etc/nsswitch.conf specifies sss as authentication sources for passwd, shadow and
Check PAM Configuration: /etc/pam.d/system-auth that the PAM specifies sss as a source of authentication
Check firewall rules on both the LDAP client and the LDAP server.
Check that the port number is specified correctly: either 389 or 636 for ldaps://
Case 2: Authentication *IS* winding Through sss LDAP Interface:
If errors such as the following are received, it means that authentication is hitting sssd, so it is broken either in where sssd points the query, or the configuration of sssd itself;
tail -fn 20 /var/log/secure Nov 12 19:53:03 someHost sshd: pam_sss(sshd:auth): received for user houlahanterrence: 9 (Authentication service cannot retrieve authentication info)
Therefore you need to determine which gear is broken: sssd or PAM.
Test sssd: If the following returns a correct result, then BOTH the LDAP and sss configurations have been proven.
getent passwd -s sss someUser someUser:*:1162:1162:Some User:/home/someUser:/bin/bash
Test a local (non-ssh) Login: If a local login (not via ssh) works, then the PAM configuration is also proven. If it doesn’t, then your PAM setup is probably duff somewhere.
That only leaves a few places to look:
=> ssh parameters are incorrect somewhere. => Duff connection parameters in /etc/openldap/ldap.conf can also result in the above error message. Do a diff on a working copy of this file from another host if possible and the cause will likely present immediately.
Non-SSSD LDAP Connectivity Errors
LDAP tools rely on the configuration information in /etc/openldap/ldap.conf. Run the following LDAP query:
ldapsearch -x -LLL -b 'ou=Users,dc=f1linux,dc=com' -s sub -W -D 'cn=Manager,dc=f1linux,dc=com' 'uid=someUser'
If it returns a result, then the LDAP server can be both found and queried; nothing is broken here.
If the LDAP query fails with the following error after you enter the password:
ldap_result: Can't contact LDAP server (-1)
Then something is duff in /etc/openldap/ldap.conf:
=> Verify the URI is correct. If ldaps:// connectivity is required, authconfig merely specifies just insecure ldap:// as the "URI." => Verify all the other parameters are correct in this file. Assuming the system is correct and there's no firewall of networking issues, problem is likely to be found in /etc/openldap/ldap.conf
Hopefully this HowTo got you out of your LDAP hell. Any errors, omissions or suggested improvements to this document, please advise-