ARCHIVED: What is the LAN Manager Authentication Level setting?

This content has been archived, and is no longer maintained by Indiana University. Information here may no longer be accurate, and links may no longer be available or reliable.

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.

Note: Authentication via the Kerberos protocol is also available, but because Kerberos is not configurable through the LAN Manager Authentication Level setting, it will not be included here.

Because not all clients can use the highest level available, the LAN Manager Authentication Level can be set relatively low to ensure compatibility with computers using other authentication protocols. However, increasing compatibility also increases vulnerability, as the older LM and NTLMv1 protocols are now considered insecure. To find the setting, see ARCHIVED: 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 & NTLM - 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, where some clients that cannot use NTLMv2 (for example, older operating systems, such as Windows 95/98/Me, old Unix versions, Mac OS X 10.3 and earlier) must still be able to authenticate. Communication between servers and these older clients will be insecure, unlike communication with current clients (e.g., Windows 2000 or XP, Mac OS X 10.4, new Unix distributions).
  • 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.

Though not recommend by UITS, stand-alone computers are still able to authenticate to each other via LM or NTLMv1 if necessary. 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.

This is document atvn in the Knowledge Base.
Last modified on 2018-01-18 15:27:09.