设置基于证书的身份验证Microsoft

2025-08-16

你的组织可以使用Microsoft基于 Entra 证书的身份验证（CBA）通过用户 X.509 证书实现防钓鱼、新式和无密码身份验证。

本文介绍如何将 Microsoft Entra 租户设置为允许或要求租户用户使用 X.509 证书进行身份验证。用户使用企业公钥基础结构（PKI）创建 X.509 证书，以便进行应用程序和浏览器登录。

设置 Microsoft Entra CBA 时，在登录期间，用户会看到使用证书而不是输入密码进行身份验证的选项。如果设备上的多个匹配证书位于设备上，则用户选择相关证书，并针对用户帐户验证证书。如果验证成功，用户将登录。

完成本文中所述的步骤，为 Office 365 企业版和美国政府计划中租户配置和使用 Microsoft Entra CBA。必须已配置 PKI 。

先决条件

请确保满足下列先决条件：

至少有一个证书颁发机构（CA）和任何中间 CA 在 Microsoft Entra ID 中配置。
用户有权访问从租户上配置的受信任 PKI 颁发的用户证书，该证书用于在 Microsoft Entra ID 中进行客户端身份验证。
每个 CA 都有一个可从面向 Internet 的 URL 引用的证书吊销列表（CRL）。如果未为受信任 CA 配置 CRL，则 Microsoft Entra ID 不会执行任何 CRL 检查，无法吊销用户证书，并且不会阻止身份验证。

注意事项

确保 PKI 安全且不容易泄露。如果发生违规事件，攻击者可以创建和签名客户端证书并入侵租户中的任何用户，包括从本地同步的用户。强大的关键保护策略和其他物理和逻辑控制可以提供深度防御，以防止外部攻击者或内部威胁损害 PKI 的完整性。有关详细信息，请参阅保护 PKI。
有关Microsoft加密（包括选择算法、密钥长度和数据保护）的最佳做法，请参阅 Microsoft建议。请务必使用推荐算法之一、建议的密钥长度和 NIST 批准的曲线。
作为持续安全改进的一部分，Azure 和 Microsoft 365 终结点添加了对 TLS 1.3 的支持。此过程预计需要几个月才能覆盖 Azure 中的数千个服务终结点，Microsoft 365。 Microsoft Entra CBA 使用的 Microsoft Entra 终结点包含在更新中： *.certauth.login.microsoftonline.com 和 *.certauth.login.microsoftonline.us。

TLS 1.3 是 Internet 最常部署的安全协议的最新版本。 TLS 1.3 加密数据，以提供两个终结点之间的安全信道。它消除了过时的加密算法，增强了早期版本的安全性，并尽可能多地加密握手。强烈建议在应用程序和服务中开始测试 TLS 1.3。
评估 PKI 时，请务必查看证书颁发策略和执行。如前所述，将 CA 添加到 Microsoft Entra 配置允许这些 CA 颁发的证书对 Microsoft Entra ID 中的任何用户进行身份验证。

请务必考虑 CA 如何以及何时允许颁发证书以及如何实现可重用标识符。管理员只需确保特定证书可用于对用户进行身份验证，但他们应专门使用高关联绑定来实现更高级别的保证，即只有特定证书才能对用户进行身份验证。有关详细信息，请参阅高相关性绑定。

配置和测试 entra CBA Microsoft

在启用 Microsoft Entra CBA 之前，必须完成一些配置步骤。

管理员必须配置颁发用户证书的可信 CA。如下图所示，Azure 使用基于角色的访问控制（RBAC）来确保只有最低特权管理员才能进行更改。

重要说明

Microsoft 建议使用权限最少的角色。此做法有助于提高组织的安全性。全局管理员是一个高度特权的角色，应仅限于紧急情况或无法使用现有角色时。

（可选）可以配置身份验证绑定，将证书映射到单因素身份验证或多重身份验证（MFA）。配置用户名绑定以将证书字段映射到用户对象的属性。身份验证策略管理员可以配置用户相关的设置。

完成所有配置后，在租户上打开 Microsoft Entra CBA。

此图概述了启用基于 entra 证书的身份验证Microsoft所需的步骤。

步骤 1：使用基于 PKI 的信任存储配置 CA

