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

• 适用于:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

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

升级注意事项

随着 Credential Guard 的发展和增强其安全功能，运行 Credential Guard 的较新版本的 Windows 可能会影响以前的功能方案。 例如，Credential Guard 可能会限制某些凭据或组件的使用，以阻止利用漏洞的恶意软件。

建议在更新使用 Credential Guard 的设备之前，在组织中全面测试操作方案。

升级到 Windows 11、版本 22H2 和 Windows Server 2025 时，默认情况下会启用 Credential Guard，除非显式禁用。

Wi-Fi 和 VPN 注意事项

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

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

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

委派注意事项

启用 Credential Guard 后，某些类型的标识委派不可用，因为其基础身份验证方案与 Credential Guard 不兼容，或者需要提供的凭据。

启用 Credential Guard 后， 凭据安全支持提供程序 (“CredSSP”) 不再能够使用保存的凭据或 SSO 凭据，但仍可以提供明文凭据。 基于 CredSSP 的委派要求在目标计算机上提供明文凭据，一旦启用了 Credential Guard 并阻止明文凭据泄露，则无法使用 SSO。 由于凭据被盗的风险，不建议 使用 CredSSP 进行委派和一般使用。

Kerberos 不受约束委派和 DES 被 Credential Guard 阻止。 建议不要使用不受约束的委派。

通常建议使用 Kerberos 或 Negotiate SSP 进行身份验证，对于委派，建议使用 Kerberos 约束委派 和 基于资源的 Kerberos 约束委派 。 这些方法整体提供更高的凭据安全性，并且还与 Credential Guard 兼容。

非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。

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

保存的 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 Server 2025 时使用 Hyper-V 中断的实时迁移

升级到 Windows Server 2025 后，使用基于 CredSSP 的委派的设备可能无法再 将实时迁移与 Hyper-V 配合使用。 依赖于实时迁移 (（如 SCVMM) ）的应用程序和服务也可能受到影响。 基于 CredSSP 的委派是 Windows Server 2022 及更早版本的默认委派，用于实时迁移。

	描述
受影响的设备	任何启用了 Credential Guard 的服务器都可能会遇到此问题。 从 Windows Server 2025 开始，默认情况下， 凭据防护 在不属于域控制器的所有已加入域的服务器上启用。 在升级之前，可以 先行阻止 Credential Guard 的默认启用。
问题的原因	如果给定连接的一端或两端尝试使用启用了 Credential Guard 的 CredSSP，则使用 Hyper-V 的实时迁移以及依赖它的应用程序和服务将受到问题的影响。 启用 Credential Guard 后，CredSSP 只能使用提供的凭据，而不能使用保存的凭据或 SSO 凭据。 如果实时迁移的源计算机在启用了 Credential Guard 的情况下使用 CredSSP 进行委派，则实时迁移会失败。 在大多数情况下，Credential Guard 在目标计算机上的启用状态不会影响实时迁移。 实时迁移在群集方案中也会失败， (例如 SCVMM) ，因为任何设备都可能充当源计算机。
解决方案	建议使用 Kerberos 约束委派和 Resource-Based Kerberos 约束委派 ，而不是 CredSSP 委派。 除了与 Credential Guard 兼容外，这些委派形式还提供更大的凭据保护。 Hyper-V 的管理员可以手动或在自动化脚本的帮助下 配置这些委派类型 。

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

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

	描述
受影响的设备	任何启用了 Credential Guard 的设备都可能会遇到此问题。 从 Windows 11、版本 22H2 和 Windows Server 2025（未禁用 Credential Guard 的合格设备）开始，默认启用它。 这会影响企业版 (E3 和 E5) 和教育版许可证以及某些 Pro 许可证上的所有设备，只要它们满足 最低硬件要求。 以前在符合条件的许可证上运行 Credential Guard，后来降级为专业版，但仍满足 最低硬件要求的所有 Windows 专业版设备都会获得默认启用。
问题的原因	当应用程序和服务依赖于使用基于密码的身份验证的不安全协议时，它们会受到此问题的影响。 此类协议被视为不安全，因为它们可能导致客户端或服务器上的密码泄露，并且 Credential Guard 会阻止它们。 受影响的协议包括： - 阻止 kerberos 不受约束的委派 (SSO 和提供的凭据) - 当 PKINIT 使用 RSA 加密而不是 Diffie-Hellman (SSO 和提供的凭据被阻止时，Kerberos) - MS-CHAP (仅阻止 SSO) -) 阻止 WDigest (仅 SSO - NTLM v1 (仅阻止 SSO) 注意：由于 MS-CHAP、WDigest 和 NTLM v1 仅阻止 SSO，因此仍可通过提示用户提供凭据来使用这些协议。
解决方案	Microsoft建议从基于 MSCHAPv2 的连接 (（例如，PEAP-MSCHAPv2 和 EAP-MSCHAPv2) ）转向基于证书的身份验证 (例如 PEAP-TLS 或 EAP-TLS) 。 Credential Guard 不会阻止基于证书的身份验证。 对于更直接但不太安全的修复， 请禁用 Credential Guard。 Credential Guard 没有按协议或按应用程序策略，可以打开或关闭它。 如果禁用 Credential Guard，则存储的域凭据很容易被盗。

提示

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

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

注意

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

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

如何确认问题

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"
/>

非Microsoft应用程序的问题

以下问题影响 MSCHAPv2：

• Credential Guard 不适用于 MSCHAPv2 配置，其中 Cisco ISE 是常见的企业实现。

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

• JDK-8161921：Credential Guard 不允许与 Java 共享 TGT

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

供应商支持

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

• Check Point Endpoint Security Client 支持Microsoft Credential Guard 和 Hypervisor-Protected 代码完整性功能
• Windows 10主机上的 VMware 工作站和设备/凭据防护不兼容错误 (2146361)
• Microsoft Windows 中对 Hypervisor-Protected 代码完整性和凭据防护的 ThinkPad 支持
• 具有 Credential Guard 和 Symantec Endpoint Protection 12.1 的 Windows 设备

重要提示

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