LmCompatibilityLevel Is a Windows Policy, Not a VPN Fix

Someone cannot reach a file share over the VPN, reads that lowering LmCompatibilityLevel fixes NTLM problems, and changes it on a shared server. The next morning other applications fail, and the original problem is still there. The setting was never a per-tunnel switch; it is a machine-wide statement about which authentication responses this system will send and accept. Changing it to fix one logon rewrites the rules for every logon the machine performs.

Reading the documented levels is the fastest way to stop treating a policy value as a magic number.

Three levels, three different promises

Level 1 makes the client send LM and NTLM responses, using NTLMv2 session security when the negotiation allows it. Level 3 makes the client send only NTLMv2 responses, which is not the same thing as refusing every legacy response on the receiving side. Level 5 keeps the client at NTLMv2 and adds the documented domain-controller refusal of LM and NTLMv1. Three numbers, and the gap between them is a policy decision rather than a preference.

Those differences explain why copying a value from a working case is unreliable. Moving a misconfigured client from 1 to the approved baseline can be correct. Moving a hardened deployment from 5 down to 3 because a forum thread mentioned 3 relaxes a boundary somebody chose deliberately, and it does so for every service the machine talks to.

Read the effective policy, not one registry value

A read-only look at the local value is a reasonable starting point: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. An absent value does not mean the effective policy is zero, because a domain or local security policy can set it elsewhere and the machine's role changes what it does with the number.

Check the managed policy, the system role and the actual build before concluding anything. A workstation and a domain controller with the same value behave differently at the top end, which is the part people forget when they compare two machines.

Identify which authentication actually failed

Kerberos ticket problems, NTLM rejections and VPN admission failures need different evidence. Keep the target service, the account and the exact error together in one note, then look at what the service requested rather than at what the client prefers. That one note prevents the most common wrong turn, which is changing a client-side value to answer a server-side refusal.

Repeatedly lowering a policy until a generic logon error disappears is not diagnosis; it is a change that hides the evidence. If the application uses Kerberos, the NTLM compatibility level is not even the relevant control, and you have relaxed a boundary for nothing.

Some protocol support cannot be restored

Windows 11 24H2 and Windows Server 2025 no longer include NTLMv1 network authentication at all. No compatibility number brings back a protocol the build no longer implements, so a downgrade that appeared to help on an older release will simply fail on a newer one. Microsoft documents that removal separately from the policy setting, and conflating the two produces advice that cannot work.

A related but distinct restriction applies to NTLMv1-derived credentials used by MSCHAPv2-based single sign-on. That is a derived-credential question, not the network protocol itself, and not this one registry value. Treating all three as the same topic is how organisations end up weakening one control while trying to fix another.

Change it through the owner, then test both directions

If a correction is genuinely needed, make it through the policy owner so the baseline stays coherent, and record why. Then test an authorized application under the new setting and a deliberately disallowed authentication case, because a change that fixes one share and silently permits legacy responses elsewhere is not a success. A working VPN connection proves that admission succeeded. It does not validate the authentication policy of the machine, and it certainly does not show that every service behind it still behaves as designed.

If the failing service is Kerberos-based, stop looking at this setting entirely. If it is a legacy appliance that genuinely cannot do better, document that exception and scope it, because the alternative is a quietly weakened baseline that nobody remembers approving.