Share via

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 使用租户名称进行主领域发现，用户名用于在租户中查找用户。

    “我的应用”门户登录的屏幕截图。

  4. Microsoft Entra ID 检查是否为租户启用了 CBA。 如果启用了 CBA，则用户会在密码页上看到“使用证书或智能卡”链接。 如果用户未看到登录链接，请确保在租户上启用了 CBA。 有关详细信息，请参阅如何启用 Microsoft Entra CBA？。

    注意

    如果在租户上启用了 CBA，则所有用户会在密码页上看到“使用证书或智能卡”链接。 但是，只有 CBA 范围内的用户才能针对使用 Microsoft Entra ID 作为标识提供者 (IdP) 的应用程序成功进行身份验证。

    “使用证书或智能卡”的屏幕截图。

    如果启用了其他身份验证方法（例如手机登录或安全密钥），用户可能会看到不同的登录屏幕。

    在同时启用了 FIDO2 的情况下的“登录”屏幕截图。

  5. 用户选择基于证书的身份验证后，客户端将重定向到 certauth 终结点，即公共 Entra ID 的 https://certauth.login.microsoftonline.com。 对于 Azure 政府，certauth 终结点为 https://certauth.login.microsoftonline.us。

    终结点执行 TLS 相互身份验证，并在 TLS 握手过程中请求客户端证书。 此请求的条目将显示在登录日志中。

    注意

    网络管理员应允许访问“用户登录”页以及客户云环境的 certauth 终结点 *.certauth.login.microsoftonline.com。 在 certauth 终结点上禁用 TLS 检查，以确保客户端证书请求在 TLS 握手中成功完成。

    确保 TLS 检查禁用也适用于具有颁发者提示的新 URL。 不要使用 tenantId 对 url 进行硬编码，因为对于 B2B 用户，它可能会更改。 使用正则表达式可使新旧 URL 均可用于 TLS 检查禁用。 例如，请根据代理使用 *.certauth.login.microsoftonline.com 或 *certauth.login.microsoftonline.com。 在 Azure 政府中，使用 *.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。 当用户处于 CBA 范围内时，用户可能需要更多配置来完成 MFA 和证明以注册其他身份验证方法。

如果启用了 CBA 的用户只有单因素 (SF) 证书，并且需要完成 MFA：

  1. 使用密码和 SF 证书。
  2. 颁发临时访问密码。
  3. 身份验证策略管理员添加电话号码，并允许对用户帐户进行语音/短信身份验证。

如果尚未向已启用 CBA 的用户颁发证书，并且需要完成 MFA：

  1. 颁发临时访问密码。
  2. 身份验证策略管理员添加电话号码，并允许对用户帐户进行语音/短信身份验证。

如果启用了 CBA 的用户无法使用 MF 证书，例如在没有智能卡支持的移动设备上，并且需要完成 MFA：

  1. 颁发临时访问密码。
  2. 用户需要注册其他 MFA 方法（在用户可以使用 MF 证书的情况下）
  3. 使用密码和 MF 证书（在用户可以使用 MF 证书的情况下）。
  4. 身份验证策略管理员添加电话号码，并允许对用户帐户进行语音/短信身份验证。

具有基于单因素证书的身份验证的 MFA（预览版）

可将 Microsoft Entra CBA 用作第二个因素，以通过单因素证书满足 MFA 要求。 部分支持的组合包括：

  1. CBA（第一因素）和无密码手机登录（无密码登录作为第二因素）
  2. CBA（第一因素）和 FIDO2 安全密钥（第二因素）
  3. 密码（第一因素）和 CBA（第二因素）

用户需要通过其他方式获取 MFA 且需要提前注册无密码登录或 FIDO2 才能使用 Microsoft Entra CBA 登录。

重要

当用户包含在 CBA 方法设置中时，会被视为支持 MFA 的用户。 这意味着用户无法在身份验证时使用证明来注册其他可用方法。 确保没有有效证书的用户不包含在 CBA 方法设置中。 有关身份验证工作原理的详细信息，请参阅 Microsoft Entra 多重身份验证。

