共用方式為

Microsoft Entra 憑證型驗證技術概念

本文說明技術概念，以說明 Microsoft Entra 憑證型驗證 （CBA） 的運作方式。 取得技術背景，以進一步瞭解如何在租用戶中設定和管理 Microsoft Entra CBA。

Microsoft Entra 憑證型驗證如何運作？

下圖描述當使用者嘗試登入已設定 Microsoft Entra CBA 之租使用者中的應用程式時所發生的情況。

顯示 Microsoft Entra 憑證型驗證中步驟概觀的圖表。

下列步驟摘要說明 Microsoft Entra CBA 程式：

  1. 使用者嘗試存取應用程式，例如 MyApps 入口網站。

  2. 如果使用者尚未登入，系統會將他們重新導向至 Microsoft Entra ID 使用者登入頁面 https://login.microsoftonline.com/，網址為 。

  3. 他們會在 Microsoft Entra 登入頁面上輸入其使用者名稱，然後選取 [ 下一步]。 Microsoft Entra ID 會使用租用戶名稱完成主領域探索。 它會使用使用者名稱來查閱租用戶中的使用者。

    螢幕擷取畫面，顯示 MyApps 入口網站的登入頁面。

  4. Microsoft Entra ID 會檢查是否已為租用戶設定 CBA。 如果已設定 CBA，使用者會在密碼頁面上看到使用 憑證或智慧卡 的連結。 如果使用者看不到登入連結，請確定已為租用戶設定 CBA。

    如需詳細資訊，請參閱如何 開啟 Microsoft Entra CBA？。

    註記

    如果已為租用戶設定 CBA，所有使用者都會在密碼登入頁面上看到 [ 使用憑證或智慧卡 ] 連結。 不過，只有 CBA 範圍內的使用者才能成功驗證使用 Microsoft Entra ID 作為其身分識別提供者的應用程式。

    螢幕擷取畫面，顯示使用憑證或智慧卡的選項。

    如果您提供其他驗證方法，例如手機登入或安全性金鑰，使用者可能會看到不同的登入對話方塊。

    螢幕擷取畫面，顯示登入對話方塊 （如果 FIDO2 驗證也可用）。

  5. 使用者選取 CBA 之後，用戶端會重新導向至憑證驗證端點。 針對公用 Microsoft Entra ID，憑證驗證端點是 https://certauth.login.microsoftonline.com。 針對 Azure 政府，憑證驗證端點是 https://certauth.login.microsoftonline.us。

    端點會執行傳輸層安全性 （TLS） 相互驗證，並在 TLS 交握中要求用戶端憑證。 此要求的項目會出現在登入記錄中。

    註記

    系統管理員應允許存取使用者登入頁面，以及 *.certauth.login.microsoftonline.com 雲端環境的憑證驗證端點。 關閉憑證驗證端點上的 TLS 檢查，以確保用戶端憑證要求在 TLS 交握過程中成功。

    請確定關閉 TLS 檢查也適用於具有新 URL 的簽發者提示。 請勿使用租用戶識別碼硬式編碼 URL。 企業對企業 （B2B） 使用者的租用戶識別碼可能會變更。 使用正規表示式，在關閉 TLS 檢查時，允許先前的 URL 和新 URL 同時運作。 例如，視 Proxy 而定，請使用 *.certauth.login.microsoftonline.com 或 *certauth.login.microsoftonline.com。 在 Azure Government 中，使用 *.certauth.login.microsoftonline.us 或 *certauth.login.microsoftonline.us。

    除非允許存取，否則如果您開啟 簽發者提示，CBA 就會失敗。

  6. Microsoft Entra ID 要求用戶端憑證。 使用者選取用戶端憑證，然後選取 [ 確定]。

    顯示憑證選擇器的螢幕擷取畫面。

  7. Microsoft Entra ID 會驗證憑證撤銷清單 （CRL） ，以確保憑證未撤銷且有效。 Microsoft Entra ID 藉由使用租用戶上設定的使用者名稱繫結來識別使用者，以將憑證欄位值對應至使用者屬性值。

  8. 如果透過需要多重要素驗證 （MFA） 的 Microsoft Entra 條件式存取原則找到唯一使用者，且 憑證驗證系結規則 符合 MFA，則 Microsoft Entra ID 會立即登入使用者。 如果需要 MFA，但憑證只滿足單一因素，如果使用者已註冊，則會提供無密碼登入和 FIDO2 作為第二個因素。

  9. Microsoft Entra ID 透過傳回主要重新整理權杖，來完成登入流程，表示登入成功。

如果使用者登入成功，使用者就可以存取應用程式。

簽發者提示 （預覽版）

簽發者提示會傳回 受信任的 CA 指示器，作為 TLS 交握的一部分。 受信任的 CA 清單會設定為租用戶上傳至 Microsoft Entra 信任存放區的 CA 主體。 瀏覽器用戶端或原生應用程式用戶端可以使用伺服器傳回的提示來篩選憑證選擇器中顯示的憑證。 用戶端只會顯示信任存放區中 CA 所簽發的驗證憑證。

開啟簽發者提示

若要開啟發行者提示，請選取 [發行者提示] 核取方塊。 驗證原則系統管理員應該在確定已正確更新已設定 TLS 檢查的 Proxy 之後，選取 [我確認]，然後儲存變更。

