共用方式為

Microsoft Entra 憑證型驗證技術深入探討

  • 發行項

本文說明 Microsoft Entra 憑證型驗證 (CBA) 的運作方式，並深入探討 Microsoft Entra CBA 組態的技術詳細資料。

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

下圖描述當使用者嘗試登入已啟用 Microsoft Entra CBA 之租用戶中的應用程式時，會發生什麼情況。

說明 Microsoft Entra 憑證型驗證如何運作的步驟。

現在我們將逐步說明每個步驟：

  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 作為其識別提供者 (IdP) 的應用程式進行驗證。

    [使用憑證或智慧卡] 的螢幕擷取畫面。

    如果您已啟用其他驗證方法 (例如，手機登入或安全性金鑰)，使用者可能會看到不同的登入畫面。

    如果也啟用 FIDO2 的 [登入] 螢幕擷取畫面。

  5. 使用者選取憑證型驗證後，用戶端會重新導向 certauth 端點，即適用於公用 Microsoft Entra ID 的 https://certauth.login.microsoftonline.com。 針對 Azure Government，certauth 端點為 https://certauth.login.microsoftonline.us。

    該端點會執行 TLS 相互驗證，並在 TLS 交握過程中要求用戶端憑證。 此要求的項目會出現在登入記錄中。

    注意

    網路管理員應該允許存取客戶雲端環境的使用者登入頁面和 certauth 端點 *.certauth.login.microsoftonline.com。 在 certauth 端點上停用 TLS 檢查，以確保用戶端憑證要求會在 TLS 交握過程中成功。

    請確定 TLS 檢查停用也適用於具有簽發者提示的新 URL。 請勿使用 tenantId 硬式編碼 URL，因為它可能會針對 B2B 使用者變更。 使用規則運算式可讓舊 URL 和新 URL 都可用於 TLS 檢查停用。 例如，視 Proxy 而定，請使用 *.certauth.login.microsoftonline.com 或 *certauth.login.microsoftonline.com。 在 Azure Government 中，使用 *.certauth.login.microsoftonline.us 或 *certauth.login.microsoftonline.us。

    除非允許存取，否則如果您啟用簽發者提示功能，憑證型驗證會失敗。

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

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

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

  8. 如果透過條件式存取原則找到唯一的使用者，而該使用者需要多重要素驗證，同時憑證驗證繫結規則滿足 MFA，則 Microsoft Entra ID 會立即將該使用者登入。 如果需要 MFA，但憑證只滿足單一要素，如果已註冊無密碼登入或 FIDO2，則會以第二個要素的形式提供。

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

  10. 如果使用者登入成功，使用者即可存取應用程式。

了解簽發者提示 (預覽)

簽發者提示會在 TLS 交握時傳回信任的 CA 指示。 信任的 CA 清單會設定為 Entra 信任存放區中租用戶上傳的憑證授權單位 (CA) 主體。 瀏覽器用戶端或原生應用程式用戶端可以使用伺服器傳回的提示來篩選憑證選擇器中顯示的憑證。 用戶端只會顯示信任存放區中 CA 所簽發的驗證憑證。

啟用簽發者提示

若要啟用，請按兩下複選框 [簽發者提示]。 在確定已啟用 TLS 檢查的 Proxy 正確更新並儲存之後，驗證原則系統管理員應該按兩下 [我確認]。

注意

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

如何啟用簽發者提示的螢幕快照。

注意

在開啟簽發者提示之後，證書頒發機構單位 URL 的格式會是 t{tenantId}.certauth.login.microsoftonline.com 。

在啟用簽發者提示之後的憑證選擇器螢幕快照。

CA 信任存放區更新傳播

在啟用簽發者提示，並從信任狀態新增、更新或刪除 CA 之後，最多會延遲 10 分鐘將簽發者提示傳播回用戶端。 在傳播提示之前，使用者無法向新 CA 發出的憑證進行驗證。

驗證原則系統管理員在啟用簽發者提示起始傳播之後，應該使用憑證登入。 當 CA 信任存放區更新在傳播之中時，使用者會看到下列錯誤訊息。

使用者看到的錯誤螢幕快照，其中顯示更新是否正在進行。

使用單一要素憑證型驗證的 MFA

