如何設定 Microsoft Entra 憑證式驗證

發行項
11/24/2024

Microsoft Entra 憑證式驗證 (CBA) 可讓組織設定其 Microsoft Entra 租用戶，允許或要求使用者以企業公開金鑰基礎結構 (PKI) 建立的 X.509 憑證驗證來登入應用程式和瀏覽器。這項功能可讓組織使用 X.509 憑證採用防網路釣魚的新式無密碼驗證。

登入期間，使用者也會看到使用憑證進行驗證的選項，而不是輸入密碼。如果裝置上有多個相符的憑證，則使用者可以選擇要使用哪一個憑證。憑證驗證通過使用者帳戶後，如果成功，使用者帳戶即可登入。

請遵循下列指示，為 Office 365 企業版和美國政府方案中的租用戶設定及使用 Microsoft Entra CBA。您應該已設定公開金鑰基礎結構 (PKI)。

必要條件

確定滿足下列必要條件：

在 entra 識別碼 Microsoft中，至少設定一個證書頒發機構單位（CA）和任何中繼 CA。
使用者必須能夠存取用於用戶端驗證的使用者憑證 (從租用戶上設定的受信任公開金鑰基礎結構簽發)，以針對 Microsoft Entra ID 進行驗證。
每個 CA 都應該有憑證撤銷清單 (CRL)，可從網際網路對應的 URL 參考。如果受信任的 CA 未設定 CRL，Microsoft Entra ID 不會執行任何 CRL 檢查、撤銷使用者憑證無法運作，也不會封鎖驗證。

重要

請確定 PKI 是安全的，且不容易遭到入侵。當遭到入侵時，攻擊者可以建立並簽署用戶端憑證，入侵租用戶中的任何使用者，包括從內部部署同步的使用者和僅限雲端使用者。不過，強式金鑰保護原則以及其他實體和邏輯控制項 (例如 HSM 啟用卡或用於安全儲存成品的權杖) 可以提供深度防禦，以防止外部攻擊者或內部威脅危害 PKI 的完整性。如需詳細資訊，請參閱保護 PKI。

重要

請瀏覽 Microsoft 建議，以取得Microsoft 密碼編譯的最佳做法，包括演算法選擇、金鑰長度和資料保護。請務必使用其中一個建議的演算法、金鑰長度和 NIST 核准的曲線。

重要

作為持續安全性改善的一部分，Azure/M365 端點正在新增 TLS1.3 的支援，此流程預計需要幾個月的時間才能涵蓋 Azure/M365 中的數千個服務端點。這包括 Microsoft Entra 憑證式驗證 (CBA) *.certauth.login.microsoftonline.com 和 *.certauth.login.microsoftonline.us 所使用的 Microsoft Entra 端點。 TLS 1.3 是最新版本的網際網路最多部署的安全性通訊協定，可加密資料，以提供兩個端點之間的安全通訊通道。 TLS 1.3 可消除過時的密碼編譯演算法、增強舊版的安全性，並旨在儘可能加密大部分的交握。強烈建議開發人員開始在其應用程式和服務中測試 TLS 1.3。

注意

評估 PKI 時，請務必檢閱憑證發行原則和施行。如前所述，將憑證授權單位 (CA) 新增至 Microsoft Entra 設定，即可讓這些 CA 簽發的憑證驗證 Microsoft Entra ID 中的所有使用者。因此，請務必考慮 CA 簽發憑證的方式和時機，以及其如何實作可重複使用的識別碼。系統管理員必須確保只有特定憑證能夠用來驗證使用者，只有系統管理員可以使用高親和性繫結，從更高的層級確保只有特定憑證能夠驗證使用者。如需詳細資訊，請參閱高親和性繫結。

設定及測試 Microsoft Entra CBA 的步驟

啟用 Microsoft Entra CBA 之前，必須先完成一些設定步驟。首先，系統管理員必須設定可發出使用者憑證的受信任 CA。如以下圖表所示，我們會使用角色型存取控制，確保只需要擁有最低權限的系統管理員即可執行變更。

管理此功能需要全域系統管理員。

或者，您也可以設定驗證繫結，將憑證對應至單一要素或多重要素驗證，並設定使用者名稱繫結，將憑證欄位對應至使用者物件屬性。驗證原則系統管理員可以設定使用者相關設定。完成所有設定之後，請在租用戶上啟用 Microsoft Entra CBA。