註記

如果您的組織具有使用 TLS 檢查的防火牆或 Proxy，請確認您已關閉 CA 端點的 TLS 檢查，該端點能夠比對 下的任何名稱 [*.]certauth.login.microsoftonline.com，並根據使用中的特定 Proxy 進行自訂。

顯示如何開啟簽發者提示的螢幕擷取畫面。

註記

開啟簽發者提示之後，CA URL 的格式 <tenantId>.certauth.login.microsoftonline.com為 。

螢幕擷取畫面，顯示您開啟簽發者提示之後的憑證選擇器。

CA 信任存放區更新分發

開啟簽發者提示並從信任存放區新增、更新或刪除 CA 之後，簽發者提示傳播回用戶端時，可能會發生長達 10 分鐘的延遲。 驗證原則系統管理員應該在提供簽發者提示以起始傳播之後，使用憑證登入。

在傳播提示之前，使用者無法使用新 CA 所發行的憑證進行驗證。 當傳播 CA 信任存放區更新時，使用者會看到下列錯誤訊息：

螢幕擷取畫面，顯示使用者看到的錯誤，如果更新正在進行中。

具有單一因素 CBA 的 MFA

Microsoft Entra CBA 符合第一因素驗證和第二因素驗證的資格。

以下是一些支援的組合：

使用者必須有辦法取得 MFA ，並在使用 Microsoft Entra CBA 登入之前註冊無密碼登入或 FIDO2。

重要

如果使用者的使用者名稱出現在 CBA 方法設定中，則會被視為具有 MFA 功能。 在此案例中，使用者無法使用其身分識別作為驗證的一部分，以註冊其他可用的方法。 請確定沒有有效憑證的使用者不會包含在 CBA 方法設定中。 如需驗證運作方式的詳細資訊，請參閱 Microsoft Entra 多重要素驗證。

取得已啟用 CBA 的 MFA 功能的選項

Microsoft Entra CBA 可以是單一因素或多因素，視租用戶設定而定。 開啟 CBA 可讓使用者可能完成 MFA。 具有單一因素憑證或密碼的使用者必須使用其他因素才能完成 MFA。

我們不允許在未先滿足 MFA 的情況下註冊其他方法。 如果使用者沒有註冊任何其他 MFA 方法，且在 CBA 的範圍內，則使用者無法使用身分證明來註冊其他驗證方法並取得 MFA。

如果支援 CBA 的使用者只有單一因素憑證，而且需要完成 MFA，請選擇下列 其中一個 選項來驗證使用者：

  • 使用者可以輸入密碼並使用單因素憑證。
  • 驗證原則管理員可以發出暫時存取密碼。
  • 驗證原則管理員可以新增電話號碼，並允許使用者帳戶的語音或文字訊息驗證。

如果支援 CBA 的使用者尚未獲得憑證，而且需要完成 MFA，請選擇下列 其中一個 選項來驗證使用者：

  • 驗證原則管理員可以發出暫時存取密碼。
  • 驗證原則管理員可以新增電話號碼，並允許使用者帳戶的語音或文字訊息驗證。

如果支援 CBA 的使用者無法使用多重要素憑證，例如，如果他們使用沒有智慧卡支援的行動裝置，但需要完成 MFA，請選擇下列 其中一個 選項來驗證使用者：

  • 驗證原則管理員可以發出暫時存取密碼。
  • 使用者可以註冊另一個 MFA 方法 （當使用者 可以在 裝置上使用多重要素憑證時）。
  • 驗證原則管理員可以新增電話號碼，並允許使用者帳戶的語音或文字訊息驗證。

使用 CBA 設定無密碼手機登入

若要讓無密碼手機登入正常運作，請先為使用者關閉透過行動應用程式的舊版通知。

  1. 以至少驗證原則管理員的身分登入 Microsoft Entra 系統管理中心。

  2. 完成 啟用無密碼手機登入驗證中所述的步驟。

    重要

    請確定您選取 [無密碼] 選項。 對於您新增至無密碼電話登入的任何群組，您必須將 驗證模式 的值變更 為無密碼。 如果您選取 [任何]，則 CBA 和無密碼登入將無法運作。

  3. 選取 Entra ID>多重要素驗證>其他雲端式多重要素驗證設定。

    螢幕擷取畫面，顯示如何設定 MFA 設定。

  4. 在 [驗證選項] 底下，清除 [透過行動應用程式通知] 核取方塊，然後選取 [儲存]。

    屏幕截圖顯示瞭如何通過移動應用程序選項刪除通知。

使用單一因素憑證和無密碼登入的 MFA 驗證流程

請考慮具有單一因素憑證且設定為無密碼登入的使用者範例。 身為使用者，您將完成下列步驟：

  1. 輸入您的使用者主體名稱 （UPN），然後選取 [ 下一步]。

    螢幕擷取畫面，顯示如何輸入使用者主體名稱。

  2. 選取 [ 使用憑證或智慧卡]。

    螢幕擷取畫面，顯示如何使用憑證登入。

    如果您提供其他驗證方法，例如手機登入或安全性金鑰，使用者可能會看到不同的登入對話方塊。

    螢幕擷取畫面顯示使用憑證登入的替代方式。

  3. 在用戶端憑證選擇器中，選取正確的使用者憑證，然後選取 [確定]。

    螢幕擷取畫面，顯示如何選取憑證。

  4. 由於憑證已設定為單一因素驗證的強度，因此您需要第二個因素來滿足 MFA 需求。 可用的第二個因素會顯示在登入對話方塊中。 在此情況下，它是無密碼登入。 請選取 [在我的 Microsoft Authenticator 應用程式上核准要求]。

    顯示完成第二因素要求的螢幕擷取畫面。

  5. 您會在手機上收到通知。 選取 [核准登入？]。 顯示電話核准請求的螢幕擷取畫面。

  6. 在 Microsoft Authenticator 中，輸入您在瀏覽器或應用程式中看到的號碼。

    顯示數字匹配的屏幕截圖。

  7. 選取 [ 是]，您就可以驗證並登入。

驗證繫結原則

驗證繫結原則有助於將驗證的強度設定為單一因素或多因素。 驗證原則管理員可以將預設方法從單一因素變更為多因素。 系統管理員也可以在 IssuerAndSubject憑證中使用 、 PolicyOID或 Issuer 和 PolicyOID 來設定自訂原則設定。

證書強度

驗證原則管理員可以判斷憑證強度是單因素還是多因素。 如需詳細資訊，請參閱將 NIST 驗證保證等級對應至 Microsoft Entra 驗證方法的文件，其建置基礎是根據 NIST 800-63B SP 800-63B，數位身分識別指導方針：驗證和生命週期管理。

多重要素憑證驗證

當使用者擁有多重要素憑證時，他們只能使用憑證來執行 MFA。 不過，驗證原則系統管理員應該確定憑證受到 PIN 或生物特徵辨識的保護，才能被視為多重要素。

多個驗證原則繫結規則

您可以使用不同的憑證屬性來建立多個自訂驗證繫結原則規則。 例如，使用發行者和原則 OID，或僅使用原則 OID，或僅使用發行者。

下列順序會決定自訂規則重疊時的驗證保護層級：

  1. 簽發者和原則 OID 規則優先於原則 OID 規則。 原則 OID 規則的優先順序高於憑證簽發者規則。
  2. 會先評估發行者和原則 OID 規則。 如果您有具有簽發者 CA1 的自訂規則，以及具有 MFA 的原則 OID 1.2.3.4.5 ，則只有同時滿足簽發者值和原則 OID 的憑證 A 才會提供 MFA。
  3. 會評估使用政策 OID 的自訂規則。 如果您有原則 OID 為的 1.2.3.4.5 憑證 A，以及以原則 OID 為 1.2.3.4.5.6的憑證為基礎的衍生認證 B，且自訂規則定義為具有 MFA 值 1.2.3.4.5 的原則 OID，則只有憑證 A 符合 MFA。 認證 B 僅滿足單一因素驗證。 如果使用者在登入期間使用衍生認證，並已設定為 MFA，系統會要求使用者提供第二個因素才能成功驗證。
  4. 如果多個原則 OID 之間發生衝突 （例如，當憑證有兩個原則 OID，其中一個系結至單一因素驗證，另一個系結至 MFA） 時，請將憑證視為單一要素驗證。
  5. 會評估使用簽發者 CA 的自訂規則。 如果憑證具有相符的原則 OID 和簽發者規則，則一律會先檢查原則 OID。 如果找不到原則規則，則會檢查簽發者連結。 原則 OID 的強式驗證繫結優先順序高於簽發者。
  6. 如果有一個 CA 繫結至 MFA，此 CA 所簽發的所有使用者憑證都有資格作為 MFA。 同樣的邏輯也適用於單因素身份驗證。
  7. 如果一個原則 OID 系結至 MFA，則包含此原則 OID 作為其中一個 OID 的所有使用者憑證都符合 MFA 的資格。 （使用者憑證可以有多個原則 OID。
  8. 一個憑證簽發者只能有一個有效的強式驗證繫結 （也就是說，憑證無法同時繫結至單一要素驗證和 MFA）。

重要

目前，在正在解決的已知問題中，如果驗證原則系統管理員同時使用簽發者和原則 OID 來建立 CBA 原則規則，則某些裝置註冊案例會受到影響。

受影響的場景包括：

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

使用工作區聯結、Microsoft Entra ID 和 Microsoft Entra 混合式聯結案例的裝置註冊不會受到影響。 使用簽發者 或 原則 OID 的 CBA 原則規則不會受到影響。

若要緩解此問題，驗證原則管理員 應該完成下列 其中一個選項：

  • 編輯目前同時使用簽發者和原則 OID 的 CBA 原則規則，以移除簽發者或原則識別碼需求。
  • 移除目前同時使用簽發者和政策 OID 的驗證政策規則，然後建立僅使用簽發者或政策 OID 的規則。

使用者名稱繫結原則

使用者名稱繫結原則可協助驗證使用者的憑證。 依預設，憑證中的主體替代名稱 （SAN） 主體名稱會對應至 userPrincipalName 使用者物件的屬性，以識別使用者。

使用憑證繫結來達到更高的安全性

