HowTo: Troubleshoot LDAP Errors

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'

TLS Errors:

Troubleshooting TLS:

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:

http://www.linuxquestions.org/questions/linux-enterprise-47/rhel-6-ldap-now-requires-tls-843917/

 

SSSD LDAP Connectivity Errors

Calls for authentication wind through the sss LDAP interface.

if you run either:

id someUserName

or:

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.

"authconfig --test"

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 passwdshadow 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[4984]: 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 PAM:

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

Conclusion:

Hopefully this HowTo got you out of your LDAP hell.  Any errors, omissions or suggested improvements to this document, please advise-

-Terrence


Posted in LDAP Tagged with: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Categories

Recent Comments

    Archives