What is NTLM?

NTLM is an 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:

1. The client sends a Type 1 message to the server. This primarily contains a list of features supported by the client and requested of the server.
2. The server responds with a Type 2 message. This contains a list of features supported and agreed upon by the server. Most importantly, however, it contains a challenge generated by the server.
3. The client replies to the challenge with a Type 3 message. This contains several pieces of information about the client, including the domain and username of the client user. It also contains one or more responses to the Type 2 challenge.

Before we start digging in any further, we will need to define a few data types as used in the messages.

For our purposes, a "short" is a little-endian, 16-bit unsigned value. For example, the decimal value "1234" represented as a short would be physically laid out as "0xd204" in hexadecimal.

A "long" is a little-endian, 32-bit unsigned value. The decimal value "1234" represented as a long in hexidecimal would be "0xd2040000".

A Unicode string is a string in which each character is represented as a 16-bit little-endian value (16-bit UCS-2 Transformation Format, little-endian byte order, with no Byte Order Mark and no null-terminator). The string "hello" in Unicode would be represented hexidecimally as "0x680065006c006c006f00".

An OEM string is a string in which each character is represented as an 8-bit value from the local machine's native character set (DOS codepage). There is no null-terminator. In NTLM messages, OEM strings are typically presented in uppercase. The string "HELLO" in OEM would be represented hexidecimally as "0x48454c4c4f".

A "security buffer" is a structure used to point to a buffer of binary data. It consists of:

1. A short containing the length of the buffer in bytes.
2. A short containing the allocated space for the buffer in bytes (typically, though not necessarily, the same as the length).
3. A long containing the offset to the start of the buffer in bytes (from the beginning of the NTLM message).

So the security buffer "0xd204d204e1100000" would be read as:

Length: 0xd204 (1234 bytes)
Allocated Space: 0xd204 (1234 bytes)
Offset: 0xe1100000 (4321 bytes)

Now we're ready to look at the physical layout of NTLM message headers.

All messages start with the NTLMSSP signature, which is (aptly enough) the null-terminated ASCII string "NTLMSSP" (hexadecimal "0x4e544c4d53535000").

Next is a long containing the message type (1, 2, or 3). A Type 1 message, for example, has type "0x01000000" in hex.

The message flags are contained in a bitfield within the header. This is a long, in which each bit represents a specific flag. Most of these will make more sense later, but we'll go ahead and present them here to establish a frame of reference for the rest of the discussion. Many of these flags are not used, or are used infrequently; commonly occurring flags are displayed in bold in the table below. Flags marked as "unidentified" or "unknown" are outside the realm of the author's knowledge (which is not by any means absolute).

