Logon Timeout Due to Slow Domain Controller - microsoft/CSS_SQL_Networking_Tools GitHub Wiki

Logon Timeout Due to Slow Domain Controller

This trace shows a logon timeout for a Windows Integrated login using NTLM credentials. After the NTLM Challenge and Response packets, the SQL Server must validate the login credentials with a domain controller. A delay in this communication can lead to a login timeout.

Frame Time Offset Source IP   Dest IP     Description
----- ----------- ----------- ----------- ---------------------------------------------------------------------------------------------------
--- Opening a new connection
  390  24.9189885 10.10.10.55 10.10.10.44 TCP:Flags=......S., SrcPort=55419, DstPort=1433, PayloadLen=0, Seq=1712313520, Ack=0, Win=8192 ( Ne
  393  24.9193855 10.10.10.44 10.10.10.55 TCP:Flags=...A..S., SrcPort=1433, DstPort=55419, PayloadLen=0, Seq=2598736647, Ack=1712313521, Win=
  394  24.9195788 10.10.10.55 10.10.10.44 TCP:Flags=...A...., SrcPort=55419, DstPort=1433, PayloadLen=0, Seq=1712313521, Ack=2598736648, Win=
  395  24.9201155 10.10.10.55 10.10.10.44 TDS:Prelogin, Version = 7.300000(No version information available, using the default version), SPID
  396  24.9202518 10.10.10.44 10.10.10.55 TDS:Response, Version = 7.300000(No version information available, using the default version), SPID
  397  24.9207371 10.10.10.55 10.10.10.44 TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:37, SSLVersionSelector:36, TDS:35, TCP:34, IPv4:3
  398  24.9210500 10.10.10.44 10.10.10.55 TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done. {TLS:37, SSLVersionSel
  399  24.9215741 10.10.10.55 10.10.10.44 TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec La
  400  24.9225477 10.10.10.44 10.10.10.55 TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TL
  401  24.9290055 10.10.10.55 10.10.10.44 TLS:TLS Rec Layer-1 SSL Application Data {TLS:37, SSLVersionSelector:36, TDS:35, TCP:34, IPv4:33}

--- NTLM Challenge and response packets provide the user domain credentials to the server
  402  24.9293100 10.10.10.44 10.10.10.55  NLMP:NTLM CHALLENGE MESSAGE {TDS:35, TCP:34, IPv4:33}
  403  24.9302185 10.10.10.55 10.10.10.44  NLMP:NTLM AUTHENTICATE MESSAGEVersion:v2, Domain: CONTOSO, User: joe133, Workstation: JOEWKS

--- Normally, the server would respond with a TDS:Response packet validating the login, but it's taking some time,
--- so the Kernel (TCP.SYS) sends an ACK packet as a placeholder
  410  25.1296946 10.10.10.44 10.10.10.55 TCP:Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=0, Seq=2598737640, Ack=1712314859, Win=

--- 13 seconds later, the client decides the connection was taking too long and initiates the closing sequence
--- and the server ACKs this
  599  38.9303524 10.10.10.55 10.10.10.44 TCP:Flags=...A...F, SrcPort=55419, DstPort=1433, PayloadLen=0, Seq=1712314859, Ack=2598737640, Win=
  600  38.9303952 10.10.10.44 10.10.10.55 TCP:Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=0, Seq=2598737640, Ack=1712314860, Win=

--- The server is still busy and does not send it's half of the closing handshake.
--- Instead, after 30 seconds, we perform a Keep-Alive exchange
 1106  68.9230117 10.10.10.55 10.10.10.44 TCP:[Segment Lost]Flags=...A...., SrcPort=55419, DstPort=1433, PayloadLen=1, Seq=1712314859 - 17123
 1107  68.9230578 10.10.10.44 10.10.10.55 TCP:[Dup Ack #600]Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=0, Seq=2598737640, Ack=17
 1108  68.9369020 10.10.10.44 10.10.10.55 TCP:[Segment Lost]Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=1, Seq=2598737639 - 25987
 1109  68.9370822 10.10.10.55 10.10.10.44 TCP:Flags=...A...., SrcPort=55419, DstPort=1433, PayloadLen=0, Seq=1712314860, Ack=2598737640, Win=

--- Another 30 seconds, another Keep-Alive exchange
 1751  98.9299527 10.10.10.55 10.10.10.44 TCP:[ReTransmit #1106]Flags=...A...., SrcPort=55419, DstPort=1433, PayloadLen=1, Seq=1712314859 - 1
 1752  98.9300005 10.10.10.44 10.10.10.55 TCP:[Dup Ack #600]Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=0, Seq=2598737640, Ack=17
 1753  98.9409402 10.10.10.44 10.10.10.55 TCP:[ReTransmit #1108]Flags=...A...., SrcPort=1433, DstPort=55419, PayloadLen=1, Seq=2598737639 - 2
 1754  98.9411201 10.10.10.55 10.10.10.44 TCP:[Dup Ack #1109]Flags=...A...., SrcPort=55419, DstPort=1433, PayloadLen=0, Seq=1712314860, Ack=2

Note: Even though the parser does not recognize the Keep-Alive exchange, you can tell by the 30-second interval. The Keep-Alive packets have a Payload length of 1 byte and the Keep-Alive ACK packets have a payload length of 0 bytes.

Unfortunately the network trace terminated before the conversation was totally completed, but eventually, the SQL Server would have responded with a TDS:Response for the login and then it's side of the closing sequence. The client would have sent one or more RESET packets to close down any further communication.