如何設定 Microsoft Entra 憑證型驗證

發行項
02/03/2024

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

登入期間，使用者也會看到使用憑證進行驗證的選項，而不是輸入密碼。如果裝置上存在多個相符憑證，用戶可以挑選要使用的憑證。憑證會根據使用者帳戶進行驗證，如果成功，則會登入。

請遵循這些指示，為 Office 365 企業版和美國政府方案中的租用戶設定及使用 Microsoft Entra CBA。您應該已經設定公鑰基礎結構（PKI）。

必要條件

確定滿足下列先決條件：

在 Microsoft Entra ID 中設定至少一個證書頒發機構單位（CA）和任何中繼 CA。
用戶必須具有用戶憑證的存取權（從租用戶上設定的受信任公鑰基礎結構發出），該憑證是用來向 Microsoft Entra ID 進行驗證的客戶端驗證。
每個 CA 都應該有可從因特網對應 URL 參考的證書吊銷清單（CRL）。如果受信任的 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.mcirosoftonline.us 所使用的 Entra 識別符端點。 TLS 1.3 是因特網最部署安全性通訊協定的最新版本，可加密數據，以提供兩個端點之間的安全通道。 TLS 1.3 可消除過時的密碼編譯演算法、增強舊版的安全性，並旨在盡可能加密大部分的交握。強烈建議開發人員開始在其應用程式和服務中測試 TLS 1.3。

注意

評估 PKI 時，請務必檢閱憑證發行原則和強制執行。如前所述，將證書頒發機構單位（CA）新增至 Microsoft Entra 設定可讓這些 CA 所簽發的憑證驗證 Microsoft Entra 識別碼中的任何使用者。基於這個理由，請務必考慮如何和何時允許 CA 發行憑證，以及其如何實作可重複使用的標識符。當系統管理員只需要確保只有特定憑證能夠用來驗證使用者時，系統管理員應該專門使用高親和性系結，以達到只有特定憑證能夠驗證使用者的較高層級保證。如需詳細資訊，請參閱高親和性系結。

設定及測試 Microsoft Entra CBA 的步驟

啟用 Microsoft Entra CBA 之前要完成的一些設定步驟。首先，系統管理員必須設定簽發用戶憑證的受信任 CA。如下圖所示，我們使用角色型訪問控制來確保只需要最低許可權的系統管理員才能進行變更。只有全域管理員 istrator 角色可以設定 CA。

您也可以選擇性地設定驗證系結，將憑證對應至單一因素或多重要素驗證，以及設定使用者名稱系結，將憑證字段對應至用戶對象的屬性。驗證原則管理員 istrators 可以設定使用者相關設定。完成所有設定之後，請在租用戶上啟用 Microsoft Entra CBA。

Diagram of the steps required to enable Microsoft Entra certificate-based authentication.

步驟 1：設定證書頒發機構單位

您可以使用 Microsoft Entra 系統管理中心或 Microsoft Graph REST API 和支援的 SDK，例如 Microsoft Graph PowerShell 來設定證書頒發機構單位（CA）。 PKI 基礎結構或 PKI 系統管理員應該能夠提供發行 CA 的清單。若要確定您已設定所有 CA，請開啟使用者憑證，然後按兩下 [認證路徑] 索引卷標，並確定每個 CA，直到根目錄上傳至 Entra 信任存放區為止。如果缺少CA，CBA驗證將會失敗。

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

若要啟用憑證式驗證，並在 Microsoft Entra 系統管理中心設定用戶系結，請完成下列步驟：

以全域管理員 istrator 身分登入 Microsoft Entra 系統管理中心。
流覽至 [保護>] 顯示更多>資訊安全中心 （或身分識別安全分數） >證書頒發機構單位。
若要上傳 CA，請選取 [上傳]：
1. 選取 CA 檔案。
2. 如果 CA 是跟證書，請 選取 [是 ]，否則請選取 [ 否]。
3. 針對 [證書吊銷清單 URL]，針對包含所有已撤銷憑證的 CA 基底 CRL 設定因特網對應 URL。如果未設定 URL，則具有已撤銷憑證的驗證將不會失敗。
4. 針對 差異證書吊銷清單 URL，設定 CRL 的因特網對應 URL，其中包含自上次發布基底 CRL 之後的所有已撤銷憑證。
5. 選取 [新增]。
若要刪除 CA 憑證，請選取憑證，然後選取 [ 刪除]。
選取 [ 資料行] 以新增或刪除資料列。

注意

