2026 年 10 月补丁星期二更新 KB5127648 修了“管理员保护”的组策略 bug，却引入了一个更痛的问题：安装后 Windows 11 设备无法通过 802.1X PEAP 认证连接 WPA2-Enterprise Wi-Fi。认证流程能启动但无法完成，WPA2-Personal 网络不受影响。
问题横跨英特尔、高通等多家无线芯片，卸载更新即可恢复，确认是系统级回归而非驱动问题。好消息是有手动修复方案，坏消息是这个修复本身是在回退微软正在淘汰的安全机制。
发生了什么
KB5127648 改变了 Windows 对 NTLMv1 衍生凭据的处理方式。自 Windows 11 24H2 起，微软一直在逐步收紧这类遗留加密的使用，而本次更新似乎将默认行为从“审计模式”推向了“强制阻止模式”。PEAP 认证依赖 MS-CHAPv2，而 MS-CHAPv2 在某些单点登录场景下会生成 NTLMv1 衍生凭据——当 Windows 开始阻止这些凭据时，Wi-Fi 认证就断了。
微软文档明确说明：BlockNtlmv1SSO 注册表值控制 Windows 是审计（0）还是阻止（1）为登录用户生成 NTLMv1 衍生凭据的尝试。微软原计划在 2026 年 10 月将未显式配置的设备默认值改为强制模式——这恰好与 KB5127648 的发布时间吻合。不是 bug 触发了问题，是计划中的安全收紧如期落地，只是落地时砸到了仍在用 PEAP 的企业网络。
临时修复步骤
⚠️ 操作前请评估安全风险：此修复将系统切回审计模式，意味着 Windows 会继续允许微软试图淘汰的遗留认证行为。在部署前务必确认你的网络环境是否仍需 NTLMv1 衍生凭据。
单机修复：
- 以管理员身份打开注册表编辑器
- 导航至
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 - 新建 32 位 DWORD 值
BlockNtlmv1SSO（如已存在则直接修改） - 将值设为
0 - 重启电脑
批量部署（IT 管理员）：
可通过组策略推送该注册表设置。已有管理员确认 GPO 部署有效，适合管理多台受影响设备的环境。
多个用户和管理员已验证此方法可恢复 PEAP 认证。
为什么这不是长久之计
将 BlockNtlmv1SSO 设为 0 只是把时钟拨回了微软收紧安全之前的状态。它恢复了 connectivity，但也恢复了微软认为应该被淘汰的攻击面。Credential Guard 可以缓解部分风险，但前提是设备支持且已启用。
真正的解决方案是迁移到更现代的认证方法（如 EAP-TLS），但这涉及 RADIUS 服务器配置、证书部署和客户端适配，不是改个注册表就能完成的过渡。
现在该怎么办
- 确认症状：仅 WPA2-Enterprise + PEAP 失败，Personal 正常，且问题出现在 KB5127648 安装后
- 评估影响范围：统计受影响的设备和网络，确认是否所有 PEAP 用户都中招
- 短期应急：对关键设备应用注册表修复，优先保障业务连续性
- 安全评审：与信息安全团队确认审计模式下的风险敞口，是否需要额外补偿性控制
- 长期规划：启动 EAP-TLS 或其他现代认证方法的迁移评估，这才是微软希望你走的路
- 监控官方更新：微软可能会发布后续补丁调整默认行为或提供更精细的策略选项
这次事件是一个典型的“安全收紧撞上遗留依赖”案例。微软的计划没有错，企业的现有架构也没有错，错的是两者在时间线上撞车时缺少足够的缓冲和预警。
如果你管着企业 Wi-Fi，今天该做的不只是改注册表，而是认真审视一下：你的认证基础设施，还撑得住下一轮安全收紧吗？
