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 is the Linux server and is the global catalog server.

If I try to use telnet from the Linux box, I see:

[[email protected] ~]# telnet gcfoo.exampleAD.local 3269
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          TCP         66        27246 > msft-gc-ssl [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SAC_PERM=1 WS=128
2       0.000162          TCP         62        msft-gc-ssl > 27246 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1
3       0.000209          TCP         54        27246 > msft-gc-ssl [ACK] Seq=1 Ack=1 Win=5840 Len=0
4       0.003462          TCP         248       27246 > msft-gc-ssl [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=194
5       0.007264          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?

Leave a Reply

Your email address will not be published. Required fields are marked *