Microsoft Entra 具有基于 PKI 的新 CA 信任存储。信任存储将 CA 保留在每个 PKI 的容器对象内。管理员可以更轻松地管理基于 PKI 的容器中的 CA，而不是管理 CA 的平面列表。

基于 PKI 的信任存储区的限制高于经典信任存储区的数量和每个 CA 文件的大小。基于 PKI 的信任存储为每个 CA 对象最多支持 250 个 CA 和 8 KB。

如果使用经典信任存储来配置 CA，强烈建议设置基于 PKI 的信任存储。基于 PKI 的信任存储是可缩放的，支持新功能，如颁发者提示。

管理员必须配置颁发用户证书的可信 CA。只有最低特权管理员才能进行更改。基于 PKI 的信任存储分配有特权身份验证管理员角色。

基于 PKI 的信任存储的 PKI 上传功能仅适用于 Microsoft Entra ID P1 或 P2 许可证。但是，使用 Microsoft Entra 免费许可证，管理员可以单独上传所有 CA，而不是上传 PKI 文件。然后，他们可以配置基于 PKI 的信任存储并添加上传的 CA 文件。

使用 Microsoft Entra 管理中心配置 CA

创建 PKI 容器对象（Microsoft Entra 管理中心）

创建 PKI 容器对象：

使用分配有特权身份验证管理员角色的帐户登录到 Microsoft Entra 管理中心。
转到 Entra ID>标识安全功能分数>公钥基础结构。
选择“ 创建 PKI”。
对于 显示名称，请输入名称。
选择创建。
若要添加或删除列，请选择“ 编辑列”。
若要刷新 PPI 列表，请选择“ 刷新”。

删除 PKI 容器对象

若要删除 PKI，请选择 PKI，然后选择“删除”。如果 PKI 包含 CA，请输入 PKI 的名称以确认删除 PKI 中的所有 CA。然后选择“删除”。

将单个 CA 上传到 PKI 容器对象

将 CA 上传到 PKI 容器：

选择 “添加证书颁发机构”。
选择 CA 文件。
如果 CA 是根证书，请选择“ 是”。否则，请选择 “否”。
对于 证书吊销列表 URL，请输入包含所有已吊销证书的 CA 基 CRL 的面向 Internet 的 URL。如果未设置 URL，则尝试使用吊销的证书进行身份验证不会失败。
对于 增量证书吊销列表 URL，请输入 CRL 的面向 Internet 的 URL，其中包含自上次发布基 CRL 以来所有已吊销的证书。
如果 CA 不应包含在颁发者提示中，请关闭颁发者提示。 默认情况下，颁发者提示标志处于关闭状态。
选择“保存”。
若要删除 CA，请选择 CA，然后选择“ 删除”。
若要添加或删除列，请选择“ 编辑列”。
若要刷新 PPI 列表，请选择“ 刷新”。

最初会显示 100 个 CA 证书。向下滚动窗格时会显示更多内容。

将所有 CA 上传到 PKI 容器对象

将所有 CA 批量上传到 PKI 容器：

创建 PKI 容器对象或打开现有容器。
选择 Upload PKI。
输入文件的 HTTP 面向 Internet 的 .p7b URL。
输入文件的 SHA-256 校验和。
选择“上传”。

PKI 上传过程是异步的。每个 CA 上传后，就可在 PKI 中使用。整个 PKI 上传最多可能需要 30 分钟。
选择“刷新”可刷新 CA 列表。
每个上传的 CA CRL 终结点 属性都更新为 CA 证书的第一个可用 HTTP URL，这些 URL 列为 CRL 分发点 属性。必须手动更新任何叶证书。

若要生成 PKI .p7b 文件的 SHA-256 校验和，请运行：

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

编辑 PKI

在 PKI 行上，选择 ... ，然后选择 “编辑”。
输入新的 PKI 名称。
选择“保存”。

编辑 CA

在 CA 行上，选择 ... ，然后选择“ 编辑”。
根据要求输入 CA 类型（根或中间）、CRL URL、增量 CRL URL 或启用颁发者提示的标志的新值。
选择“保存”。

批量编辑颁发者提示属性

若要编辑多个 CA 并打开或关闭 已启用颁发者提示 的属性，请选择多个 CA。
选择 “编辑”，然后选择“ 编辑颁发者提示”。
选中所有所选 CA 的“颁发者提示”复选框 ，或清除选择以关闭所有所选 CA 的颁发者提示已启用 标志。默认值为 不确定。
选择“保存”。