Microsoft支援 Entra CBA 作為驗證的第一個因素和 selcond 因數。 支援的一些組合如下：

  1. CBA (第一個要素) 和通行金鑰 (第二個要素)
  2. CBA (第一個要素) 和無密碼手機登入 (第二個要素)
  3. CBA (第一個要素) 和 FIDO2 安全性金鑰 (第二個要素)
  4. 密碼 （第一因素） + CBA （第二因素） （預覽）

注意

CBA 作為 iOS 上的第二個因素有 已知問題 ，並在 iOS 上遭到封鎖。 我們正努力修正問題，而且應該在iOS上受到支援。

用戶必須能夠事先取得 MFA 並註冊無密碼登入或 FIDO2，才能使用 Microsoft Entra CBA 登入。

重要

當使用者包含在 CBA 方法設定中時，即視為支援 MFA。 這表示使用者無法使用證明作為驗證的一部分來註冊其他可用的方法。 請確定無有效憑證的使用者不會包含在 CBA 方法設定中。 如需驗證運作方式的詳細資訊，請參閱 Microsoft Entra 多重要素驗證。

使用單一要素憑證取得 MFA 功能的選項

Microsoft Entra CBA 能夠進行多重要素驗證 (MFA)。 根據租用戶組態，Microsoft Entra CBA 可以是單一要素 (SF) 或多重要素 (MF)。 啟用 CBA 可讓使用者完成 MFA。 具有單一因素驗證的使用者需要另一個驗證因素才能完成多重因素驗證（MFA）。 如果使用者未註冊任何其他驗證方法並且已被新增至 CBA 驗證方法的適用範圍內，該使用者將無法進一步驗證以註冊其他驗證方法。

如果已啟用 CBA 的使用者只有單一要素 (SF) 憑證，且需要完成 MFA：

  1. 使用密碼和 SF 憑證。
  2. 發行臨時存取密碼。
  3. 驗證原則管理員會新增電話號碼，並允許使用者帳戶的語音/簡訊驗證。

如果已啟用 CBA 的使用者尚未發行憑證，且需要完成 MFA：

  1. 發行臨時存取密碼。
  2. 驗證原則管理員會新增電話號碼，並允許使用者帳戶的語音/簡訊驗證。

如果已啟用 CBA 的使用者無法使用 MF 憑證，例如在沒有智慧卡支援的行動裝置上，且必須完成 MFA：

  1. 發行臨時存取密碼。
  2. 使用者必須註冊另一個 MFA 方法 (當使用者可以使用 MF 憑證時)。
  3. 使用密碼和 MF 憑證 (當使用者可以使用 MF 憑證時)。
  4. 驗證原則管理員會新增電話號碼，並允許使用者帳戶的語音/簡訊驗證。

使用 CBA 設定無密碼手機登入 (PSI) 的步驟

若要讓無密碼登入能夠運作，使用者應該透過其行動應用程式停用舊版通知。

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

  2. 請遵循啟用無密碼手機登入驗證中的步驟。

    重要

    在上述設定中，請確定您選擇 [無密碼] 選項。 您必須將針對 PSI 所新增任何群組的 [驗證模式] 變更為 [無密碼]。 如果您選擇 [任何]，則 CBA 和 PSI 將無法運作。

  3. 選取 [保護]>[多重要素驗證]>[其他雲端式多重要素驗證設定]。

    如何設定多重要素驗證設定的螢幕擷取畫面。

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

    如何透過行動應用程式移除通知的螢幕擷取畫面。

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

讓我們看看使用單一要素憑證，並設定為無密碼登入的使用者範例。

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

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

  2. 選取 [使用憑證登入]。

    如何使用憑證登入的螢幕擷取畫面。

    如果您已啟用其他驗證方法 (例如，手機登入或 FIDO2 安全性金鑰)，使用者可能會看到不同的登入畫面。

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

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

    如何選取憑證的螢幕擷取畫面。

  4. 由於憑證已設定為單一要素驗證強度，因此使用者需要第二個要素才能符合 MFA 需求。 使用者會看到可用的第二個要素，在此情況下是無密碼登入。 選取 [核准我的 Microsoft Authenticator 應用程式上的要求]。

    第二個要素要求的螢幕擷取畫面。

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

  6. 將您在瀏覽器或應用程式畫面上看到的數字輸入至 Microsoft Authenticator。

    數字相符的螢幕擷取畫面。

  7. 選取 [是]，使用者便可以驗證並登入。

