Subject: A Example of The NTLM Type 3 Message
Author: authen
In response to: The NTLM Type 3 Message
Posted on: 06/06/2006 03:19:19 AM
A sample of a Type 3 Message:
0x4e544c4d5353500003000000180018006a00000018001800
820000000c000c0040000000080008004c00000016001600
54000000000000009a0000000102000044004f004d004100
49004e00750073006500720057004f0052004b0053005400
4100540049004f004e00c337cd5cbd44fc9782a667af6d42
7c6de67c20c2d3e77c5625a98c1c31e81847466b29b2df46
80f39958fb8c213a9cc6
This message is decomposed as:
0 0x4e544c4d53535000
--NTLMSSP Signature
8 0x03000000
--Type 3 Indicator
12 0x180018006a000000
-LM Response Security Buffer:
--Length: 24 bytes (0x1800)
--Allocated Space: 24 bytes (0x1800)
--Offset: 106 bytes (0x6a000000)
20 0x1800180082000000
-NTLM Response Security Buffer:
--Length: 24 bytes (0x1800)
--Allocated Space: 24 bytes (0x1800)
--Offset: 130 bytes (0x82000000)
28 0x0c000c0040000000
-Domain Name Security Buffer:
--Length: 12 bytes (0x0c00)
--Allocated Space: 12 bytes (0x0c00)
--Offset: 64 bytes (0x40000000)
36 0x080008004c000000
-User Name Security Buffer:
--Length: 8 bytes (0x0800)
--Allocated Space: 8 bytes (0x0800)
--Offset: 76 bytes (0x4c000000)
44 0x1600160054000000
-Workstation Name Security Buffer:
--Length: 22 bytes (0x1600)
--Allocated Space: 22 bytes (0x1600)
--Offset: 84 bytes (0x54000000)
52 0x000000009a000000
-Session Key Security Buffer:
--Length: 0 bytes (0x0000)
--Allocated Space: 0 bytes (0x0000)
--Offset: 154 bytes (0x9a000000)
60 0x01020000 Flags:
--Negotiate Unicode (0x00000001)
--Negotiate NTLM (0x00000200)
64 0x44004f004d00410049004e00
-Domain Name Data ("DOMAIN")
76 0x7500730065007200
-User Name Data ("user")
84 0x57004f0052004b00530054004100540049004f004e00
-Workstation Name Data ("WORKSTATION")
106 0xc337cd5cbd44fc9782a667af6d427c6de67c20c2d3e77c56
-LM Response Data
130 0x25a98c1c31e81847466b29b2df4680f39958fb8c213a9cc6
-NTLM Response Data
This message reveals:
This is an NTLM Type 3 message (from the NTLMSSP Signature and Type 3 Indicator).
The client has indicated that strings are encoded using Unicode (the Negotiate Unicode flag is set).
The client supports NTLM authentication (Negotiate NTLM).
The client's domain is "DOMAIN".
The client's username is "user".
The client's workstation is "WORKSTATION".
The client's LM response is "0xc337cd5cbd44fc9782a667af6d427c6de67c20c2d3e77c56".
The client's NTLM response is "0x25a98c1c31e81847466b29b2df4680f39958fb8c213a9cc6".
An empty session key has been sent.
Upon receipt of the Type 3 message, the server calculates the LM and NTLM responses and compares them to the values provided by the client; if they match, the user is successfully authenticated.
>
> On 06/06/2006 03:02:52 AM authen wrote:
Structure:
--0- NTLMSSP Signature -- Null-terminated ASCII "NTLMSSP" (0x4e544c4d53535000)
--8- NTLM Message Type -- long (0x03000000)
-12- LM/LMv2 Response -- security buffer
-20- NTLM/NTLMv2 Response -- security buffer
-28- Domain Name -- security buffer
-36- User Name -- security buffer
-44- Workstation Name -- security buffer
(52) Session Key (optional) -- security buffer
(60) Flags (optional) -- long
-52 (64) start of data block
The Type 3 message is the final step in authentication. This message contains the client's responses to the Type 2 challenge, which demonstrate that the client has knowledge of the account password without sending the password directly. The Type 3 message also indicates the domain and username of the authenticating account, as well as the client workstation name.
Typically, the Type 3 message details one or more of the following:
1. The LM/LMv2 response -- reply created from the user's password in response to the Type 2 challenge.
2. The NTLM/NTLMv2 response -- NT based reply created from the user's password in response to the Type 2 challenge.
3. The domain name -- the authentication realm in which the authenticating account has membership. This is either Unicode or OEM, depending on the negotiated encoding.
4. The user name -- the authenticating account name. This is either Unicode or OEM, depending on the negotiated encoding.
5. The workstation name -- the client workstation's name. This is either Unicode or OEM, depending on the negotiated encoding.
6. The session key -- is often empty when included; it is apparently relevant in newer signing and sealing mechanisms. The Open Group documentation states that it additionally plays a role in datagram-style authentication.
7. The flags
When "Negotiate Local Call" has been established in the Type 2 message, the security buffers in the Type 3 message are typically all empty (zero length). The client "adopts" the SSPI context sent in the Type 2 message, effectively circumventing the need to calculate an appropriate response.
It should be noted that the flags in the Type 3 message are optional; older clients include neither the session key nor the flags in the message. In this case, the data block begins at offset 52, immediately following the workstation name security buffer. It has been determined experimentally that the Type 3 flags (when included) do not carry any additional semantics in connection-oriented authentication; they do not appear to have any discernable effect on either authentication or the establishment of session security. Clients sending flags typically mirror the established Type 2 settings fairly closely. It is possible that the flags are sent as a "reminder" of established options, to allow the server to avoid caching the negotiated settings. The Type 3 flags are relevant during datagram-style authentication, however.
References:
