Change LAN Manager Authentication Level

What the LAN Manager authentication enforcer does

This Automox Worklet™ enforces the LAN Manager authentication compatibility level on Windows endpoints by setting LMCompatibilityLevel under HKLM:\SYSTEM\CurrentControlSet\Control\Lsa to the value held in $authenticationLevel (default 5). Level 5 maps to the CIS Benchmarks setting "Send NTLMv2 response only. Refuse LM and NTLM," and is the highest of the six levels Microsoft defines for this key.

The Worklet treats the setting as continuous-enforcement state rather than a one-shot configuration. The evaluation script exits non-zero on every run, which schedules the remediation script every cycle. The remediation script then re-asserts the registry value, so a Group Policy refresh, a manual change by a local admin, or a software installer that downgrades the setting is corrected on the next Automox policy run rather than waiting for the next audit.

The same Worklet covers domain controllers, member servers, and workstations from Windows 7 / Server 2008 R2 forward. The registry path and value name are identical across SKUs, and the script uses Get-Item, New-Item, and New-ItemProperty so it works whether the Lsa key exists or has been pruned by a hardening tool. Set $authenticationLevel to a different value (0–5) in the policy if your environment still requires a transitional setting, but the default of 5 is the value that closes the LM / NTLMv1 attack surface completely.

Why enforce NTLMv2-only authentication

LM and NTLMv1 are the authentication protocols an attacker hopes to find. LM hashes use DES with a 7-byte key and no salt and are recovered in minutes on a modern GPU. NTLMv1 challenge-response is still vulnerable to chosen-plaintext attacks and to NTLM relay, where an attacker captures authentication on the wire (Responder) and replays it against a target service (ntlmrelayx) to obtain code execution or remote registry access. CIS Microsoft Windows Benchmarks control 2.3.11.7 ("Network security: LAN Manager authentication level") prescribes Level 5 for exactly this reason, and DISA STIG WN10-SO-000205 calls out the same registry value as a hardening requirement on Windows endpoints.

LM and NTLMv1 exposure is one of the oldest and most reliable findings in every red-team report, and the fix has been documented since 2004: set LMCompatibilityLevel to 5 under HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. This Worklet writes that value on every Windows endpoint in scope, covers domain controllers, member servers, and workstations from Windows 7 / Server 2008 R2 forward, and re-asserts the setting on each policy run to catch drift from group policy overrides or in-place upgrades.

How LAN Manager level enforcement works

1. Evaluation phase: The evaluation script exits 1 unconditionally, which marks the endpoint non-compliant and schedules remediation on every policy cycle. This force-run pattern is intentional for hardening Worklets: the registry value can be silently flipped back by Group Policy, an MDM profile, or a downstream installer, and the Worklet acts as the watchdog that puts it back. If you prefer drift-detection semantics instead, change the evaluation to read (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LMCompatibilityLevel).LMCompatibilityLevel and exit 0 only when it equals $authenticationLevel.

2. Remediation phase: The remediation script wraps Get-Item -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa in a try/catch and, if the key is missing, creates it with New-Item -Force. It then writes the value with New-ItemProperty -Path $key.PSPath -Name LMCompatibilityLevel -Value $authenticationLevel. The change takes effect for new authentication sessions immediately and persists across reboots through the SYSTEM hive. If your Lsa key already holds a non-default LMCompatibilityLevel, add -Force to the New-ItemProperty call (or delete the existing value first) so the assignment overwrites cleanly on every run.

LAN Manager hardening requirements

• Windows 7 / Server 2008 R2 or later, including Windows 10, Windows 11, Server 2012 R2, 2016, 2019, and 2022

• Local administrator rights to write to HKLM (the Automox agent runs as SYSTEM by default and already meets this)

• Every server, appliance, and printer the endpoint authenticates against must support NTLMv2; modern Windows, Samba 4, and current NAS firmware all do

• If Group Policy already manages "Network security: LAN Manager authentication level," align this Worklet's value with the GPO so the two do not fight each other

• Optional companion setting: NoLMHash under the same Lsa key (DWORD = 1) prevents Windows from storing LM hashes locally and is worth deploying as a follow-on policy

Expected authentication state after remediation

After the Worklet runs, the endpoint sends NTLMv2 responses only and refuses to send or accept LM and NTLM. SMB, MSRPC, LDAP, and HTTP-NTLM authentication against modern servers continue to work unchanged. A legacy host that still requires LM or NTLMv1 returns an authentication failure, which is the audit signal you want – it surfaces the systems that need an upgrade or a documented exception rather than letting them silently lower the entire fleet's posture.

Validate from PowerShell with (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LMCompatibilityLevel).LMCompatibilityLevel, which should return 5. From a domain admin workstation, run gpresult /h report.html and search for "LAN Manager authentication level" to confirm no Group Policy is overriding the value. For audit evidence, export the Lsa key with reg export HKLM\SYSTEM\CurrentControlSet\Control\Lsa lsa-baseline.reg and attach it to the policy run identifier. The setting persists across reboots and Windows feature updates, and the next Automox evaluation re-applies it if anything – Group Policy refresh, a misbehaving installer, a security tool's "compatibility" toggle – tries to roll it back.