| |
Minimium of The NTLM Type 2 Message |
|
|
Subject: Minimium of The NTLM Type 2 Message
Author: authen
In response to: The NTLM Type 2 Message
Posted on: 06/06/2006 02:47:14 AM
The context and target information may be omitted, in which case the data block begins at offset 32 (immediately following the challenge). A minimal Type 2 message would look something like this:
0x4e544c4d53535000020000000000000000000000020200000123456789abcdef
This message contains only: the NTLMSSP signature, 0x4e544c4d53535000
the NTLM message type, 0x02000000
an empty target name, 0x0000000000000000
minimal flags, 02020000 (Negotiate NTLM and Negotiate OEM), and
the challenge, 0x0123456789abcdef
>
> On 06/06/2006 02:40:43 AM authen wrote:
Structure:
--0-- NTLMSSP Signature -- Null-terminated ASCII "NTLMSSP" (0x4e544c4d53535000)
--8-- NTLM Message Type -- long (0x02000000)
-12-- Target Name -- security buffer
-20-- Flags -- long
-24-- Challenge -- 8 bytes
(32) Context (optional) -- 8 bytes (two consecutive longs)
(40) Target Information (optional) -- security buffer
32 (48) start of data block
The Type 2 message is sent by the server to the client in response to the client's Type 1 message. It serves to complete the negotiation of options with the client, and also provides a challenge to the client. It may optionally contain information about the authentication target.
Typically, the Type 2 message details one or more of the following:
1. The target name -- the name of the authentication target. This is typically sent in response to a client requesting the target (via the Request Target flag in the Type 1 message). This can contain a domain, server, or (apparently) a network share. The target type is indicated via the Target Type Domain, Target Type Server, and Target Type Share flags. The target name can be either Unicode or OEM, as indicated by the presence of the appropriate flag in the Type 2 message.
2. The flags -- the security machanisms to be servered by server:
Negotiate Unicode (0x00000001) The server sets this flag to indicate that it will be using Unicode strings. This should only be set if the client indicates (in the Type 1 message) that it supports Unicode. Either this flag or Negotiate OEM should be set, but not both.
Negotiate OEM (0x00000002) This flag is set to indicate that the server will be using OEM strings. This should only be set if the client indicates (in the Type 1 message) that it will support OEM strings. Either this flag or Negotiate Unicode should be set, but not both.
Request Target (0x00000004) This flag is often set in the Type 2 message; while it has a well-defined meaning within the Type 1 message, its semantics here are unclear.
Negotiate NTLM (0x00000200) Indicates that NTLM authentication is supported.
Negotiate Local Call (0x00004000) The server sets this flag to inform the client that the server and client are on the same machine. The server provides a local security context handle with the message.
Negotiate Always Sign (0x00008000) Indicates that communication between the client and server after authentication should carry a "dummy" signature.
Target Type Domain (0x00010000) The server sets this flag to indicate that the authentication target is being sent with the message and represents a domain.
Target Type Server (0x00020000) The server sets this flag to indicate that the authentication target is being sent with the message and represents a server.
Target Type Share (0x00040000) The server apparently sets this flag to indicate that the authentication target is being sent with the message and represents a network share. This has not been confirmed.
Negotiate NTLM2 Key (0x00080000) Indicates that this server supports the NTLM2 signing and sealing scheme; if negotiated, this can also affect the client's response calculations.
Negotiate Target Info (0x00800000) The server sets this flag to indicate that a Target Information block is being sent with the message.
Negotiate 128 (0x20000000) Indicates that this server supports strong (128-bit) encryption.
Negotiate 56 (0x80000000) Indicates that this server supports medium (56-bit) encryption.
3. The challenge -- an 8-byte block of random data. The client will use this to formulate a response.
4. The context field -- typically populated when Negotiate Local Call is set. It contains an SSPI context handle, which allows the client to "short-circuit" authentication and effectively circumvent responding to the challenge. Physically, the context is two long values. This is covered in greater detail later, in the "Local Authentication" section.
5. The target information -- a Target Information block used in calculating the NTLMv2 response. This is composed of a sequence of subblocks, each consisting of:
a).Indicator of the type of data in this subblock:
(0x0100): Server name
(0x0200): Domain name
(0x0300): Fully-qualified DNS host name (i.e., server.domain.com)
(0x0400): DNS domain name (i.e., domain.com)
b). Length in bytes of this subblock's content field; and
c). Content as indicated by the type field. Always sent in Unicode, even when OEM is indicated by the message flags.
The sequence is terminated by a terminator subblock; this is a subblock of type "0", of zero length. Subblocks of type "5" have also been encountered, apparently containing the "parent" DNS domain for servers in subdomains; it may be that there are other as-yet-unidentified subblock types as well.
References:
|
|
|
|