Microsoft Entra 支援七種使用憑證繫結的方法。 一般而言，如果對應類型是以您無法重複使用的識別碼為基礎， SubjectKeyIdentifier 例如 （SKI） 或 SHA1PublicKey。 這些識別碼傳達了更高的保證，即只能使用單一憑證來驗證使用者。

以使用者名稱和電子郵件地址為基礎的對應類型會被視為低親和性。 Microsoft Entra ID 會實作三個對應，這些對應會根據可重複使用的識別碼視為低親和性。 其他則會視為高親和性繫結。 如需詳細資訊，請參閱certificateUserIds。

憑證對應欄位 中的值範例 certificateUserIds 使用者物件屬性 類型
PrincipalName X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 低親和力
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 低親和力
IssuerAndSubject X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 低親和力
Subject X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 低親和力
SKI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds 高親和力
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
SHA1PublicKey值 （整個憑證內容的 SHA1 雜湊，包括公開金鑰） 位於憑證的 Thumbprint 屬性中。		 certificateUserIds 高親和力
IssuerAndSerialNumber X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
要獲取序列號的正確值，請運行此命令並存儲顯示在：certificateUserIds
語法：
certutil –dump –v [~certificate path~] >> [~dumpFile path~]
範例：
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds 高親和力

重要

您可以使用 CertificateBasedAuthentication PowerShell 模組 來尋找憑證中使用者的正確 certificateUserIds 值。

定義和覆寫親和性繫結

驗證原則管理員可以配置使用者是否可以使用低親和性或高親和性使用者名稱繫結對應來進行驗證。

設定租用戶的 必要親和性繫結 ，這適用於所有使用者。 若要覆寫全租用戶預設值，請根據簽發者和原則 OID，或只根據原則 OID，或只根據簽發者建立自訂規則。

多個使用者名稱原則繫結規則

若要解析多個使用者名稱原則繫結規則，Microsoft Entra ID 會使用最高優先順序 （最低數目） 繫結：

  1. 使用使用者名稱或 UPN 來查閱使用者物件。
  2. 取得驗證原則管理員在依屬性排序 priority 的 CBA 方法組態中設定的所有使用者名稱繫結清單。 目前，優先順序不會顯示在系統管理中心。 Microsoft Graph 會傳回 priority 每個繫結的屬性。 然後，在評估過程中使用優先級。
  3. 如果租用戶已設定高親和性繫結，或憑證值符合需要高親和性繫結的自訂規則，則會從清單中移除所有低親和性繫結。
  4. 評估清單中的每個繫結，直到驗證成功為止。
  5. 如果所設定繫結的 X.509 憑證欄位在呈現的憑證上，Microsoft Entra ID 會比對憑證欄位中的值與使用者物件屬性值。
    • 如果找到相符值，使用者驗證就會成功。
    • 如果找不到相符項目，則移至下一個優先順序繫結。
  6. 如果 X.509 憑證欄位不在呈現的憑證上，則移至下一個優先順序繫結。
  7. 驗證所有已設定的使用者名稱繫結，直到其中一個連結產生相符且使用者驗證成功為止。
  8. 如果在任何已設定的使用者名稱繫結上找不到相符值，則使用者驗證會失敗。

使用多個使用者名稱繫結來保護 Microsoft Entra 設定

每個 Microsoft Entra 使用者物件屬性都可用於將憑證繫結至Microsoft Entra 使用者帳戶 （userPrincipalName、 onPremiseUserPrincipalName和 certificateUserIds） 都有唯一的條件約束，以確保憑證僅符合單一Microsoft Entra 使用者帳戶。 不過，Microsoft Entra CBA 支援使用者名稱繫結原則中的多種繫結方法。 驗證原則系統管理員可以容納多個 Microsoft Entra 使用者帳戶設定中使用的一個憑證。

重要

如果您設定多個繫結，Microsoft Entra CBA 驗證的安全性僅與最低親和性繫結一樣安全，因為 CBA 會驗證每個繫結以驗證使用者。 若要避免單一憑證符合多個 Microsoft Entra 帳戶的案例，驗證原則管理員可以：

  • 在使用者名稱繫結原則中設定單一繫結方法。
  • 如果租用戶已設定多個繫結方法，而且不想允許一個憑證對應至多個帳戶，驗證原則系統管理員必須確保原則中設定的所有允許方法對應至相同的 Microsoft Entra 帳戶。 所有使用者帳戶都應該具有符合所有繫結的值。
  • 如果租用戶已設定多個繫結方法，驗證原則系統管理員應該確保它們沒有多個低親和性繫結。

例如，您有 PrincipalName 兩個使用者名稱繫結對應至 UPN，而 SubjectKeyIdentifier （SKI） 對應至 certificateUserIds。 如果您想要憑證只用於單一帳戶，驗證原則系統管理員必須確定帳戶具有憑證中存在的 UPN。 然後，管理員會在相同帳戶的屬性中SKI實作certificateUserIds對應。

支援具有一個 Microsoft Entra 使用者帳戶的多個憑證 (M:1)

在某些情況下，組織會針對單一身分識別發行多個憑證。 它可能是行動裝置的衍生認證，但也可能是次要智慧卡或支援 X.509 認證持有者的裝置，例如 YubiKey。