Flag	Name	Description
0x00000001	Negotiate Unicode	Indicates that Unicode strings are supported for use in security buffer data.
0x00000002	Negotiate OEM	Indicates that OEM strings are supported for use in security buffer data.
0x00000004	Request Target	Requests that the server's authentication realm be included in the Type 2 message.
0x00000008	unknown	This flag's usage has not been identified.
0x00000010	Negotiate Sign	Specifies that authenticated communication between the client and server should carry a digital signature (message integrity).
0x00000020	Negotiate Seal	Specifies that authenticated communication between the client and server should be encrypted (message confidentiality).
0x00000040	Negotiate Datagram Style	Indicates that datagram authentication is being used.
0x00000080	Negotiate Lan Manager Key	Indicates that the LAN Manager session key should be used for signing and sealing authenticated communications.
0x00000100	Negotiate Netware	This flag's usage has not been identified.
0x00000200	Negotiate NTLM	Indicates that NTLM authentication is being used.
0x00000400	unknown	This flag's usage has not been identified.
0x00000800	unknown	This flag's usage has not been identified.
0x00001000	Negotiate Domain Supplied	Sent by the client in the Type 1 message to indicate that the name of the domain in which the client workstation has membership is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
0x00002000	Negotiate Workstation Supplied	Sent by the client in the Type 1 message to indicate that the client workstation's name is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
0x00004000	Negotiate Local Call	Sent by the server to indicate that the server and client are on the same machine. Implies that the client may use the established local credentials for authentication instead of calculating a response to the challenge.
0x00008000	Negotiate Always Sign	Indicates that authenticated communication between the client and server should be signed with a "dummy" signature.
0x00010000	Target Type Domain	Sent by the server in the Type 2 message to indicate that the target authentication realm is a domain.
0x00020000	Target Type Server	Sent by the server in the Type 2 message to indicate that the target authentication realm is a server.
0x00040000	Target Type Share	Sent by the server in the Type 2 message to indicate that the target authentication realm is a share. Presumably, this is for share-level authentication. Usage is unclear.
0x00080000	Negotiate NTLM2 Key	Indicates that the NTLM2 signing and sealing scheme should be used for protecting authenticated communications. Note that this refers to a particular session security scheme, and is not related to the use of NTLMv2 authentication. This flag can, however, have an effect on the response calculations (as detailed in the "NTLM2 Session Response" section).
0x00100000	Request Init Response	This flag's usage has not been identified.
0x00200000	Request Accept Response	This flag's usage has not been identified.
0x00400000	Request Non-NT Session Key	This flag's usage has not been identified.
0x00800000	Negotiate Target Info	Sent by the server in the Type 2 message to indicate that it is including a Target Information block in the message. The Target Information block is used in the calculation of the NTLMv2 response.
0x01000000	unknown	This flag's usage has not been identified.
0x02000000	unknown	This flag's usage has not been identified.
0x04000000	unknown	This flag's usage has not been identified.
0x08000000	unknown	This flag's usage has not been identified.
0x10000000	unknown	This flag's usage has not been identified.
0x20000000	Negotiate 128	Indicates that 128-bit encryption is supported.
0x40000000	Negotiate Key Exchange	Indicates that the client will provide an encrypted master session key in the "Session Key" field of the Type 3 message. This is used in signing and sealing, and is RC4-encrypted using the previous session key as the encryption key.
0x80000000	Negotiate 56	Indicates that 56-bit encryption is supported.

As an example, consider a message specifying:

Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)

Let's jump in and take a look at the Type 1 message:

	Description	Content
0	NTLMSSP Signature	Null-terminated ASCII "NTLMSSP" (0x4e544c4d53535000)
8	NTLM Message Type	long (0x01000000)
12	Flags	long
(16)	Supplied Domain (Optional)	security buffer
(24)	Supplied Workstation (Optional)	security buffer
(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 contains flags from the following set:

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.

The supplied domain is a security buffer containing the domain in which the client workstation has membership. This is always in OEM format, even if Unicode is supported by the client.

The supplied workstation is a security buffer containing 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). The "most-minimal" well-formed Type 1 message, therefore, would be:

    4e544c4d535350000100000002020000

Consider the following hexadecimal Type 1 Message:

    4e544c4d535350000100000007320000060006002b0000000b000b0020000000
    574f524b53544154494f4e444f4d41494e

We break this up as follows:

0	0x4e544c4d53535000	NTLMSSP Signature
8	0x01000000	Type 1 Indicator
12	0x07320000	Flags: Negotiate Unicode (0x00000001) Negotiate OEM (0x00000002) Request Target (0x00000004) Negotiate NTLM (0x00000200) Negotiate Domain Supplied (0x00001000) Negotiate Workstation Supplied (0x00002000)
16	0x060006002b000000	Supplied Domain Security Buffer: Length: 6 bytes (0x0600) Allocated Space: 6 bytes (0x0600) Offset: 43 bytes (0x2b000000)
24	0x0b000b0020000000	Supplied Workstation Security Buffer: Length: 11 bytes (0x0b00) Allocated Space: 11 bytes (0x0b00) Offset: 32 bytes (0x20000000)
32	0x574f524b53544154494f4e	Supplied Workstation Data ("WORKSTATION")
43	0x444f4d41494e	Supplied Domain Data ("DOMAIN")