还原 PKI

选择“已删除的 PKI”选项卡。
选择 PKI 并选择“还原 PKI”。

还原 CA

选择“已删除的 CA”选项卡。
选择 CA 文件，然后选择 “还原证书颁发机构”。

为 CA 配置 isIssuerHintEnabled 属性

颁发者提示在传输层安全性（TLS）握手过程中发送回 受信任的 CA 指示器。受信任的 CA 列表设置为租户上传到 Microsoft Entra 信任存储的 CA 的主题。有关详细信息，请参阅了解颁发者提示。

默认情况下，Microsoft Entra 信任存储中所有 CA 的使用者名称都将作为提示发送。如果要仅向特定 CA 发送回提示，请将颁发者提示属性 isIssuerHintEnabled 设置为 true。

服务器可以向 TLS 客户端发送最多 16 KB 的颁发者提示（CA 使用者名称）的响应。建议仅为颁发用户证书的 CA 设置 isIssuerHintEnabled 属性 true 。

如果来自同一根证书的多个中间 CA 颁发用户证书，则默认情况下，所有证书都显示在证书选取器中。如果设置为isIssuerHintEnabledtrue特定 CA，则只会在证书选取器中显示相关的用户证书。

使用 Microsoft Graph API 配置 CA

以下示例演示如何使用 Microsoft Graph 通过 PKI 或 CA 的 HTTP 方法运行创建、读取、更新和删除（CRUD）作。

创建 PKI 容器对象（Microsoft Graph）

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

获取所有 PKI 对象

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

按 PKI ID 获取 PKI 对象

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

使用 .p7b 文件上传 CA

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-id>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
     "uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
     "sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

获取 PKI 中的所有 CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

按 CA ID 获取 PKI 中的特定 CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

更新特定 CA 颁发者提示标志

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

使用 PowerShell 配置 CA

对于这些步骤，请使用 Microsoft Graph PowerShell。

使用 “以管理员身份运行 ”选项启动 PowerShell。

安装和导入 Microsoft Graph PowerShell SDK：

Install-Module Microsoft.Graph -Scope AllUsers
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

连接到租户并接受所有：

   Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>

基于 PKI 的信任存储和经典 CA 存储之间的优先级

如果基于 PKI 的 CA 存储和经典 CA 存储中都存在 CA，则会优先设置基于 PKI 的信任存储的优先级。

在这些方案中，经典 CA 存储的优先级如下：

这两个存储中都存在 CA，基于 PKI 的存储没有 CRL，但经典存储 CA 具有有效的 CRL。
这两个存储中都存在 CA，而基于 PKI 的存储 CA CRL 不同于经典存储 CA CRL。

Microsoft Entra 登录日志中断条目在 “其他详细信息 ”下有两个属性，用于指示身份验证期间是否使用了经典或旧信任存储。

旧存储使用的 值为 0 ，指示使用了基于 PKI 的存储。值为 1 表示使用了经典存储或旧存储。
旧存储使用信息 显示使用经典存储或旧存储的原因。

显示使用基于 PKI 的存储或经典 CA 存储的登录日志条目的屏幕截图

审核日志

在信任存储内的 PKI 或 CA 上运行的任何 CRUD作都显示在 Microsoft Entra 审核日志中。

从经典 CA 存储迁移到基于 PKI 的存储

租户管理员可以将所有 CA 上传到基于 PKI 的存储。然后，PKI CA 存储优先于经典存储，所有 CBA 身份验证都通过基于 PKI 的存储进行。租户管理员可以在确认使用经典或旧存储的登录日志中没有指示后，从经典存储或旧存储中删除 CA。

常见问题解答

为什么 PKI 上传失败？

验证 PKI 文件是否有效，并且它是否可以访问，且没有任何问题。 PKI 文件的最大大小是 2 MB（每个 CA 对象的 250 CA 和 8 KB）。

PKI 上传的服务级别协议是什么？

PKI 上传是一项异步作，最长可能需要 30 分钟才能完成。

如何为 PKI 文件生成 SHA-256 校验和？

若要生成 PKI .p7b 文件的 SHA-256 校验和，请运行以下命令：

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

步骤 2：为租户启用 CBA

重要说明

