設定 Microsoft Entra 憑證型驗證

您的組織可以使用 Microsoft Entra 憑證型驗證（CBA），透過使用者 X.509 憑證來實作防網路釣魚、新式和無密碼驗證。

在本文中，瞭解如何設定 Microsoft Entra 租用戶，以允許或要求租用戶使用者使用 X.509 憑證進行驗證。使用者會使用企業公開金鑰基礎結構（PKI）來建立 X.509 憑證，以進行應用程式和瀏覽器登入。

設定 Microsoft Entra CBA 時，在登入期間，使用者會看到使用憑證進行驗證的選項，而不是輸入密碼。如果裝置上有多個相符的憑證，使用者會選取相關憑證，並針對使用者帳戶驗證憑證。如果驗證成功，使用者會登入。

完成本文中所述的步驟，以針對 Office 365 企業版和美國政府版方案中的租用戶設定和使用 Microsoft Entra CBA。您必須已配置 PKI 。

必要條件

確定滿足下列必要條件：

至少一個憑證授權單位（CA）和任何中繼 CA 會在 Microsoft Entra ID 中設定。
使用者可以存取從租用戶上設定的受信任 PKI 所發出的使用者憑證，以用於 Microsoft Entra ID 中的用戶端驗證。
每個 CA 都有一個憑證撤銷清單（CRL），可以從網際網路對向的 URL 參考。如果受信任的 CA 未設定 CRL，Microsoft Entra ID 不會執行任何 CRL 檢查、撤銷使用者憑證無法運作，也不會封鎖驗證。

考慮事項

確保 PKI 是安全的並且不會輕易受到損害。如果發生違規，攻擊者可以建立和簽署用戶端憑證，並入侵租用戶中的任何使用者，包括從內部部署同步處理的使用者。強大的金鑰保護策略以及其他實體和邏輯控制可以提供深度防禦，以防止外部攻擊者或內部威脅損害 PKI 的完整性。如需詳細資訊，請參閱保護 PKI。
如需 Microsoft 密碼編譯的最佳做法，包括演算法、金鑰長度和資料保護的選擇，請參閱 Microsoft 建議。請務必使用其中一種建議的演算法、建議的金鑰長度和 NIST 核准的曲線。
作為持續安全性改善的一部分，Azure 和 Microsoft 365 端點新增了對 TLS 1.3 的支援。該過程預計需要幾個月的時間來涵蓋 Azure 和 Microsoft 365 中的數千個服務端點。 Microsoft Entra CBA 使用的 Microsoft Entra 端點包含在更新中： *.certauth.login.microsoftonline.com 和 *.certauth.login.microsoftonline.us。

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。如下圖所示，Azure 會使用角色型存取控制（RBAC）來確保只需要最低許可權的系統管理員進行變更。

重要

Microsoft 建議您使用權限最少的角色。這種做法可協助改善貴組織的安全性。全域管理員是擁有高度權限的角色，應限於緊急情況下使用，或無法使用現有角色時。

或者，您可以設定驗證繫結，以將憑證對應至單一要素驗證或多重要素驗證（MFA）。設定使用者名稱繫結，以將憑證欄位對應至使用者物件的屬性。驗證原則管理員可以設定使用者相關設定。

完成所有設定時，請在租用戶上開啟 Microsoft Entra CBA。

圖表顯示開啟 Microsoft Entra 憑證型驗證所需步驟的概觀。

步驟 1：使用基於 PKI 的信任存放區配置 CA

Microsoft Entra 有新的 PKI 型 CA 信任存放區。信任存放區會將 CA 保留在每個 PKI 的容器物件內。系統管理員可以根據 PKI 管理容器中的 CA，比管理 CA 的一般清單更輕鬆。

PKI 型信任存放區在 CA 數目和每個 CA 檔案大小方面，比傳統信任存放區有更高的限制。以 PKI 為基礎的信任存放區最多支援 250 個 CA 和每個 CA 物件的 8 KB。

如果您使用傳統信任存放區來設定 CA，強烈建議您設定以 PKI 為基礎的信任存放區。以 PKI 為基礎的信任存放區是可調整的，並支援新功能，例如簽發者提示。

系統管理員必須設定簽發用戶憑證的受信任 CA。只有最低權限的管理員才能進行變更。以 PKI 為基礎的信任存放區會獲指派 Privileged Authentication Administrator 角色。

PKI 型信任存放區的 PKI 上傳功能僅適用於 Microsoft Entra ID P1 或 P2 授權。不過，使用 Microsoft Entra 免費授權，系統管理員可以個別上傳所有 CA，而不是上傳 PKI 檔案。然後，他們可以配置基於 PKI 的信任存儲並添加其上傳的 CA 檔案。

