Skip to content

Logon Timeout Due to Slow Domain Controller

Jump to bottom
Malcolm Stewart edited this page Jun 25, 2021 · 3 revisions

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.

Clone this wiki locally