Microsoft Entra 基于证书的身份验证技术深入探讨

本文介绍 Microsoft Entra 基于证书的身份验证 (CBA) 的工作原理，并深入探讨有关 Microsoft Entra CBA 配置的技术详细信息。

Microsoft Entra 基于证书的身份验证如何工作？

下图描绘了当用户尝试登录到启用了 Microsoft Entra CBA 的租户中的应用程序时会发生什么情况。

现在我们逐步执行每个步骤：

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) 的应用程序成功进行身份验证。

   

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

   

5. 用户选择基于证书的身份验证后，客户端将重定向到 certauth 终结点，即公共 Microsoft 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。

   除非允许访问，否则，如果启用证书颁发者提示，则基于证书的身份验证将失败。

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 检查的代理正确更新后，身份验证策略管理员应当单击“我确认”，然后保存。

注意

如果你的组织具有启用了 TLS 检查的防火墙或代理，请确认你已禁用 certauth 终结点的 TLS 检查（该终结点能够匹配 [*.]certauth.login.microsoftonline.com 下的任何名称），并根据使用的特定代理进行了自定义。

注意

启用证书颁发者提示后，证书颁发机构 URL 的格式为 t{tenantId}.certauth.login.microsoftonline.com。

CA 信任存储更新传播

启用证书颁发者提示并从信任存储添加、更新或删除 CA 后，会有长达 10 分钟的延迟，在这期间会将证书颁发者提示传播回客户端。 在传播提示之前，用户无法使用新 CA 颁发的证书进行身份验证。

身份验证策略管理员应在启用证书颁发者提示以启动传播后使用证书登录。 当 CA 信任存储更新正在传播时，用户会看到以下错误消息。

基于证书的身份验证 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（第一因素）和无密码手机登录（第二因素）
3. CBA（第一因素）和 FIDO2 安全密钥（第二因素）

用户需要通过其他方式获取 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. 选择“是”，用户可以进行身份验证和登录。

将基于证书的身份验证用作第二重身份验证的 MFA（预览版）

CBA 可以用作第二重身份验证，例如使用密码（第一重身份验证）和 CBA（第二重身份验证）进行 MFA。

注意

在 iOS 上，具有基于证书的身份验证的用户会看到“双重提示”，他们必须在其中单击“使用基于证书的身份验证”选项两次。 在 iOS 上，对于采用 Microsoft Authenticator 应用的用户，如果存在强制实施 CBA 的身份验证强度策略，或者用户使用 CBA 作为第二重身份验证或升级身份验证，则他们还会看到要求通过 CBA 进行身份验证的每小时登录提示。

了解身份验证绑定策略

身份验证绑定策略有助于确定身份验证的强度是单因素还是多因素。 身份验证策略管理员可以将默认值从单重更改为多重，或者通过使用证书中的证书颁发者主题或策略 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）。

重要

存在一个已知问题：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) 映射到 certificateUserId。 如果希望证书仅用于单个帐户，则身份验证策略管理员必须确保该帐户具有证书中存在的 UPN，并在同一帐户的 certificateUserId 属性中实现 SKI 映射。

支持一个 Microsoft Entra 用户帐户对应多个证书 (M:1)

在某些应用场景中，组织会为单个标识颁发多个证书。 通常，这可能是移动设备的派生凭证，也可以是支持辅助智能卡或 x509 凭证持有者的设备（例如 Yubikey）的派生凭证。

仅限云的帐户 对于仅限云的帐户，可以通过使用标识每个证书的唯一值填充 CertificateUserIds 字段（用户门户中的授权信息）来映射多个证书（最多 5 个）。 如果组织使用高相关性绑定，例如 Issuer + SerialNumber，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 字段以查找特定绑定类型（本例中为证书颁发者+序列号），用户即可成功登录。

混合同步帐户 对于同步帐户，可以通过在 AD 中填充标识每个证书的值中的 altSecurityIdentities 字段来映射多个证书以供使用。 如果组织使用的是高相关性（即强身份验证）绑定（如证书颁发者+序列号），则可能如下所示：

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，情况则有所不同，并且也没有提示。 相反，主领域发现会通过标识所需帐户检查证书值。 另一个主要区别在于，Microsoft Entra CBA 在 CertificateUserIds 字段中强制实施唯一性。 这意味着两个帐户不能同时填充相同证书值。

重要

使用同一凭据对不同的 Microsoft Entra 帐户进行身份验证并不是一种非常安全的配置，建议不要允许多个 Microsoft Entra 用户帐户使用同一个证书。

仅限云的帐户 对于仅限云的帐户，需要创建多个用户名绑定，并且需要将唯一值映射到将使用该证书的每个用户帐户。 每个帐户均将使用不同用户名绑定进行身份验证。 这适用于单个目录/租户边界内（也就是说，身份验证策略管理员也可以将证书映射到其他目录/租户中使用，只要每个帐户的值也保持唯一）。

使用标识所需证书的唯一值填充 CertificateUserIds 字段（用户门户中的授权信息）。 如果组织使用的是高相关性绑定（即强身份验证）绑定（如证书颁发者+序列号和 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 字段，并包含该用户帐户类型（如 detailee、admin、developer 等）所需的证书值。 在 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 租户中的受信任颁发者的设置过程中配置 CRL 分发点。 每个受信任的颁发者都应有一个可以使用面向 Internet 的 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 IDy中 CRL 的最大允许大小({size} 字节)。 请在几分钟后重试。 如果该问题仍然出现，请与租户管理员联系。”

出错后，Microsoft Entra ID 尝试下载受服务端限制的 CRL（在公共 Microsoft 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 文档已过期，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 命令指示的日期）。

了解 CRL 验证（预览版）

CRL 是证书颁发机构 (CA) 在其有效期结束前吊销的数字证书的记录。 将 CA 上传到 Microsoft Entra 信任存储时，不需要 CRL 或更具体地说是不需要 CrlDistributionPoint 属性。 在没有 CRL 终结点的情况下可以上传 CA，如果颁发 CA 未指定 CRL，则基于证书的身份验证不会失败。

为了增强安全性并避免配置错误，如果为颁发最终用户证书的 CA 未配置 CRL，身份验证策略管理员可以要求 CBA 身份验证失败。

启用 CRL 验证

若要启用 CRL 验证，请单击“需要 CRL 验证（建议）”。

启用后，如果最终用户证书是由未配置 CRL 的 CA 颁发的，则任何 CBA 都将失败。

身份验证策略管理员可以免除 CA（如果 CRL 存在应修复的问题）。 单击“添加豁免”并选择应免除的任何 CA。

免除列表中的 CA 不需要配置 CRL，并且他们颁发的最终用户证书身份验证不会失败。

注意

对象选取器存在已知问题，其中未正确显示所选项。 使用“证书颁发机构”选项卡选择或删除 CA。

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 协作跨租户访问。

后续步骤

• Microsoft Entra CBA 概述
• 如何配置 Microsoft Entra CBA
• iOS 设备上的 Microsoft Entra CBA
• Android 设备上的 Microsoft Entra CBA
• 使用 Microsoft Entra CBA 进行 Windows 智能卡登录
• 证书用户 ID
• 如何迁移联合用户
• 常见问题解答
• Microsoft Entra CBA 故障排除