了解驗證繫結原則

驗證繫結原則可協助您以單一要素或多重要素的形式來判斷驗證的強度。 驗證原則管理員可以將預設值從單一要素變更為多重要素，或藉由使用憑證中的簽發者主體或原則 OID，或是簽發者與原則 OID 欄位來設定自訂原則設定。

憑證強度

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

多重要素憑證驗證

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

Microsoft Entra ID 如何解析多個驗證原則繫結規則

因為可以使用不同的憑證欄位來建立多個自訂驗證繫結原則規則，例如使用簽發者 + 原則 OID，或僅原則 OID 或僅簽發者。 以下是自訂規則重疊時用來判斷驗證保護層級的步驟。 這些範本如下：

  1. 簽發者 + 原則 OID 規則的優先順序高於原則 OID 規則。 原則 OID 規則的優先順序高於憑證簽發者規則。
  2. 簽發者 + 原則 OID 規則會先進行評估。 如果您有使用簽發者 CA1 和原則 OID 1.2.3.4.5 搭配 MFA 的自訂規則，則只有憑證 A 會同時滿足簽發者值且原則 OID 將收到 MFA。
  3. 接下來，系統會評估使用原則 OID 的自訂規則。 如果您擁有的憑證 A 具備原則 OID 1.2.3.4.5，且根據該憑證衍生的認證 B 具備原則 OID 1.2.3.4.5.6，而自訂規則會定義為具有 MFA 的原則 OID 且值是 1.2.3.4.5，則只有憑證 A 將滿足 MFA，而認證 B 將只會滿足單一要素驗證。 如果使用者在登入期間使用了衍生認證，並且已設定為具有 MFA，則會要求該使用者提供第二個要素，以進行成功驗證。
  4. 如果多個原則 OID 之間發生衝突 (例如，當一個憑證有兩個原則 OID 時，其中一個繫結至單一要素驗證，另一個則繫結至 MFA)，則會將憑證視為單一要素驗證。
  5. 接下來，系統會評估使用簽發者 CA 的自訂規則。
  6. 如果憑證同時具有原則 OID 和簽發者規則比對，一律會先檢查原則 OID，如果找不到任何原則規則，則會檢查簽發者繫結。 原則 OID 的增強式驗證繫結優先順序比簽發者更高。
  7. 如果有一個 CA 繫結至 MFA，此 CA 所簽發的所有使用者憑證都有資格作為 MFA。 相同邏輯也適用於單一要素驗證。
  8. 如果有一個原則 OID 繫結至 MFA，所有包含此原則 OID 作為其中一個 OID 的使用者憑證 (一個使用者憑證可以有多個原則 OID) 都有資格作為 MFA。
  9. 一個憑證簽發者只能有一個有效的增強式驗證繫結 (也就是，一個憑證無法同時繫結至單一要素和 MFA)。

重要

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

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

使用 Workplace Join、Microsoft Entra ID 和混合式 Microsoft Entra 裝置加入案例進行裝置註冊不會受到影響。 使用憑證簽發者或原則 OID 的 CBA 驗證原則規則不會受到影響。 若要移轉，驗證原則管理員應：

  • 編輯目前同時使用憑證簽發者和原則 OID 選項的憑證型驗證原則規則，移除憑證簽發者或 OID 需求後儲存。 OR
  • 移除目前同時使用憑證簽發者和原則 OID 的驗證原則規則，並且僅使用憑證簽發者或原則 OID 建立規則

我們正努力修正此問題。

了解使用者名稱繫結原則

使用者名稱繫結原則可協助驗證使用者的憑證。 根據預設，憑證中的主體交替名稱 (SAN) 主體名稱會對應至使用者物件的 UserPrincipalName 屬性，以判斷使用者。

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

憑證繫結有七種支援的方法。 一般而言，如果對應類型是以您無法重複使用的識別碼 (例如主體金鑰識別碼或 SHA1 公開金鑰) 為基礎，則對應類型會視為高親和性。 這些識別碼會傳達更高的保證，表示只能使用單一憑證來驗證個別使用者。

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

憑證對應欄位 certificateUserIds 中的值範例 使用者物件屬性 類型
主體名稱 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 低親和性
主體 (預覽) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 低親和性
SKI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds 高親和性
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR 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 高親和性