在身份验证方法策略中将用户指定为 CBA 的范围时，该用户被视为能够完成 MFA。此策略要求意味着用户无法使用标识证明作为身份验证的一部分来注册其他可用方法。如果用户无权访问证书，则它们被锁定，并且无法注册 MFA 的其他方法。分配了身份验证策略管理员角色的管理员必须仅对具有有效证书的用户启用 CBA。对于 CBA，不包含“所有用户”。仅使用具有有效证书的用户组。有关详细信息，请参阅 Microsoft Entra 多重身份验证。

若要通过 Microsoft Entra 管理中心启用 CBA，请执行以下作：

使用至少分配有身份验证策略管理员角色的帐户登录到 Microsoft Entra 管理中心。
转到 “组>所有组”。
选择 “新建组 ”并为 CBA 用户创建组。
转到基于证书的>身份验证的 Entra ID> 身份验证方法。
在“ 启用”和“目标”下，选择“ 启用”，然后选择“ 我确认 ”复选框。
选择 “选择组>添加组”。
选择特定组，例如创建的组，然后选择 “选择”。使用特定组而不是 所有用户。
选择“保存”。

为租户启用 CBA 后，租户中的所有用户都会看到使用证书登录的选项。只有能够使用 CBA 的用户才能使用 X.509 证书进行身份验证。

注意

除了终结点之外，网络管理员还应允许访问组织的云环境的 login.microsoftonline.com 证书身份验证终结点。在证书身份验证终结点上关闭 TLS 检查，以确保客户端证书请求在 TLS 握手过程中成功。

步骤 3：配置身份验证绑定策略

身份验证绑定策略有助于将身份验证强度设置为单个因素或 MFA。租户上所有证书的默认保护级别是单因素身份验证。

租户级别的默认关联绑定 相关性较低。身份验证策略管理员可以将默认值从单因素身份验证更改为 MFA。如果保护级别发生更改，则租户上的所有证书都设置为 MFA。同样，租户级别的地缘绑定可以设置为 高相关性。然后，所有证书仅使用高相关性属性进行验证。

重要说明

管理员必须将租户默认设置为适用于大多数证书的值。仅为需要与租户默认值不同的保护级别或关联绑定的特定证书创建自定义规则。所有身份验证方法配置都位于同一策略文件中。创建多个冗余规则可能会超过策略文件大小限制。

身份验证绑定规则将 颁发者、 策略对象 ID（OID）和 颁发者和策略 OID 等证书属性映射到指定的值。规则为该规则设置默认保护级别和关联绑定。

若要通过 Microsoft Entra 管理中心修改默认租户设置和创建自定义规则，请执行以下作：

使用至少分配有身份验证策略管理员角色的帐户登录到 Microsoft Entra 管理中心。
转到 Entra ID>身份验证方法>策略。
在“管理迁移”下，选择“基于证书的>身份验证”身份验证方法。
若要设置身份验证绑定和用户名绑定，请选择“ 配置”。
若要将默认值更改为 MFA，请选择 多重身份验证。保护级别属性的默认值为“单因素身份验证”。

注意

如果未添加自定义规则，默认保护级别将生效。如果添加自定义规则，则遵循规则级别定义的保护级别，而不是默认保护级别。
还可以设置自定义身份验证绑定规则，以帮助确定客户端证书的保护级别，这些证书需要与租户默认值不同的保护级别或关联绑定值。可以使用证书中的颁发者主体或策略 OID 或策略 OID 或这两个字段来配置规则。

身份验证绑定规则将证书属性（颁发者或策略 OID）映射到值。该值设置该规则的默认保护级别。可创建多个规则。在以下示例中，假定租户默认为 多重身份验证 ，低关联绑定。

若要添加自定义规则，请选择“ 添加规则”。