圖表顯示啟用 Microsoft Entra 憑證式驗證所需的步驟。

步驟 1：使用 PKI 型信任存放區設定證書頒發機構單位（預覽）

Entra 有新的公鑰基礎結構（PKI）型證書頒發機構單位（CA）信任存放區。 PKI 型 CA 信任存放區會將 CA 保留在每個不同 PKI 的容器物件內。系統管理員可以根據 PKI 在容器中管理 CA，比一般 CA 清單更容易。

PKI 型信任存放區對於 CA 數目和每個 CA 檔案的大小有較高的限制。 PKI 型信任存放區針對每個 CA 物件支援最多 250 個 CA 和 8 KB 大小。強烈建議您使用新的 PKI 型信任存放區來儲存 CA，其可調整並支援簽發者提示等新功能。

注意

如果您使用舊的信任存放區來設定 CA，建議您設定以 PKI 為基礎的信任存放區。

系統管理員必須設定簽發用戶憑證的受信任 CA。只需要具備最低許可權的系統管理員才能進行變更。以 PKI 為基礎的信任存放區具有 RBAC 角色許可權驗證系統管理員和驗證管理員。

PKI 型信任存放區的上傳 PKI 功能僅適用於 Microsoft Entra ID P1 或 P2 授權。不過，使用免費授權，系統管理員也可以個別上傳所有 CA，而不是 PKI 檔案，並設定以 PKI 為基礎的信任存放區。

重要

由於新商店存在已知問題，建議不要刪除舊商店中的所有 CA，並且至少在舊商店中保留一個 CA。我們正努力修正此問題，以移除限制。

使用 Microsoft Entra 系統管理中心設定證書頒發機構單位

建立 PKI 容器物件

建立 PKI 容器物件。
以驗證原則管理員身分登入 Microsoft Entra 系統管理中心。
流覽至 [保護>] 顯示更多>資訊安全中心 （或身分識別安全分數） >公鑰基礎結構（預覽）。
按兩下 [+ 建立 PKI]。
輸入 顯示名稱。
按一下 [建立]。
選取 [欄標籤] 以新增或刪除欄標籤。
選取 [ 重新整理 ] 以重新整理 PKIs 清單。

刪除 PKI 容器物件

若要刪除 PKI，請選取 PKI，然後選取 [ 刪除]。如果 PKI 中有 CA，請輸入 PKI 的名稱，以確認刪除其中的所有 CA，然後選取 [ 刪除]。

將個別 CA 上傳至 PKI 容器物件

若要將 CA 上傳至 PKI 容器：
1. 按兩下 [ + 新增證書頒發機構單位]。
2. 選取 CA 檔案。
3. 如果 CA 是根憑證，請選取 [是]，否則選取 [否]。
4. 針對憑證撤銷清單 URL，請設定包含所有已撤銷憑證的 CA 基礎 CRL 網際網路對應 URL。如果未設定 URL，則具有已撤銷憑證的驗證不會失敗。
5. 針對 Delta 憑證撤銷清單 URL，請為包含自從上次發佈基礎 CRL 後所有撤銷憑證的 CRL 來設定網際網路對應 URL。
6. 簽發 者提示 旗標預設為啟用。如果 CA 不應該包含在簽發者提示中，請關閉 簽發者提示 。
7. 選取儲存。
8. 若要刪除 CA 憑證，請選取 [憑證]，然後選取 [刪除]。
9. 選取 [欄標籤] 以新增或刪除欄標籤。
10. 選取 [ 重新整理 ] 以重新整理 CA 清單。

將 PKI 上傳至 PKI 容器物件的所有 CA

若要一次將所有 CA 上傳至 PKI 容器：
1. 建立 PKI 容器物件，或開啟一個。
2. 選取 [ 上傳 PKI]。
3. 輸入 .p7b 檔案可用的 HTTP 因特網對應 URL。
4. 輸入檔案的SHA256總和檢查碼。
5. 選取上傳。
6. 上傳 PKI 是異步程式。隨著每個 CA 的上傳，PKI 中都有提供。完成 PKI 上傳最多可能需要 30 分鐘的時間。
7. 選取 [ 重新整理 ] 以重新整理 CA。
若要產生 PKI .p7b 檔案的 SHA256 總和檢查碼，請執行此命令：
```
Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
```

編輯 PKI

