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

  • 發行項

本文說明 Microsoft Entra 憑證型驗證 （CBA） 的運作方式，並深入探討 Microsoft Entra CBA 設定的技術詳細數據。

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

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

圖例說明 Microsoft Entra 憑證型驗證的運作方式。

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

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

  2. 如果使用者尚未登入，則會將使用者重新導向至 位於https://login.microsoftonline.com/的 Microsoft Entra ID 使用者登入頁面。

  3. 使用者將其使用者名稱輸入 Microsoft Entra 登入頁面，然後選取 [ 下一步]。 Microsoft Entra ID 會使用租使用者名稱進行主領域探索，並使用使用者名稱來查閱租使用者中的使用者。

    MyApps 入口網站的 [登入] 螢幕快照。

  4. Microsoft Entra ID 會檢查是否已為租用戶啟用 CBA。 如果已啟用 CBA，使用者會在密碼頁面上看到使用憑證或智慧卡的連結。 如果使用者看不到登入連結，請確定已在租用戶上啟用 CBA。 如需詳細資訊，請參閱 如何? 啟用 Microsoft Entra CBA？。

    注意

    如果租使用者上已啟用 CBA，所有用戶都會在密碼頁面上看到使用憑證或智慧卡的連結。 不過，只有 CBA 範圍中的使用者才能針對使用 Microsoft Entra ID 作為其識別提供者的應用程式成功進行驗證。

    使用憑證或智慧卡的螢幕快照。

    如果您啟用其他驗證方法，例如 電話 登入或安全性密鑰，使用者可能會看到不同的登入畫面。

    如果 FIDO2 也已啟用，則為 [登入] 的螢幕快照。

  5. 一旦用戶選取憑證式驗證，用戶端就會重新導向至憑證驗證端點，這是 https://certauth.login.microsoftonline.com 用於公用 Entra ID。 針對 Azure Government，憑證驗證端點為 https://certauth.login.microsoftonline.us。

    端點會執行 TLS 相互驗證，並要求用戶端憑證作為 TLS 交握的一部分。 此要求的專案會出現在登入記錄中。

    注意

    網路管理員應該允許存取客戶雲端環境的 [使用者登入] 頁面和憑證驗證端點 *.certauth.login.microsoftonline.com 。 停用憑證驗證端點上的 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。

    除非您允許存取，否則如果您啟用即將推出的受信任 CA 提示功能，憑證式驗證會失敗。

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

    注意

    不支援受信任的 CA 提示，因此無法進一步界定憑證清單。 我們打算在未來新增這項功能。

    憑證選擇器螢幕快照。

  7. Microsoft Entra ID 會驗證證書吊銷清單，以確定憑證未撤銷且有效。 Microsoft Entra ID 會使用 租用戶上設定的使用者名稱系結 來識別使用者，以將憑證域值對應至使用者屬性值。

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

  9. Microsoft Entra ID 會藉由將主要重新整理令牌傳回以指出登入成功，來完成登入程式。

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

憑證式驗證具有 MFA 功能

Microsoft Entra CBA 能夠進行多重要素驗證（MFA）。 根據租用戶設定，Microsoft Entra CBA 可以是單一因素 （SF） 或多重要素 （MF）。 啟用 CBA 可讓使用者完成 MFA。 使用者可能需要更多組態才能完成 MFA，並在用戶位於 CBA 的範圍內時註冊其他驗證方法。

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

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

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

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

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

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

具有單一要素憑證型驗證的 MFA （預覽）

Microsoft Entra CBA 可作為第二個因素，以符合 MFA 需求與單一要素憑證。 支援的一些組合如下：

  1. CBA （第一因素） 和無密碼手機登入 （無密碼登入作為第二因素）
  2. CBA （第一因素） 和 FIDO2 安全性金鑰 （第二因素）
  3. 密碼 （第一因素） 和 CBA （第二因素）

使用者需要有另一種方式來取得 MFA，並事先註冊無密碼登入或 FIDO2，才能使用 Microsoft Entra CBA 登入。

重要

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

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

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

  1. 以至少驗證原則 管理員 istrator 身分登入 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、Digital Identity Guidelines：Authentication and Lifecycle Mgmt 為基礎。

多重要素憑證驗證

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

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

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

  1. 簽發者 + 原則 OID 規則的優先順序高於原則 OID 規則。 原則 OID 規則優先於憑證簽發者規則。
  2. 簽發者 + 原則 OID 規則會先進行評估。 如果您有具有簽發者 CA1 和原則 OID 1.2.3.4.5 與 MFA 的自定義規則，則只有憑證 A 會同時滿足簽發者值和原則 OID。
  3. 接下來，會評估使用原則 OID 的自定義規則。 如果您有具有原則 OID 1.2.3.4.5 和衍生認證 B 的憑證 A，且該憑證具有原則 OID 1.2.3.4.5.6，且自定義規則定義為 Policy 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）。

重要

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

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

