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.

 
> 
> On 06/06/2006 02:49:13 AM authen wrote:

    0x4e544c4d53535000020000000c000c003000000001028100
    0123456789abcdef0000000000000000620062003c000000
    44004f004d00410049004e0002000c0044004f004d004100
    49004e0001000c0053004500520056004500520004001400
    64006f006d00610069006e002e0063006f006d0003002200
    7300650072007600650072002e0064006f006d0061006900
    6e002e0063006f006d0000000000

• Next Post: A Example of The NTLM Type 3 Message   authen  06/06/2006 03:19:19 AM
• Previous Post: A Example of The NTLM Type 2 Message  authen  06/06/2006 02:49:13 AM
• Next Topic: NTLM HTTP Authentication  authen  06/08/2006 01:14:44 AM
• Previous Topic: Forwardable Ticket vs Proxiable Ticket  Alex_Raj  05/20/2006 03:38:33 PM
• Index: by Date
• Index: by Topic