僅限雲端帳戶 （M：1）

對於僅限雲端帳戶，您可以使用唯一值填入欄位來識別每個憑證，以對應 certificateUserIds 最多五個憑證來使用。 若要對應憑證，請在系統管理中心移至 [授權資訊 ] 索引標籤。

如果組織使用高親和性連結， IssuerAndSerialNumber例如 ，中的 certificateUserIds 值可能看起來像下列範例：

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

在此範例中，第一個值代表 X509Certificate1。 第二個值代表 X509Certificate2。 使用者可以在登入時出示任一憑證。 如果 CBA 使用者名稱繫結設定為指向 certificateUserIds 欄位以尋找特定繫結類型 （在此範例中） IssuerAndSerialNumber，則使用者會成功登入。

混合同步帳戶 （M：1）

對於同步處理的帳戶，您可以對應多個憑證。 在內部部署 Active Directory 中，使用識別每個憑證的值填入 altSecurityIdentities 欄位。 如果您的組織使用高親和性連結 （亦即強式鑑別）， IssuerAndSerialNumber例如 ，值可能看起來像下列範例：

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

在此範例中，第一個值代表 X509Certificate1。 第二個值代表 X509Certificate2。 然後，必須將值同步至 certificateUserIds Microsoft Entra ID 中的欄位。

支援一個憑證用於多個 Microsoft Entra 使用者帳戶 (1:M)

在某些情況下，組織需要使用者使用相同的憑證來驗證多個身分。 它可能適用於管理帳戶、開發人員或臨時值班帳戶。

在內部部署 Active Directory 中，此 altSecurityIdentities 欄位會填入憑證值。 登入期間會使用提示，將 Active Directory 導向至預期的帳戶，以檢查登入。

Microsoft Entra CBA 有不同的程式，而且不包含任何提示。 相反地，主領域探索會識別預期的帳戶並檢查憑證值。 Microsoft Entra CBA 也會強制執行欄位的唯一 certificateUserIds 性。 兩個帳戶無法填入相同的憑證值。

重要

使用相同的認證來驗證不同的 Microsoft Entra 帳戶不是安全設定。 建議您不允許將單一憑證用於多個 Microsoft Entra 使用者帳戶。

僅限雲端帳戶 （1：M）

對於僅限雲端的帳戶，請建立多個使用者名稱繫結，並將唯一值對應至使用憑證的每個使用者帳戶。 每個帳戶的存取權都會使用不同的使用者名稱繫結來驗證。 此驗證層級適用於單一目錄或租用戶的界限。 驗證原則管理員可以將憑證對應到另一個目錄或租戶中使用它，前提是每個帳戶的值保持唯一。

使用識別憑證的唯一值填入 certificateUserIds 欄位。 若要填入欄位，請在系統管理中心移至 [ 授權資訊 ] 索引標籤。

如果組織使用高親和性連結 （亦即強式鑑別） （例如 IssuerAndSerialNumber 和 SKI），則值可能看起來像下列範例：

使用者名稱繫結：

  • IssuerAndSerialNumber > certificateUserIds
  • SKI > certificateUserIds

使用者帳戶 certificateUserIds 值：
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

現在，當任一使用者在登入時提供相同的憑證時，使用者會成功登入，因為其帳戶符合該憑證上的唯一值。 一個帳戶會使用 進行 IssuerAndSerialNumber 驗證，另一個帳戶會使用 SKI 繫結來驗證。

註記

能夠以此方式使用的帳戶數目受限於租用戶上設定的使用者名稱繫結數目。 如果組織只使用高親和性繫結，則支援的帳戶數目上限為三個。 如果組織也使用低親和性繫結，則數目會增加至七個帳戶：一個 PrincipalName、一個 RFC822Name、一個 SKI、 SHA1PublicKey一個、 IssuerAndSubject一個、一個 IssuerAndSerialNumber和一個 Subject。

混合式同步帳戶 （1：M）

同步帳戶需要不同的方法。 雖然驗證原則系統管理員可以將唯一值對應至使用憑證的每個使用者帳戶，但將所有值填入 Microsoft Entra ID 中每個帳戶的常見做法會讓此方法變得困難。 相反地，Microsoft Entra Connect 應該將每個帳戶的值篩選為填入 Microsoft Entra ID 中帳戶的唯一值。 唯一性規則會套用至單一目錄或租用戶的界限。 驗證原則管理員可以將憑證對應到另一個目錄或租戶中使用它，前提是每個帳戶的值保持唯一。

組織也可能有多個 Active Directory 樹系，可將使用者提供給單一 Microsoft Entra 租用戶。 在此情況下，Microsoft Entra Connect 會將篩選套用至每個具有相同目標的 Active Directory 樹系：只填入雲端帳戶的特定唯一值。

在 Active Directory 中填 altSecurityIdentities 入欄位，以識別憑證的值。 包括該使用者帳戶類型的特定憑證值 （例如 detailed、 admin或 developer）。 選取 Active Directory 中的索引鍵屬性。 此屬性會告知同步處理使用者正在評估的使用者帳戶類型 （例如 msDS-cloudExtensionAttribute1）。 使用此屬性填入您要使用的使用者類型值，例如 detailed、 admin或 developer。 如果帳戶是使用者的主要帳戶，則值可以是空的或 Null。