若要編輯 PKI，請在 PKI 數據列上選取 ... ，然後選取 [ 編輯]。
輸入新的 PKI 名稱，然後選取 [ 儲存]。

編輯 CA

若要編輯 CA，請在 CA 資料列上選取 ... ，然後選取 [ 編輯]。
視需要輸入證書頒發機構單位類型（root/intermediate）、CRL URL、Delta CRL URL、已啟用簽發者提示旗標的新值，然後選取 [ 儲存]。

還原 PKI

選取 [ 已刪除的 PKIs] 索引標籤 。
選取 PKI，然後選取 [還原 PKI]。

還原 CA

選取 [ 已刪除的 CA] 索引標籤 。
選取 CA 檔案，然後選取 [還原證書頒發機構單位]。

瞭解 CA 上的 isIssuerHintEnabled 屬性

簽發者提示會將信任的 CA 指示傳送回傳輸層安全性（TLS）交握的一部分。信任的 CA 列表會設定為租使用者在 Entra 信任存放區中上傳之 CA 的主體。如需簽發者提示的詳細資訊，請參閱瞭解簽發者提示。

根據預設，Microsoft Entra 信任存放區中所有 CA 的主體名稱會以提示傳送。如果您要只傳送具有特定 CA 的提示，請將簽發者提示屬性 isIssuerHintEnabled 設定為 true。

簽發者提示的字元限制為 16 KB，伺服器可以傳送回 TLS 用戶端。最佳做法是，將屬性 isIssuerHintEnabled 設定為 true，僅適用於簽發用戶憑證的 CA。

如果來自相同跟證書的多個中繼 CA 發出用戶憑證，則預設所有憑證都會顯示在憑證選擇器中。但是，如果您針對特定 CA 將 isIssuerHintEnabled 設定為 true ，則只會在憑證選擇器中顯示適當的用戶憑證。若要開啟 isIssuerHintEnabled，請編輯 CA，並將值更新為 true。

使用 Microsoft Graph API 設定證書頒發機構單位

Microsoft Graph API 可用來設定 CA。下列範例示範如何使用 Microsoft Graph 來執行 PKI 或 CA 的建立、讀取、更新或刪除（CRUD）作業。

建立 PKI 容器物件

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

取得所有 PKI 物件

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

依 PKI-id 取得 PKI 物件

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/
ConsistencyLevel: eventual

使用 .p7b 檔案上傳 CA

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
    	"uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
    	"sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

取得 PKI 中的所有 CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities
ConsistencyLevel: eventual

依 CA 識別碼在 PKI 內取得特定 CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
ConsistencyLevel: eventual

更新特定的 CA 簽發者提示旗標

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

使用 PowerShell 設定證書頒發機構單位（CA）針對此設定，您可以使用 [Microsoft Graph PowerShell] （/powershell/microsoftgraph/installation）。

以系統管理員權限啟動 PowerShell。

安裝並匯入 Microsoft Graph PowerShell SDK。

Install-Module Microsoft.Graph -Scope AllUsers
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

連線到租用戶並接受全部項目。

   Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>

稽核記錄

信任存放區內 PKI 或 CA 上的任何 CRUD 作業都會記錄到 entra 稽核記錄Microsoft。

稽核記錄的圖表。

常見問題集

問題：上傳 PKI 為何失敗？

答：檢查 PKI 檔案是否有效，而且可以存取，而沒有任何問題。 PKI 檔案的大小上限應該是

問題:P KI上傳的服務等級協定（SLA）為何？

答:P KI上傳是異步操作，最多可能需要 30 分鐘才能完成。

問題：如何產生 PKI 檔案的 SHA256 總和檢查碼？

答：若要產生 PKI.p7b 檔案的 SHA256 總和檢查碼，請執行此命令：

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

步驟 2：在租用戶上啟用 CBA

重要

當使用者在驗證方法原則中的憑證式驗證的範圍時，使用者會被視為能夠 MFA。此原則需求表示使用者無法使用證明作為驗證的一部分來註冊其他可用的方法。如果使用者無法存取憑證，他們就會遭到鎖定，且無法註冊 MFA 的其他方法。驗證原則系統管理員只需要為具有有效憑證的用戶啟用 CBA。請勿包含 CBA的所有使用者 。僅使用具有有效憑證的使用者群組。如需其他資訊，請參閱 Microsoft Entra 多重要素驗證 (部分機器翻譯)。

