go to  ForumEasy.com   
Home » Archive » Message

[Email To Friend][View in Live Context][prev topic « prev post | next post » next topic]
  A Example of The NTLM Type 3 Message
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:


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:


    --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.



    Powered by ForumEasy © 2002-2012, All Rights Reserved. | Privacy Policy | Terms of Use
    Get your own forum today. It's easy and free.