March 25, 2011, 4:07 p.m.
posted by whitehat
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
[[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
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
Possible stunnel Errors in Fedora Core 2
You may get a cryptonet error when starting stunnel:
Unable to open "/dev/cryptonet"
[[email protected] tmp]# rpm -e hwcrypto