使用 Microsoft Entra 系統管理中心設定 CA

建立 PKI 容器物件（Microsoft Entra 系統管理中心）

若要建立 PKI 容器物件：

使用獲指派特殊許可權驗證系統管理員角色的帳戶登入 Microsoft Entra 系統管理中心。
移至 Entra ID>身分識別安全評分公開>金鑰基礎結構。
選取 [ 建立 PKI]。
針對 Display Name （顯示名稱），輸入名稱。
選取 ，創建。
若要新增或刪除欄，請選取 [編輯欄]。
若要重新整理 PKI 清單，請選取 [重新整理]。

刪除 PKI 容器物件

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

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

若要將 CA 上傳至 PKI 容器：

選取 [新增憑證授權單位]。
選取 CA 檔案。
如果 CA 是根憑證，請選取 [ 是]。否則，請選取 [ 否]。
針對 [憑證撤銷清單 URL]，輸入包含所有已撤銷憑證之 CA 基礎 CRL 的網際網路對向 URL。如果未設定 URL，則嘗試使用已撤銷的憑證進行驗證不會失敗。
針對 [差異憑證撤銷清單 URL]，輸入 CRL 的網際網路對向 URL，其中包含自上次發佈基底 CRL 以來所有已撤銷憑證的 URL。
如果 CA 不應該包含在簽發者提示中，請關閉簽發者提示。依預設， 「簽發者提示 」旗標會關閉。
選取儲存。
若要刪除 CA，請選取 CA，然後選取 [刪除]。
若要新增或刪除欄，請選取 [編輯欄]。
若要重新整理 PKI 清單，請選取 [重新整理]。

最初，會顯示 100 個 CA 憑證。當您向下捲動窗格時，會出現更多內容。

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

若要將所有 CA 大量上傳至 PKI 容器：

建立 PKI 容器物件或開啟現有容器。
選取 [ 上傳 PKI]。
輸入檔案的 .p7b HTTP 網際網路對向 URL。
輸入檔案的 SHA-256 總和檢查碼。
選取上傳。

PKI 上傳過程是非同步的。隨著每個 CA 的上傳，它便可在 PKI 中使用。整個 PKI 上傳最多可能需要 30 分鐘。
選取 [ 重新整理 ] 以重新整理 CA 清單。
每個上傳的 CA CRL 端點 屬性都會更新為 CA 憑證的第一個可用 HTTP URL，列為 CRL 發佈點 屬性。您必須手動更新任何分葉憑證。

若要產生 PKI .p7b 檔案的 SHA-256 總和檢查碼，請執行：

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

編輯 PKI

在 PKI 資料列上，選取 ...，然後選取 [編輯]。
輸入新的 PKI 名稱。
選取儲存。

編輯 CA

在 CA 資料列上，選取 [...]，然後選取 [編輯]。
根據您的需求，輸入 CA 類型（根或中間）、CRL URL、差異 CRL URL 或啟用簽發者提示旗標的新值。
選取儲存。

大量編輯簽發者提示屬性

若要編輯多個 CA 並開啟或關閉已 啟用的發行者提示 屬性，請選取多個 CA。
選取 [編輯]，然後選取 [編輯簽發者提示]。
選取所有選取 CA 的 [ 已啟用發行者提示 ] 核取方塊，或清除選取項目，以關閉所有選取 CA 的 [已啟用發行者提示 ] 旗標。預設值為 Indeterminate。
選取儲存。

還原公開金鑰基礎設施 (PKI)

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

還原 CA

選取 [已刪除的 CA] 索引標籤。
選取 CA 檔案，然後選取 [還原憑證授權單位]。

設定 CA 的 isIssuerHintEnabled 屬性

簽發者提示會傳回 受信任的 CA 指示器，作為傳輸層安全性（TLS）交握的一部分。受信任的 CA 清單會設定為租用戶上傳至 Microsoft Entra 信任存放區的 CA 主體。如需詳細資訊，請參閱瞭解簽發者提示。

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

伺服器可以將簽發者提示（CA 的主體名稱）的最多 16 KB 回應傳回 TLS 用戶端。建議您將屬性設定 isIssuerHintEnabled 為 true 僅針對發行使用者憑證的 CA。

如果來自相同根憑證的多個中繼 CA 發行使用者憑證，依預設，所有憑證都會顯示在憑證選擇器中。如果您針對 isIssuerHintEnabled 特定 CA 設定為， true 則憑證選擇器中只會顯示相關的使用者憑證。

