Change LAN Manager Authentication Level

What the LAN Manager Level Changer does

This Automox Worklet™ configures the LAN Manager authentication compatibility level on Windows endpoints. The LMCompatibilityLevel setting controls which authentication protocols Windows accepts for network logons, including file sharing, print services, and administrative tools. Setting this value to 5 enforces the highest security level.

The Worklet modifies the registry at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa by setting the LMCompatibilityLevel value. Level 5 means the endpoint sends NTLMv2 responses only and refuses LM and NTLM authentication. This prevents the use of weaker authentication protocols that are vulnerable to capture and cracking.

You can configure the authentication level by modifying the $authenticationLevel variable. Levels range from 0 (accept all including LM) to 5 (NTLMv2 only, refuse all others). Microsoft documentation describes each level's behavior for organizations that need to support legacy systems.

Why upgrade LAN Manager authentication

Older LAN Manager and NTLMv1 protocols use weak cryptographic algorithms that attackers can exploit. LM hashes use DES encryption that modern computers can crack in minutes. NTLMv1 hashes are vulnerable to rainbow table attacks and can be cracked or relayed to access other systems. Enforcing NTLMv2 significantly increases the difficulty of these attacks.

Network reconnaissance tools can capture NTLM authentication traffic and either crack the hashes offline or relay them to authenticate against other systems. Setting LMCompatibilityLevel to 5 forces endpoints to use NTLMv2 with its stronger challenge-response mechanism and timestamp inclusion, reducing the effectiveness of relay attacks.

CIS Benchmarks and security hardening guides recommend setting LMCompatibilityLevel to 5 for maximum security. This configuration is compatible with all modern Windows versions and most enterprise applications. Legacy systems running Windows XP or Windows Server 2003 may require a lower level, but these systems should be prioritized for upgrade.

How LAN Manager level configuration works

1. Evaluation phase: The Worklet immediately exits with code 1 to trigger remediation on every run. This force-run approach treats the setting as a continuous enforcement rather than a one-time configuration, verifying the authentication level remains at the desired setting even if changed by other processes or Group Policy.

2. Remediation phase: The Worklet opens the registry path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa, creating it if it does not exist. It then sets the LMCompatibilityLevel property to the value specified in $authenticationLevel (default: 5). The change takes effect immediately for new authentication requests.

LAN Manager authentication requirements

• Windows 7 or later, Windows Server 2008 R2 or later

• Administrative privileges to modify HKLM registry

• All systems the endpoint communicates with must support NTLMv2

• Legacy Windows systems (XP, Server 2003) may require lower levels or updated configurations

Expected authentication behavior after remediation

After remediation, the endpoint only sends NTLMv2 authentication responses and refuses to accept LM or NTLMv1 authentication. Network connections to file shares, printers, and other resources succeed when servers support NTLMv2. Connections fail with authentication errors if the remote system requires older protocols.

You can verify the configuration by checking the LMCompatibilityLevel registry value at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa, which should show 5. If you experience authentication failures, check the remote systems for NTLMv2 compatibility and consider deploying this Worklet to those systems as well.

How to validate change lan manager authentication level changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for change lan manager authentication level.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as the evaluation and remediation scripts.

4. Validate remediation effects from script operations such as Get-Item, New-Item, New-ItemProperty, then rerun evaluation for compliance.