This article was previously published under Q147706
Prior to Windows NT 4.0 Service Pack 4 (SP4), Windows NT supported twokinds of challenge/response authentication:
LanManager (LM) challenge/response
Windows NT challenge/response (also known as NTLM challenge/response)
Windows NT also supported session security mechanisms that provided formessage confidentiality and integrity.
To allow access to servers that only support LM authentication, Windows NTclients prior to SP4 always use both, even to Windows NT servers thatsupported NTLM authentication.
LM authentication is not as strong as Windows NT authentication so somecustomers may want to disable its use, because an attacker eavesdropping onnetwork traffic will attack the weaker protocol. A successful attack cancompromise the user's password.
Microsoft has developed an enhancement to NTLM called NTLMv2 thatsignificantly improves both the authentication and session securitymechanisms.
In addition, the implementation of the NTLM Security Service Provider (SSP)has been enhanced to allow clients to control which variants of NTLM areused, and to allow servers to control which variants they will accept, bysetting a new registry key appropriately. It also allows clients andservers to require the negotiation of message confidentiality (encryption),message integrity, 128-bit encryption, and NTLMv2 session security.
These changes affect the following Windows NT components: Any applicationthat uses Microsoft remote procedure call (RPC) or that uses the NTLM SSP,use the authentication and session security described herein. TheWorkstation and Server services use authentication but support their ownsession security.
LM authentication is not as strong as NTLM or NTLMv2 because the algorithmallows passwords longer than 7 characters to be attacked in 7 characterchunks. This limits the effective password strength to 7 characters drawnfrom the set of uppercase alphabetic, numeric, and punctuation characters,plus 32 special ALT characters. Users often do not even avail themselves ofanything more than alphabetic characters.
In contrast, NTLM authentication takes advantage of all 14 characters inthe password and allows lowercase letters. Thus, even though an attackereavesdropping on the Windows NT authentication protocol can attack it inthe same way as the LM authentication protocol, it will take far longer forthe attack to succeed. If the password is strong enough, it will take asingle 200 MHz Pentium Pro computer an average of 2,200 years to find thekeys derived from it and 5,500 years to find the password itself (or 2.2years and 5.5 years with 1,000 such computers, and so forth).
NOTE: This estimate is based on the rate at which the recent RSA Labs "DESChallenge" code tests DES keys on a 200 MHz Pentium Pro: 1,000,000/second;and the number of DES keys: 2**56 or 7.2*10**16. For more information aboutthe "DES Challenge", please see the following Web site:
On the other hand, if a password is not strong enough, a dictionary lookupcan find it in seconds.
One possible way of getting a "strong enough" password is to have it be atleast 11 characters in length, with at least 4 of those charactersuppercase, numbers, or punctuation. Even if the remaining 7 characters arelowercase low randomness text with (say) 3 bits of randomness percharacter, this will give more than DES's key space of 7.2*10**16 possiblecombinations, and the password will not be in dictionaries.
However, hardware accelerators costing $250,000 have been built that canfind either the LM or NTLM password-derived key in 3-6 days no matter howlong the password is. These numbers change as technology gets better. For current statistics and details please see the following Web site:
Having the password-derived key of a user does not allow an attacker to logon interactively but, with special software, it is sufficient to accessnetwork resources as that user.
For NTLMv2, the key space for password-derived keys is 128 bits. This makesa brute force search infeasible, even with hardware accelerators, if thepassword is strong enough.
If both client and server are using SP4, the enhanced NTLMv2 sessionsecurity is negotiated. It provides separate keys for message integrity andconfidentiality, and client input into the challenge to prevent chosenplain text attacks, and makes use of the HMAC-MD5 algorithm (see RFC 2104)for message integrity checking.
Because the datagram variant of NTLM does not have a negotiation step, useof otherwise negotiated options, such as NTLMv2 session security and 128-bit encryption for message confidentiality, has to be configured.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
Control of NTLM security is through the following registry key:
NOTE: On Win9x, the valid registry key is LMCompatibilitywhile on Windows NT it is LMCompatibilityLevel.
Choice of the authentication protocol variants used and accepted is throughthe following value of that key:
Value: LMCompatibilityLevel Value Type: REG_DWORD - Number Valid Range: 0-5 Default: 0 Description: This parameter specifies the type of authentication to be used. Level 0 - Send LM response and NTLM response; never use NTLMv2 session security Level 1 - Use NTLMv2 session security if negotiated Level 2 - Send NTLM authentication only Level 3 - Send NTLMv2 authentication only Level 4 - DC refuses LM authentication Level 5 - DC refuses LM and NTLM authentication (accepts only NTLMv2)
NOTE: Authentication is used to establish a session (username/password). Session securityis used once a session is established using the apropriate type of authentication.Also system times should be within 30 mins of one another. Authentication can fail because the server will think the challenge from the client has expired.
Control over the minimum security negotiated for applications using NTLMSSPis through the following key:
Value: NtlmMinClientSec Value Type: REG_DWORD - Number Valid Range: the logical 'or' of any of the following values: 0x00000010 0x00000020 0x00080000 0x20000000 Default: 0 Value: NtlmMinServerSec Value Type: REG_DWORD - Number Valid Range: same as NtlmMinClientSec Default: 0 Description: This parameter specifies the minimum security to be used. 0x00000010 Message integrity 0x00000020 Message confidentiality 0x00080000 NTLMv2 session security 0x20000000 128 bit encryption
LMCompatibilityLevel - Clients
IMPORTANT: For an SP4 client to choose level 3 or greater, the domain controllers for the user's account domains for all users who will use the client (hereafter, "the users' domain controllers") MUST have been upgraded to SP4.
If an SP4 client chooses level 0, which is the default, it willinteroperate with earlier servers exactly as it did with Service Pack 3(SP3).
If an SP4 client chooses level 1, it will interoperate with earlier serversexactly as it did at Service Pack 3 (SP3). In addition, it will negotiateNTLMv2 session security with SP4 servers.
IMPORTANT: When using level 1 or greater, if the last password change came from a Windows for Workgroups or MS-DOS LanManager 2.x client or earlier, the data needed for NTLM and NTLMv2 authentication will not be available on the domain controller, and SP4 clients will not be able to connect to SP4 servers. The workaround is to use level 0, or always change passwords from a Windows NT, Windows 95, or Windows 98 client.
If an SP4 client chooses level 2, it will not be able to connect to serversthat only support LM authentication, such as Windows 95, Windows 98,Windows for Workgroups and earlier (hereafter called "downlevel LMclients/servers"), unless the users' domain controllers have been upgraded.
If an SP4 client chooses level 3 or greater, it will always send the newNTLMv2 response. This response can pass through downlevel LM servers andSP3 or earlier Windows NT servers and their domain controllers as long asthe users' domain controllers have been upgraded to SP4. For example, if anSP4 client chooses level 3 or greater, the users' domain controllers MUSThave been upgraded to SP4 as well. However, this response will not workwith downlevel LM servers in Share Level security mode with non-nullpasswords. The workaround is to configure them to use User Level security.
LMCompatibilityLevel - Servers/DCs
If an SP4 server chooses level 4 or greater, a user with a local account onthat server will not be able to connect to it from a downlevel LM clientusing that local account.
If an SP4 domain controller chooses level 4 or greater, a user with anaccount in that domain will not be able to connect to any member serverfrom a downlevel LM client using their domain account. Thus, level 4 meansthat all users with accounts on a server or domain have to be using WindowsNT to connect.
If an SP4 server chooses level 5 or greater, a user with a local account onthat server will not be able to connect to it from an SP3 or earlierWindows NT client using that local account.
SP4 clients choosing level 0 or 1 will still be able to connect to SP4servers, even with levels 1 or 3 configured, but will be using both theWindows NT protocol and the weaker LM protocol. They will also be able toconnect to downlevel LM servers, even if the users' domain controllers havenot been upgraded.
Because of the above considerations, if it is preferred to deploy NTLMv2,the following steps should be taken:
Upgrade the domain controllers where the accounts for all users that are to use NTLMv2 are stored.
Even before the upgrade of the domain controllers is completed, clients and servers can be upgraded to SP4 and will obtain enhanced security when connecting SP4 to SP4 by setting level 1.
When step 1 is completed, individual systems that have already been upgraded to SP4 can start setting level 3 or greater.
If users in some account domain never need to access resources from downlevel LM clients, that domain's domain controllers can have their level set to 4, and after all of those users' systems have been upgraded to SP4, that domain's domain controllers can have their level set to 5.
NtlmMinClientSec and NtlmMinServerSec
If the bit with value 0x00000010 is set in the NtlmMinClientSec orNtlmMinServerSec value, the connection will fail if message integrity isnot negotiated.
If the bit with value 0x00000020 is set in the NtlmMinClientSec orNtlmMinServerSec value, the connection will fail if message confidentialityis not negotiated.
If the bit with value 0x00080000 is set in the NtlmMinClientSec orNtlmMinServerSec value, the connection will fail if NTLMv2 session securityis not negotiated.
If the bit with value 0x20000000 is set in the NtlmMinClientSec orNtlmMinServerSec value, the connection will fail if 128-bit encryption isnot negotiated.
NOTE: These settings will not guarantee that the NTLM SSP is actually used by every application, or that message integrity or confidentiality will actually be used by an application even when they are negotiated.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
152734 How to obtain the latest Windows NT 4.0 service pack
After installing SP4, perform the following steps to configure LMCompatibility level on Windows NT workstations and servers:
Run Registry Editor (Regedt32.exe).
From the HKEY_LOCAL_MACHINE subtree, go to the following key: