Introduction
This document describes the NT LAN Manager (NTLM) authentication at the packet level.
What should NTLM authentication look like at the packet level?
A packet capture to follow this article can be downloaded here: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
Client IP: 10.122.142.190
WSA IP: 10.122.144.182
Packet Number and Details
#4 The client sends a GET request to the proxy.
#7 The proxy sends back a 407. This means that the proxy does not allow traffic due to a lack of proper authentication. If you look at the HTTP headers in this response, you will see a "Proxy-authenticate: NTLM". This tells the client that an acceptable method of authentication is NTLM. Likewise, if the header "Proxy-authenticate: Basic" is present, the proxy tells the client that basic credentials are acceptable. If both headers are present (common), the client decides which method of authentication it will use.
One thing to note is that the authentication header is "Proxy-authenticate:". This is because the connection in capture uses explicit forward proxy. If this were a transparent proxy deployment, the response code would be 401 instead of 407 and the headers would be "www-authenticate:" instead of "proxy-authenticate:".
#8 The proxy FINs this TCP socket. This is correct and normal.
#15 On a new TCP socket the client performs another GET request. This time notice that the GET contains the HTTP header "proxy-authorization:". This contains an encoded string that contains details regarding the User / Domain.
If you expand the Proxy-authorization > NTLMSSP, you will see the decoded information sent in the NTLM data. In the "NTLM Message Type", you will notice that it is "NTLMSSP_NEGOTIATE". This is the first step in the three-way NTLM handshake.
#17 The proxy responds with another 407. Another "proxy-authenticate" header is present. This time it contains an NTLM challenge string. If you expand it further, you will see the NTLM Message Type is "NTLMSSP_CHALLENGE". This is the second step in the three-way NTLM handshake.
In NTLM authentication, the Windows domain controller sends a challenge string to the client. The client then applies an algorithm to the NTLM challenge which factors in the user's password in the process. This allows the domain controller to verify that the client knows the correct password without ever sending the password across the line. This is much more secure than basic credentials, in which the password is sent in plain text for all sniffing devices to see.
#18 The client sends a final GET. Note that this GET is on the SAME TCP socket as that the NTLM Negotiate and NTLM Challenge occurred on. This is vital to the NTLM process. The entire handshake must occur on the SAME TCP socket, otherwise authentication will be invalid.
In this request the client sends the modified NTLM Challenge (NTLM Response) to the proxy. This is the final step in the three-way NTLM handshake.
#21 The proxy sends back an HTTP response. This means that the proxy accepted the credentials and has decided to serve up the content.
Feedback