What is the LAN Manager Authentication Level setting?

Windows servers and workstations on a network must agree to an authentication protocol when users attempt to authenticate to a given network resource. The LAN Manager Authentication Level setting governs which protocols Windows accepts.

Windows can use the following three protocols:

• LAN Manager (also called LM or Lanman): In terms of security, this is the lowest level at which any Windows computer can operate.
• NTLMv1 (sometimes referred to as NTLM): NTLMv1 is an improvement over LM, but is still not as secure as the newest version of NTLM.
• NTLMv2: This is the latest version of the available Windows authentication protocols, and is the most secure.

Although a fourth authentication protocol, Kerberos, is available, it's irrelevant to this document because it's not configurable through the LAN Manager Authentication Level setting.

The LAN Manager Authentication Level can be set relatively low to ensure compatibility with computers using other authentication protocols, because not all clients can use the highest level available. However, increasing compatibility also increases vulnerability, as the older LM and NTLMv1 protocols are now considered insecure. To find the setting, see In Windows XP or later, how do I view my LAN Manager Authentication Level setting?

The following six options are available; the level numbers refer to the corresponding registry key settings:

• Send LM & NTLM responses: Level 0 offers the lowest level of security because LM and NTLM are considered obsolete. Clients at this setting never use NTLMv2. Servers at this setting will accept any of the three protocols.
  
  
• Send LM & NLTM - use NTLMv2 session security if negotiated: Level 1 allows the use of LM and NTLMv1, so it does not eliminate the vulnerabilities inherent in those protocols. Servers at this setting will continue to accept any of the three protocols, although clients will now have the ability to step up to NTLMv2 if they're able to and the server they're connecting to asks for it.
  
  
• Send NTLM response only: When level 2 is implemented across a domain, clients begin using NTLMv1 and can use NTLMv2 if the servers on the network support it. Domain controllers will again continue to accept any of the three protocols.
  
  
• Send NTLMv2 response only: At level 3, domain controllers still accept any of the three protocols, but client computers so able will use only NTLMv2, ignoring LM and NTLMv1 traffic. This is the minimum security level acceptable for mixed networks on which some clients absolutely must continue to authenticate although they cannot use NTLMv2 (for example, older operating systems, such as Windows 95/98/Me, old Unix versions, Mac OS X 10.3 and earlier). Communication between servers and those older clients will still be insecure, but communication between servers and current clients (e.g., Windows 2000 or XP, Mac OS X 10.4, new Unix distributions) will be secure.
  
  
• Send NTLMv2 response only\refuse LM: At level 4, clients and domain controllers ignore any LM traffic; clients only attempt to use NTLMv2, while domain controllers will accept NTLMv1.
  
  
• Send NTLMv2 response only\refuse LM & NTLM: Level 5 is the highest setting. Clients and servers all actively reject LM and NTLMv1 traffic, and use only NTLMv2.

The information above is adapted from Microsoft TechNet.

The Indiana University network is at the highest setting (level 5, Send NTLMv2 response only\refuse LM & NTLM). As a result, anything that authenticates against the IU Active Directory must use NTLMv2; this includes ADS logins, Student Technology Center (STC) and Residential Technology Center (RTC) printing, Exchange access, and file sharing with a computer joined to ADS. UITS has no plans to block the LM and NTLMv1 protocols on IU's network.

Though UITS does not recommend it, stand-alone computers are still able to authenticate to each other via LM or NTLMv1, if the computer owners wish. The switch to level 5 is motivated by security concerns; LM and NTLM are insecure by today's standards, and continuing to use those protocols perpetuates a vulnerability that can lead to a system compromise.

Comments/Questions/Corrections