A linux server of mine is trying to establish a LDAPS connection to a global catalog server and the connection is getting dropped (presumably by the GC side).
For the purpose of discussion, let’s say that 220.127.116.11 is the Linux server and 18.104.22.168 is the global catalog server.
If I try to use
telnet from the Linux box, I see:
[[email protected] ~]# telnet gcfoo.exampleAD.local 3269 Trying 22.214.171.124... Connected to gcfoo.examplead.local. Escape character is '^]'. Connection closed by foreign host.
There’s no delay between the 4th and 5th lines. It just immediately drops the connection.
I thought that
telnet results might be a little misleading (since it’s not actually appropriate for any type of secure communication) so I collected a packet capture of the actual connection attempt from the appliance (using the actual program requiring LDAPS).
Here’s what I see (again, IPs and source ports have been renamed to protect the innocent):
No. Time Source Destination Protocol Length Info 1 0.000000 126.96.36.199 188.8.131.52 TCP 66 27246 > msft-gc-ssl [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SAC_PERM=1 WS=128 2 0.000162 184.108.40.206 220.127.116.11 TCP 62 msft-gc-ssl > 27246 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1 3 0.000209 18.104.22.168 22.214.171.124 TCP 54 27246 > msft-gc-ssl [ACK] Seq=1 Ack=1 Win=5840 Len=0 4 0.003462 126.96.36.199 188.8.131.52 TCP 248 27246 > msft-gc-ssl [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=194 5 0.007264 184.108.40.206 220.127.116.11 TCP 60 msft-gc-ssl > 27246 [RST] Seq=1 Win=64046 Len=0
I’m a bit rusty with TCP/IP so please forgive my ignorance… I see the three-way handshake taking place in packets 1-3. That makes sense. What’s going on in packet #4 though? What does
[PSH, ACK] mean? This seems like a redundant acknowledgement that’s unnecessary. Is actual data being sent in this 4th packet? Or is this some weird continuation of the handshake?