使用 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 的自定义规则和具有 MFA 的策略 OID 1.2.3.4.5，则仅向同时满足颁发者值和策略 OID 的证书 A 提供 MFA。
  3. 然后评估使用策略 OID 的自定义规则。 如果证书 A 具有策略 OID 1.2.3.4.5，而基于该证书的派生凭据 B 具有策略 OID 1.2.3.4.5.6，并且自定义规则定义为值为 1.2.3.4.5 且具有 MFA 的策略 OID，则只有证书 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 无密码手机登录

工作区加入、Entra ID 与混合 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 低相关性
SKI 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 高相关性

在租户级别定义相关性绑定并使用自定义规则进行替代（预览版）

借助此功能，身份验证策略管理员可以配置是否可以使用低相关性或高相关性用户名绑定映射对用户进行身份验证。 可以为租户设置所需的相关性绑定，其适用于所有用户。 还可通过创建自定义规则或者“证书颁发者和策略 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 支持用户名绑定策略中的多个绑定方法，该策略允许管理员使一个证书适应多个 Entra 用户帐户配置。

重要

如果配置多个绑定，Microsoft Entra CBA 身份验证仅与最低相关性绑定一样安全，因为 CBA 会验证每个绑定以对用户进行身份验证。 若要防止单个证书与多个 Microsoft Entra 帐户匹配的情况，身份验证策略管理员可以：

  • 在用户名绑定策略中配置单个绑定方法。
  • 如果租户配置了多个绑定方法，并且不希望允许一个证书映射到多个帐户，则身份验证策略管理员必须确保策略中配置的所有允许方法都映射到同一个 Microsoft Entra 帐户。 所有用户帐户应具有与所有绑定匹配的值。
  • 如果租户配置了多个绑定方法，则身份验证策略管理员应确保它们没有多个低相关性绑定。

例如，假设 PrincipalName 上有两个用户名绑定映射到 UPN，SubjectKeyIdentifier (SKI) 映射到 certificateUserId。 如果希望证书仅用于单个帐户，则身份验证策略管理员必须确保该帐户具有证书中存在的 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 字段用于填充证书值，并在登录期间使用提示将 AD 定向到所需帐户以便检查登录。 对于 Microsoft Entra CBA，情况则有所不同，并且也没有提示。 相反，主领域发现会通过标识所需帐户检查证书值。 另一个主要区别在于，Microsoft Entra CBA 在 CertificateUserIds 字段中强制实施唯一性。 这意味着两个帐户不能同时填充相同证书值。

重要

使用同一凭证对不同的 Entra ID 帐户进行身份验证并非安全配置，建议不允许多个 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 Connect 应将每个帐户的所需值筛选出 Entra ID 中填充到帐户中的唯一值。 唯一性规则适用于单个目录/租户的边界（即，只要每个帐户的值也保持唯一性，租户管理员还可通过映射证书将其用于另一目录/租户）。 此外，组织可能使用多个 AD 林帮助用户使用单个 Entra ID 租户。 在这种情况下，Azure AD Connect 会为了同一目标将筛选器应用于其中每个 AD 林，这样即可仅向云帐户填充所需的唯一值。

使用标识所需证书的值填充 AD 中的 altSecurityIdentities 字段，并纳入该用户帐户类型的所需证书值（例如借调人员、管理员、开发人员等）。 在 AD 中选择一个键属性，该键属性会告知同步用户正在评估的用户帐户类型（例如 msDS-cloudExtensionAttribute1）。 使用所需用户类型值（如借调人员、管理员或开发人员）填充此属性。 如果这是用户的主帐户，则该值可为空/null。

帐户可能如下所示：

林 1 - Account1 (bob@woodgrove.com)：
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