若要在 Microsoft Entra 系統管理中心啟用 CBA，請完成下列步驟：

至少以驗證原則管理員的身分登入 Microsoft Entra 管理中心。
流覽至 [ 群組>][所有群組> ] 選取 [新增群組 ]，然後為 CBA 使用者建立群組。
瀏覽至 [資料保護]>[驗證方法]>[憑證式驗證]。
在 [啟用] 和 [目標] 下，選取 [啟用]。
選取 [新增群組 ] 以選取特定群組，例如您所建立的群組。使用特定群組，而不是 [所有使用者]。

在租用戶上啟用憑證式驗證之後，租使用者中的所有用戶都會看到使用憑證登入的選項。只有已啟用 CBA 的使用者才能使用 X.509 憑證進行驗證。

注意

除了 login.microsoftonline.com 之外，網路系統管理員應該允許存取客戶的雲端環境 certauth 端點。在 certauth 端點上停用 TLS 檢查，以確保用戶端憑證要求會在 TLS 交握過程中成功。

步驟 3：設定驗證繫結原則

驗證繫結原則可協助您以單一要素或多重要素來決定驗證的強度。租用戶上憑證的預設保護層級是單一要素驗證。

驗證原則管理員可以將預設值從單一要素變更為多重要素，並設定自訂原則規則。驗證系結規則會將簽發者、原則對象標識碼（OID）或簽發者和原則 OID 等憑證屬性對應至值，然後選取該規則的默認保護層級。您可以建立多個規則。

若要修改 Microsoft Entra 系統管理中心中的租用戶預設設定，請完成下列步驟：

至少以驗證原則管理員的身分登入 Microsoft Entra 管理中心。
瀏覽至 [資料保護]>[驗證方法]>[原則]。
在 [管理] 底下，選取 [驗證方法]>[憑證式驗證]。
選取 [設定]，以設定驗證繫結和使用者名稱繫結。
保護層級屬性的預設值為 [單一要素驗證]。選取 [多重要素驗證]，將預設值變更為 MFA。

注意

如果未新增任何自訂規則，則預設保護層級值會生效。如果新增自訂規則，則會改為接受在規則層級定義的保護層級。
您也可以設定自訂驗證繫結規則，以協助判斷用戶端憑證的保護層級。您可以使用憑證中的「簽發者主體」或「原則 OID」欄位來加以設定。

驗證系結規則會將憑證屬性（簽發者或原則 OID）對應至值，然後選取該規則的默認保護層級。可以建立多個規則。

若要新增自訂規則，請選取 [新增規則]。

若要依憑證簽發者建立規則，請選取 [憑證簽發者]。
1. 從清單方塊中選取 [憑證簽發者識別碼]。
2. 選取 [多重要素驗證]、[低] 親和性繫結，然後按一下 [新增]。出現提示時，按一下 [我確認] 以完成新增規則。
若要依原則 OID 建立規則，請選取 [原則 OID]。
1. 輸入 [原則 OID] 的值。
2. 選取 [多重要素驗證]、[低] 親和性繫結，然後按一下 [新增]。出現提示時，按一下 [我確認] 以完成新增規則。
若要依憑證簽發者和原則 OID 建立規則：
1. 選取 [憑證簽發者]，以及 [原則 OID]。
2. 選取 [憑證簽發者] 並輸入原則 OID。
3. 針對 [驗證強度]，選取 [單一要素驗證] 或 [多重要素驗證]。
4. 針對 [親和性繫結]，選取 [低]。
5. 選取 [新增]。
6. 使用原則 OID 為 3.4.5.6 且由 CN=CBATestRootProd 簽發的憑證進行驗證。驗證應該通過並取得多重要素宣告。

重要

已知有一個問題，其中Microsoft Entra 租使用者驗證原則管理員會同時使用簽發者和原則 OID 來設定 CBA 驗證原則規則。此問題會影響某些裝置註冊案例，包括：

Windows Hello 企業版註冊
FIDO2 安全性金鑰註冊
Windows 無密碼手機登入

使用 Workplace Join 進行裝置註冊，Microsoft Entra 標識碼和混合式Microsoft Entra 裝置加入案例不會受到影響。使用簽發者或原則 OID 的 CBA 驗證原則規則不會受到影響。若要減輕問題，系統管理員應該：

