Microsoft 已确认，2026 年 9 月发布的安全更新导致部分企业域中的 Windows 11 用户出现登录问题，即使用户名和密码正确，仍会显示域信任或凭据错误。该公司发布了临时解决方案，等待后续更新直接修复根本原因。
该问题与 Machine Identity Isolation 机制有关。在安装适用于 Windows 11 24H2 和 25H2 版本的 KB5124008，以及适用于 Windows 11 26H1 版本的 KB5124012 后，Windows 系统开始遵守当前设置或通过策略强制实施的设置。Microsoft 说明，这些更新不会直接启用该机制，但会使系统应用此前已配置为强制执行的设置。
是什么导致身份验证失败？
这些变化在某些环境中破坏了设备与域控制器之间的信任关系，导致用户无法使用有效凭据登录。用户和 IT 管理员已通过 Microsoft Q&A 论坛、Reddit 及其他平台报告了这一问题。
Microsoft 的文档还警告称，在强制模式下启用 Machine Identity Isolation 后再将其禁用，可能导致域身份验证中断，并可能需要将设备从 Windows 域中移除后再重新加入。
该公司表示，此机制仅支持连接到运行 Windows Server 2025 域功能级别或更高版本的域控制器的环境。因此，应在其他环境中禁用该机制；对于此前已配置为使用该机制、但未连接到满足这一条件的域控制器的设备，也应禁用该机制。
面向系统管理员的临时解决方案
Microsoft 建议使用启用 Machine Identity Isolation 时所采用的相同管理方式将其禁用。如果该设置是通过 Intune 强制实施的，则必须通过 Intune 禁用；如果使用的是 Group Policy，则应修改相应策略本身。
如果该机制是直接通过 Windows 注册表启用的，则在 Windows 11 24H2 或 25H2 设备上应执行以下步骤：
- 检查注册表中的以下两个路径：HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation 和 HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation。
- 如果 MachineIdentityIsolation 的值为 2，则将其设置为 0。
- 禁用该机制后重新启动设备。
- 使用以下命令修复安全通道：Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
实际会发生什么变化？
该问题并不意味着用户凭据已失效，而是部分设备在应用已存在或此前已强制实施的安全设置后，无法再完成与域之间的信任关系。因此，系统管理员首先需要检查 Machine Identity Isolation 的启用方式，而不是随意更改密码，或假定故障源于用户账户。
已发布的解决方案并非最终修复方案；Microsoft 表示正在开发未来更新，以暂时阻止强制实施 Machine Identity Isolation。该公司还发布了紧急更新，用于处理由 9 月更新导致的其他故障，包括 Remote Desktop Services、Hyper-V 和 USB 音频问题，但这些更新并未解决所有已知的音频问题。在进行任何大范围更改前，确定受影响的设备并核实 Windows Server 2025 域功能级别仍是必要步骤。