在租用戶層級定義親和性繫結，並使用自訂規則覆寫 (預覽)

透過此功能，驗證原則管理員可以設定使用者是否可以使用低親和性或高親和性使用者名稱繫結對應來進行驗證。 您可以為租用戶設定 [必要的親和性繫結]，這會套用至所有使用者。 您也可以根據簽發者和原則 OID 或原則 OID 或簽發者來建立自訂規則，以覆寫整個租用戶的預設值。

Microsoft Entra ID 如何解析多個使用者名稱原則繫結規則

使用最高優先順序 (最小數字) 的繫結。

  1. 藉由使用使用者名稱或使用者主體名稱來查閱使用者物件。
  2. 取得驗證原則管理員在 CBA 驗證方法設定中，依「優先順序」屬性排序來設定的所有使用者名稱繫結清單。 目前，優先順序的概念不會在入口網站 UX 中公開。 Graph 會傳回每個繫結的優先順序屬性，並在評估程序中使用這些屬性。
  3. 如果租用戶已啟用高親和性繫結，或憑證值符合需要高親和性繫結的自訂規則，請從清單中移除所有低親和性繫結。
  4. 評估清單中的每個繫結，直到驗證成功為止。
  5. 如果所設定繫結的 X.509 憑證欄位在呈現的憑證上，Microsoft Entra ID 會比對憑證欄位中的值與使用者物件屬性值。
    1. 如果找到相符值，使用者驗證就會成功。
    2. 如果找不到相符值，請移至下一個優先順序繫結。
  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，並在相同帳戶的 certificateUserId 屬性中實作 SKI 對應。

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

在某些情況下，組織會針對單一身分識別發出多個憑證。 通常，這可能是行動裝置的衍生認證，也可以是次要智慧卡或 x509 認證持有者支援的裝置，例如 Yubikey。

僅限雲端帳戶 針對僅限雲端的帳戶，您可以藉由在 certificateUserIds 欄位 (使用者入口網站中的授權資訊) 中填入可識別每個憑證的唯一值，來對應多個憑證 (最多 5 個) 以供使用。 如果組織使用高親和性繫結，表示 CertificateUserIds 中的 Issuer + SerialNumber 值可能如下所示：

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 欄位以尋找特定繫結類型 (也就是此範例中的 Issuer+SerialNumber)，使用者便能成功登入。

混合式同步處理帳戶 針對同步處理的帳戶，您可以藉由將識別每個憑證的值填入 AD 中的 altSecurityIdentities 欄位來對應多個憑證以供使用。 如果組織使用高親和性 (也就是強式驗證) 繫結，例如 Issuer + SerialNumber，這可能如下所示：

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)

在某些情況下，組織需要使用者使用相同的憑證向多個身分識別進行驗證。 最常見的是針對系統管理帳戶。 它也可以用於開發人員帳戶或臨時工作帳戶。 在傳統 AD 中，altSecurityIdentities 欄位會用來填入憑證值，並在登入期間使用「提示」，以將 AD 導向至所需的帳戶來檢查登入。 使用 Microsoft Entra CBA 時這會有所不同，且沒有提示。 相反地，Home Realm Discovery 會識別所需的帳戶來檢查憑證值。 另一個主要差異在於，Microsoft Entra CBA 會在 certificateUserIds 欄位中強制執行唯一性。 這表示兩個帳戶都無法填入相同的憑證值。

重要

使用相同認證向不同的 Microsoft Entra 帳戶進行驗證並不是一個非常安全的組態，因此建議您不要允許多個 Microsoft Entra 使用者帳戶使用一個憑證。

僅限雲端帳戶 針對僅限雲端的帳戶，您需要建立多個使用者名稱繫結，且需要將唯一值對應至將利用憑證的每個使用者帳戶。 每個帳戶都會使用不同的使用者名稱繫結進行驗證。 這會套用在單一目錄/租用戶的界限內 (也就是驗證原則管理員可以對應憑證，以用於另一個目錄/租用戶，只要每個帳戶的值也保持唯一即可)。

以識別所需憑證的唯一值填入 certificateUserIds 欄位 (使用者入口網站中的授權資訊)。 如果組織使用高親和性繫結 (也就是強式驗證) 繫結，例如 Issuer + SerialNumber 和 SKI，這可能如下所示：

使用者名稱繫結：

  • 簽發者 + 序號 -> CertificateUserIds
  • SKI -> CertificateUserIds

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