使用 Workplace Join、Entra ID 和 Hybrid Entra ID 裝置加入案例進行裝置註冊不會受到影響。 使用簽發者或原則 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 低親和性
滑雪 X509:<SKI>123456789abcdef certificateUserIds 高親和性
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds 高親和性
IssuerAndSerialNumber （預覽） X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
若要取得序號的正確值，請執行此命令並儲存 CertificateUserIds 中顯示的值：
語法：
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
範例：
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds 高親和性

在租用戶層級定義親和性系結，並使用自訂規則覆寫 （預覽）

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

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

使用最高優先順序 （最低數位） 系結。

  1. 使用使用者名稱或用戶主體名稱來查閱用戶物件。
  2. 取得租用戶系統管理員在 CBA 驗證方法組態中依 『priority』 屬性排序的所有使用者名稱系結清單。 目前，優先順序的概念不會在入口網站 UX 中公開。 Graph 會傳回每個系結的優先順序屬性，並在評估程式中使用這些屬性。
  3. 如果租用戶已啟用高親和性系結，或憑證值符合需要高親和性系結的自定義規則，請從清單中移除所有低同質系結。
  4. 評估清單中的每個系結，直到驗證成功為止。
  5. 如果所設定系結的 X.509 憑證欄位位於所呈現的憑證上，Microsoft Entra ID 會將憑證欄位中的值與使用者物件屬性值相符。
    1. 如果找到相符專案，用戶驗證就會成功。
    2. 如果找不到相符專案，請移至下一個優先順序系結。
  6. 如果出示的憑證上沒有 X.509 憑證欄位，請移至下一個優先順序系結。
  7. 驗證所有已設定的使用者名稱系結，直到其中一個用戶系結產生相符專案且使用者驗證成功為止。
  8. 如果在任何已設定的使用者名稱系結上找不到相符專案，用戶驗證就會失敗。

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

每個 Microsoft Entra 使用者物件屬性 （userPrincipalName， onPremiseUserPrincipalName， certificateUserIds） 都可用來將憑證系結至 Microsoft Entra 使用者帳戶具有唯一條件約束，以確保憑證只符合單一 Microsoft Entra 使用者帳戶。 不過，Microsoft Entra CBA 支援使用者名稱系結原則中的多個系結方法，讓系統管理員能夠容納一個憑證到多個 Entra 使用者帳戶組態。

重要

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

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

例如，假設您在 PrincipalName 上有兩個使用者名稱系結，其對應至 UPN 和 SubjectKeyIdentifier （SKI） 至 certificateUserIds。 如果您希望憑證只用於單一帳戶，驗證原則 管理員 istrator 必須確定帳戶具有憑證中的 UPN，並在相同帳戶的 certificateUserId 屬性中實作 SKI 對應。

支援具有一個 Entra 用戶帳戶的多個憑證 （M：1）

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

在此範例中，第一個值代表 X509Certificate1，而第二個值則代表 X509Certificate2。 使用者可能會在登入時顯示任一憑證，只要 CBA 用戶名稱系結設定為指向 certificateUserIds 字段來尋找特定系結類型（亦即在此範例中為 Issuer+SerialNumber），使用者就會成功登入。

混合式同步處理帳戶 針對同步處理的帳戶 ，您可以藉由在AD中填入altSecurityIdentities字段來對應多個憑證以供使用，這些值會識別每個憑證。 如果組織使用高親和性（例如強式驗證）系結，表示Issuer + SerialNumber，這可能如下所示：

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

在此範例中，第一個值代表 X509Certificate1，而第二個值則代表 X509Certificate2。 然後，這些值必須同步處理至 Azure AD 中的 certificateUserIds 字段。

支援具有多個 Entra 使用者帳戶的一個憑證 （1：M）

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

重要

使用相同認證向不同的 Entra 標識符帳戶進行驗證並不十分安全，因此建議不要允許多個 Entra 用戶帳戶使用一個憑證。

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

以識別所需憑證的唯一值填入 certificateUserIds 欄位（使用者入口網站中的授權資訊）。 如果組織使用高親和性系結（亦即強式驗證）系結，表示 Issuer + SerialNumber 和 SKI，這可能如下所示：

使用者名稱系結：

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

用戶帳戶 CertificateUserIds 值：
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

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

注意

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

混合式同步處理帳戶 針對同步處理的帳戶 ，方法會有所不同。 雖然租用戶系統管理員可以將唯一值對應至將使用憑證的每個用戶帳戶，但將所有值填入 Entra ID 中每個帳戶的常見做法會讓這種情況變得困難。 相反地，Azure AD 連線 應該將每個帳戶所需的值篩選為在 Entra ID 中填入帳戶的唯一值。 唯一性規則會套用在單一目錄/租使用者的界限內（也就是租用戶系統管理員可以對應憑證，以用於另一個目錄/租使用者，只要這些值也一律保留每個帳戶的唯一值）。 此外，組織可能會有多個 AD 樹系將用戶貢獻至單一 Entra ID 租使用者。 在此情況下，Azure AD 連線 會將篩選套用至每個 AD 樹系，其目標相同，只填入雲端帳戶所需的唯一值。