林 1 - Account2 (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 和键属性 msDS-cloudExtensionAttribute1is，查看其是否已填充。 否则即检查 altSecurityIdentities，查看其是否已填充。 如果为空，将其设为 NULL。 否则，该帐户属于默认情况，在此示例中，我们仅筛选出 Issuer+SerialNumber 映射。 如果填充了键属性，则检查该值，查看其是否等于我们定义的其中一种用户类型。 在此示例中，如果该值为借调人员，则从 altSecurityIdentities 筛选出 SHA1PublicKey 值。 如果该值为开发人员，则从 altSecurityIdentities 筛选出 SubjectKeyIssuer 值。 可能存在多个特定类型的证书值。 例如，多个 PrincipalName 值或多个 SKI 或 SHA1-PUKEY 值。 筛选器不仅仅只是获取并同步所找到的第一个值，而是获取所有值并同步到 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 的既往规则或后续规则，并且 Entra ID 中的结果为空。

  1. 配置优先级较低的新自定义出站规则（高于 160 的数字 - 列表底部）。
  2. 添加将 alternativeSecurityIds 字段作为源、CertificateUserIds 字段作为目标的直接转换。
  3. 运行同步周期，完成 Entra ID 的数据填充。

确保每个租户中的 CBA 均配置了指向从证书映射的字段类型的 CertificateUserIds 字段的用户名绑定。 现在，任何此类用户均可在登录时显示证书，根据 CertificateUserIds 字段验证证书的唯一值后，该用户即可成功登录。

了解证书吊销过程

通过证书吊销过程，管理员可以吊销以前颁发的证书，使其不再用于将来的身份验证。 证书吊销不会吊销用户的已颁发令牌。 按照以下步骤在配置吊销中手动吊销令牌。

在用户身份验证过程中，Microsoft Entra ID 从证书颁发机构下载并缓存客户证书吊销列表 (CRL)，以检查证书是否吊销。

管理员可以在 Microsoft Entra 租户中的受信任颁发者的设置过程中配置 CRL 分发点。 每个受信任的颁发者都应有一个可以使用面向 Internet 的 URL 引用的 CRL。

重要

Microsoft Entra ID 在交互式登录时可成功下载和缓存的 CRL 最大大小在公共 Entra ID 中为 20 MB，在 Azure 美国政府云中为 45 MB，且下载 CRL 所需的时间不得超过 10 秒。 如果 Microsoft Entra ID 无法下载 CRL，则使用相应 CA 颁发的证书进行基于证书的身份验证会失败。 将 CRL 文件保持在大小限制范围内的最佳做法是将证书生存期保持在合理的范围内，并清理已过期的证书。 有关详细信息，请参阅 CRL 大小是否有限制？。

当用户使用证书执行交互式登录，而 CRL 超过云的交互限制时，用户的初始登录会失败并出现以下错误：

“从 {uri} 下载的证书吊销列表(CRL)已超过 Microsoft Entra IDy中 CRL 的最大允许大小({size} 字节)。 请在几分钟后重试。 如果该问题仍然出现，请与租户管理员联系。”

出错后，Microsoft Entra ID 尝试下载受服务端限制的 CRL（在公共 Entra ID 中为 45 MB，在 Azure 美国政府云中为 150 MB）。

重要

如果管理员跳过 CRL 的配置，则在用户进行基于证书的身份验证过程中，Microsoft Entra ID 不会执行任何 CRL 检查。 这对于初始故障排除可能有用，但不应考虑用于生产用途。

到目前为止，由于性能和可靠性方面的原因，我们不支持联机证书状态协议 (OCSP)。 Microsoft Entra ID 在首次登录时下载一次 CRL 并对其进行缓存，而非在每次连接时由 OCSP 的客户端浏览器下载，从而提高 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（最高级别为根 CA）的 CRL。 在 PKI 链中，叶客户端证书的、要进行 CRL 验证的 CA 数限制为最多 10 个。 实施限制的目的是确保恶意行动者无法通过上传包含大量 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）进行交互。 有关常见迁移问题，请参阅迁移常见问题解答。 注意：2024 年 6 月 30 日之后，MSOnline 版本 1.0.x 可能会遇到中断。

以下步骤概述了通过设置 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 方法上的身份验证绑定策略来确定证书的强度。 现在，可以在创建自定义身份验证强度时配置高级选项，以便在用户执行 CBA 访问某些敏感资源时，根据颁发者和策略 OID 要求使用特定证书。 此功能提供更精确的配置，用于确定可以访问资源的证书和用户。 有关详细信息，请参阅条件访问身份验证强度的高级选项。

了解登录日志

登录日志提供有关登录以及用户如何使用资源的信息。 有关登录日志的详细信息，请参阅 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 协作跨租户访问。

后续步骤