Analyzing this information, we can see:

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

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

Typical Type 2 message flags include:

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.

The target name is a security buffer containing 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.

The challenge is an 8-byte block of random data. The client will use this to formulate a response.

Let's look at the following hexadecimal Type 2 Message:

    4e544c4d53535000020000000c000c003000000001028100
    0123456789abcdef0000000000000000620062003c000000
    44004f004d00410049004e0002000c0044004f004d004100
    49004e0001000c0053004500520056004500520004001400
    64006f006d00610069006e002e0063006f006d0003002200
    7300650072007600650072002e0064006f006d0061006900
    6e002e0063006f006d0000000000

Breaking this into its constituent fields gives:

0	0x4e544c4d53535000	NTLMSSP Signature
8	0x02000000	Type 2 Indicator
12	0x0c000c0030000000	Target Name Security Buffer: Length: 12 bytes (0x0c00) Allocated Space: 12 bytes (0x0c00) Offset: 48 bytes (0x30000000)
20	0x01028100	Flags: Negotiate Unicode (0x00000001) Negotiate NTLM (0x00000200) Target Type Domain (0x00010000) Negotiate Target Info (0x00800000)
24	0x0123456789abcdef	Challenge
32	0x0000000000000000	Context
40	0x620062003c000000	Target Information Security Buffer: Length: 98 bytes (0x6200) Allocated Space: 98 bytes (0x6200) Offset: 60 bytes (0x3c000000)
48	0x44004f004d004100 49004e00	Target Name Data ("DOMAIN")
60	0x02000c0044004f00 4d00410049004e00 01000c0053004500 5200560045005200 0400140064006f00 6d00610069006e00 2e0063006f006d00 0300220073006500 7200760065007200 2e0064006f006d00 610069006e002e00 63006f006d000000 0000	Target Information Data: 0x02000c0044004f00 4d00410049004e00 Domain name subblock: Type: 2 (Domain name, 0x0200) Length: 12 bytes (0x0c00) Data: "DOMAIN" 0x01000c0053004500 5200560045005200 Server name subblock: Type: 1 (Server name, 0x0100) Length: 12 bytes (0x0c00) Data: "SERVER" 0x0400140064006f00 6d00610069006e00 2e0063006f006d00 DNS domain name subblock: Type: 4 (DNS domain name, 0x0400) Length: 20 bytes (0x1400) Data: "domain.com" 0x0300220073006500 7200760065007200 2e0064006f006d00 610069006e002e00 63006f006d00 DNS server name subblock: Type: 3 (DNS server name, 0x0300) Length: 34 bytes (0x2200) Data: "server.domain.com" 0x00000000 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).

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

The client creates one or more responses to the Type 2 challenge, and sends these in the Type 3 message. There are five types of responses:

• LM (LAN Manager) Response - Sent by most clients, this is the "original" response type.
• NTLM Response - This is sent by NT-based clients, including Windows 2000 and XP.
• NTLMv2 Response - A newer response type, introduced in Windows NT Service Pack 4. This replaces the NTLM response on systems that have NTLM version 2 enabled.
• LMv2 Response - The replacement for the LM response on NTLM version 2 systems.
• NTLM2 Session Response - Used when NTLM2 session security is negotiated without NTLMv2 authentication, this scheme alters the semantics of both the LM and NTLM responses.

The LM Response

The LM response is sent by most clients. This scheme is older than the NTLM response, and less secure. While newer clients support the NTLM response, they typically send both responses for compatibility with legacy servers; hence, the security flaws present in the LM response are still exhibited in many clients supporting the NTLM response.

The NTLM Response

The NTLM response is sent by newer clients. This scheme addresses some of the flaws in the LM response; however, it is still considered fairly weak. Additionally, the NTLM response is nearly always sent in conjunction with the LM response. The weaknesses in that algorithm can be exploited to obtain the case-insensitive password, and trial-and-error used to find the case-sensitive password employed by the NTLM response.

