Before diving into authentication issues, let's verify basic LDAP connectivity from the client:

ldapsearch -x -H ldap://your.ldap.server -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -W

This basic query should return your LDAP directory structure. If it fails, you have a network or basic configuration issue.

Verify your client's LDAP configuration files on CentOS 6.3:

# Check nsswitch.conf
cat /etc/nsswitch.conf | grep passwd

# Check PAM configuration
cat /etc/pam.d/system-auth

# Check LDAP client config
cat /etc/openldap/ldap.conf

On your OpenLDAP server (CentOS 5.5), enable verbose logging:

# Edit slapd.conf
loglevel 256

# Restart slapd
service ldap restart

# Monitor logs in real-time
tail -f /var/log/slapd.log

Use these commands to test authentication specifically:

# Simple bind test
ldapwhoami -x -H ldap://your.ldap.server -D "uid=testuser,ou=people,dc=example,dc=com" -W

# SASL bind test
ldapwhoami -x -H ldap://your.ldap.server -D "uid=testuser,ou=people,dc=example,dc=com" -W -ZZ

Ensure network connectivity and proper ports are open:

# Test basic connectivity
telnet your.ldap.server 389

# Check firewall rules
iptables -L -n | grep 389

# Verify DNS resolution
nslookup your.ldap.server

SELinux often interferes with LDAP authentication:

# Check current status
getenforce

# Temporarily disable for testing
setenforce 0

# Check audit logs for denials
cat /var/log/audit/audit.log | grep AVC

For stubborn cases, use packet capture:

# On the client
tcpdump -i eth0 port 389 -w ldap-traffic.pcap

# After reproducing the issue, analyze with:
wireshark ldap-traffic.pcap

Watch for these frequent issues:

# 1. Base DN mismatch between client and server
# 2. Incorrect TLS/SSL settings
# 3. Time synchronization issues (Kerberos)
# 4. PAM module order in system-auth
# 5. Missing schema definitions

---

When troubleshooting LDAP authentication failures, start with basic network connectivity tests:

telnet ldap-server-ip 389
# Or for secure LDAP:
telnet ldap-server-ip 636

If these fail, you're dealing with network-level issues before even reaching LDAP. For proper LDAP testing, install these tools:

yum install openldap-clients nss-pam-ldapd

Use ldapsearch to verify basic connectivity and query capability:

ldapsearch -x -H ldap://your.ldap.server -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -W "(objectClass=*)"

Breakdown of parameters:

• -x: Simple authentication
• -H: LDAP server URI
• -b: Base DN for search
• -D: Bind DN
• -W: Prompt for password

Enable verbose logging on your OpenLDAP server (slapd):

# In /etc/openldap/slapd.conf
loglevel 256

# Or for newer versions in /etc/openldap/slapd.d/
olcLogLevel: 256

Then restart slapd and monitor logs:

service slapd restart
tail -f /var/log/slapd.log

Check your PAM and NSS configuration files:

# Verify /etc/ldap.conf or /etc/openldap/ldap.conf
# Check /etc/nsswitch.conf for ldap entries
# Review /etc/pam.d/system-auth

Example working configuration snippet:

# /etc/ldap.conf
base dc=example,dc=com
uri ldap://ldap.example.com/
ldap_version 3
pam_password exop
ssl no
nss_base_passwd ou=People,dc=example,dc=com?one
nss_base_shadow ou=People,dc=example,dc=com?one

Verify that user information can be retrieved:

getent passwd ldapusername

If this returns the user's LDAP entry, your basic NSS configuration is working.

When all else fails, trace system calls during authentication attempt:

strace -f -o /tmp/auth.debug /bin/login

Look for failed connection attempts or permission errors in the output.

For LDAPS connections, verify certificates:

openssl s_client -connect ldapserver:636 -showcerts

Check if the client has the CA certificate properly installed in /etc/openldap/cacerts/