使用 Credential Guard 时的注意事项和已知问题

除了部署 Credential Guard 之外,建议组织从密码转向其他身份验证方法,例如Windows Hello 企业版、FIDO 2 安全密钥或智能卡。

Wi-Fi 和 VPN 注意事项

启用 Credential Guard 后,不能再使用 NTLM 经典身份验证进行单一登录。 你将被迫输入凭据以使用这些协议,并且无法保存凭据以供将来使用。

如果使用基于 MS-CHAPv2 的 WiFi 和 VPN 终结点,它们会受到与 NTLMv1 类似的攻击。

对于 WiFi 和 VPN 连接,建议从基于 MSCHAPv2 的连接 ((例如 PEAP-MSCHAPv2 和 EAP-MSCHAPv2) )迁移到基于证书的身份验证 (,例如 PEAP-TLS 或 EAP-TLS) 。

Kerberos 注意事项

启用 Credential Guard 后,可以不再使用 Kerberos 不受限制的委派或 DES 加密。 不受限制的委派可能允许攻击者从隔离的 LSA 进程中提取 Kerberos 密钥。
改用受限的或基于资源的 Kerberos 委派。

非 Microsoft 安全支持提供程序注意事项

某些非 Microsoft 安全支持提供程序 (SSP 和 AP) 可能与 Credential Guard 不兼容,因为它不允许非 Microsoft SSP 从 LSA 请求密码哈希。 但是,当用户登录和/或更改其密码时,SSP 和 AP 仍会收到与密码相关的通知。 不支持在自定义 SSP 和 AP 中使用未记录的 API。
建议使用 Credential Guard 测试 SSP/AP 的自定义实现。 依靠任何未记录或不受支持的行为的 SSP 和 AP 均会失败。 例如,不支持使用 KerbQuerySupplementalCredentialsMessage API。 使用自定义 SSP 和 AP 替换 NTLM 或 Kerberos SSP。

有关详细信息,请参阅 有关注册和安装安全包的限制

升级注意事项

随着 Credential Guard 提供的保护的深度和广度增加,运行 Credential Guard 的 Windows 新版本可能会影响过去运行的方案。 例如,Credential Guard 可能会阻止使用特定类型的凭据或特定组件,以防止恶意软件利用漏洞。

在使用 Credential Guard 升级设备之前,测试组织中操作所需的方案。

保存的 Windows 凭据注意事项

凭据管理器 允许存储三种类型的凭据:

  • Windows 凭据
  • 基于证书的凭据
  • 通用凭据

凭据 管理器 中存储的域凭据受 Credential Guard 保护。

通用凭据(例如用于登录网站的用户名和密码)不受保护,因为应用程序需要明文密码。 如果应用程序不需要密码副本,则可以将域凭据另存为受保护的 Windows 凭据。 Windows 凭据用于连接到网络上的其他计算机。

以下注意事项适用于凭据管理器的 Credential Guard 保护:

  • 无法将远程桌面客户端保存的 Windows 凭据发送到远程主机。 尝试使用保存的 Windows 凭据失败,显示错误消息 登录尝试失败
  • 提取 Windows 凭据的应用程序失败
  • 从启用了 Credential Guard 的电脑备份凭据时,无法还原 Windows 凭据。 如果需要备份凭据,则必须在启用 Credential Guard 之前备份凭据

TPM 清除注意事项

基于虚拟化的安全 (VBS) 使用 TPM 保护其密钥。 清除 TPM 后,用于加密 VBS 机密的 TPM 保护密钥将丢失。

警告

清除 TPM 将导致所有使用 VBS 保护数据的功能的受保护数据丢失。

清除 TPM 后,使用 VBS 保护数据 的所有 功能都无法再解密其受保护的数据。

因此,Credential Guard 无法再解密受保护的数据。 VBS 为 Credential Guard 创建新的受 TPM 保护的密钥。 Credential Guard 使用新密钥保护新数据。 但是,之前受保护的数据将永远丢失。

注意

Credential Guard 在初始化期间获取密钥。 数据丢失只会影响永久性数据,并在下次系统启动后发生。

Windows 凭据被保存到凭据管理器

由于凭据管理器无法解密已保存的 Windows 凭据,因此会将其删除。 应用程序应提示之前保存的凭据。 如果再次保存,Windows 凭据将受 Credential Guard 保护。

已加入域的设备自动预配的公钥

已加入域的 Active Directory 设备会自动预配绑定公钥,有关自动公钥预配的详细信息,请参阅 已加入域的设备公钥身份验证

由于 Credential Guard 无法解密受保护的私钥,因此 Windows 使用已加入域的计算机的密码对域进行身份验证。 除非部署了其他策略,否则不应丢失功能。 如果设备配置为仅使用公钥,则在禁用该策略之前,它无法使用密码进行身份验证。 有关将设备配置为仅使用公钥的详细信息,请参阅加入域的设备的公钥身份验证

此外,如果任何访问控制检查(包括身份验证策略)要求设备具有 KEY TRUST IDENTITY (S-1-18-4)FRESH PUBLIC KEY IDENTITY (S-1-18-3) 已知的 SID,则这些访问检查将失败。 有关身份验证策略的详细信息,请参阅 身份验证策略和身份验证策略接收器。 有关已知 SID 的详细信息,请参阅 [MS-DTYP] 第 2.4.2.4 节已知的 SID 结构

破坏已加入域的设备上的 DPAPI

在已加入域的设备上,DPAPI 可以使用来自用户域的域控制器恢复用户密钥。 如果已加入域的设备无法连接到域控制器,则无法恢复。

重要提示

在已加入域的设备上清除 TPM 的最佳做法是通过连接到域控制器的网络。 这将保障 DPAPI 的正常功能,帮助用户避免异常行为。