若要按证书颁发者创建规则，请执行以下作：
1. 选择 证书颁发者。
2. 对于 证书颁发者标识符，请选择相关值。
3. 对于 身份验证强度，请选择 “多重身份验证”。
4. 对于 相关性绑定，请选择“ 低”。
5. 选择 “添加”。
6. 出现提示时，选中“ 我确认” 复选框以添加规则。
按策略 OID 创建规则：
1. 选择 策略 OID。
2. 对于 策略 OID，请输入一个值。
3. 对于 身份验证强度，请选择 “单因素身份验证”。
4. 对于 相关性绑定，请选择“ 低 ”进行关联绑定。
5. 选择 “添加”。
6. 出现提示时，选中“ 我确认” 复选框以添加规则。
按颁发者和策略 OID 创建规则：
1. 选择 “证书颁发者 ”和 “策略 OID”。
2. 选择颁发者并输入策略 OID。
3. 对于 身份验证强度，请选择 “多重身份验证”。
4. 对于 相关性绑定，请选择“ 低”。
5. 选择 “添加”。
6. 使用策略 OID 的 3.4.5.6 证书进行身份验证，并由该 CN=CBATestRootProd证书颁发。验证身份验证是否通过多重声明。
按颁发者和序列号创建规则：
1. 添加身份验证绑定策略。该策略要求使用 CN=CBATestRootProd 策略 OID 1.2.3.4.6 颁发的任何证书只需要高相关性绑定。使用颁发者和序列号。
2. 选择证书字段。对于此示例，请选择 “颁发者”和“序列号”。
3. 唯一支持的用户属性是 certificateUserIds。选择 certificateUserIds 并选择“ 添加”。
4. 选择“保存”。
  
  登录日志显示用于登录的绑定以及证书中的详细信息。
选择 “确定 ”以保存任何自定义规则。

重要说明

使用对象标识符格式输入策略 OID。例如，如果证书策略显示 “所有颁发策略”，请在添加规则时输入策略 OID 2.5.29.32.0 。字符串“所有颁发策略”对于规则编辑器无效，因此不会生效。

步骤 4：配置用户名绑定策略

用户名绑定策略有助于验证用户的证书。默认情况下，若要确定用户，请将证书中的 主体名称 映射到 userPrincipalName 用户对象中。

身份验证策略管理员可以替代默认值并创建自定义映射。有关详细信息，请参阅用户名绑定的工作原理。

有关使用该 certificateUserIds 属性的其他方案，请参阅证书用户 ID。

重要说明

如果用户名绑定策略使用同步的属性（例如 certificateUserIds， onPremisesUserPrincipalName以及 userPrincipalName 用户对象的属性），则在本地 Windows Server Active Directory 中具有管理权限的帐户可以进行更改，这些更改会影响 Microsoft Entra ID 中的这些属性。例如，在 Microsoft Entra Connect Server 上具有委托权限的用户对象或管理员角色的帐户可以进行这些类型的更改。

选择要与某个用户属性绑定的一个 X.509 证书字段，以创建用户名绑定。用户名绑定顺序表示绑定的优先级。第一个用户名绑定具有最高优先级等。

如果在证书上找到了指定的 X.509 证书字段，但Microsoft Entra ID 找不到具有相应值的用户对象，身份验证将失败。然后，Microsoft Entra ID 会尝试列表中的下一个绑定。
选择“保存”。

最终配置类似于以下示例：

步骤 5：测试配置

本部分介绍如何测试证书和自定义身份验证绑定规则。

测试证书

在第一个配置测试中，尝试使用设备浏览器登录到 MyApps 门户。

输入用户主体名称（UPN）。
选择 “下一步”。

如果提供了其他身份验证方法（如电话登录或 FIDO2），则用户可能会看到其他登录对话框。
选择“使用证书登录”。
在客户端证书选取器 UI 中选择正确的用户证书，然后选择“ 确定”。
验证是否已登录到 MyApps 门户。

如果登录成功，则可确定：

在测试设备中预配用户证书。
Microsoft Entra ID 已正确配置为使用受信任的 CA。
正确配置了用户名绑定。找到并验证用户。

测试自定义身份验证绑定规则

接下来，完成验证强身份验证的方案。创建两个身份验证策略规则：一个是使用颁发者主体满足单因素身份验证，另一个是使用策略 OID 来满足多重身份验证。

创建具有单因素身份验证保护级别的颁发者主体规则。将该值设置为 CA 主题值。

例如：

CN=WoodgroveCA
创建具有多重身份验证保护级别的策略 OID 规则。将该值设置为证书中的策略 OID 之一。示例为 1.2.3.4。
为用户创建Microsoft Entra 条件访问策略以要求 MFA。完成条件访问 - 需要 MFA 中所述的步骤。
转到 MyApps 门户。输入 UPN，然后选择“ 下一步”。
选择“ 使用证书或智能卡”。

如果提供了其他身份验证方法（如电话登录或安全密钥），则用户可能会看到其他登录对话框。
选择客户端证书，然后选择“ 证书信息”。