編輯使用簽發者和原則 OID 選項的憑證式驗證原則規則。拿掉簽發者或原則 OID 需求和儲存。 - 或者 -
拿掉使用簽發者和原則 OID 的驗證原則規則。建立僅使用簽發者或原則 OID 的規則。

我們正在修正此問題。

若要依憑證簽發者和序號建立規則：

新增驗證系結原則。原則要求 CN=CBATestRootProd 與 policyOID 1.2.3.4.6 簽發的任何憑證只需要高親和性系結。使用簽發者和序號。
選取 [憑證] 欄位。在此範例中，讓我們選取 [簽發者] 和 [序號]。
唯一支援的使用者屬性是 CertificateUserIds。選取 [新增]。
選取儲存。

登入記錄會顯示用於登入的系結，以及憑證的詳細數據。
選取 [確定] 以儲存任何自訂規則。

重要

使用物件識別碼格式輸入 PolicyOID。例如，如果憑證原則為 所有簽發原則，請在新增規則時輸入 OID 2.5.29.32.0。規則編輯器的 [所有發行原則] 字串無效，而且不會生效。

步驟 4：設定使用者名稱繫結原則

使用者名稱繫結原則可協助驗證使用者的憑證。根據預設，我們會將憑證中的主體名稱對應至使用者物件中的 UserPrincipalName，以判斷使用者。

驗證原則管理員可以覆寫預設值並建立自訂對應。若要判斷如何設定使用者名稱繫結，請參閱使用者名稱繫結的運作方式。

如需使用 certificateUserIds 屬性的其他案例，請參閱憑證用戶標識碼。

重要

如果使用者名稱繫結原則使用同步處理的屬性，例如 certificateUserIds、onPremisesUserPrincipalName，以及使用者物件的 userPrincipalName 屬性，請注意 Active Directory 中具有系統管理權限的帳戶 (例如具有使用者物件委派權限的帳戶，或在 Microsoft Entra Connect 伺服器上具有系統管理權限的帳戶) 可以變更，以影響在 Microsoft Entra ID 中的這些屬性。

選取其中一個 [X.509 憑證] 欄位來繫結其中一個使用者屬性，以建立使用者名稱繫結。使用者名稱繫結順序表示繫結的優先順序層級。第一個具有最高的優先順序，依此類推。

如果在憑證上找到指定的 X.509 憑證欄位，但 Microsoft Entra ID 找不到使用該值的使用者物件，則驗證會失敗。 Microsoft Entra ID 會嘗試清單中的下一個繫結。
選取儲存以儲存變更。

最終組態看起來像這樣映射：

最終設定的螢幕擷取畫面。

步驟 5：測試您的設定

本節說明如何測試您的憑證和自訂驗證繫結規則。

測試您的憑證

在第一個設定測試中，您應該嘗試使用您裝置上的瀏覽器來登入 MyApps 入口網站。

輸入您的使用者主體名稱 (UPN)。
選取 [下一步]。

如果您已啟用其他驗證方法 (例如，手機登入或 FIDO2)，使用者可能會看到不同的登入畫面。
選取 [使用憑證登入]。
在用戶端憑證選擇器 UI 中選擇正確的使用者憑證，然後選取 [確定]。
使用者應登入 MyApps 入口網站。

如果登入成功，您便知道︰

用戶憑證會布建到您的測試裝置。
Microsoft Entra ID 已使用受信任的 CA 正確設定。
已正確設定使用者名稱繫結，並已找到且驗證使用者。

測試自訂驗證繫結規則

讓我們逐步解說驗證增強式驗證的案例。我們會建立兩個驗證原則規則，一個是使用簽發者主體滿足單一要素驗證，另一個是使用原則 OID 來滿足多重要素驗證。

建立具有保護層級的簽發者主體規則作為單一要素驗證，並將值設定為您的 CA 主體值。例如：

CN = WoodgroveCA
建立原則 OID 規則，並將保護層級設定為多重要素驗證，以及將值設定為您的憑證中的其中一個原則 OID。例如，1.2.3.4。
建立條件式存取原則，讓使用者遵循條件式存取 (需要 MFA) 中的步驟，要求多重要素驗證。
導覽至 MyApps 入口網站。輸入您的 UPN，然後選取 [下一步]。
選取 [使用憑證登入]。