現在，當使用者在登入時出示相同的憑證時，使用者將會成功登入，因為他們的帳戶符合該憑證的唯一值。 一個帳戶將會使用 Issuer+SerialNumber 進行驗證，另一個則使用 SKI 繫結進行驗證。

注意

能夠以此方式使用的帳戶數目受限於租用戶上設定的使用者名稱繫結數目。 如果組織只使用高親和性繫結，則支援的帳戶數目將限制為 3。 如果組織也利用低親和性繫結，則此數字會增加到 7 個帳戶 (1 個 PrincipalName、1 個 RFC822Name、1 個 SubjectKeyIdentifier、1 個 SHA1PublicKey、1 個 Issuer+Subject、1 個 Issuer+SerialNumber、1 個 Subject)。

混合式同步處理帳戶 針對同步處理的帳戶，方法會有所不同。 雖然驗證原則管理員可以將唯一值對應至將利用憑證的每個使用者帳戶，但常見將所有值填入至 Microsoft Entra ID 中每個帳戶的作法，會讓這種情況變得困難。 相反地，Microsoft Entra Connect 應該將每個帳戶所需的值篩選為填入 Microsoft Entra ID 中帳戶的唯一值。 這會套用在單一目錄/租用戶的界限內 (也就是租用戶管理員可以對應憑證以用於另一個目錄/租用戶，只要每個帳戶的值也保持唯一即可)。 此外，組織可能會有多個 AD 樹系，將使用者分配至單一 Microsoft Entra 租用戶。 在此情況下，Microsoft Entra Connect 會將篩選套用至每個 AD 樹系，並使用相同的目標，只填入雲端帳戶所需的唯一值。

將識別所需憑證的值填入 AD 中的 altSecurityIdentities 欄位，並包含該使用者帳戶類型的所需憑證值 (例如借調人員、系統管理員、開發人員等等)。 在 AD 中選取索引鍵屬性，告知同步處理使用者正在評估的使用者帳戶類型 (例如 msDS-cloudExtensionAttribute1)。 使用您想要的使用者類型值填入此屬性，例如借調人員、系統管理員或開發人員。 如果這是使用者的主要帳戶，則值可以保留為空白/null。

帳戶看起來可能如下所示：

樹系 1 - Account1 (bob@woodgrove.com)：
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