证书将显示，你也可以验证颁发者和策略 OID 值。
若要查看策略 OID 值，请选择“ 详细信息”。
选择客户端证书，然后选择“ 确定”。

证书中的策略 OID 与配置的 MFA 值 1.2.3.4 匹配并满足 MFA。证书中的颁发者与配置的值 CN=WoodgroveCA 匹配并满足单因素身份验证。

由于策略 OID 规则优先于颁发者规则，因此证书满足 MFA。

用户的条件访问策略需要 MFA，并且证书满足 MFA，以便用户可以登录到应用程序。

测试用户名绑定策略

用户名绑定策略有助于验证用户的证书。用户名绑定策略支持三个绑定：

IssuerAndSerialNumber > certificateUserIds
IssuerAndSubject > certificateUserIds
Subject > certificateUserIds

默认情况下，Microsoft Entra ID 将证书userPrincipalName中的主体名称映射到用户对象中以确定用户。身份验证策略管理员可以替代默认值并创建自定义映射，如前所述。

身份验证策略管理员必须设置新绑定。若要准备，他们必须确保在用户对象的属性中 certificateUserIds 更新相应的用户名绑定的正确值：

对于仅限云的用户，请使用 Microsoft Entra 管理中心或 Microsoft Graph API 更新值 certificateUserIds。
对于本地同步用户，请使用 Microsoft Entra Connect 通过遵循 Microsoft Entra Connect 规则或同步值，从本地同步 AltSecId 值。

重要说明

颁发者、使用者和序列号的值的格式必须按证书格式的相反顺序排列。不要在 颁发者 或 使用者 值中添加任何空格。

颁发者和序列号手动映射

以下示例演示颁发者和序列号手动映射。

要添加的 颁发者 值是：

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

显示颁发者值的手动映射的屏幕截图。

若要获取序列号的正确值，请运行以下命令。存储中显示的 certificateUserIds值。

命令语法为：

certutil –dump –v [~certificate path~] >> [~dumpFile path~]

例如：

certutil -dump -v firstusercert.cer >> firstCertDump.txt

下面是命令的示例 certutil ：

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48

要添加certificateUserId的序列号值为：

b24134139f069b49997212a86ba0ef48

值为 certificateUserIds ：

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

颁发者和使用者手动映射

以下示例演示颁发者和使用者手动映射。

颁发者值为：

显示与多个绑定一起使用时颁发者值的屏幕截图。

Subject 值为：

显示“主题”值的屏幕截图。

值为 certificateUserId ：

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

使用者手动映射

以下示例演示主题手动映射。

Subject 值为：

显示另一个“主题”值的屏幕截图。

值为 certificateUserIds ：

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

测试相关性绑定

使用至少分配有身份验证策略管理员角色的帐户登录到 Microsoft Entra 管理中心。
转到 Entra ID>身份验证方法>策略。
在“管理”下，选择“基于证书的>身份验证”身份验证方法。
选择“配置”。
在租户级别设置所需的相关性绑定。

重要说明

请谨慎使用租户范围的相关性设置。如果更改租户 的必需关联绑定 值，并且用户对象中没有正确的值，则可能会锁定整个租户。同样，如果创建自定义规则，该规则适用于所有用户，并且需要高相关性绑定，则租户中的用户可能会被锁定。
若要测试，对于 所需的相关性绑定，请选择“ 低”。
添加高相关性绑定，如主题密钥标识符（SKI）。在 “用户名绑定”下，选择“ 添加规则”。
选择 SKI ，然后选择 “添加”。

完成后，规则看起来类似于以下示例：
对于所有用户对象，请使用用户证书中正确的 SKI 值更新 certificateUserIds 属性。

有关详细信息，请参阅 CertificateUserID 支持的模式。
为身份验证绑定创建自定义规则。
选择 “添加”。

检查已完成的规则是否类似于以下示例：
使用证书和策略 OID 9.8.7.5中的正确 SKI 值更新用户certificateUserIds值。
使用策略为 OID 的 9.8.7.5证书进行测试。验证用户是否已使用 SKI 绑定进行身份验证，并提示他们使用 MFA 登录，并且仅使用证书登录。

使用 Microsoft 图形 API 设置 CBA

若要使用 Microsoft Graph API 设置 CBA 并配置用户名绑定，