在AD中填入altSecurityIdentities字段，其中包含識別所需憑證的值，並包含該使用者帳戶類型的所需憑證值（例如詳細數據者、系統管理員、開發人員等）。 在AD中選取索引鍵屬性，告知同步處理使用者正在評估的用戶帳戶類型（例如 msDS-cloudExtensionAttribute1）。 使用您想要的使用者類型值填入此屬性，例如詳細數據者、系統管理員或開發人員。 如果這是使用者的主要帳戶，值可以保留空白/Null。

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

樹系 1 - 帳戶 1 （bob@woodgrove.com）：
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

樹系 2 – ADAccount1 （bob-tdy@woodgrove.com）：
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

然後，這些值必須同步處理至 Entra ID 中的 certificateUserIds 字段。

同步至 certificateUserIds 的步驟

  1. 設定 Azure AD 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 和 key 屬性 msDS-cloudExtensionAttribute1is，以查看是否已填入它們。 如果沒有，則會檢查 altSecurityIdentities，以查看是否已填入。 如果它是空的，則我們將它設定為 NULL。 否則，帳戶會屬於預設案例，在此範例中，我們只會篩選成Issuer+SerialNumber 對應。 如果已填入索引鍵屬性，則會檢查值是否等於其中一個已定義的用戶類型。 在此範例中，如果該值是詳細數據，則我們會從altSecurityIdentities篩選至SHA1PublicKey值。 如果值為開發人員，則我們會從altSecurityIdentities篩選為SubjectKeyIssuer值。 特定類型可能會有多個憑證值。 例如，多個 PrincipalName 值或多個 SKI 或 SHA1-PUKEY 值。 篩選條件會取得所有值，並同步處理至 Entra 標識符，而不只是它找到的第一個值。

  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的先前或後續規則，而且結果在 Entra ID 中是空的。

  1. 設定具有低優先順序的新自定義輸出規則（高於 160 的高數位 – 清單底部）。
  2. 使用alternativeSecurityIds欄位作為來源新增直接轉換，並將 certificateUserIds 字段新增為目標。
  3. 執行同步處理迴圈，以完成 Entra ID 中的數據母體擴展。

請確定每個租使用者中的 CBA 都已設定為指向您從憑證對應之字段類型的 certificateUserIds 字段的使用者名稱系結。 現在，任何這些使用者都可以在登入時出示憑證，並在憑證的唯一值根據 certificateUserIds 字段進行驗證之後，該使用者將會成功登入。

瞭解證書吊銷程式

憑證撤銷程式可讓系統管理員撤銷先前發行的憑證，使其無法用於未來的驗證。 憑證撤銷不會撤銷使用者已發行的令牌。 請遵循在設定撤銷時手動撤銷令牌的步驟。

Microsoft Entra ID 會從其證書頒發機構單位下載並快取客戶證書吊銷清單 （CRL），以檢查憑證是否在使用者驗證期間撤銷。

系統管理員可以在 Microsoft Entra 租使用者的受信任簽發者設定程式期間設定 CRL 發佈點。 每個受信任的簽發者都應該有可使用因特網對應 URL 來參考的 CRL。

重要

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

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

「從 {uri} 下載的證書吊銷清單 （CRL） 超過 Microsoft Entra ID 中 CRL 允許的大小上限 （{size} 個字節）。 請在幾分鐘內再試一次。 如果問題持續發生，請連絡您的租用戶系統管理員。」

錯誤發生之後，Microsoft Entra ID 會嘗試下載 CRL，但受限於服務端限制（在公用 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 會檢查 PKI 信任鏈結中發行 CA 和其他 CA 的 CRL 到根 CA。 PKI 鏈結中 CRL 驗證的分葉用戶端憑證最多有 10 個 CA 的限制。 限制是藉由上傳具有大量CRL大小的CA來上傳 PKI鏈結，以確保不良動作專案不會降低服務。 如果租使用者的 PKI 鏈結有超過 5 個 CA 且 CA 遭到入侵，系統管理員應該從 Microsoft Entra 租使用者設定中移除遭入侵的信任簽發者。

重要

由於CRL快取和發佈周期的性質，強烈建議您撤銷憑證，以在 Microsoft Entra ID 中撤銷受影響使用者的所有會話。

到目前為止，無法手動強制或重新嘗試下載CRL。

如何設定撤銷

若要撤銷用戶端憑證，Microsoft Entra ID 會從上傳為證書頒發機構單位資訊的 URL 擷取憑證吊銷清單 （CRL），並加以快取。 CRL 中的最後一個發佈時間戳 （Effective Date 屬性） 是用來確保 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 命令所指出的日期）。

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 方法，用戶必須取消憑證選擇器、選取 [其他登入方式]，然後選取使用者可用的其他方法並成功進行驗證。

外部身分識別支援

外部身分識別無法使用 Microsoft Entra CBA 對資源租用戶執行多重要素驗證。 相反地，讓使用者在主租使用者中使用 CBA 執行 MFA，並設定資源租使用者的跨租用戶設定，以信任來自主租使用者的 MFA。

如需如何從 Microsoft Entra 租使用者啟用信任多重要素驗證的詳細資訊，請參閱設定 B2B 共同作業跨租使用者存取。

下一步