The NTLMv2 Response

NTLM version 2 ("NTLMv2") was concocted to address the security issues present in NTLM. While its effectiveness in this regard is questionable, it does at least provide a more secure replacement for the LM response. When NTLMv2 is enabled, the NTLM response is replaced with the NTLMv2 response, and the LM response is replaced with the LMv2 response (which we will discuss next).

The LMv2 Response

The NTLM2 Session Response

The NTLM2 session response can be employed in conjunction with NTLM2 session security (it is made available with the "Negotiate NTLM2 Key" flag). This is used to provide enhanced protection against precomputed dictionary attacks in environments which do not support NTLMv2 authentication.

Type 3 Message Example

Now that we're familiar with the Type 3 responses, we are ready to examine a Type 3 Message:

    4e544c4d5353500003000000180018006a00000018001800
    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	0x44004f004d004100 49004e00	Domain Name Data ("DOMAIN")
76	0x7500730065007200	User Name Data ("user")
84	0x57004f0052004b00 5300540041005400 49004f004e00	Workstation Name Data ("WORKSTATION")
106	0xc337cd5cbd44fc97 82a667af6d427c6d e67c20c2d3e77c56	LM Response Data
130	0x25a98c1c31e81847 466b29b2df4680f3 9958fb8c213a9cc6	NTLM Response Data

Analysis of this 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.

NTLM version 2 consists of three new response algorithms (NTLMv2, LMv2, and the NTLM2 session response, discussed previously) and a new signing and sealing scheme (NTLM2 session security). NTLM2 session security is negotiated via the "Negotiate NTLM2 Key" flag; NTLMv2 authentication, however, is enabled through a modification to the registry. Further, the registry setting on the client and server must be compatible in order for authentication to be successful. The result is that the overwhelming majority of hosts just use the default setting, and NTLMv2 authentication is rarely seen in deployed systems.

Now that we have a working knowledge of NTLM authentication, it is appropriate to look at how NTLM fits into the "big picture".

Local Authentication

We have alluded to the local authentication sequence at various points in our discussion; having a basic understanding of SSPI, we can look at this scenario in more detail.

Local authentication is negotiated through a series of decisions made by the client and server, based on the information in the NTLM messages. It works as follows:

1. The client calls the AcquireCredentialsHandle function, specifying the default credentials by passing in null to the "pAuthData" parameter. This obtains a handle to the credentials of the logged in user for single sign-on.
2. The client calls the SSPI InitializeSecurityContext function to create the Type 1 message. When the default credential handle is supplied, the Type 1 message contains the workstation and domain name of the client. This is indicated by the presence of the "Negotiate Domain Supplied" and "Negotiate Workstation Supplied" flags, and the inclusion of populated Supplied Domain and Supplied Workstation security buffers in the message.
3. The server receives the Type 1 message from the client, and calls AcceptSecurityContext. This creates a local security context on the server to represent the client. The server examines the domain and workstation information sent by the client to determine if the client and server are the same machine. If so, the server initiates local authentication by setting the "Negotiate Local Call" flag in the resultant Type 2 message. The first long in the Context field of the Type 2 message is populated with the "upper" portion of the newly obtained SSPI context handle (specifically, the "dwUpper" field of the SSPI CtxtHandle structure). The second long in the Context field appears to be empty in all cases. (although logically one would assume it should contain the "lower" portion of the context handle).
4. The client receives the Type 2 message from the server and passes it to InitializeSecurityContext. Having noted the presence of the "Negotiate Local Call" flag, the client examines the server context handle to determine if it represents a valid local security context. If the context cannot be validated, authentication proceeds as usual - the appropriate responses are calculated, and included with the domain, workstation, and username in the Type 3 message. If the security context handle from the Type 2 message can be validated, however, no responses are prepared whatsoever. Instead, the default credentials are internally associated with the server context. The resulting Type 3 message is completely empty, containing zero-length security buffers for the responses as well as the username, domain, and workstation.
5. The server receives the Type 3 message and uses it as input to the AcceptSecurityContext function. The server verifies that the security context has been associated with a user; if so, authentication has successfully completed. If the context has not been bound to a user, authentication fails.