檢查帳戶看起來是否與以下範例相似：

樹系 1：帳戶 1 （bob@woodgrove.com）：
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

樹系 1：帳戶 2 （bob-admin@woodgrove.com）：
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

森林 2：ADAccount1 （bob-tdy@woodgrove.com）：
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

然後，您必須將這些值同步至 certificateUserIds Microsoft Entra ID 中的欄位。

同步至 certificateUserIds：

  1. 設定 Microsoft Entra Connect 以將欄位新增至 alternativeSecurityIds Metaverse。
  2. 針對每個內部部署 Active Directory 樹系，設定具有高優先順序的新自訂輸入規則 （低數目，低於 100）。 新增 Expression 以欄位作為來源的 altSecurityIdentities 轉換。 目標運算式會使用您選取並移入的索引鍵屬性，並使用您定義之使用者類型的對應。

例如：

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

在此範例中， altSecurityIdentities 會先檢查索引鍵屬性 msDS-cloudExtensionAttribute1 ，以查看是否已填入。 如果未填入， altSecurityIdentities 則會檢查是否已填入。 如果是空的，請將其設定為 NULL。 否則，帳戶是預設案例。

同樣在此範例中，僅根據對應進行 IssuerAndSerialNumber 篩選。 如果已填入索引鍵屬性，則會檢查值，以查看它是否等於您定義的其中一個使用者類型。 在此範例中，如果該值是 detailed，則篩選 中的值SHA1PublicKey。altSecurityIdentities 如果值為 developer，則會篩選 SubjectKeyIssuer中的值。altSecurityIdentities

您可能會遇到特定類型的多個憑證值。 例如，您可能會看到多個 PrincipalName 值或多個 SKI 或 SHA1-PUKEY 值。 篩選會取得所有值，並在 Microsoft Entra ID 中同步處理它們，而不只是它找到的第一個值。

以下是第二個範例，顯示如何在控制項屬性為空時推送空值：

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
)

如果中的 altSecurityIdentities 值不符合控制項屬性中的任何搜尋值，則會傳遞值 AuthoritativeNull 。 此值可確保忽略填入的 alternativeSecurityId 先前或後續規則。 結果在 Microsoft Entra ID 中是空的。

若要同步處理空白值：

  1. 設定具有低優先順序的新自訂輸出規則 （高數字，高於 160，但從清單底部開始）。
  2. 新增以欄位為來源，以欄位為目標的alternativeSecurityIds直接轉換certificateUserIds。
  3. 執行同步處理週期，以完成 Microsoft Entra ID 中的資料填入。

請確定每個租用戶中的 CBA 都設定了指向您從憑證對應之欄位類型的欄位的使用者名稱繫結 certificateUserIds 。 現在，這些使用者中的任何一個都可以在登入時出示憑證。 針對欄位驗證 certificateUserIds 憑證的唯一值之後，使用者會成功登入。

憑證授權單位 （CA） 範圍設定 （預覽版）

Microsoft Entra 中的 CA 範圍可讓租用戶系統管理員將特定 CA 的使用限制為已定義的使用者群組。 此功能可確保只有授權使用者才能使用特定 CA 所核發的憑證進行驗證，從而增強 CBA 的安全性和可管理性。

CA 範圍在多 PKI 或 B2B 案例中很有用，其中多個 CA 會跨不同的使用者母體使用。 它有助於防止非預期的存取，並促進符合組織政策。

重點優勢

  • 將憑證使用限制為特定使用者群組
  • 透過多個 CA 支援複雜的 PKI 環境
  • 提供增強的保護，防止憑證濫用或入侵
  • 透過登入記錄和監控工具提供 CA 使用情況的可見性

系統管理員可以使用 CA 範圍來定義規則，將 CA （由其 SKI 識別） 與特定 Microsoft Entra 群組產生關聯。 當使用者嘗試使用憑證進行鑑別時，系統會檢查憑證的發行 CA 範圍是否限定為包含使用者的群組。 Microsoft Entra 會向上推進 CA 鏈結。 它會套用所有範圍規則，直到在所有範圍規則的其中一個群組中找到使用者為止。 如果使用者不在範圍群組中，則驗證會失敗，即使憑證在其他方面有效也一樣。