如果現有的 CA 已過期，則上傳新的 CA 會失敗。全域管理員 istrator 應該刪除任何過期的 CA，然後重試上傳新的 CA。

使用 PowerShell 設定憑證頒發機構單位（CA）

僅支援信任 CA 的一個 CRL 發佈點（CDP）。 CDP 只能是 HTTP URL。不支援在線憑證狀態通訊協定（OCSP）或輕量型目錄存取通訊協定（LDAP） URL。

若要在 Microsoft Entra ID 中設定您的證書頒發機構單位，請針對每個證書頒發機構單位上傳下列專案：

憑證的公開部分，格式為 .cer
證書吊銷清單（CRL）所在的因特網對應 URL

憑證頒發機構單位的架構如下所示：

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

針對設定，您可以使用 Microsoft Graph PowerShell：

使用系統管理員許可權啟動 Windows PowerShell。
安裝 Microsoft Graph PowerShell：
```
    Install-Module Microsoft.Graph
```

在第一個設定步驟中，您必須建立與租用戶的連線。一旦租用戶連線存在，您就可以檢閱、新增、刪除和修改目錄中定義的受信任證書頒發機構單位。

連線

若要與租使用者建立連線，請使用連線-MgGraph：

    Connect-MgGraph

Retrieve

若要擷取目錄中定義的受信任證書頒發機構單位，請使用 Get-MgOrganizationCertificateBasedAuthConfiguration。

    Get-MgOrganizationCertificateBasedAuthConfiguration

加

注意

當任何現有的 CA 到期時，新 CA 的上傳將會失敗。租使用者管理員應刪除過期的 CA，然後上傳新的 CA。

請遵循上述步驟，在 Microsoft Entra 系統管理中心中新增 CA。

AuthorityType

使用 0 表示跟證書授權單位
使用 1 表示中繼或發行證書頒發機構單位

crlDistributionPoint

您可以下載 CRL 並比較 CA 憑證和 CRL 資訊，以驗證上述 PowerShell 範例中的 crlDistributionPoint 值，對於您想要新增的 CA 有效。

下表和圖形顯示如何將 CA 憑證的信息對應至所下載 CRL 的屬性。

CA 憑證資訊	=	下載的CRL資訊
主旨	=	Issuer
主體金鑰識別碼	=	授權金鑰識別碼（KeyID）

Compare CA Certificate with CRL Information.

提示

上述範例中crlDistributionPoint的值是CA證書吊銷清單（CRL）的 HTTP 位置。您可以在幾個位置找到此值：

在 CA 所發行憑證的 CRL 發佈點（CDP）屬性中。

如果發行 CA 執行 Windows Server：

在證書頒發機構單位 Microsoft Management Console （MMC）中的 CA 屬性上。
藉由執行，在 CA 上執行 certutil -cainfo cdp。如需詳細資訊，請參閱 certutil。

如需詳細資訊，請參閱瞭解證書吊銷程式。

驗證證書頒發機構單位設定

請務必確保上述組態步驟結果為 Entra ID 能夠同時驗證證書頒發機構單位信任鏈結，並確認已設定證書頒發機構單位 CRL 發佈點的證書吊銷清單（CRL）。若要協助這項工作，建議您安裝 MSIdentity Tools PowerShell 模組，並執行 Test-MsIdCBATrustStoreConfiguration。此 PowerShell Cmdlet 會檢閱 Entra 租使用者證書頒發機構單位設定，並針對常見的設定錯誤問題呈現錯誤/警告。

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

重要

當使用者位於驗證方法原則中憑證式驗證的範圍內時，使用者就會被視為能夠用於 MFA。此原則需求表示使用者無法使用證明作為驗證的一部分，以註冊其他可用的方法。如果用戶沒有憑證的存取權，他們將被鎖定，而且無法註冊 MFA 的其他方法。因此，系統管理員必須啟用具有有效憑證的用戶進入CBA範圍。請勿將所有用戶用於CBA目標，並使用具有有效憑證的使用者群組。如需詳細資訊，請參閱 Microsoft Entra 多重要素驗證。

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

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

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

注意

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

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

驗證系結原則有助於判斷單一因素或多重要素的驗證強度。租用戶上憑證的默認保護層級是 單一要素驗證。

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

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

