嗨，我来帮你搞定这个LanMan/NTLMv1的漏洞问题！虽然网上大多是老系统的资料，但Server 2016的修复思路是相通的，操作起来反而更清晰。

修复步骤 #

• 通过组策略禁用LanMan/NTLMv1（推荐方式）

  1. 按下Win+R输入gpedit.msc打开组策略编辑器
  2. 依次导航到：计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 安全选项
  3. 找到两个关键策略项并修改：
     • 网络安全：LAN Manager 身份验证级别：推荐设置为仅发送 NTLMv2 响应\拒绝 LM（更严格），也可以先选发送 NTLMv2 响应\拒绝 LM & NTLM做过渡
     • 网络安全：限制 NTLM：NTLM 身份验证在本域：如果环境内没有依赖NTLMv1的设备，可设为拒绝所有；如果不确定，先设为拒绝域账户观察运行情况
  4. 运行gpupdate /force刷新组策略，多数场景无需重启即可生效（部分服务可能需要手动重启）

• 通过注册表手动配置（组策略不适用时）

  1. Win+R输入regedit打开注册表编辑器
  2. 定位到路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  3. 修改LmCompatibilityLevel的DWORD值：
     • 值为4：仅发送NTLMv2响应，拒绝LM和NTLMv1请求
     • 值为5：彻底拒绝LM和NTLMv1，只接受NTLMv2
  4. 重启服务器让更改生效

潜在风险及注意事项 #

• 旧设备/应用兼容性问题：如果你的环境里还有Windows XP、Server 2003这类老系统，或者有依赖NTLMv1的遗留应用（比如工业控制系统、旧版客户端软件），禁用后这些设备/应用大概率会认证失败，导致无法访问资源。
• 服务账户异常：有些旧服务可能默认配置为使用NTLMv1认证，禁用后要检查这些服务的运行状态，必要时更新服务的认证方式或者调整服务账户权限。
• 域信任关系影响：如果你的域和其他老域存在信任关系，或者有跨域的旧系统访问需求，可能会出现信任失效的情况，建议修复前先在测试环境验证跨域访问是否正常。

我的建议是，修复前先在测试环境复刻生产场景验证，或者先设置较宽松的级别（比如值4）运行一段时间，确认没有兼容性问题后再升级到更严格的5，这样能最大程度降低风险。

备注：内容来源于stack exchange，提问作者Sloughi