Troubleshooting LDAP Logins





Troubleshooting LDAP Logins

You can never be certain about the functioning of any application unless you test it. LDAP is fairly complicated to install and should be as thoroughly tested as possible before you deploy it. Here are some steps you can take to help you sleep better at night.

Test Using ldapsearch

Always run the ldapsearch command on both the LDAP client and server to test your LDAP configuration:

[[email protected] tmp]# ldapsearch -x -b 'dc=example,dc=com' \
      '(objectclass=*)'

When LDAP is configured correctly, the command sends a full database listing to your screen.

Use SSH or the Linux Console

Try to log in as user ldapuser to the LDAP client Linux system as an alternative test. If it fails, try restarting SSH on the LDAP client so that the /etc/nsswitch.conf file can be reread with the new LDAP information. This step is not required in all versions of Linux.

Use the tcpdump Command

If the LDAP configuration files appear correct and LDAP still doesn't work, then you should try using the tcpdump command, outlined in Chapter 4, "Simple Network Troubleshooting," to see whether your systems can correctly communicate with one another. A failure to communicate could be due to poor routing, misconfigured firewalls along the way, or possibly LDAP being turned off on the server.

Test Secure LDAP

On the LDAP server, use the tcpdump command to listen for traffic on the secure LDAP port 636 or ldaps. Run the ldapsearch command on the LDAP client and if everything is configured correctly, you should see packet flows such as this one:

     [[email protected] tmp]# tcpdump -n tcp port ldaps
     tcpdump: listening on eth0
     09:20:02.281257 192.168.1.102.1345 > 192.168.1.100.ldaps: S
     1665037104:1665037104(0) win 5840 <mss 1460,sackOK,timestamp 74401362
     0,nop,wscale 0> (DF)
     09:20:02.281356 192.168.1.100.ldaps > 192.168.1.102.1345: S
     1911175072:1911175072(0) ack 1665037105 win 5792 <mss
     1460,sackOK,timestamp 20737195 74401362,nop,wscale 0> (DF)
     ...
     ...
     [[email protected] tmp]#

Test Regular LDAP

On the LDAP server, use the tcpdump command to listen for traffic on the regular LDAP port 389 or ldap. Run the ldapsearch command on the LDAP client:

     [[email protected] tmp]# tcpdump -n tcp port ldap

If everything is configured correctly, you should see LDAP packet flows similar to those in the last section.

Test Basic Connectivity

The very first step is to use TELNET to determine whether your LDAP server is accessible on TCP port 389 (LDAP) or 636 (LDAPS).

Lack of connectivity could be caused by a firewall in the path between the LDAP server and client or there could be firewall software running on the servers themselves.

Other sources of failure include LDAP not being started at all, the server could be down, or there could be a network related failure.

Troubleshooting with Telnet is covered in Chapter 4.

LDAP Works But Is Not Using LDAPS

An LDAPS configuration will default to using regular LDAP if there is an error with the SSL keys. This is usually caused by incorrect permissions and ownerships on the key file.

stunnel Doesn't Appear to Work

Changes to the stunnel.conf file take effect only after stunnel has been restarted. Unfortunately, there is no stunnel script in the /etc/init.d directory to do this. You have to use the pkill command to stop it and the stunnel command to start it again:

     [[email protected] tmp]# pkill stunnel ; stunnel
     [[email protected] tmp]#

LDAP bind Errors

The LDAP bind utility is used for each login and can give failure errors that are usually not very descriptive. Two of the main ones that usually occur when running the ldapadd command are:

  • Can't contact LDAP server (81): This is usually caused by not configuring the correct IP address in the LDAP client's ldap.conf file.

  • Invalid credentials (49): This is usually caused by incorrect dc[eq] statements in the configuration files or in commands used.

Possible stunnel Errors in Fedora Core 2

You may get a cryptonet error when starting stunnel:

     Unable to open "/dev/cryptonet"

This is caused by an incompatibility with the hwcrypto RPM used for hardware-, not software-based encryption. You need to uninstall hwcrypto to get stunnel to work correctly:

     [[email protected] tmp]# rpm -e hwcrypto


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows