Windows服务器安全配置NTLM身份验证级别

Windows服务器的NTLM身份验证级别直接决定了网络登录的安全性强度，它通过一系列策略控制NTLM协议的交互方式，从完全禁用旧协议到强制使用更安全的版本。不当配置可能导致凭证传递攻击或兼容性问题。核心解决路径是在组策略中精准设置“网络安全：LAN管理器身份验证级别”，根据环境需求选择从“仅发送NTLMv2响应”到“仅拒绝LM和NTLM”等六级策略，并结合禁用LM哈希存储、启用SMB签名等配套措施，构建纵深防御。

NTLM协议是Windows网络身份验证的基石，但其演进过程中留下了安全隐患。最初是LM（LAN Manager），它使用弱加密且密码被拆分为两部分处理，极易被破解。随后是NTLMv1，安全性有所提升但仍存在缺陷，例如响应机制可能被重放攻击。目前主流是NTLMv2，它引入了时间戳和增强的加密算法，能有效抵御中间人攻击和重放攻击。然而，许多服务器为了兼容旧客户端或应用程序，默认允许较弱的LM或NTLMv1响应，这为攻击者提供了利用漏洞发起“传递哈希”或“中继攻击”的机会，直接威胁服务器安全。

在Windows服务器上，关键配置项是“网络安全：LAN管理器身份验证级别”（策略路径：计算机配置 > Windows设置 > 安全设置 > 本地策略 > 安全选项）。它提供从0到5六个可选值，每个值代表不同的安全严格程度：

级别0 – 发送LM和NTLM响应： 这是最不安全的选项，客户端会使用LM和NTLM进行身份验证，仅在服务器拒绝时尝试NTLMv2。除非环境中有无法更新的古董级系统，否则应避免使用。

级别1 – 使用NTLMv2会话安全时发送LM和NTLM响应： 安全性略有提升，但依然允许弱协议。当协商会话安全时，才可能使用NTLMv2。

级别2 – 仅发送NTLM响应： 禁用LM，但允许NTLMv1。这比级别0和1安全，但NTLMv1的漏洞依然存在。

级别3 – 仅发送NTLMv2响应： 这是许多现代环境的推荐起点。客户端强制使用NTLMv2，服务器接受NTLMv2。它平衡了安全性与兼容性，大部分新版Windows和现代应用都能良好支持。

级别4 – 仅发送NTLMv2响应\拒绝LM： 域控制器拒绝LM身份验证，仅接受NTLM和NTLMv2。这进一步收紧策略。

级别5 – 仅发送NTLMv2响应\拒绝LM和NTLM： 这是最严格的级别。域控制器完全拒绝LM和NTLMv1，只接受NTLMv2响应。这是最高安全配置，但要求所有客户端和设备都必须支持NTLMv2，否则会导致身份验证失败。

配置主要通过组策略编辑器或本地安全策略完成。对于单台服务器，可以运行"secpol.msc"打开本地安全策略，导航到上述路径，双击策略进行设置。对于域环境，应在域组策略对象中配置以实现统一管理。此外，也可以通过PowerShell命令快速查询和设置：

# 查询当前NTLM身份验证级别
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"

# 设置级别为3（仅发送NTLMv2响应）
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" -Value 3

修改后需要重启服务器或等待策略刷新生效。建议在测试环境中先行验证，确保所有关键业务应用和登录流程不受影响。

仅调整身份验证级别是不够的，必须结合其他安全策略形成组合拳：

禁用LM哈希存储： 在同一个安全选项节点中，找到“网络安全：不要在下次更改密码时存储LAN管理器哈希值”，将其设置为“已启用”。这可以防止系统在SAM数据库或Active Directory中保存脆弱的LM哈希，即使密码本身很强。

启用SMB签名： NTLM中继攻击常利用未签名的SMB流量。应启用“Microsoft网络服务器：数字签名的通信（始终）”和“Microsoft网络客户端：数字签名的通信（始终）”，强制对SMB数据包进行签名，防止数据被篡改或中继。

限制NTLM使用范围： 在高级安全审核策略中，启用“审核NTLM”相关策略，监控网络中的NTLM使用情况。更进一步，可以在“安全设置 > 本地策略 > 安全选项”中配置“网络安全：限制NTLM”相关策略，在可能的情况下，逐步将应用迁移到更安全的Kerberos协议，并禁止不必要的NTLM流量。

强化账户策略： 设置强密码策略和账户锁定策略，增加攻击者暴力破解的难度。这是防御凭证攻击的基础。

将级别设置为4或5时，最大的挑战是兼容性。一些旧版操作系统、嵌入式设备、特定版本的Linux Samba客户端或老旧业务软件可能无法支持NTLMv2。在实施前，应进行全面的应用兼容性测试。排查身份验证失败时，首先检查服务器安全事件日志（事件ID 4624为成功登录，4625为失败登录），失败事件会包含身份验证包和失败原因。同时，在客户端和服务器端启用NTLM审核日志，可以详细追踪NTLM请求的来源和类型。对于必须使用旧协议的极少数情况，可以考虑通过网络隔离将其限制在特定网段，而非降低整个服务器的安全标准。

尽管强化NTLM配置至关重要，但NTLM本身已被微软视为遗留协议。长远来看，企业应积极规划向更现代、更安全的身份验证框架迁移。Kerberos是Active Directory域环境的默认首选，它支持双向认证且效率更高。对于云和混合环境，应推广使用基于证书的身份验证或Windows Hello for Business。对于面向互联网的服务，应逐步淘汰NTLM，转而采用OAuth 2.0、OpenID Connect等现代协议。服务器安全配置并非一劳永逸，定期审计身份验证日志、关注微软安全公告、及时更新和调整策略，才能构建动态、弹性的安全防线。