转到 Microsoft Graph Explorer。
选择 “登录到 Graph 资源管理器” 并登录到租户。
按照步骤同意 Policy.ReadWrite.AuthenticationMethod 委派的权限。

获取所有身份验证方法：

GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy

获取 X.509 证书身份验证方法的配置：

GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate

默认情况下，X.509 证书身份验证方法处于关闭状态。若要允许用户使用证书登录，必须启用身份验证方法，并通过更新作配置身份验证和用户名绑定策略。若要更新策略，请运行请求 PATCH 。

请求主体

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
Content-Type: application/json

{
    "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
    "id": "X509Certificate",
    "state": "enabled",
    "certificateUserBindings": [
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "onPremisesUserPrincipalName",
            "priority": 1
        },
        {
            "x509CertificateField": "RFC822Name",
            "userProperty": "userPrincipalName",
            "priority": 2
        }, 
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "certificateUserIds",
            "priority": 3
        }
    ],
    "authenticationModeConfiguration": {
        "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
        "rules": [
            {
                "x509CertificateRuleType": "issuerSubject",
                "identifier": "CN=WoodgroveCA ",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            },
            {
                "x509CertificateRuleType": "policyOID",
                "identifier": "1.2.3.4",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            }
        ]
    },
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false
        }
    ]
}

204 No content验证响应代码是否返回。重新运行 GET 请求以确保策略正确更新。
通过使用满足策略的证书进行登录来测试配置。

使用 Microsoft PowerShell 设置 CBA

打开 PowerShell。

连接到 Microsoft Graph：

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

创建用于为 CBA 用户定义组的变量：

$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"

定义请求正文：

$body = @{
"@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
"id" = "X509Certificate"
"state" = "enabled"
"certificateUserBindings" = @(
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "SubjectKeyIdentifier"
        "userProperty" = "certificateUserIds"
        "priority" = 1
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "PrincipalName"
        "userProperty" = "UserPrincipalName"
        "priority" = 2
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "RFC822Name"
        "userProperty" = "userPrincipalName"
        "priority" = 3
    }
)
"authenticationModeConfiguration" = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
    "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
    "rules" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateRule"
            "x509CertificateRuleType" = "policyOID"
            "identifier" = "1.3.6.1.4.1.311.21.1"
            "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
        }
    )
}
"includeTargets" = @(
    @{
        "targetType" = "group"
        "id" = $group.Id
        "isRegistrationRequired" = $false
    }
) } | ConvertTo-Json -Depth 5

PATCH运行请求：

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"

反馈

此页面是否有帮助？

通过

设置基于证书的身份验证Microsoft

先决条件

注意事项

配置和测试 entra CBA Microsoft

步骤 1：使用基于 PKI 的信任存储配置 CA

使用 Microsoft Entra 管理中心配置 CA

创建 PKI 容器对象（Microsoft Entra 管理中心）

删除 PKI 容器对象

将单个 CA 上传到 PKI 容器对象

将所有 CA 上传到 PKI 容器对象

编辑 PKI

编辑 CA

批量编辑颁发者提示属性

还原 PKI

还原 CA

为 CA 配置 isIssuerHintEnabled 属性

使用 Microsoft Graph API 配置 CA

创建 PKI 容器对象（Microsoft Graph）

获取所有 PKI 对象

按 PKI ID 获取 PKI 对象

使用 .p7b 文件上传 CA

获取 PKI 中的所有 CA

按 CA ID 获取 PKI 中的特定 CA

更新特定 CA 颁发者提示标志

使用 PowerShell 配置 CA

基于 PKI 的信任存储和经典 CA 存储之间的优先级

登录日志

审核日志

从经典 CA 存储迁移到基于 PKI 的存储

常见问题解答

为什么 PKI 上传失败？

PKI 上传的服务级别协议是什么？

如何为 PKI 文件生成 SHA-256 校验和？

步骤 2：为租户启用 CBA

步骤 3：配置身份验证绑定策略

步骤 4：配置用户名绑定策略

步骤 5：测试配置

测试证书

测试自定义身份验证绑定规则

测试用户名绑定策略

颁发者和序列号手动映射

颁发者和使用者手动映射

使用者手动映射

测试相关性绑定

使用 Microsoft 图形 API 设置 CBA

请求主体

使用 Microsoft PowerShell 设置 CBA

相关内容

反馈

其他资源