如果您已啟用其他驗證方法 (例如，手機登入或安全性金鑰)，使用者可能會看到不同的登入畫面。
選取用戶端憑證，然後選取 [憑證資訊]。
憑證隨即出現，您可以驗證憑證簽發者和原則 OID 值。
若要查看原則 OID 值，請選取 [詳細資料]。
選取用戶端憑證，然後選取 [確定]。
憑證中的原則 OID 符合所設定的 1.2.3.4 值，而且將滿足多重要素驗證。同樣地，憑證中的簽發者會符合所設定的 CN=WoodgroveCA 值，並且會滿足單一要素驗證。
由於原則 OID 規則優先於憑證簽發者規則，因此憑證將滿足多重要素驗證。
使用者的條件式存取原則需要 MFA 且憑證滿足多重要素，因此可讓使用者登入應用程式。

測試使用者名稱繫結原則

使用者名稱繫結原則可協助驗證使用者的憑證。使用者名稱繫結原則支援三個繫結：

IssuerAndSerialNumber>CertificateUserIds
IssuerAndSubject>CertificateUserIds
Subject>CertificateUserIds

根據預設，Microsoft Entra ID 會將憑證中的主體名稱對應至用戶物件中的 UserPrincipalName，以判斷使用者。驗證原則管理員可以覆寫預設值並建立自定義對應，如先前所述。

驗證原則管理員必須啟用新的系結。若要準備，他們必須確定用戶物件的 CertificateUserIds 屬性中已更新對應使用者名稱系結的正確值：

針對僅限雲端的使用者，請使用 Microsoft Entra 系統管理中心或 Microsoft Graph API 來更新 CertificateUserIds 中的值。
針對內部部署同步處理的使用者，請使用 Microsoft Entra Connect 來同步處理內部部署的值，方法是遵循 Microsoft Entra Connect 規則或同步處理 AltSecId 值。

重要

憑證簽發者、主體和 SerialNumber 值的格式應該以憑證中格式的反向順序排列。請勿在憑證簽發者或主體中新增任何空格。

手動對應憑證簽發者和序號

以下是手動對應憑證簽發者和序號的範例。要新增的憑證簽發者值如下：

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

憑證簽發者值的螢幕擷取畫面。

若要取得序號的正確值，請執行下列命令，並儲存 CertificateUserIds 中顯示的值。命令語法為：

Certutil –dump –v [~certificate path~] >> [~dumpFile path~]

例如：

certutil -dump -v firstusercert.cer >> firstCertDump.txt

以下是 certutil 命令的範例：

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48

CertificateUserId 中要加入的 SerialNumber 值是：

b24134139f069b49997212a86ba0ef48

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

手動對應票證和主體

以下是手動對應票證和主體的範例。憑證簽發者值為：

搭配多個繫結使用時憑證簽發者值的螢幕擷取畫面。

主體值為：

主體值的螢幕擷取畫面。

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

手動對應主體

以下是手動對應主體的範例。主體值為：

另一個主體值的螢幕擷取畫面。

CertificateUserId:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

測試親和性繫結

至少以驗證原則管理員的身分登入 Microsoft Entra 管理中心。
瀏覽至 [資料保護]>[驗證方法]>[原則]。
在 [管理] 底下，選取 [驗證方法]>[憑證式驗證]。
選取設定。
在租用戶層級設定 [必要的親和性繫結]。

重要

請小心使用整個租用戶的親和性設定。如果您變更租用戶的 [必要的親和性繫]，而且使用者物件中沒有適當的值，則可以鎖定整個租用戶。同樣地，如果您建立套用至所有使用者且需要高親和性繫結的自訂規則，租用戶中的使用者可能會遭到鎖定。
若要測試，請將 [必要的親和性繫結] 選取為 [低]。
新增像 SKI 這樣的高親和性繫結。在 [使用者名稱繫結] 底下，選取 [新增規則]。
選取 [SKI]，然後選取 [新增]。

完成時，規則看起來會像此螢幕擷取畫面：
更新所有使用者物件 CertificateUserIds 屬性，以從使用者憑證取得正確的 SKI 值。如需詳細資訊，請參閱 CertificateUserIDs 支援的模式。
建立驗證繫結的自訂規則。
選取 [新增]。

完成時，規則看起來會像此螢幕擷取畫面：
使用來自具有原則 OID 9.8.7.5 憑證的正確的 SKI 值更新使用者 CertificateUserIds。
使用具有原則 OID 9.8.7.5 的憑證測試，且使用者應該以 SKI 繫結驗證，並且僅使用憑證取得 MFA。

