NTLM 签名强制第一阶段落地 我在一台 Win10 22H2 上跑了七项自查

起因是我在想一个问题：微软说 11 月 10 日起，Windows 客户端在 NTLM 会话里默认会提供消息签名。那我手上这台停在 10 月补丁的 22H2，到底算不算已经进了这个状态？如果算，该看哪个开关；如果不算，我又还能查到什么。

先把官方口径摆清楚。微软 KB5135557 的标题是 NTLM signing security improvements in Windows，发布日期 2026 年 11 月 10 日。里面写了两阶段：第一阶段从 2026 年 11 月 10 日开始，Windows 客户端在全部非匿名连接上默认提供 NTLM 签名，服务器暂时同时接受签名与不签名的客户端，靠审计事件把还在用不签名的客户端找出来；第二阶段计划 2027 年 5 月启动，Windows 服务器默认要求签名，不提供的客户端会被拒绝。



为什么这事值得单独看：KB 里给了两种签名模式。NTLMSSP_NEGOTIATE_SIGN，值 0x00000010，是真的 HMAC-MD5 签名，会话密钥建立起来，伪造不了；NTLMSSP_NEGOTIATE_ALWAYS_SIGN，值 0x00008000，是 16 字节的零占位，没有任何密码学保护。以前的毛病在于，应用程序如果不请求 ISC_REQ_INTEGRITY、ISC_REQ_RELAY_DETECT 或 ISC_REQ_SEQUENCE_DETECT，拿到的就是 ALWAYS_SIGN 那种占位上下文，看着像签了，实际没有。这次改的是让它必须协商到真签名。

有一处我没对上，如实写。KB5135557 里说，11 月 10 日及以后的更新是为了处理 CVE-2026-118737。但同一个编号在 MSRC 漏洞库里是 Windows RPC Runtime 的远程代码执行，Critical，8.1，CWE-347，说要赢一个跟挂起 DNS 查询有关的竞态条件。我没法把这两段描述拼到一起，也不替微软解释，所以下面只按 KB 写的实施时间表、注册表项和事件项来写，不拿那条 CVE 做结论。

下面是实测。机器是 Windows 10 Pro 22H2，build 19045.7807，最近一次更新 KB5126256，安装日期 2026 年 10 月 18 日。

第一项，看两个新开关在不在。

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'

这个键下面现在只有三项：Auth132、NtlmMinClientSec、NtlmMinServerSec。KB 里说的 ClientAllowUnsignedNtlm 和 ServerRequireNtlmSign，一个都没有。

第二项，看 Lsa 根键下的老参数。

LmCompatibilityLevel、RestrictSendingNTLMTraffic、RestrictReceivingNTLMTraffic、AuditReceivingNTLMTraffic，四个都没有显式设置，全部走系统默认。也就是说这台机器既没有限制出站 NTLM，也没有限制入站 NTLM。

第三项，最小会话安全。

NtlmMinClientSec = 0，NtlmMinServerSec = 0。

这两个为 0，意思是不要求 NTLMv2 会话安全，也不要求 128 位加密。
第四项，SMB 签名。

Get-SmbClientConfiguration 里 RequireSecuritySignature=False，EnableSecuritySignature=True。
Get-SmbServerConfiguration 里 RequireSecuritySignature=False，EnableSecuritySignature=False。

客户端是支持但不强制，服务端连支持都没开。

第五项，NTLM 审计通道。

Get-WinEvent -ListLog 'Microsoft-Windows-NTLM/Operational'

能列出来，IsEnabled=True，RecordCount=0。通道在，一条记录没有。

KB 里说 4022（客户端侧）和 4023（服务器侧）这两个事件要在 Windows Server 2019 及以后、并且开了 NTLM 增强审计才有。我这台是客户端系统，通道存在但没数据，算是符合预期，但也说明我没法靠它判断本机有没有在用不签名的 NTLM。

第六项，想直接读 Security 日志里的 8001 到 8004，也就是老的 NTLM 审计事件。没有提权，直接报一句：无法检索到有关 Security 日志的信息，尝试执行未经授权的操作。

第七项，试了 auditpol /get /category:"Account Logon"，返回 0x00000057，参数错误。中文系统上分类名对不上，这一项也要提权才有意义，没继续纠缠。

七项跑完，结论很朴素：这台机器根本没进第一阶段。19045.7807 低于这轮要求的 19045.7846，所以 KB 里那两个注册表项压根没被写进去。ClientAllowUnsignedNtlm 不存在，含义不是默认 0，而是这套逻辑还不在机器上。

这一点我一开始理解错了。我以为键不存在等于取默认值，后来对着 KB 里 Value 0 (default) - Client offers SIGN on all non-anonymous connections 这句才想明白：default 是给装了更新的机器准备的，没装更新的机器上，那段提供签名的代码也还没到。

那这台机器现在能做什么？按 KB 的推导，顺序不能反。先打 11 月更新，让两个键出现；再让 4023 审计跑一段时间，看有没有客户端的 Negotiated Flags 缺 0x10（SIGN）和 0x40000000（KEY_EXCH）；确认没有不签名的连接之后，再把 ServerRequireNtlmSign 置 1。KB 里明确写了，第二阶段被拒的客户端会收到 SEC_E_UNSUPPORTED_FUNCTION，0x80090302，服务器侧记一条 4023 警告。先在服务器上强制、再去做审计，等于自己给自己造一次认证故障。

在同一台机器上，不依赖新开关也能先做的两件事：把 SMB 服务端签名打开，它现在是 Require=False；以及评估 NtlmMinClientSec 和 NtlmMinServerSec 要不要从 0 提上去。前者对外来连接是实打实的降风险，后者得先看环境里还有没有只支持老协议的设备。

KB 里还有一句：服务器不支持 SIGN 时，客户端会自动退回 ALWAYS_SIGN，连接不会失败。所以不报错不等于签名生效，只能抓 flags 看。

这篇的局限得说清楚。单机、非域环境、没有抓到真实的 NTLM 协商过程，4022 和 4023 的实际字段我一个都没验证到；Security 日志没有提权读不了；auditpol 那一项是失败的尝试，不算结论。KB 里附了一段现成的 PowerShell，用来从 4023 里筛掉没有 SIGN 位的连接，我没有可运行的环境去验证它的输出，所以不在这里贴，用之前先自己读一遍参数。

如果也在做这件事，建议先把"我在第几阶段"确认掉，再谈策略。我这台机器就是个反例：以为在准备期，其实还在第零阶段。

来源：
1. Microsoft Support KB5135557，NTLM signing security improvements in Windows（2026-11-10 发布，2026-11-13 查阅）https://support.microsoft.com/help/5135557
2. MSRC，CVE-2026-118737（2026-11-10）https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-118737
3. MS-NLMP，NEGOTIATE_MESSAGE NegotiateFlags（KB 内引用）https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/
4. 本机 PowerShell 实测回显，Windows 10 Pro 22H2 build 19045.7807，2026-11-13 采集
5. 新浪财经对 NTLM 签名强更两阶段时间表的报道（中文二手，用于时间线交叉核对，实施细节以 KB 为准）https://finance.sina.cn/tech/2026-11-12/detail-iniynpnv1137633.d.html

HKTULU
2026-11-13