Datagram Authentication

Datagram-style authentication is used to negotiate NTLM over a connectionless transport. While much of the semantics around the messages remain unchanged, there are a few significant differences:

• SSPI does not create a Type 1 message during the first call to InitializeSecurityContext.
• Authentication options are offered by the server, rather than requested by the client.
• Rather than being superfluous (as in connection-oriented authentication), the flags in the Type 3 message carry their usual meanings.

During "normal" (connection-oriented) authentication, all options are negotiated in the first transaction between the client and the server, during the exchange of the Type 1 and Type 2 messages. The negotiated settings are "remembered" by the server and applied to the client's Type 3 message. Although most clients send the agreed-upon flags with the Type 3 message, they are not used in connection authentication.

In datagram authentication, however, the game changes a bit; to alleviate the server's need to track the negotiated options (which becomes more difficult without a persistent connection), the Type 1 message is removed completely. The server generates a Type 2 message containing all supported flags (as well as the challenge, of course). The client then decides which options it will support, and replies with a Type 3 message containing the responses to the challenge and the set of selected flags. The SSPI handshake sequence for datagram authentication is as follows:

1. The client calls AcquireCredentialsHandle to obtain a representation of the credential set for the user.
2. The client calls InitializeSecurityContext, passing the ISC_REQ_DATAGRAM flag as a context requirement via the fContextReq parameter. This starts the construction of the client's security context, but does not produce a request token (Type 1 message).
3. The server calls the AcceptSecurityContext function, specifying the ASC_REQ_DATAGRAM context requirement flag and passing in a null input token. This creates the local security context and yields an authentication response token (the Type 2 message). This Type 2 message will contain the "Negotiate Datagram Style" flag, as well as all flags supported by the server. This is sent to the client as usual.
4. The client receives the Type 2 message and passes it to InitializeSecurityContext. The client selects appropriate options from those presented by the server (including "Negotiate Datagram Style", which must be set), creates the responses to the challenge, and populates the Type 3 message. The message is then relayed to the server.
5. The server passes the Type 3 message into the AcceptSecurityContext function. The message is processed according to the flags selected by the client, and the context is successfully accepted.

When used with SSPI, there is apparently no means of producing a datagram-style Type 1 message. It is interesting to note, however, that we can "induce" datagram semantics at a lower level by subtly manipulating the NTLMSSP tokens to produce our own datagram Type 1 token.

This can be achieved by setting the "Negotiate Datagram Style" flag on the Type 1 message produced by the first InitializeSecurityContext call in a connection-oriented SSPI handshake before passing the token to the server. When the modified Type 1 message is passed into the AcceptSecurityContext function, the server will adopt datagram semantics (even though ASC_REQ_DATAGRAM was not specified). This will produce a Type 2 message with the "Negotiate Datagram Style" flag set, but otherwise identical to the connection-oriented message that would normally have been generated; that is, the Type 1 flags sent by the client are considered during the construction of the Type 2 message, rather than simply offering all supported options.

The client can then call InitializeSecurityContext with this Type 2 token. Note that the client is still in connection-oriented mode; the Type 3 message produced will ignore the "Negotiate Datagram Style" flag applied to the Type 2 message. The server, however, is enforcing datagram semantics, and will now require the Type 3 flags to be set appropriately. Adding the "Negotiate Datagram Style" flag to the Type 3 message manually before sending it to the server allows the server to successfully call AcceptSecurityContext with the modified token.

This results in successful authentication; the "doctored" Type 1 message effectively switches the server into datagram-style authentication, in which the Type 3 flags are observed and enforced. There is no known practical use for this, but it does demonstrate some of the interesting and unexpected behavior that can be observed by strategically manipulating the NTLM messages.