使用 Microsoft Graph API 啟用 CBA

若要啟用 CBA 並使用 Graph API 設定使用者名稱繫結，請完成下列步驟。

移至 Microsoft Graph 總管。
選取 [登入 Graph 總管]，然後登入您的租用戶。
遵循下列步驟來同意 Policy.ReadWrite.AuthenticationMethod 委派權限。

取得所有驗證方法：

GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy

取得 x509 憑證驗證方法的設定：

GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate

預設會停用 x509 憑證驗證方法。若要允許使用者使用憑證登入，您必須啟用驗證方法，並透過更新作業來設定驗證和使用者名稱繫結原則。若要更新原則，請執行 PATCH 要求。

要求本文：

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
Content-Type: application/json

{
    "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
    "id": "X509Certificate",
    "state": "enabled",
    "certificateUserBindings": [
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "onPremisesUserPrincipalName",
            "priority": 1
        },
        {
            "x509CertificateField": "RFC822Name",
            "userProperty": "userPrincipalName",
            "priority": 2
        }, 
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "certificateUserIds",
            "priority": 3
        }
    ],
    "authenticationModeConfiguration": {
        "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
        "rules": [
            {
                "x509CertificateRuleType": "issuerSubject",
                "identifier": "CN=WoodgroveCA ",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            },
            {
                "x509CertificateRuleType": "policyOID",
                "identifier": "1.2.3.4",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            }
        ]
    },
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false
        }
    ]
}

您會得到 204 No content 回應碼。請重新執行 GET 要求，以確定原則已正確更新。
使用滿足原則的憑證登入來測試設定。

使用 Microsoft PowerShell 啟用 CBA

開啟 PowerShell。

連線到 Microsoft Graph：

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

建立變數來定義 CBA 使用者的群組：

$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"

定義要求本文：

$body = @{
"@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
"id" = "X509Certificate"
"state" = "enabled"
"certificateUserBindings" = @(
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "SubjectKeyIdentifier"
        "userProperty" = "certificateUserIds"
        "priority" = 1
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "PrincipalName"
        "userProperty" = "UserPrincipalName"
        "priority" = 2
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "RFC822Name"
        "userProperty" = "userPrincipalName"
        "priority" = 3
    }
)
"authenticationModeConfiguration" = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
    "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
    "rules" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateRule"
            "x509CertificateRuleType" = "policyOID"
            "identifier" = "1.3.6.1.4.1.311.21.1"
            "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
        }
    )
}
"includeTargets" = @(
    @{
        "targetType" = "group"
        "id" = $group.Id
        "isRegistrationRequired" = $false
    }
) } | ConvertTo-Json -Depth 5

執行 PATCH 要求：

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"

共用方式為

如何設定 Microsoft Entra 憑證式驗證

必要條件

設定及測試 Microsoft Entra CBA 的步驟

步驟 1：使用 PKI 型信任存放區設定證書頒發機構單位 （預覽）

使用 Microsoft Entra 系統管理中心設定證書頒發機構單位

建立 PKI 容器物件

刪除 PKI 容器物件

將個別 CA 上傳至 PKI 容器物件

將 PKI 上傳至 PKI 容器物件的所有 CA

編輯 PKI

編輯 CA

還原 PKI

還原 CA

瞭解 CA 上的 isIssuerHintEnabled 屬性

使用 Microsoft Graph API 設定證書頒發機構單位

建立 PKI 容器物件

取得所有 PKI 物件

依 PKI-id 取得 PKI 物件

使用 .p7b 檔案上傳 CA

取得 PKI 中的所有 CA

依 CA 識別碼在 PKI 內取得特定 CA

更新特定的 CA 簽發者提示旗標

稽核記錄

常見問題集

步驟 2：在租用戶上啟用 CBA

步驟 3：設定驗證繫結原則

步驟 4：設定使用者名稱繫結原則

步驟 5：測試您的設定

測試您的憑證

測試自訂驗證繫結規則

測試使用者名稱繫結原則

手動對應憑證簽發者和序號

手動對應票證和主體

手動對應主體

測試親和性繫結

使用 Microsoft Graph API 啟用 CBA

要求本文：

使用 Microsoft PowerShell 啟用 CBA

下一步

意見反應

其他資源

步驟 1：使用 PKI 型信任存放區設定證書頒發機構單位（預覽）