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.