LDAPS Problem: Can’t contact LDAP server (-1)

LDAP authentication problem in the customer environment:

$ ldapsearch -LLL -H ldaps://the.domain:3269 -D "CN=ldapuser,OU=org,DC=the,DC=domain" -W -b "DC=the,DC=domain" "(sAMAccountName=ausername)" sAMAccountName
Enter LDAP Password: xxx
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

The error message was received right after entering the password.

Tshark says:

    1 0.000000000 →  TCP 74 44780 → 3269 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2891116193 TSecr=0 WS=128
    2 0.001225814 → TCP 74 3269 → 44780 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=705129002 TSecr=2891116193
    3 0.001239847 →  TCP 66 44780 → 3269 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2891116194 TSecr=705129002
    4 0.001363208 →  TCP 66 44780 → 3269 [FIN, ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2891116194 TSecr=705129002
    5 0.002264141 → TCP 66 3269 → 44780 [ACK] Seq=1 Ack=2 Win=263424 Len=0 TSval=705129003 TSecr=2891116194
    6 0.002470589 → TCP 60 3269 → 44780 [RST, ACK] Seq=1 Ack=2 Win=0 Len=0

So the TCP three-way handshake was completed (= TCP connection was successful), no data was transferred, but the client decided to FIN the connection right away without waiting, asking or receiving anything from the server.

In this light, in my opinion, “Can’t contact LDAP server” is a highly exaggerated statement.

Anyway, it’s not a password problem, because no password was ever attempted against the server (again, no data was transferred). It cannot be an LDAP query syntax problem either. Neither can it be the recent LDAP signing requirement changes in Windows server. Clearly there is some client-side application-level issue.

I checked my memos about LDAP configurations. Because of something I saw there, I checked the client-side /etc/ldap/ldap.conf, which said:

TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
TLS_CACERT      /home/admin/ldaps.crt
TLS_REQCERT     allow

Strange: two TLS_CACERT configurations. And there is no ldaps.crt in that directory anymore (because of recent things).

I removed the second (leftover) TLS_CACERT configuration, and then there was great success:

$ ldapsearch -LLL -H ldaps://the.domain:3269 -D "CN=ldapuser,OU=org,DC=the,DC=domain" -W -b "DC=the,DC=domain" "(sAMAccountName=ausername)" sAMAccountName
Enter LDAP Password: xxx
sAMAccountName: ausername

Some takeaways:

  • Packets don’t lie (but the application-level error messages could)
  • The questions “when did it last work” and “what was changed recently or just before the errors were experienced” are still relevant.

Leave a Reply