Microsoft has established the proprietary "NTLM" authentication scheme for HTTP to provide integrated authentication to IIS web servers. This authentication mechanism allows clients to access resources using their Windows credentials, and is typically used within corporate environments to provide single sign-on functionality to intranet sites. Historically, NTLM authentication was only supported by Internet Explorer; recently, however, support has been added to various other user agents.

The NTLM HTTP authentication mechanism works as follows:

1. The client requests a protected resource from the server:

       GET /index.html HTTP/1.1
   

2. The server responds with a 401 status, indicating that the client must authenticate. "NTLM" is presented as a supported authentication mechanism via the "WWW-Authenticate" header. Typically, the server closes the connection at this time:

       HTTP/1.1 401 Unauthorized
       WWW-Authenticate: NTLM
       Connection: close
   

   Note that Internet Explorer will only select NTLM if it is the first mechanism offered; this is at odds with RFC 2616, which states that the client must select the strongest supported authentication scheme.

3. The client resubmits the request with an "Authorization" header containing a Type 1 message parameter. The Type 1 message is Base-64 encoded for transmission. From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests. This implies that the server and client must support persistent connections, via either the HTTP 1.0-style "Keep-Alive" header or HTTP 1.1 (in which persistent connections are employed by default). The relevant request headers appear as follows (the line break in the "Authorization" header below is for display purposes only, and is not present in the actual message):

       GET /index.html HTTP/1.1
       Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1
       JLU1RBVElPTkRPTUFJTg==
   

4. The server replies with a 401 status containing a Type 2 message in the "WWW-Authenticate" header (again, Base-64 encoded). This is shown below (the line breaks in the "WWW-Authenticate" header are for editorial clarity only, and are not present in the actual header).

       HTTP/1.1 401 Unauthorized
       WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8
       AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTA
       EUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHI
       ALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=
   

5. The client responds to the Type 2 message by resubmitting the request with an "Authorization" header containing a Base-64 encoded Type 3 message (again, the line breaks in the "Authorization" header below are for display purposes only):

       GET /index.html HTTP/1.1
       Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAA
       AACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIA
       VwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjB
       wx6BhHRmspst9GgPOZWPuMITqcxg==
   

6. Finally, the server validates the responses in the client's Type 3 message and allows access to the resource.

       HTTP/1.1 200 OK
   

This scheme differs from most "normal" HTTP authentication mechanisms, in that subsequent requests over the authenticated connection are not themselves authenticated; NTLM is connection-oriented, rather than request-oriented. So a second request for "/index.html" would not carry any authentication information, and the server would request none. If the server detects that the connection to the client has been dropped, a request for "/index.html" would result in the server reinitiating the NTLM handshake.

A notable exception to the above is the client's behavior when submitting a POST request (typically employed when the client is sending form data to the server). If the client determines that the server is not the local host, the client will initiate reauthentication for POST requests over the active connection. The client will first submit an empty POST request with a Type 1 message in the "Authorization" header; the server responds with the Type 2 message (in the "WWW-Authenticate" header as shown above). The client then resubmits the POST with the Type 3 message, sending the form data with the request.

The NTLM HTTP mechanism can also be used for HTTP proxy authentication. The process is similar, except:

• The server uses the 407 response code (indicating proxy authentication required) rather than 401.
• The client's Type 1 and 3 messages are sent in the "Proxy-Authorization" request header, rather than the "Authorization" header.
• The server's Type 2 challenge is sent in the "Proxy-Authenticate" response header (instead of "WWW-Authenticate").

NTLM SMTP Authentication

Note that due to the highly dynamic and transient nature of the Web, these may or may not be available.

Appendix A: Java Implementation of the Type 3 Response Calculations

Permission to use, copy, modify, and distribute this document for any purpose and without any fee is hereby granted, provided that the above copyright notice and this list of conditions appear in all copies.