LmCompatibilityLevel 是 Windows 的策略，不是 VPN 的修复项

有人通过 VPN 访问不了文件共享，读到降低 LmCompatibilityLevel 能解决 NTLM 问题，就在一台共享服务器上改了它。第二天早上其他应用开始出错，而原先的问题依然存在。这个设置从来不是针对某条隧道的开关；它是整台机器层面的声明，说明系统会发送和接受哪些身份验证响应。为了修好一次登录而改它，等于重写这台机器每一次登录的规则。

读一读有文档的级别，是停止把某个策略值当成魔法数字的最快办法。

三个级别，三种不同的承诺

级别 1 让客户端发送 LM 和 NTLM 响应，并在协商允许时使用 NTLMv2 会话安全。级别 3 让客户端只发送 NTLMv2 响应，这与在接收端拒绝所有旧式响应并不是一回事。级别 5 让客户端保持在 NTLMv2，并加上文档所述的域控制器对 LM 和 NTLMv1 的拒绝。三个数字，它们之间的差距是策略决定，而不是偏好。

这些差异说明了为什么从能用的案例里照搬数值并不可靠。把配置错误的客户端从 1 调到已批准的基线可能是对的。只因为论坛帖子里提到 3，就把加固过的部署从 5 降到 3，等于放松了某人有意选定的边界，而且是对这台机器所通信的每一项服务都如此。

读生效的策略，而不是一个注册表值

以只读方式查看本地值是一个合理的起点：Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel。值不存在并不代表生效策略是零，因为域策略或本地安全策略可能在别处设置它，而机器的角色会改变它对这数字的处理方式。

在下任何结论之前，先检查受管策略、系统角色和实际版本。数值相同的工作站和域控制器在上限一侧表现不同，而这正是人们比较两台机器时容易忘记的部分。

判断究竟是哪种身份验证失败

Kerberos 票据问题、NTLM 被拒和 VPN 接入失败需要不同的证据。把目标服务、账户和确切的错误记在同一条笔记里，然后去看服务请求了什么，而不是客户端偏好什么。这一条笔记能挡住最常见的错误转向：改动客户端侧的值，去回应服务器侧的拒绝。

反复降低策略直到那条笼统的登录错误消失，并不是诊断；这是一种掩盖证据的改动。如果应用用的是 Kerberos，NTLM 兼容级别根本就不是相关的控制项，而你已经白白放松了一道边界。

有些协议支持无法恢复

Windows 11 24H2 和 Windows Server 2025 已经完全不再包含 NTLMv1 网络身份验证。没有任何兼容级别数字能把版本已不再实现的协议找回来，所以在旧版本上似乎有效的降级，在新版本上只会失败。Microsoft 把这次移除与策略设置分开记载，把两者混为一谈会得出根本无法奏效的建议。

一项相关但不同的限制适用于基于 MSCHAPv2 的单点登录所使用的、由 NTLMv1 派生的凭据。这是派生凭据的问题，不是网络协议本身的问题，也不是这一个注册表值的问题。把三者当成同一件事，正是组织在试图修好一项控制时悄悄削弱另一项的原因。

通过策略所有者去改，然后两个方向都测

如果确实需要修正，请通过策略所有者来做，以保持基线一致，并记录原因。然后在新设置下测试一个被授权的应用，以及一个被刻意禁止的身份验证场景，因为只修好一个共享、却在别处悄悄放行旧式响应的改动不算成功。VPN 能连上，只能证明接入成功了。它并不验证这台机器的身份验证策略，更不能说明其背后的每一项服务仍按设计运行。

如果出问题的服务基于 Kerberos，那就彻底别再看这个设置。如果确实是无法做得更好的老旧设备，就把这项例外记录下来并限定范围，因为替代方案是一条被悄悄削弱、谁都不记得批准过的基线。