以至少驗證原則管理員 istrator 身分登入 Microsoft Entra 系統管理中心。
流覽至 [保護>驗證方法>原則]。
在 [管理] 底下，選取 [驗證方法>憑證式驗證]。
選取 [ 設定 ] 以設定驗證系結和使用者名稱系結。
保護層級屬性的預設值 為 Single-Factor Authentication。選取 [多重要素驗證 ]，將預設值變更為 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 發行的憑證進行驗證。驗證應該通過並取得多重要素宣告。

重要

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

Windows Hello 企業版註冊
Fido2 安全性金鑰註冊
Windows 無密碼電話登入

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

編輯目前同時使用簽發者和原則 OID 選項的憑證式驗證原則規則，並移除簽發者或 OID 需求並儲存。 OR
拿掉目前同時使用簽發者和原則 OID 的驗證原則規則，並只使用簽發者或原則 OID 建立規則

我們正努力修正此問題。

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

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

登入記錄會顯示使用哪個系結，以及憑證的詳細數據。

Screenshot of Sign-ins log.

選取 [ 確定 ] 以儲存任何自定義規則。

重要

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

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

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

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

如需使用 certificateUserIds 屬性之案例的詳細資訊，請參閱憑證用戶標識碼。

重要

如果使用者名稱系結原則使用同步處理的屬性，例如 certificateUserIds、onPremisesUserPrincipalName 和用戶物件的 userPrincipalName 屬性，請注意 Active Directory 中具有系統管理許可權的帳戶（例如具有用戶物件委派許可權的帳戶，或是 Entra 連線 Server 上具有委派許可權的帳戶）可以在 Entra ID 中做出影響這些屬性的變更。

選取其中一個要與其中一個使用者屬性系結的 X.509 憑證欄位，以建立使用者名稱系結。用戶名稱系結順序代表系結的優先順序層級。第一個優先順序最高，依序等。

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

最終組態看起來會像下圖：

Screenshot of the final configuration.

步驟 5：測試您的設定

本節涵蓋如何測試憑證和自定義驗證系結規則。

測試您的憑證

作為第一個組態測試，您應該嘗試使用裝置瀏覽器登入 MyApps 入口網站。

輸入您的用戶主體名稱（UPN）。
選取 [下一步]。

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

如果您的登入成功，則您知道：

用戶憑證已布建到您的測試裝置。
Microsoft Entra 識別碼已使用受信任的 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，以判斷使用者。驗證原則管理員 istrator 可以覆寫預設值並建立自定義對應，如步驟 4 稍早所述。

啟用新的系結之前，驗證原則管理員 istrator 必須確定已針對對應的使用者名稱系結，在用戶物件屬性 Certificate UserIds 中更新系結的正確值。

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

重要

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

簽發者和序號手動對應

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

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

Screenshot of the Issuer value.

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

問題和主旨手動對應

以下是問題和主體手動對應範例。簽發者值為：

Screenshot of the Issuer value when used with multiple bindings.

Subject 值為：

Screenshot of the Subject value.

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

主旨手動對應

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

Screenshot of another Subject value.

CertificateUserId：

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

測試親和性系結

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

重要

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

完成時，規則看起來會像下列螢幕快照：
更新所有用戶物件 CertificateUserIds 屬性，以從用戶憑證取得正確的 SKI 值。如需詳細資訊，請參閱 CertificateUserID 的支援模式。
建立驗證系結的自定義規則。
選取 [新增]。

完成時，規則看起來會像下列螢幕快照：
使用原則 OID 9.8.7.5，從憑證使用正確的 SKI 值更新使用者 CertificateUserIds。
使用原則 OID 9.8.7.5 的憑證進行測試，且用戶應該使用 SKI 系結進行驗證，並只使用憑證取得 MFA。

使用 Microsoft Graph API 啟用 CBA

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

注意

下列步驟使用美國政府雲端中無法使用的 Graph 總管。美國政府雲端租使用者可以使用Postman來測試 Microsoft Graph 查詢。

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

GET 所有驗證方法：

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 Entra 憑證型驗證

必要條件

設定及測試 Microsoft Entra CBA 的步驟

步驟 1：設定證書頒發機構單位

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

使用 PowerShell 設定憑證頒發機構單位 （CA）

連線

Retrieve

加

驗證證書頒發機構單位設定

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

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

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

步驟 5：測試您的設定

測試您的憑證

測試自定義驗證系結規則

測試用戶名稱系結原則

簽發者和序號手動對應

問題和主旨手動對應

主旨手動對應

測試親和性系結

使用 Microsoft Graph API 啟用 CBA

要求本文：

下一步

其他資源

使用 PowerShell 設定憑證頒發機構單位（CA）