Microsoft Entra 憑證基礎認證技術概念

本文將說明技術概念，以說明 Microsoft Entra 憑證基礎認證（CBA）的運作方式。 取得技術背景，讓你更了解如何在租戶中設定和管理 Microsoft Entra 集體談判協議。

Microsoft Entra 憑證式認證是如何運作的？

下圖顯示使用者嘗試登入已設定 Microsoft Entra CBA 的租戶應用程式時會發生什麼。

以下步驟總結了 Microsoft Entra 集體談判流程：

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

2. 如果使用者尚未登入，會被導向Microsoft Entra ID用戶登入頁面，地址為 https://login.microsoftonline.com/。

3. 他們會在Microsoft Entra登入頁面輸入使用者名稱，然後選擇Next。 Microsoft Entra ID 透過租戶名稱完成家庭領域的發現。 它會使用使用者名稱來查找承租者中的用戶。

   

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

   更多資訊請參見 我們如何開啟Microsoft Entra集體合作協議？。

   註記

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

   

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

   

5. 使用者選取 CBA 之後，用戶端會重新導向至憑證驗證端點。 對於公開Microsoft Entra ID，憑證認證端點為 https://certauth.login.microsoftonline.com。 對於 Azure Government，憑證認證端點為 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 條件式存取政策找到唯一使用者，Microsoft Entra ID會立即登入該使用者。 如果需要 MFA，但憑證只滿足單一因素，如果使用者已註冊，則會提供無密碼登入和 FIDO2 作為第二個因素。

9. Microsoft Entra ID 會透過回傳主要刷新令牌來完成登入流程，以表示登入成功。

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

發行人提示

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

開啟發行者提示

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

CA 信任存放區更新分發

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

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

具有單一因素 CBA 的 MFA

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

以下是一些支援的組合：

• CBA (第一個要素) 和通行金鑰 (第二個要素)
• CBA (第一個要素) 和無密碼手機登入 (第二個要素)
• CBA (第一個要素) 和 FIDO2 安全性金鑰 (第二個要素)
• 密碼（第一因素）與憑證驗證（CBA，第二因素）

使用者必須有方法在登入前取得多重身份驗證（MFA）並註冊無密碼登入或 FIDO2，並透過 Microsoft Entra CBA 登入。

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

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

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

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

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

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

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

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

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

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

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

1. 請至少以 Authentication Policy Administrator 的身份登入 Microsoft Entra 系統管理中心。

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

   重要

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

3. 選擇 Entra ID>多重認證>額外的雲端多重認證設定。

   

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）。

使用者名稱繫結原則

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

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

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

以使用者名稱和電子郵件地址為基礎的映射類型會被視為低親和性。 Microsoft Entra ID 實作三種基於可重複使用識別碼的低親和力映射。 其他則會視為高親和性繫結。 如需詳細資訊，請參閱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 使用者帳號設定。

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

支援一個 Microsoft Entra 使用者帳號（M：1）同時支援多個憑證

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

僅限雲端帳戶 （M：1）

對於僅限雲端的帳戶，您可以填寫唯一值在 certificateUserIds 欄位中，以識別每個憑證，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。 這些值必須同步到 Microsoft Entra ID 中的 certificateUserIds 欄位。

支援單一憑證與多個 Microsoft Entra 使用者帳號（1：M）

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

在 內部部署的 Active Directory 中，altSecurityIdentities 欄位會填入憑證值。 登入時會使用提示，引導 Active Directory 到指定帳號檢查登入情況。

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

僅限雲端帳戶 （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 綁定進行驗證。

混合式同步帳戶 （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

接著你必須將這些值與Microsoft Entra ID中的 certificateUserIds 欄位同步。

將資料同步至 certificateUserIds。

1. 設定 Microsoft Entra Connect 新增 alternativeSecurityIds 欄位至中繼資料庫。
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. 請至少以 Authentication Policy Administrator 的身份登入 Microsoft Entra 系統管理中心。

2. 請前往 Entra ID>驗證方法>基於憑證的驗證。

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

   

4. 選取 [新增規則]。

   

5. 選取 依 PKI 篩選 CA。

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

6. 選取 PKI。

   

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

   

8. 選取 [ 新增群組]。

   

9. 選取群組。

   

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

    

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

    

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

    

已知限制

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

登入記錄條目

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

  

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

  

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

  

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 憑證。 Interrupted狀態表示Microsoft Entra ID已驗證租戶已設定 CBA。 要求憑證進行驗證。

   

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

   

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

   

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

   

測試多因素驗證 (MFA)

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

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 的左側，選取鎖定圖示，然後選取 [ 您的憑證選擇]。

   

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

   

4. 選取 [重設選擇]。

   

5. 選取 其他登入方式。

   

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

MostRecentlyUsed 方法中的 CBA

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

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

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

外部身分識別支援

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

相關內容

• Microsoft Entra集體談判概述
• Microsoft Entra CBA 的技術深度探討
• 如何設定Microsoft Entra CBA
• Microsoft Entra 集體談判證書吊銷名單
• 適用於 Android 裝置的 Microsoft Entra CBA
• Windows智慧卡登入，使用Microsoft Entra CBA
• 憑證使用者識別碼
• 如何移轉同盟使用者
• 常見問題集
• Microsoft Entra 集體談判證書吊銷名單
• 適用於 Android 裝置的 Microsoft Entra CBA
• Windows智慧卡登入，使用Microsoft Entra CBA
• 憑證使用者識別碼
• 如何移轉同盟使用者
• 常見問題集