設定 CA 範圍功能

  1. 以至少驗證原則管理員的身分登入 Microsoft Entra 系統管理中心。

  2. 移至 Entra ID>驗證方法>憑證型驗證。

  3. 在 [設定] 底下，移至 [憑證簽發者範圍設定原則]。

    顯示 CA 範圍原則的螢幕擷取畫面。

  4. 選取 [新增規則]。

    螢幕擷取畫面，顯示如何新增 CA 範圍規則。

  5. 選取 依 PKI 篩選 CA。

    傳統 CA 會顯示傳統 CA 存放區中的所有 CA。 選取特定 PKI 會顯示所選 PKI 中的所有 CA。

  6. 選取 PKI。

    顯示 CA 範圍 PKI 篩選的螢幕擷取畫面。

  7. 憑證簽發者清單會顯示所選 PKI 中的所有 CA。 選取 CA 以建立範圍規則。

    螢幕擷取畫面，顯示如何在 CA 範圍設定中選取 CA。

  8. 選取 [ 新增群組]。

    螢幕擷取畫面，顯示 CA 範圍設定中的新增群組選項。

  9. 選取群組。

    螢幕擷取畫面，顯示 CA 範圍設定中的選取群組選項。

  10. 選取 [ 新增 ] 以儲存規則。

    顯示 CA 範圍設定中的儲存規則選項的螢幕擷取畫面。

  11. 選取 [我確認] 核取方塊，然後選取 [儲存]。

    螢幕擷取畫面顯示 CA 範圍設定中的 [儲存 CBA] 組態選項。

  12. 若要編輯或刪除 CA 範圍原則，請選取 [...]在規則列上。 若要編輯規則，請選取 [編輯]。 若要刪除規則，請選取 [刪除]。

    螢幕擷取畫面，顯示如何在 CA 範圍中編輯或刪除。

已知限制

  • 每個 CA 只能指派一個群組。
  • 最多支援 30 個範圍規則。
  • 範圍會在中繼 CA 層級強制執行。
  • 如果沒有有效的範圍規則存在，則不正確的配置可能會導致使用者鎖定。

登入記錄條目

  • 登入記錄會顯示成功。 在 「其他詳細資料」 索引標籤上，範圍設定原則規則中 CA 的 SKI 隨即顯示。

    顯示 CA 範圍規則登入記錄成功的螢幕擷取畫面。

  • 當 CBA 因 CA 範圍規則而失敗時，登入記錄中的 [ 基本資訊 ] 索引標籤會顯示錯誤碼 500189。

    顯示 CA 範圍登入記錄錯誤的螢幕擷取畫面。

    使用者會看到下列錯誤訊息：

    顯示 CA 範圍使用者錯誤的螢幕擷取畫面。

CBA 如何與條件式存取驗證強度原則搭配運作

您可以使用內建的 Microsoft Entra 網路釣魚防護 MFA 驗證強度來建立條件式存取驗證原則，以指定使用 CBA 來存取資源。 此原則只允許防網路釣魚的驗證方法，例如 CBA、FIDO2 安全性金鑰和 Windows Hello 企業版。

您也可以建立自訂驗證強度，只允許 CBA 存取敏感性資源。 您可以允許 CBA 作為單一因素驗證、MFA 或兩者。 如需詳細資訊，請參閱條件式存取驗證強度。

CBA實力與高級選項

在 CBA 方法原則中，驗證原則系統管理員可以使用 CBA 方法上的 驗證繫結原則 來判斷憑證的強度。 現在，當使用者執行 CBA 存取特定敏感性資源時，您可以根據簽發者和原則 OID 要求使用特定憑證。 當您建立自訂驗證強度時，請移至 進階選項。 此功能提供更精確的組態，以判斷可存取資源的憑證及使用者。 如需詳細資訊，請參閱條件式存取驗證強度的進階選項。

登入記錄

登入記錄提供登入的相關資訊，以及您的資源在組織中的使用方式。 如需詳細資訊，請參閱 Microsoft Entra ID 中的登入記錄。

接下來，考慮兩種情況。 在一種情況下，憑證滿足單因素身份驗證。 在第二種案例中，憑證符合 MFA。

針對測試案例，選取具有需要 MFA 之條件式存取原則的使用者。

將 主體替代名稱 和 主體名稱 對應至 userPrincipalName 使用者物件，以設定使用者繫結原則。

使用者憑證的配置應如以下螢幕擷取畫面所示：

顯示使用者憑證的螢幕擷取畫面。

針對登入記錄中動態變數的登入問題進行疑難排解

雖然登入記錄通常會提供偵錯登入問題所需的所有資訊，但有時需要特定值。 登入記錄不支援動態變數，因此在某些情況下，登入記錄沒有偵錯所需的資訊。

例如，登入記錄中的失敗原因可能會顯示 "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." 在此案例中，<expectedSKI> 而且 <crlAKI> 不會填入正確的值。

當使用者使用 CBA 登入失敗時，您可以從錯誤頁面上的 [更多詳細資料] 連結複製記錄詳細資料。 如需詳細資訊，請參閱 瞭解 CBA 錯誤頁面。

測試單一要素驗證

針對第一個測試案例，請設定規則滿足單一因素驗證的 IssuerAndSubject 驗證原則。

螢幕擷取畫面，顯示所需的驗證原則設定和單一因素驗證。

  1. 使用 CBA 以測試使用者身分登入 Microsoft Entra 系統管理中心。 驗證原則是在規則滿足單一因素驗證的位置 IssuerAndSubject 設定的。

  2. 搜尋，然後選取 [登入記錄]。

    下圖顯示您可以在登入記錄中找到的一些專案。

    第一個項目會向使用者要求 X.509 憑證。 [ 中斷] 狀態表示 Microsoft Entra ID 已驗證已為租用戶設定 CBA。 要求憑證進行鑑別。

    螢幕擷取畫面，顯示登入記錄中的單一因素驗證專案。

    活動詳細資料顯示 要求是使用者選取憑證的預期登入流程的一部分。

    螢幕擷取畫面，顯示登入記錄中的活動詳細資料。

    其他詳細資料會 顯示憑證資訊。

    螢幕擷取畫面，顯示登入記錄中的多重要素其他詳細資料。

    其他項目顯示驗證已完成，主要重新整理記號會傳回瀏覽器，並授與使用者資源的存取權。

    螢幕擷取畫面，顯示登入記錄中的重新整理權杖專案。

