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.
1 0.000000000 192.168.99.200 → 10.10.10.10 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 10.10.10.10 → 192.168.99.200 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 192.168.99.200 → 10.10.10.10 TCP 66 44780 → 3269 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2891116194 TSecr=705129002 4 0.001363208 192.168.99.200 → 10.10.10.10 TCP 66 44780 → 3269 [FIN, ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2891116194 TSecr=705129002 5 0.002264141 10.10.10.10 → 192.168.99.200 TCP 66 3269 → 44780 [ACK] Seq=1 Ack=2 Win=263424 Len=0 TSval=705129003 TSecr=2891116194 6 0.002470589 10.10.10.10 → 192.168.99.200 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
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 dn:: LOTSOFMIME sAMAccountName: ausername $
- 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.