Guest

Cisco Web Security Appliance

What should NTLM authentication look like at the packet level?

Document ID: 117931

Updated: Jul 14, 2014

Contributed by Josh Wolfer and Jeff Richmond, Cisco TAC Engineers.
 

   Print

Question:

What should NTLM authentication look like at the packet level?

ip.addr==165.2.2.129.158 client
ip.addr==165.202.2.150 WSA>
 

Packet number / Details:

#4 The client sends a GET request to the proxy

#6 The proxy sends back a 407. This means that the proxy is not allowing the 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" were present, the proxy would be telling the client that basic credentials are acceptable. If both headers are present (common), the client will decide 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 is using 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 3 way NTLM handshake.

#17 The proxy responds with another 407. Another "proxy-authenticate" header is present. This time containing 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 3 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 factoring in the users 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 then 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 3 way NTLM handshake.
#20 The proxy sends back an HTTP response. This means that the proxy accepted the credentials and has decided to serve up the content.

Updated: Jul 14, 2014
Document ID: 117931