使用 Microsoft Graph API 設定 CA

下列範例示範如何使用 Microsoft Graph 透過 PKI 或 CA 的 HTTP 方法執行建立、讀取、更新和刪除（CRUD）作業。

建立 PKI 容器物件（Microsoft Graph）

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 識別碼取得 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。

安裝並匯入 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 存放區之間的優先順序

如果 CA 同時存在於 PKI 型 CA 存放區和傳統 CA 存放區中，則會優先使用 PKI 型信任存放區。

在下列案例中，傳統 CA 存放區會優先處理：

兩個存放區上都存在 CA，PKI 型存放區沒有 CRL，但傳統存放區 CA 具有有效的 CRL。
CA 存在於兩個存放區上，且以 PKI 為基礎的存放區 CA CRL 與傳統存放區 CA CRL 不同。

Microsoft Entra 登入記錄中斷專案在 [其他詳細資料] 底下有兩個屬性，以指出在驗證期間是否使用傳統或舊版信任存放區。

是否使用舊版存放區的值為 0，表示使用了 PKI 型存放區。值 1 表示使用傳統或舊版存放區。
舊版存放區使用資訊會 顯示使用傳統或舊版存放區的原因。

螢幕擷取畫面，顯示使用 PKI 型存放區或傳統 CA 存放區的登入記錄專案

稽核記錄

您在信任存放區內的 PKI 或 CA 上執行的任何 CRUD 作業都會出現在 Microsoft Entra 稽核記錄中。

從傳統 CA 存放區移轉至 PKI 型存放區

租用戶系統管理員可以將所有 CA 上傳至 PKI 型存放區。然後，PKI CA 存放區優先於傳統存放區，而且所有 CBA 驗證都會透過 PKI 型存放區進行。租用戶系統管理員可以在登入記錄中確認未顯示使用傳統或舊版存放區之後，從傳統或舊版存放區移除 CA。

常見問題集

為什麼 PKI 上傳失敗？

驗證 PKI 檔案是否有效並且可以毫無問題地存取它。 PKI 檔案的大小上限為 2 MB （每個 CA 物件 250 個 CA 和 8 KB）。

PKI 上傳的服務等級協定是什麼？

PKI 上傳是非同步作業，最多可能需要 30 分鐘才能完成。

如何為 PKI 檔案產生 SHA-256 校驗和？

要生成PKI .p7b 檔案的SHA-256總和檢查碼，請運行以下命令：

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

步驟 2：為租用戶開啟 CBA

重要

當使用者在驗證方法原則中指定為 CBA 範圍內時，會被視為能夠完成 MFA。此原則需求表示使用者無法使用身分證明作為其驗證的一部分來註冊其他可用的方法。如果使用者無法存取憑證，則會鎖定，且無法註冊 MFA 的其他方法。獲指派驗證原則系統管理員角色的系統管理員必須只針對具有有效憑證的使用者開啟 CBA。請勿將所有使用者包含在CBA中。僅使用具有有效憑證的使用者群組。如需其他資訊，請參閱 Microsoft Entra 多重要素驗證。

若要透過 Microsoft Entra 系統管理中心開啟 CBA：

使用至少獲指派驗證原則系統管理員角色的帳戶登入 Microsoft Entra 系統管理中心。
前往 「群組」「>所有群組」。
選取 新增群組 ，然後為 CBA 使用者建立群組。
移至 Entra ID>驗證方法>憑證型驗證。
在 [啟用和目標] 底下，選取 [ 啟用]，然後選取 [ 我確認 ] 核取方塊。
選擇 [選取群組>] [新增群組]。
選擇特定群組，例如您建立的群組，然後選擇 [選取]。 使用特定群組，而不是 所有使用者。
選取儲存。

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

注意

除了端點之外 login.microsoftonline.com ，網路管理員還應允許存取組織雲端環境的憑證驗證端點。關閉憑證驗證端點上的 TLS 檢查，以確保用戶端憑證要求在 TLS 交握過程中成功。

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

驗證繫結原則有助於將驗證強度設定為單一因素或 MFA。租用戶上所有憑證的預設保護層級是單一因素驗證。

租用戶層級的預設親緣性繫結是 低親緣性。驗證原則管理員可以將預設值從單一因素驗證變更為 MFA。如果保護層級變更，租用戶上的所有憑證都會設定為 MFA。同樣地，租用戶層級的親緣性繫結可以設定為 高親緣性。然後，僅使用高親和性屬性來驗證所有憑證。

重要