自动 VPN 配置由用户 DPAPI 提供保护。 用户可能无法使用 VPN 连接到域控制器,因为 VPN 配置已丢失。 如果你必须清除已加入域但未连接到域控制器的设备上的 TPM,则应该考虑以下事项。

在清除 TPM 后,只要未连接到域控制器,域用户即可在已加入域的设备上登录:

凭据类型 行为
证书(智能卡或 Windows Hello 企业版) 使用用户 DPAPI 保护的所有数据都不可用,并且用户 DPAPI 根本不起作用。
密码 如果用户在清除 TPM 之前使用证书或密码登录,则可以使用密码登录,并且用户 DPAPI 不受影响。

设备连接到域控制器后,DPAPI 会恢复用户密钥,且在清除 TPM 之前受保护的数据可以解密。

DPAPI 故障对 Windows 信息保护的影响

当使用用户 DPAPI 保护的数据不可用时,用户将断开对由 Windows 信息保护进行保护的所有工作数据的访问。 影响包括:Outlook 无法启动,无法打开工作受保护的文档。 如果 DPAPI 正在工作,那么新创建的工作数据将受到保护并可以访问。

解决方法:用户可以通过将其设备连接到域并重新启动或使用其加密文件系统数据恢复代理证书来解决该问题。 有关加密文件系统数据恢复代理证书的详细信息,请参阅创建和验证加密文件系统 (EFS) 数据恢复代理 (DRA) 证书

已知问题

Credential Guard 阻止某些身份验证功能。 启用 Credential Guard 后,需要此类功能的应用程序将不起作用。

本文介绍启用 Credential Guard 时的已知问题。

升级到 Windows 11 版本 22H2 后,网络服务的单一登录中断

使用 802.1x 无线或有线网络、RDP 或 VPN 连接的设备(这些连接依赖于不安全的协议和基于密码的身份验证)的设备无法使用 SSO 登录,并且当 Credential Guard 正在运行时,必须在每个新的 Windows 会话中手动重新进行身份验证。

受影响的设备

任何启用了 Credential Guard 的设备都可能会遇到此问题。 作为Windows 11版本 22H2 更新的一部分,未禁用 Credential Guard 的合格设备默认启用它。 这会影响企业版 (E3 和 E5) 和教育版许可证以及某些专业版许可证(只要它们满足 最低硬件要求)上的所有设备。

以前在符合条件的许可证上运行 Credential Guard,后来降级到专业版,但仍满足 最低硬件要求的所有 Windows 专业版设备都将获得默认启用。

提示

若要确定 Windows 专业版设备在升级到 Windows 11 版本 22H2 时是否收到默认启用,检查中Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0是否存在注册表项IsolatedCredentialsRootSecret。 如果存在,则设备在更新后启用 Credential Guard。

可以在升级后按照 禁用说明禁用 Credential Guard。

问题的原因

当应用程序和服务依赖于使用基于密码的身份验证的不安全协议时,它们会受到此问题的影响。 此类协议被视为不安全,因为它们可能导致客户端或服务器上的密码泄露,并且 Credential Guard 会阻止它们。 受影响的协议包括:

  • 阻止 kerberos 不受约束的委派 (SSO 和提供的凭据)
  • 当 PKINIT 使用 RSA 加密而不是 Diffie-Hellman (SSO 和提供的凭据时,Kerberos 会被阻止)
  • MS-CHAP (仅 SSO 被阻止)
  • WDigest 仅 (SSO 被阻止)
  • NTLM v1 (仅阻止 SSO)

注意

由于仅阻止 MS-CHAP、WDigest 和 NTLM v1 的 SSO,因此仍可通过提示用户提供凭据来使用这些协议。

如何确认问题

MS-CHAP 和 NTLMv1 与 Windows 11 版本 22H2 更新后的 SSO 中断相关。 若要确认 Credential Guard 是否阻止了 MS-CHAP 或 NTLMv1,请打开事件查看器 (eventvwr.exe) 并转到 Application and Services Logs\Microsoft\Windows\NTLM\Operational。 检查以下日志:

事件 ID (类型)

Description

4013 (警告)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (错误)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

如何修复问题

建议从基于 MSCHAPv2 的连接(例如 PEAP-MSCHAPv2 和 EAP-MSCHAPv2)转向基于证书的身份验证,例如 PEAP-TLS 或 EAP-TLS。 Credential Guard 不会阻止基于证书的身份验证。

对于更直接但不太安全的修复, 请禁用 Credential Guard。 Credential Guard 没有按协议或按应用程序策略,可以打开或关闭它。 如果禁用 Credential Guard,则存储的域凭据很容易被盗。

提示

若要防止默认启用,请将设备配置为在更新到 Windows 11 版本 22H2 之前禁用 Credential Guard。 如果未将设置配置为 (默认状态) 并且设备符合条件,则设备会在更新后自动启用 Credential Guard。

如果 Credential Guard 被显式禁用,则设备在更新后不会自动启用 Credential Guard。

非 Microsoft 应用程序的问题

以下问题影响 MSCHAPv2:

以下问题影响 Java GSS API。 请参阅以下 Oracle Bug 数据库文章:

在 Windows 上启用 Credential Guard 时,Java GSS API 不会进行身份验证。 Credential Guard 会阻止特定的应用程序身份验证功能,并且不向应用程序提供 TGT 会话密钥,而不管注册表项设置如何。 有关详细信息,请参阅 应用程序要求

供应商支持

以下产品和服务不支持 Credential Guard:

重要提示

此列表并不全面。 检查产品供应商、产品版本或计算机系统是否在运行特定 Windows 版本的系统上支持 Credential Guard。 特定计算机系统模型可能与 Credential Guard 不兼容。