樹系 1 - Account2 (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 欄位新增至 Metaverse
  2. 針對每個 AD 樹系，設定具有較高優先順序的新自訂輸入規則 (低於 100 的數字)。 新增使用 altSecurityIdentities 欄位作為來源的運算式轉換。 目標運算式會使用您選取並填入的索引鍵屬性，以及對應至您所定義的使用者類型。
  3. 例如：
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-cloudExtensionAttribute1is，以查看是否已填入它們。 如果沒有，則會檢查 altSecurityIdentities，以查看是否已填入。 如果它是空的，則我們將其設定為 NULL。 否則，帳戶會屬於預設案例，而在此範例中，我們只會篩選至 Issuer+SerialNumber 對應。 如果已填入索引鍵屬性，則會檢查值是否等於其中一個已定義的使用者類型。 在此範例中，如果該值是借調人員，則我們會從 altSecurityIdentities 篩選至 SHA1PublicKey 值。 如果值為開發人員，則我們會從 altSecurityIdentities 篩選至 SubjectKeyIssuer 值。 特定類型可能會有多個憑證值。 例如，多個 PrincipalName 值或多個 SKI 或 SHA1-PUKEY 值。 篩選會取得所有值，並同步至 Microsoft Entra ID，而不只是找到的第一個值。

  1. 第二個範例示範如果控制項屬性是空的，則如何推送空值。
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 欄位進行驗證之後，該使用者將會成功登入。

了解憑證撤銷流程

憑證撤銷程序可讓驗證原則管理員撤銷先前簽發的憑證，使其無法用於未來的驗證。 憑證撤銷將不會撤銷已經簽發的使用者權杖。 遵循設定撤銷中的步驟，手動撤銷權杖。

Microsoft Entra ID 會從其憑證授權單位下載並快取客戶憑證撤銷清單 (CRL)，以檢查憑證是否會在使用者驗證期間撤銷。

驗證原則管理員可以在 Microsoft Entra ID 租用戶中設定信任簽發者的過程中，設定 CRL 發佈點。 每個信任的簽發者都應該具有可藉由使用網際網路對應 URL 來參考的 CRL。

重要

針對 Microsoft Entra ID 在互動式登入成功下載和快取的 CRL 大小上限，在公用 Microsoft Entra ID 中為 20 MB，在 Azure 美國政府雲端中則為 45 MB，而下載 CRL 所需的時間不能超過 10 秒。 如果 Microsoft Entra ID 無法下載 CRL，則使用由對應 CA 所簽發的憑證型驗證會失敗。 最佳做法是將 CRL 檔案保持在大小限制內，請將憑證存留期保持在合理的限制內，並清除過期的憑證。 如需詳細資訊，請參閱 CRL 大小是否有限制？。

當使用者使用憑證執行互動式登入，而 CRL 超過雲端的互動限制時，其初始登入會失敗，並出現下列錯誤：

「從 {uri} 下載的憑證撤銷清單 (CRL) 超過 Microsoft Entra ID 中 CRL 允許的大小上限 ({size} 個位元組)。 請稍後再試。 如果問題持續發生，請連絡您的租用戶系統管理員。」

錯誤發生之後，Microsoft Entra ID 嘗試下載 CRL，但受限於服務端限制 (公用 Microsoft Entra ID 中為 45 MB，而在 Azure US Government 雲端中為 150 MB)。

重要

如果驗證原則管理員略過 CRL 的設定，Microsoft Entra ID 不會在使用者進行憑證型驗證期間執行任何 CRL 檢查。 這對於初始疑難排解很有用，但不應考慮在實際執行環境中使用。

目前，基於效能和可靠性因素，我們不支援線上憑證狀態通訊協定 (OCSP)。 Microsoft Entra ID 只會在第一次登入時下載 CRL 一次並進行快取，而不是每次透過適用於 OCSP 的用戶端瀏覽器連線時下載 CRL，因而得以改善 CRL 驗證的效能和可靠性。 我們也會為快取編製索引，如此一來，每次都能加快搜尋的速度。 客戶必須發佈 CRL 以進行憑證撤銷。

下列步驟是 CRL 檢查的一般流程：

  1. Microsoft Entra ID 將嘗試在任何具有對應信任簽發者或憑證授權單位之憑證的使用者首次登入時下載 CRL。
  2. Microsoft Entra ID 會快取並重複使用 CRL 以供後續使用。 它接受下一個更新日期，以及 CRL 文件中的下一個 CRL 發行日期 (如果有的話，可供 Windows Server CA 使用)。
  3. 使用者憑證型驗證會在符合下列情況時失敗：

    • 已針對信任的簽發者設定 CRL，但 Microsoft Entra ID 因為可用性、大小或延遲限制而無法下載該 CRL。

    • 使用者的憑證在 CRL 上列為已撤銷。

      CRL 中撤銷使用者憑證的螢幕擷取畫面。

    • 如果快取的 CRL 文件已過期，Microsoft Entra ID 會嘗試從發佈點下載新的 CRL。

注意

Microsoft Entra ID 會檢查簽發 CA 和 PKI 信任鏈結中其他 CA 的 CRL，直到根 CA。 PKI 鏈結中 CRL 驗證的分葉用戶端憑證最多有 10 個 CA 的限制。 此限制是為了確保惡意執行者不會上傳具有大量 CA (具有較大 CRL 大小) 的 PKI 鏈結，而導致服務中斷。 如果租用戶的 PKI 鏈結有超過 5 個以上的 CA，在發生 CA 洩露的情況下，驗證原則管理員應該從 Microsoft Entra 租用戶設定中移除遭洩露的信任簽發者。

重要

由於 CRL 快取和發佈週期的本質，強烈建議您在憑證撤銷時，也撤銷 Microsoft Entra ID 中受影響使用者的所有工作階段。

到目前為止，沒有任何方法可以手動強制執行或重新觸發 CRL 的下載。

如何設定撤銷

若要撤銷用戶端憑證，Microsoft Entra ID 會從和憑證授權單位資訊一起上傳的 URL 中，擷取憑證撤銷清單 (CRL) 並加以快取。 在 CRL 中，上次發佈的時間戳記 ([生效日期] 屬性) 是用來確保 CRL 依然有效。 定期參考 CRL 以撤銷對清單所列憑證的存取權。

如果需要立即撤銷 (例如，使用者遺失裝置)，可以讓使用者的授權權杖失效。 使用 Windows PowerShell 設定這位特定使用者的 StsRefreshTokenValidFrom 欄位，即可讓授權權杖失效。 您必須為想要撤銷其存取權的每位使用者更新其 StsRefreshTokenValidFrom 欄位。

為了確保撤銷持續有效，您必須將 CRL 的 [生效日期] 設定為 StsRefreshTokenValidFrom 所設值之後的日期，並確保有問題的憑證位於 CRL 中。

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解，請閱讀淘汰更新。 在此日期之後，對這些模組的支援僅限於對 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 淘汰的模組將繼續運作至 2025 年 3 月 30 日。

我們建議移轉至 Microsoft Graph PowerShell 以與 Microsoft Entra ID (以前稱為 Azure AD) 互動。 如需了解常見的移轉問題，請參閱移轉常見問題。 注意：MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

下列步驟概述藉由設定 StsRefreshTokenValidFrom 欄位，來更新授權權杖並讓它失效的程序。

  1. 連線至 PowerShell：

    Connect-MgGraph

  2. 擷取使用者目前的 StsRefreshTokensValidFrom 值︰

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

  3. 將目前的時間戳記設定為使用者新的 StsRefreshTokensValidFrom 值︰

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

您設定的日期必須是未來的日期。 如果不是未來的日期，則不會設定 StsRefreshTokensValidFrom 屬性。 如果是未來的日期，才會將 StsRefreshTokensValidFrom 設定為目前的時間 (而非 Set-MsolUser 命令指示的日期)。

理解 CRL 驗證 (預覽)

CRL 是證書頒發機構單位在有效期間結束前撤銷的數位證書記錄。 當 CA 上傳至 Microsoft Entra 信任存放區時，不需要 CRL 或者具體而言是 CrlDistributionPoint 屬性。 CA 可以在沒有 CRL 端點的情況加以上傳，如果發行 CA 未指定 CRL，憑證式驗證將不會失敗。

若要加強安全性並避免設定錯誤，如果未針對發出使用者憑證的 CA 設定任何 CRL，驗證原則管理員可以要求 CBA 驗證失敗。

啟用 CRL 驗證

若要啟用 CRL 驗證，請按兩下 [需要CRL驗證]（建議）。

如何要求 CRL 驗證的螢幕快照。

在啟用之後，任何 CBA 都會失敗，因為使用者憑證是由未設定 CRL 的 CA 簽發。

如果 CA 的 CRL 有應修正問題，驗證原則管理員可以豁免 CA。 按兩下 [新增豁免]，然後選取應豁免的任何 CA。

如何豁免 CRL 驗證 CA 的螢幕快照。

豁免清單的 CA 不需要設定 CRL，且所簽發的使用者憑證不會失敗驗證。

注意

物件選擇器發生已知問題，選取的專案未正確顯示。 使用 [證書頒發機構單位] 索引標籤來選取或移除 CA。

已豁免 CRL 驗證的 CA 螢幕快照。

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

客戶可以建立條件式存取驗證強度原則，以指定 CBA 用來存取資源。

您可以使用內建的防網路釣魚 MFA 驗證強度。 該原則只允許防網路釣魚的驗證方法，例如 CBA、FIDO2 安全性金鑰和 Windows Hello 企業版。

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

使用進階選項的 CBA 驗證強度

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

了解登入記錄

登入記錄提供登入及使用者如何使用您資源的相關資訊。 如需登入記錄的詳細資訊，請參閱 Microsoft Entra ID 中的登入記錄。

讓我們逐步解說兩個案例，一個是憑證滿足單一要素驗證，另一個則是憑證滿足 MFA。

針對測試案例，選擇具有要求 MFA 之條件式存取原則的使用者。 透過將 SAN 主體名稱對應至 UserPrincipalName 來設定使用者繫結原則。

使用者憑證應設定為如下螢幕擷取畫面：

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

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

雖然登入記錄會提供所有資訊來偵錯使用者的登入問題，但有時候需要特定值，且因為登入記錄不支援動態變數，導致登入記錄會遺失資訊。 例如：登入記錄中的失敗原因會顯示類似「憑證撤銷清單 (CRL) 失敗的簽章驗證。 預期的主體金鑰識別碼 {expectedSKI} 不符合 CRL 授權單位金鑰 {crlAK}。 請要求您的租用戶系統管理員檢查 CRL 設定。」其中 {expectedSKI} 和 {crlAKI} 未填入正確的值。

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

測試單一要素驗證

針對第一個測試案例，設定簽發者主體規則滿足單一要素驗證的驗證原則。

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

  1. 使用 CBA 以測試使用者身分登入 Microsoft Entra 系統管理中心。 驗證原則的設定是簽發者主體規則滿足單一要素驗證。

  2. 搜尋並選取 [登入記錄]。

    讓我們更深入了解一些您可在 [登入記錄] 中找到的項目。

    第一個項目會向使用者要求 X.509 憑證。 已中斷狀態表示 Microsoft Entra ID 已驗證已在租用戶中啟用 CBA，且要求憑證以進行驗證。

    登入記錄中單一要素驗證項目的螢幕擷取畫面。

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

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

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

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

    這些額外的項目會顯示驗證已完成，已將主要重新整理權杖傳回給瀏覽器，而使用者會獲得資源的存取權。

    登入記錄中重新整理權杖項目的螢幕擷取畫面。

測試多重要素驗證

針對下一個測試案例，設定 policyOID 規則滿足多重要素驗證的驗證原則。

驗證原則設定的螢幕擷取畫面，其中顯示所需的多重要素驗證。

  1. 使用 CBA 登入 Microsoft Entra 系統管理中心。 因為已將原則設定為滿足多重要素驗證，所以，使用者不需使用第二個要素，即可成功登入。

  2. 搜尋並選取 [登入]。

    您會在登入記錄中看到數個項目，包括已中斷狀態的項目。

    登入記錄中數個項目的螢幕擷取畫面。

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

    登入記錄中第二個要素登入詳細資料的螢幕擷取畫面。

    狀態為 [已中斷] 的項目會在 [其他詳細資料] 索引標籤上具有更多診斷資訊。

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

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

    欄位 描述
    使用者憑證主體名稱 參考憑證中的主體名稱欄位。
    使用者憑證繫結 憑證：主體名稱；使用者屬性：userPrincipalName；順位：1
    這顯示已將哪一個 SAN PrincipalName 憑證欄位對應至 userPrincipalName 使用者屬性且優先順序為 1。
    使用者憑證驗證層級 multiFactorAuthentication
    使用者憑證驗證層級類型 PolicyId
    這顯示用來判斷驗證強度的原則 OID。
    使用者憑證驗證層級識別碼 1.2.3.4
    這顯示來自憑證的識別碼原則 OID 值。

了解憑證式驗證錯誤頁面

憑證式驗證失敗的可能原因如下，憑證無效、使用者選取錯誤的憑證或過期憑證，或因為憑證撤銷清單 (CRL) 有問題。 憑證驗證失敗時，使用者會看到此錯誤：

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

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

選取 更多詳細資料 取得可傳送給驗證原則系統管理員的記錄資訊，而管理員接著可以從登入記錄中取得更多資訊。

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

選取 [其他登入方式] 以嘗試使用者可登入的其他方法。

注意

如果您在瀏覽器中重試 CBA，它會因為瀏覽器快取問題而持續失敗。 使用者必須開啟新的瀏覽器工作階段，然後再次登入。

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

MostRecentlyUsed (MRU) 方法中的憑證式驗證

一旦使用者成功使用 CBA 進行驗證，使用者的 MostRecentlyUsed (MRU) 驗證方法會設為 CBA。 下次，當使用者輸入 UPN 並選取 [下一步] 時，使用者會直接採用 CBA 方法，而且不需要選取 [使用憑證或智慧卡]。

若要重設 MRU 方法，使用者必須取消憑證選擇器，選取 [其他登入方式]，然後選取可供使用者使用的另一種方法，並成功驗證。

外部身分識別支援

外部身分識別 B2B 來賓使用者可以在主租使用者上使用 CBA，而且如果資源租使用者的跨租用戶設定設定為信任來自主租使用者的 MFA，則會接受主租使用者的 CBA 驗證。 如需如何啟用從 Microsoft Entra 租用戶信任多重要素驗證的詳細資訊，請參閱設定 B2B 共同作業跨租用戶存取。 資源租使用者上的 CBA 尚不受支援。

下一步