| Author |
Topic: NTLM Authentication Protocol |
|
authen
member
offline  |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
 |
|
|
| NTLM Authentication Protocol |
What is NTLM?
NTLM is a challenge-response authentication protocol used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider ("NTLMSSP"). Originally used for authentication and negotiation of secure DCE/RPC, NTLM is also used throughout Microsoft's systems as an integrated single sign-on mechanism.
NTLM employs a challenge-response mechanism for authentication, in which clients are able to prove their identities without sending a password to the server. It consists of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication). It basically works like this:
The client first sends a Type 1 message containing a set of flags of features supported or requested (such as encryption key sizes, request for mutual authentication, etc.) to the server.
The server responds with a Type 2 message containing a similar set of flags supported or required by the server (thus enabling an agreement on the authentication parameters between the server and the client) and, more importantly, a random challenge (8 bytes).
Finally, the client uses the challenge obtained from the Type 2 message and the user's credentials to calculate the response. The calculation methods differ based on the NTLM authentication parameters negotiated previously, but in general they apply MD4/MD5 hashing algorithms and DES encryption to compute the response. The client then sends the response to the server in a Type 3 message.
|
|
|
|
|
|
|
authen
member
offline  |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Structure of NTLM Message |
Structure of NTLM Message
--------------------------------
NTLM Message ::= <signature><messageType><messageBody>
<signature> ::= 'NTLMSSP' '0x00' (Hex 0x4e 0x54 0x4c 0x4d 0x53 0x53 0x50 0x00)
<messageType> ::= CHOICE {
type 1 [0] long (hexadecimal 0x01 0x00 0x00 0x00)
type 2 [1] long (hexadecimal 0x02 0x00 0x00 0x00)
type 3 [2] long (hexadecimal 0x03 0x00 0x00 0x00)
}
<messageBody> ::= SEQUENCE {
securityBuffer SecurityBuffer,
messageFlag MessageFlag,
dataBlock DataBlock
}
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| The NTLM Type 1 Message |
Structure:
--0--NTLMSSP Signature Null-terminated ASCII "NTLMSSP" (0x4e544c4d53535000)
--8--NTLM Message Type long (0x01000000)
12 Flags long
(16) Supplied Domain (Optional) securityBuffer
(24) Supplied Workstation (Optional) securityBuffer
(32) start of data block (if required)
The Type 1 message is sent from the client to the server to initiate NTLM authentication. Its primary purpose is to establish the "ground rules" for authentication by indicating supported options via the flags. Optionally, it can also provide the server with the client's workstation name and the domain in which the client workstation has membership; this information is used by the server to determine whether the client is eligible for local authentication.
Typically, the Type 1 message details one or more of the following:
1. The flags -- the security machanisms supported by client:
Negotiate Unicode (0x00000001) The client sets this flag to indicate that it supports Unicode strings.
Negotiate OEM (0x00000002) This is set to indicate that the client supports OEM strings.
Request Target (0x00000004) This requests that the server send the authentication target with the Type 2 reply.
Negotiate NTLM (0x00000200) Indicates that NTLM authentication is supported.
Negotiate Domain Supplied (0x00001000) When set, the client will send with the message the name of the domain in which the workstation has membership.
Negotiate Workstation Supplied (0x00002000) Indicates that the client is sending its workstation name with the message.
Negotiate Always Sign (0x00008000) Indicates that communication between the client and server after authentication should carry a "dummy" signature.
Negotiate NTLM2 Key (0x00080000) Indicates that this client supports the NTLM2 signing and sealing scheme; if negotiated, this can also affect the response calculations.
Negotiate 128 (0x20000000) Indicates that this client supports strong (128-bit) encryption.
Negotiate 56 (0x80000000) Indicates that this client supports medium (56-bit) encryption.
2. The supplied domain -- the domain in which the client workstation has membership. This is always in OEM format, even if Unicode is supported by the client.
3. The supplied workstation -- the client workstation's name. This, too, is in OEM rather than Unicode.
Note that the supplied domain and workstation are optional fields; they may be empty (security buffer indicating a length of zero), or may not be sent at all (security buffer omitted altogether). If the supplied domain and workstation are omitted, the Type 1 message carries no data block (the message ends after the flags field, and is a fixed-length 16-byte structure).
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| The Minimium of NTML Type 1 Message |
The "most-minimal" well-formed Type 1 message, therefore, would be:
0x4e544c4d535350000100000002020000
This message contains only
the NTLMSSP signature,
the NTLM message type, and
the minimal set of flags (Negotiate NTLM and Negotiate OEM).
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| A Example of The NTLM Type 1 Message |
A sample Type 1 Message could be as follows:
0x4e544c4d535350000100000007320000060006002b0000000b000b0020000000
574f524b53544154494f4e444f4d41494e
Broken down:
0 0x4e 0x54 0x4c 0x4d 0x53 0x53 0x50 0x00
NTLMSSP Signature
8 0x01 0x00 0x00 0x00
Type 1 Indicator
12 0x07 0x32 0x00 0x00
Flags:
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Negotiate Domain Supplied (0x00001000)
Negotiate Workstation Supplied (0x00002000)
16 0x06 0x00 0x06 0x00 0x2b 0x00 0x00 0x00
Supplied Domain Security Buffer:
--Length: 6 bytes (0x0600)
--Allocated Space: 6 bytes (0x0600)
--Offset: 43 bytes (0x2b000000)
24 0x0b 0x00 0x0b 0x00 0x20 0x00 0x00 0x00
Supplied Workstation Security Buffer:
--Length: 11 bytes (0x0b00)
--Allocated Space: 11 bytes (0x0b00)
--Offset: 32 bytes (0x20000000)
32 0x57 0x4f 0x52 0x4b 0x53 0x54 0x41 0x54 0x49 0x4f 0x4e
Supplied Workstation Data ("WORKSTATION")
43 0x44 0x4f 0x4d 0x41 0x49 0x4e
Supplied Domain Data ("DOMAIN")
The above Type 1 message implies:
This is an NTLM Type 1 message (from the NTLMSSP Signature and Type 1 Indicator).
This client can support either Unicode or OEM strings (the Negotiate Unicode and Negotiate OEM flags are both set).
This client supports NTLM authentication (Negotiate NTLM).
The client is requesting that the server send information regarding the authentication target (Request Target is set).
This client is sending its domain, which is "DOMAIN" (the Negotiate Domain Supplied flag is set, and the domain name is present in the Supplied Domain Security Buffer).
The client is sending its workstation name, which is "WORKSTATION" (the Negotiate Workstation Supplied flag is set, and the workstation name is present in the Supplied Workstation Security Buffer).
Note that the supplied workstation and domain are in OEM format. Additionally, the order in which the security buffer data blocks are laid out is unimportant; in the example, the workstation data is placed before the domain data.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| The NTLM Type 2 Message |
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.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Minimium of The NTLM Type 2 Message |
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
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| A Example of The NTLM Type 2 Message |
A sample Type 1 Message could be as follows:
0x4e544c4d53535000020000000c000c003000000001028100
0123456789abcdef0000000000000000620062003c000000
44004f004d00410049004e0002000c0044004f004d004100
49004e0001000c0053004500520056004500520004001400
64006f006d00610069006e002e0063006f006d0003002200
7300650072007600650072002e0064006f006d0061006900
6e002e0063006f006d0000000000
Broken down:
0 0x4e 0x54 0x4c 0x4d 0x53 0x53 0x50 0x00
NTLMSSP Signature
8 0x02 0x00 0x00 0x00
Type 2 Indicator
12 0x0c 0x00 0x0c 0x00 0x30 0x00 0x00 0x00
Target Name:
--Length: 12 bytes (0x0c00)
--Allocated Space: 12 bytes (0x0c00)
--Offset: 48 bytes (0x30000000)
20 0x01 0x02 0x81 0x00
Flags:
--Negotiate Unicode (0x00000001)
--Negotiate NTLM (0x00000200)
--Target Type Domain (0x00010000)
--Negotiate Target Info (0x00800000)
24 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef
Challenge
32 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Context
40 0x62 0x00 0x62 0x00 0x3c 0x00 0x00 0x00
Target Information:
--Length: 98 bytes (0x6200)
--Allocated Space: 98 bytes (0x6200)
--Offset: 60 bytes (0x3c000000)
48 0x44 0x00 0x4f 0x00 0x4d 0x00 0x41 0x00 0x49 0x00 0x4e 0x00
Target Name Data ("DOMAIN")
60 <data-block>0x02...
0x02 0x00 0x0c 0x00 0x44 0x00 0x4f 0x00 0x4d 0x00 0x41 0x00 0x49 0x00 0x4e 0x00
Domain name subblock:
--Type: 2 (Domain name, 0x0200)
--Length: 12 bytes (0x0c00)
--Data: "DOMAIN"
0x01 0x00 0x0c 0x00 0x53 0x00 0x45 0x00 0x52 0x00 0x56 0x00 0x45 0x00 0x52 0x00
Server name subblock:
--Type: 1 (Server name, 0x0100)
--Length: 12 bytes (0x0c00)
--Data: "SERVER"
0x04 0x00 0x14 0x00 0x64 0x00 0x6f 0x00 0x6d 0x00 0x61 0x00 0x69 0x00 0x6e 0x00
0x2e 0x00 0x63 0x00 0x6f 0x00 0x6d 0x00
DNS domain name subblock:
--Type: 4 (DNS domain name, 0x0400)
--Length: 20 bytes (0x1400)
--Data: "domain.com"
0x03 0x00 0x22 0x00 0x73 0x00 0x65 0x00 0x72 0x00 0x76 0x00 0x65 0x00 0x72 0x00
0x2e 0x00 0x64 0x00 0x6f 0x00 0x6d 0x00 0x61 0x00 0x69 0x00 0x6e 0x00 0x2e 0x00
0x63 0x00 0x6f 0x00 0x6d 0x00
DNS server name subblock:
--Type: 3 (DNS server name, 0x0300)
--Length: 34 bytes (0x2200)
--Data: "server.domain.com"
0x00 0x00 0x00 0x00
Terminator subblock:
--Type: 0 (terminator, 0x0000)
--Length: 0 bytes (0x0000)
An analysis of this message shows:
This is an NTLM Type 2 message (from the NTLMSSP Signature and Type 2 Indicator).
The server has indicated that strings will be encoded using Unicode (the Negotiate Unicode flag is set).
The server supports NTLM authentication (Negotiate NTLM).
The Target Name provided by the server is populated and represents a domain (the Target Type Domain flag is set and the domain name is present in the Target Name Security Buffer).
The server is providing a Target Information structure (Negotiate Target Info is set). This structure is present in the Target Information Security Buffer (domain name "DOMAIN", server name "SERVER", DNS domain name "domain.com", and DNS server name "server.domain.com").
The challenge generated by the server is "0x0123456789abcdef".
An empty context has been sent.
Note that the target name is in Unicode format (as specified by the Negotiate Unicode flag).
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| The NTLM Type 3 Message |
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.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
56 |
| joined: |
06/05/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| A Example of The NTLM Type 3 Message |
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.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 06/06/2006 02:13:50 AM
Edit
Quote
Report
Profile
Reply