共用方式為

使用 Credential Guard 時的考慮和已知問題

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 進行委派和一般情況。

Credential Guard 會封鎖 Kerberos 不受限制的委派和 DES。 不建議使用不受限制的委派。

相反地，通常建議 使用 Kerberos 或 交涉 SSP 進行驗證，而針對委派，建議使用 Kerberos 限制委派 和 資源型 Kerberos 限制委派 。 這些方法整體提供更高的認證安全性，而且也與 Credential Guard 相容。

非Microsoft安全性支援提供者考慮

某些非Microsoft安全性支援提供者 (SSP 和IP) 可能與 Credential Guard 不相容，因為它不允許非Microsoft SSP 向 LSA 要求密碼哈希。 不過，當使用者登入及/或變更其密碼時，SSP 和 AP 仍然會取得密碼通知。 不支援在自定義 SSP 和 AP 中使用未記載的 API。

建議使用 Credential Guard 測試 SSP/IP 的自定義實作。 依存於任何未記載或未支援行為的 SSP 和 AP會失敗。 例如，不支援使用 KerbQuerySupplementalCredentialsMessage API。 將 NTLM 或 Kerberos SSP 取代為自訂的 SSP 與 AP。

如需詳細資訊，請參閱 註冊和安裝安全性套件的限制。

儲存的 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 的默認啟用。
問題的原因 如果指定連線的一或兩端嘗試使用已啟用 Credential Guard 的 CredSSP，則使用 Hyper-V 的即時移轉，以及依賴它的應用程式和服務，都會受到此問題影響。 啟用 Credential Guard 後，CredSSP 只能利用提供的認證，而無法儲存或 SSO 認證。

如果即時移轉的來源機器使用 CredSSP 進行委派，且已啟用 Credential Guard，即時移轉就會失敗。 在大部分情況下，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 的合格裝置預設會啟用它。 這會影響 Enterprise (E3 和 E5) 和教育版授權上的所有裝置，以及一些 Pro 授權，只要它們符合 最低硬體需求即可。

先前在合格授權上執行 Credential Guard 且稍後降級為 Pro，但仍符合 最低硬體需求的所有 Windows Pro 裝置都會收到默認啟用。
問題的原因 當應用程式和服務依賴使用密碼型驗證的不安全通訊協定時，會受到此問題影響。 這類通訊協定會被視為不安全，因為它們可能會導致用戶端或伺服器上的密碼洩漏，而 Credential Guard 會封鎖這些通訊協定。 受影響的通訊協定包括：

- SSO 和提供的認證 (Kerberos 不受限制委派都會遭到封鎖)
- 當 PKINIT 使用 RSA 加密而非 Diffie-Hellman (SSO 和提供的認證都遭到封鎖時，Kerberos 會遭到封鎖)
- 只會封鎖 MS-CHAP (SSO)
- 只封鎖 SSO (WDigest)
- 僅封鎖 SSO (NTLM v1)

注意：由於 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 Pro 裝置在升級至 Windows 11 版本 22H2 或 Windows Server 2025 時是否收到預設啟用，請檢查 登錄機碼IsolatedCredentialsRootSecret是否存在於 中Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0。 如果存在，裝置會在更新之後啟用 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。 檢查下列記錄：

事件標識碼 (類型)

描述

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：

下列問題會影響 Java GSS API。 請參閱下列 Oracle 錯誤資料庫文件：

在 Windows 上啟用 Credential Guard 時，Java GSS API 不會進行驗證。 Credential Guard 會封鎖特定的應用程式驗證功能，而且不論登錄機碼設定為何，都不會提供 TGT 會話密鑰給應用程式。 如需詳細資訊，請參閱 應用程式需求。

廠商支援

下列產品和服務不支援 Credential Guard：

重要

這份清單並不完整。 檢查您的產品廠商、產品版本或計算機系統是否在執行特定 Windows 版本的系統上支援 Credential Guard。 特定計算機系統模型可能與 Credential Guard 不相容。