系統管理員必須將租用戶預設值設定為適用於大部分憑證的值。僅針對需要與租用戶預設值不同的保護層級或親和性繫結的特定憑證建立自訂規則。所有驗證方法組態都位於相同的原則檔案中。建立多個備援規則可能會超出原則檔案大小限制。

驗證繫結規則會將憑證屬性（ 例如簽發者、 原則物件識別碼（OID） 以及 簽發者和原則 OID 對應至指定的值。這些規則會設定該規則的預設保護層級和親緣性繫結。

若要修改預設租用戶設定，並透過 Microsoft Entra 系統管理中心建立自訂規則：

使用至少獲指派驗證原則系統管理員角色的帳戶登入 Microsoft Entra 系統管理中心。
移至 Entra ID>驗證方法>原則。
在 [管理移轉] 底下，選取 [驗證方法>] [憑證型驗證]。
若要設定驗證繫結和使用者名稱繫結，請選取設定。
若要將預設值變更為 MFA，請選取 [多重要素驗證]。 保護層級屬性的預設值為 [單一要素驗證]。

注意

如果未新增自訂規則，則預設保護層級會生效。如果您新增自訂規則，則會遵循在規則層級定義的保護層級，而不是預設的保護層級。
您也可以設定自訂的身分驗證繫結規則，以協助判斷客戶端憑證的保護層級，這些憑證需要不同於租戶預設值的保護層級或關聯性繫結的值。您可以使用憑證中的簽發者主體或原則 OID 或這兩個欄位來設定規則。

驗證繫結規則會將憑證屬性（簽發者或原則 OID）對應至值。此值會設定該規則的預設保護層級。可以建立多個規則。在下列範例中，假設租用戶預設值為 多重要素驗證 ，而親和性繫結的預設值為低。

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

若要依憑證簽發者建立規則：
1. 選取 [憑證簽發者]。
2. 針對 [憑證簽發者識別碼]，選取相關值。
3. 針對 [驗證強度]，選取 [多重要素驗證]。
4. 針對 [親和性繫結]，選取 [低]。
5. 選擇 [新增]。
6. 出現提示時，請選取 [我確認 ] 核取方塊以新增規則。
若要依原則 OID 建立規則：
1. 選取 原則 OID。
2. 針對 Policy OID，輸入值。
3. 針對 [驗證強度]，選取 [單一因素驗證]。
4. 針對 [親和性繫結]，選取 [低] 以進行親和性繫結。
5. 選擇 [新增]。
6. 出現提示時，請選取 [我確認 ] 核取方塊以新增規則。
若要依簽發者和原則 OID 建立規則：
1. 選取 [憑證簽發者] 和 [原則 OID]。
2. 選取憑證簽發者並輸入策略 OID。
3. 針對 [驗證強度]，選取 [多重要素驗證]。
4. 針對 [親和性繫結]，選取 [低]。
5. 選擇 [新增]。
6. 使用原則 OID 為且由 CN=CBATestRootProd發出3.4.5.6的憑證進行鑑別。確認多重要素宣告的驗證已通過。
若要依簽發者和序號建立規則：
1. 新增驗證系結原則。原則要求原則 OID 為的任何1.2.3.4.6憑證CN=CBATestRootProd只需要高親和性繫結。使用簽發者和序號。
2. 選取 [憑證] 欄位。在此範例中，選取 [簽發者和序號]。
3. 唯一支援的使用者屬性是 certificateUserIds。選取 certificateUserIds 並選取 [新增]。
4. 選取儲存。
  
  登入記錄會顯示用於登入的繫結，以及憑證的詳細資料。
選取 [ 確定 ] 以儲存任何自訂規則。

重要

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

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

使用者名稱繫結原則有助於驗證使用者的憑證。根據預設，若要判斷使用者，請將憑證中的 主體名稱 對應至 userPrincipalName 使用者物件中的。

驗證政策管理員可以覆寫預設值並建立自訂對應。如需詳細資訊，請參閱使用者名稱繫結的運作方式。

如需使用屬性 certificateUserIds 的其他實務範例，請參閱憑證使用者 ID。

重要

如果使用者名稱繫結原則使用同步處理的屬性，例如 certificateUserIds、和onPremisesUserPrincipalNameuserPrincipalName使用者物件的屬性，則在內部部署 Windows Server Active Directory 中具有系統管理許可權的帳戶可以進行變更，以影響 Microsoft Entra ID 中的這些屬性。例如，在 Microsoft Entra Connect Server 上具有使用者物件委派許可權或系統管理員角色的帳戶可以進行這些類型的變更。