測試 MFA

針對下一個測試案例，請設定規則符合 MFA 的 policyOID 驗證原則。

螢幕擷取畫面顯示 [驗證原則設定] 顯示 [需要 MFA]。

  1. 使用 CBA 登入 Microsoft Entra 系統管理中心 。 由於原則已設定為滿足 MFA，因此使用者登入成功，無需第二個因素。

  2. 搜尋，然後選取 [登入]。

    登入記錄中會出現數個項目，包括狀態為 「已中斷」 的項目。

    顯示登入記錄中數個專案的螢幕擷取畫面。

    活動詳細資料顯示 要求是使用者選取憑證的預期登入流程的一部分。

    螢幕擷取畫面，顯示登入記錄中的第二因素登入詳細資料。

    狀態為 「已中斷」 的項目 會在「其他詳細資料」 標籤上顯示更多診斷資訊。

    螢幕擷取畫面，顯示登入記錄中中斷的嘗試詳細資料。

    下表包含每個欄位的描述。

    欄位 描述
    使用者憑證主體名稱 指向憑證中的主體名稱欄位。
    使用者憑證繫結 憑證： PrincipalName;使用者屬性： userPrincipalName;排名：1
    此欄位顯示對應至PrincipalName使用者屬性且優先順序為 1 的 SAN userPrincipalName 憑證欄位。
    使用者憑證驗證層級 multiFactorAuthentication
    使用者憑證驗證層級類型 PolicyId
    此欄位顯示策略OID用於確定身份驗證強度。
    使用者憑證驗證層級識別碼 1.2.3.4
    這顯示憑證中識別符政策 OID 的值。

CBA 錯誤頁面

CBA 可能會因多種原因而失敗。 例如，憑證無效、使用者選取錯誤的憑證或過期的憑證，或發生 CRL 問題。 當憑證驗證失敗時，使用者會看到以下錯誤訊息：

顯示憑證驗證錯誤的螢幕擷取畫面。

如果 CBA 在瀏覽器上失敗，即使失敗是因為您取消憑證選擇器，也請關閉瀏覽器工作階段。 開啟新的會話以再次嘗試 CBA。 需要新的工作階段，因為瀏覽器會快取憑證。 重試 CBA 時，瀏覽器會在 TLS 挑戰期間傳送快取的憑證，然後導致登入失敗和驗證錯誤。

  1. 若要取得要傳送給驗證原則管理員的記錄資訊，以取得登入記錄的詳細資訊，請選取 [ 更多詳細資料]。

    顯示錯誤詳細資料的螢幕擷取畫面。

  2. 選取 [ 其他登入方式 ]，然後嘗試其他可用的驗證方法來登入。

    顯示新登入嘗試的螢幕擷取畫面。

在 Microsoft Edge 中重設憑證選擇

Microsoft Edge 瀏覽器新增了一項功能，無需 重新啟動瀏覽器即可重設憑證選擇。

使用者完成下列步驟：

  1. 當 CBA 失敗時，會出現錯誤頁面。

    顯示憑證驗證錯誤的螢幕擷取畫面。

  2. 在位址 URL 的左側，選取鎖定圖示，然後選取 [ 您的憑證選擇]。

    顯示 Microsoft Edge 瀏覽器憑證選項的螢幕擷取畫面。

  3. 選取 [重設憑證選擇]。

    顯示 Microsoft Edge 瀏覽器憑證選擇重設的螢幕擷取畫面。

  4. 選取 [重設選擇]。

    螢幕擷取畫面，顯示 Microsoft Edge 瀏覽器憑證選擇重設接受。

  5. 選取 其他登入方式。

    顯示憑證驗證錯誤的螢幕擷取畫面。

  6. 選取 [ 使用憑證或智慧卡 ]，然後繼續進行 CBA 驗證。

MostRecentlyUsed 方法中的 CBA

使用者使用 CBA 成功驗證之後，使用者的 MostRecentlyUsed （MRU） 驗證方法會設定為 CBA。 下次使用者輸入其 UPN 並選取 [ 下一步] 時，他們會看到 CBA 方法，而且不需要選取 [ 使用憑證或智慧卡]。

若要重設 MRU 方法，請取消憑證選擇器，然後選取 [ 其他登入方式]。 選取其他可用的方法，然後完成驗證。

MRU 驗證方法是在使用者層級設定。 如果使用者使用不同的驗證方法成功登入不同的裝置，則會將使用者的 MRU 重設為目前登入的方法。

外部身分識別支援

外部身分識別 B2B 來賓使用者可以在主租用戶上使用 CBA。 如果資源租用戶的跨租用戶設定為信任來自主租用戶的 MFA，則會接受使用者在主租用戶上的 CBA。 如需詳細資訊，請參閱 設定 B2B 共同作業跨租用戶存取。 目前不支援資源租用戶上的 CBA。

相關內容

  • Last updated on