以建立使用者名稱繫結，請選取 [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。
建立 Microsoft Entra 條件式存取原則，讓使用者需要 MFA。完成條件式存取 - 需要 MFA 中所述的步驟。
移至 MyApps 入口網站。輸入您的 UPN，然後選取 [下一步]。
選取 [ 使用憑證或智慧卡]。

如果您提供其他驗證方法，例如手機登入或安全金鑰，使用者可能會看到不同的登入對話方塊。
選取用戶端憑證，然後選取憑證資訊。

證書會出現，您可以驗證簽發者和政策的 OID 值。
若要查看原則 OID 值，請選取 [詳細資料]。
選取用戶端憑證，然後選取 [確定]。

憑證中的原則 OID 符合的 1.2.3.4 設定值，並符合 MFA。憑證中的簽發者符合單因素身份驗證的 CN=WoodgroveCA 配置值，並滿足單因素身份驗證。

由於原則 OID 規則優先於簽發者規則，因此憑證符合 MFA。

使用者的條件式存取原則需要 MFA，且憑證符合 MFA，因此使用者可以登入應用程式。

測試使用者名稱繫結原則

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

IssuerAndSerialNumber > certificateUserIds
IssuerAndSubject > certificateUserIds
Subject > certificateUserIds

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

驗證原則管理員必須設定新的繫結。若要準備，他們必須確保在使用者物件的屬性中 certificateUserIds 更新對應使用者名稱繫結的正確值：

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

重要

「簽發者」、「主體」和「序號」值的格式必須與憑證中的格式相反。請勿在 [簽發者 ] 或 [主旨] 值中新增任何空格。

簽發者和序號手動對應

下列範例示範簽發者和序號手動對應。

要新增的 「發行者」 值為：

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

螢幕擷取畫面，顯示 Issuer 值的手動對應。

若要取得序號的正確值，請執行下列命令。儲存中顯示 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的序號值為：

b24134139f069b49997212a86ba0ef48

值為 certificateUserIds ：

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

發行人及主體手動對映

下列範例示範簽發者及主體手動對映。

「發行者」值為：

螢幕擷取畫面，顯示與多個繫結搭配使用時的 Issuer 值。

主旨值為：

顯示主旨值的螢幕擷取畫面。

值為 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

手動映射主體

下列範例示範主旨手動對映。

主旨值為：

顯示另一個主旨值的螢幕擷取畫面。

值為 certificateUserIds ：

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

測試親和性繫結

使用至少獲指派驗證原則系統管理員角色的帳戶登入 Microsoft Entra 系統管理中心。
移至 Entra ID>驗證方法>原則。
在 [管理] 底下，選取 [驗證方法>] [憑證型驗證]。
選取設定。
在租戶層級設定必要的親和性繫結。

重要

請小心使用整個租用戶的偏好設定。如果您變更租用戶的 必要親和性繫結 值，而且使用者物件中沒有正確的值，您可能會鎖定整個租用戶。同樣地，如果您建立套用至所有使用者且需要高親和性繫結的自訂規則，租使用者中的使用者可能會被鎖定。
若要測試，請針對 [必要的親和性繫結]，選取 [低]。
新增高親和性繫結，例如主旨金鑰識別碼（SKI）。在 [使用者名稱繫結] 底下，選取 [ 新增規則]。
選取 [SKI]，然後選取 [新增]。

完成後，規則看起來類似於以下示例：
對於所有使用者物件，請使用使用者憑證中的正確 SKI 值來更新 certificateUserIds 屬性。

如需詳細資訊，請參閱 CertificateUserIDs 支援的模式。
建立驗證繫結的自訂規則。
選擇 [新增]。

檢查已完成的規則是否與以下範例類似：
使用憑證中的正確 SKI 值更新使用者 certificateUserIds 值，而原則 OID 9.8.7.5為。
使用原則 OID 為 9.8.7.5的憑證進行測試。確認使用者已使用 SKI 繫結進行驗證，並提示他們使用 MFA 登入，且僅使用憑證登入。

使用 Microsoft Graph API 設定 CBA

若要使用 Microsoft Graph API 設定 CBA 並設定使用者名稱繫結：

移至 Microsoft Graph Explorer。
選取 [登入 Graph 總管] ，然後登入您的租使用者。
請依照步驟Policy.ReadWrite.AuthenticationMethod同意委派的權限。

取得所有驗證方法：

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

獲取X.509證書身份驗證方法的配置：

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

依預設，X.509 憑證驗證方法會關閉。若要允許使用者使用憑證登入，您必須開啟驗證方法，並透過更新作業來設定驗證和使用者名稱繫結原則。若要更新原則，請執行 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"

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-08-16