如何配置 Microsoft Entra 基于证书的身份验证
使用 Microsoft Entra 基于证书的身份验证 (CBA),组织可将其 Microsoft Entra 租户配置为允许或要求用户使用其企业公钥基础结构 (PKI) 创建的 X.509 证书进行身份验证,以便在应用和浏览器中登录。 借助此功能,组织可以通过 x.509 证书来采用防网络钓鱼新式无密码身份验证。
在登录期间,用户还将看到使用证书(而不是输入密码)进行身份验证的选项。 如果设备上存在多个匹配的证书,则用户可以从中选择使用某个证书。 将根据用户帐户验证证书,如果验证成功,则用户可以登录。
请按照以下说明为 Office 365 企业版和美国政府计划中的租户配置和使用 Microsoft Entra CBA。 你应当已经配置公钥基础结构 (PKI)。
先决条件
确保满足以下先决条件:
- 在 Microsoft Entra ID 中配置至少一个证书颁发机构 (CA) 和任何中间 CA。
- 用户必须能够访问(由租户上配置的可信公钥基础结构颁发的)用户证书,该证书用于针对 Microsoft Entra ID 进行客户端身份验证。
- 每个 CA 都应具有可以从面向 internet 的 URL 引用的证书吊销列表 (CRL)。 如果未为受信任 CA 配置 CRL,则 Microsoft Entra ID 不会执行任何 CRL 检查,无法吊销用户证书,并且不会阻止身份验证。
重要
确保 PKI 是安全的,并且无法轻松遭到入侵。 如果 PKI 遭到入侵,攻击者可以创建并签署客户端证书,以及侵害租户中的任何用户(包括从本地同步的用户和仅云端用户)。 但是,强大的密钥保护策略以及其他物理和逻辑控制(例如用于安全存储项目的 HSM 激活卡或令牌)可以提供深层防御,以防止外部攻击者或内部威胁破坏 PKI 的完整性。 有关详细信息,请参阅保护 PKI。
重要
请访问 Microsoft 建议,获取 Microsoft 加密的最佳做法,包括算法选择、密钥长度和数据保护。 请确保使用某个建议的算法、密钥长度和 NIST 批准的曲线。
重要
作为持续安全改进的一部分,Azure/M365 终结点正在添加对 TLS1.3 的支持,此过程预计需要几个月才能覆盖 Azure/M365 中的数千个服务终结点。 这包括 Microsoft Entra 基于证书的身份验证 (CBA) *.certauth.login.microsoftonline.com
和 *.certauth.login.microsoftonline.us
使用的Microsoft Entra 终结点。 TLS 1.3 是 Internet 部署最多的安全协议的最新版本,它对数据进行加密,在两个终结点之间提供安全通信通道。 TLS 1.3 使得不必使用过时的加密算法,增强了旧版本的安全性,并旨在对尽可能多的握手进行加密。 强烈建议开发人员开始在其应用程序和服务中测试 TLS 1.3。
注意
在评估 PKI 时,审查证书颁发策略和实施非常重要。 如前所述,将证书颁发机构 (CA) 添加到 Microsoft Entra 配置将允许这些 CA 颁发的证书对 Microsoft Entra ID 中的任何用户进行身份验证。 因此,必须考虑允许 CA 如何与何时颁发证书,以及它们如何实现可重用标识符。 在管理员需要确保只有特定证书可用于对用户进行身份验证的情况下,管理员应该专门使用高相关性绑定来实现较高级别的保证,即只有特定的证书能够对用户进行身份验证。 有关详细信息,请参阅高相关性绑定。
配置和测试 Microsoft Entra CBA 的步骤
在启用 Microsoft Entra CBA 之前要完成的一些配置步骤。 首先,管理员必须配置颁发用户证书的可信 CA。 如下图所示,我们使用基于角色的访问控制来确保只需由最低特权管理员做出更改。
此功能需要由全局管理员来管理。
(可选)还可以配置身份验证绑定以将证书映射到单重或多重身份验证,并配置用户名绑定以将证书字段映射到用户对象的属性。 身份验证策略管理员可以配置与用户相关的设置。 完成所有配置后,在租户中启用 Microsoft Entra CBA。
步骤 1:配置证书颁发机构
可以使用 Microsoft Entra 管理中心或 Microsoft Graph REST API 以及支持的 SDK(例如 Microsoft Graph PowerShell)来配置证书颁发机构 (CA)。 PKI 基础结构或 PKI 管理员应能够提供颁发者 CA 的列表。 若要确保你已配置所有 CA,请打开用户证书并单击“证书路径”选项卡,然后确保每个 CA 直到根都已上传到 Microsoft Entra ID 信任存储。 如果缺少 CA,则 CBA 身份验证将失败。
使用 Microsoft Entra 管理中心配置证书颁发机构
若要在 Microsoft Entra 管理中心中启用基于证书的身份验证并配置用户绑定,请完成以下步骤:
-
以全局管理员身份登录到 Microsoft Entra 管理中心。
浏览到“保护”>“显示更多”>“安全中心”(或“标识安全分数”)>“证书颁发机构”。
若要上传 CA,请选择“上传”:
选择 CA 文件。
如果 CA 是根证书,请选择“是”,否则请选择“否”。
对于“证书吊销列表 URL”,请为包含所有已吊销证书的 CA 基 CRL 设置面向 Internet 的 URL。 如果未设置 URL,则使用已吊销的证书进行身份验证不会失败。
对于“增量证书吊销列表 URL”,请为自上次发布基 CRL 以来,包含所有已吊销证书的 CRL 设置面向 Internet 的 URL。
选择 添加 。
若要删除 CA 证书,请选择该证书,然后选择“删除”。
选择“列”可添加或删除列。
使用 PowerShell 配置证书颁发机构 (CA)
仅支持可信 CA 的一个 CRL 分发点 (CDP)。 CDP 只能是 HTTP URL。 不支持联机证书状态协议 (OCSP) 或轻型目录访问协议 (LDAP) URL。
若要在 Microsoft Entra ID 中配置证书颁发机构,需要针对每个证书颁发机构上传以下信息:
- 证书的公共部分,格式为 .cer
- 证书吊销列表 (CRL) 所在的面向 Internet 的 URL
证书颁发机构的架构如下所示:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
对于配置,可以使用 Microsoft Graph PowerShell:
使用管理员特权启动 Windows PowerShell。
安装 Microsoft Graph PowerShell:
Install-Module Microsoft.Graph
作为第一个配置步骤,需建立与租户的连接。 与租户建立连接后,即可查看、添加、删除和修改目录中定义的受信任的证书颁发机构。
连接
若要建立与租户的连接,请使用 Connect-MgGraph:
Connect-MgGraph
检索
若要检索目录中定义的受信任的证书颁发机构,请使用 Get-MgOrganizationCertificateBasedAuthConfiguration。
Get-MgOrganizationCertificateBasedAuthConfiguration
添加
注意
当现有 CA 过期时,新 CA 的上传将失败。 租户管理员应删除过期的 CA,然后上传新 CA。
按照上述步骤在 Microsoft Entra 管理中心中添加 CA。
AuthorityType
- 使用 0 表示根证书颁发机构
- 使用 1 表示中间证书颁发机构或颁发证书颁发机构
crlDistributionPoint
可以下载 CRL 并比较 CA 证书和 CRL 信息,以验证上述 PowerShell 示例中的 crlDistributionPoint 值对于要添加的 CA 是否有效。
下面的表和图显示了如何将信息从 CA 证书映射到已下载 CRL 的属性。
CA 证书信息 | = | 已下载 CRL 信息 |
---|---|---|
使用者 | = | 颁发者 |
使用者密钥标识符 | = | 授权密钥标识符 (KeyID) |
提示
上述示例中 crlDistributionPoint 的值是 CA 的证书吊销列表的 http 位置 (CRL)。 可以在几个位置找到此值:
- 从 CA 颁发的证书的 CRL 分发点 ( CDP) 属性。
如果颁发 CA 运行 Windows Server:
有关详细信息,请参阅了解证书吊销过程。
使用 Microsoft Graph API 配置证书颁发机构
MS Graph API 可用于配置证书颁发机构。 请按照 certificatebasedauthconfiguration MSGraph 命令中的步骤更新 Microsoft Entra 证书颁发机构信任存储。
验证证书颁发机构配置
请务必确保上述配置步骤的结果是,Microsoft Entra 能够验证证书颁发机构信任链,并从所配置的证书颁发机构 CRL 分发点 (CDP) 成功获取证书吊销列表 (CRL)。 为协助完成此项任务,建议安装 MSIdentity 工具 PowerShell 模块,并运行 Test-MsIdCBATrustStoreConfiguration。 此 PowerShell cmdlet 将查看 Microsoft Entra 租户证书颁发机构配置,并显示常见错误配置问题的错误/警告。
步骤 2:在租户上启用 CBA
重要
如果用户在身份验证方法策略中处于基于证书的身份验证范围内,则该用户被视为能够进行 MFA。 此策略要求意味着用户无法在身份验证时使用证明来注册其他可用方法。 如果用户无权访问证书,他们将被锁定,并且无法注册其他 MFA 方法。 因此,管理员需要让具有有效证书的用户进入 CBA 范围。 不要将所有用户用于 CBA 目标,并使用具有可用的有效证书的用户组。 有关详细信息,请参阅 Microsoft Entra 多重身份验证。
若要在 Microsoft Entra 管理中心启用基于证书的身份验证,请完成以下步骤:
至少以身份验证策略管理员的身份登录到 Microsoft Entra 管理中心。
浏览到“组”>“所有组”> 选择“新建组”,然后为 CBA 用户创建一个组
浏览至“保护”>“身份验证方法”>“基于证书的身份验证”。
在“启用和目标”下,选择“启用”。
选择“所有用户”,或选择“添加组”以选择特定组,例如上面创建的组。 建议使用特定组,而不是“所有用户”。
一旦在租户上启用基于证书的身份验证,租户中的所有用户都将看到使用证书登录的选项。 只有启用基于证书的身份验证,用户才能使用 X.509 证书进行身份验证。
注意
除 login.microsoftonline.com
以外,网络管理员应允许访问客户所在云环境的 certauth 终结点。 在 certauth 终结点上禁用 TLS 检查,以确保客户端证书请求在 TLS 握手中成功完成。
步骤 3:配置身份验证绑定策略
身份验证绑定策略可帮助确定单因素或多因素身份验证的强度。 租户上证书的默认保护级别是单因素身份验证。
身份验证策略管理员可以将默认值从单因素更改为多因素并配置自定义策略规则。 身份验证绑定规则将证书属性(如颁发者、策略 OID 或颁发者和策略 OID)映射到值,并为该规则选择默认保护级别。 可以创建多个规则。
若要修改 Microsoft Entra 管理中心中的租户默认设置,请完成以下步骤:
至少以身份验证策略管理员的身份登录到 Microsoft Entra 管理中心。
浏览至 “保护”>“身份验证方法”>“策略”。
在“管理”下,选择“身份验证方法”>“基于证书的身份验证”。
选择“配置”,以设置身份验证绑定和用户名绑定。
保护级别属性的默认值为“单因素身份验证”。 选择“多重身份验证”,将默认值更改为 MFA。
注意
如果未添加任何自定义规则,则默认保护级别值将生效。 如果添加了自定义规则,则改为遵循在规则级别定义的保护级别。
还可以设置自定义身份验证绑定规则,以帮助确定客户端证书的保护级别。 可以使用证书中的颁发者主题或策略 OID 字段进行配置。
身份验证绑定规则将证书属性(颁发者或策略 OID)映射到值,并选择该规则的默认保护级别。 可创建多个规则。
若要添加自定义规则,请选择“添加规则”。
若要按证书颁发者创建规则,请选择“证书颁发者”。
从列表框中选择“证书颁发者标识符”。
选择“多重身份验证”,对于绑定相关性,选择“低”,然后单击“添加”。 当系统提示时,单击“我确认”以完成添加规则。
若要按策略 OID 创建规则,请选择“策略 OID”。
输入“策略 OID”的值。
选择“多重身份验证”,对于绑定相关性,选择“低”,然后单击“添加”。 当系统提示时,单击“我确认”以完成添加规则。 。
若要按颁发者和策略 OID 创建规则,请执行以下操作:
选择“证书颁发者”和“策略 OID”。
选择颁发者并输入策略 OID。
对于“身份验证强度”,请选择“单因素身份验证”或“多重身份验证”。
对于“相关性绑定”,请选择“低”。
选择 添加 。
使用策略 OID 为 3.4.5.6 且由 CN=CBATestRootProd 颁发的证书进行身份验证。 身份验证应该通过并获取多重声明。
重要
存在一个已知问题:Microsoft Entra 租户管理员同时使用证书颁发者和策略 OID 配置 CBA 身份验证策略规则会影响某些设备注册方案,包括:
- Windows Hello 企业版注册
- Fido2 安全密钥注册
- Windows 无密码手机登录
使用 Workplace Join 进行设备注册、Microsoft Entra ID 和混合 Microsoft Entra 设备加入方案不受影响。 使用发卡机构或策略 OID 的 CBA 身份验证策略规则不受影响。 要缓解该问题,管理员应该:
- 编辑目前使用发卡机构和策略 OID 选项的基于证书的身份验证策略规则,并删除发卡机构或 OID 需求并保存。 OR
- 删除当前同时使用发卡机构和策略 OID 的身份验证策略规则,并仅使用发卡机构或策略 OID 创建规则
我们正在努力修复此问题。
若要按颁发者和序列号创建规则,请执行以下操作:
添加身份验证绑定策略,要求使用 policyOID 为 1.2.3.4.6 且由 CN=CBATestRootProd 颁发的任何证书(即使用颁发者和序列号)。
选择证书字段。 在此示例中,我们将选择“颁发者和序列号”。
唯一支持的用户属性是 CertificateUserIds。 选择 添加 。
选择“保存”。
登录日志会显示使用了哪个绑定以及证书中的详细信息。
- 选择“确定”以保存任何自定义规则。
重要
通过使用对象标识符格式来输入 PolicyOID。 例如,如果证书策略显示“所有颁发策略”,则在添加规则时输入 OID 2.5.29.32.0。 字符串“所有颁发策略”对于规则编辑器无效,并且不会生效。
步骤 4:配置用户名绑定策略
用户名绑定策略有助于验证用户的证书。 默认情况下,我们将证书中的主体名称映射到用户对象中的 UserPrincipalName 以确定用户。
身份验证策略管理员可以替代默认值并创建自定义映射。 若要确定如何配置用户名绑定,请参阅用户名绑定的工作原理。
有关使用 CertificateUserIds 属性的应用场景的详细信息,请参阅证书用户 ID。
重要
如果用户名绑定策略使用已同步的属性,例如用户对象的 certificateUserIds、onPremisesUserPrincipalName 和 userPrincipalName 属性,请注意,在 Active Directory 中具有管理权限的帐户(例如在用户对象上具有委托权限的帐户或在 Microsoft Entra Connect Server 上具有管理权限的用户)可以进行更改,从而影响 Microsoft Entra ID 中的这些属性。
选择要与某个用户属性绑定的一个 X.509 证书字段,以创建用户名绑定。 用户名绑定顺序表示绑定的优先级。 第一个为最高优先级,以此类推。
如果可以在证书上找到指定的 X.509 证书字段,但 Microsoft Entra ID 找不到使用该值的用户对象,则身份验证将失败。 Microsoft Entra ID 会尝试列表中的下一个绑定。
选择“保存”,保存更改。
最终配置将如此图所示:
步骤 5:测试配置
本部分介绍如何测试证书和自定义身份验证绑定规则。
测试证书
作为第一个配置测试,应尝试使用设备浏览器登录到 MyApps 门户。
输入用户主体名称 (UPN)。
选择下一步。
如果启用了其他身份验证方法(例如手机登录或 FIDO2),用户可能会看到不同的登录屏幕。
选择“使用证书登录”。
在客户端证书选取器用户界面中选择正确的用户证书,然后选择“确定”。
用户应会登录到 MyApps 门户。
如果登录成功,则可确定:
- 已向测试设备预配用户证书。
- 已使用受信任 CA 正确配置 Microsoft Entra ID。
- 正确配置用户名绑定,并且已找到用户并对其进行身份验证。
测试自定义身份验证绑定规则
让我们学习一个验证强身份验证的方案。 我们将创建两个身份验证策略规则,一个规则使用颁发者主题来满足单重身份验证条件,另一个规则使用策略 OID 来满足多重身份验证条件。
创建颁发者主题规则,并将保护级别设置为单重身份验证,将值设置为“CA 主题”值。 例如:
CN = WoodgroveCA
创建策略 OID 规则,并将保护级别设置为多重身份验证,将值设置为证书中的某个策略 OID。 例如,1.2.3.4。
按照条件访问 - 需要 MFA 中的步骤创建条件访问策略,以便用户请求进行多重身份验证。
导航到 MyApps 门户。 输入 UPN 并选择“下一步”。
选择“使用证书登录”。
如果启用了其他身份验证方法(例如手机登录或安全密钥),用户可能会看到不同的登录屏幕。
选择客户端证书,然后选择“证书信息”。
证书将显示,你也可以验证颁发者和策略 OID 值。
若要查看策略 OID 值,请选择“详细信息”。
选择客户端证书,然后选择“确定”。
证书中的策略 OID 与所配置的值 1.2.3.4 相匹配,因此其满足多重身份验证条件。 同样,证书中的颁发者与所配置的值 CN=WoodgroveCA 相匹配,因此其满足单因素身份验证条件。
由于策略 OID 规则优先于颁发者规则,因此该证书满足多重身份验证条件。
用户的条件访问策略需要 MFA,并且证书满足多重身份验证条件,因此用户可以登录到应用程序。
测试用户名绑定策略
用户名绑定策略有助于验证用户的证书。 用户名绑定策略支持三个绑定:
- IssuerAndSerialNumber > CertificateUserIds
- IssuerAndSubject > CertificateUserIds
- Subject > CertificateUserIds
默认情况下,Microsoft Entra ID 将证书中的主体名称映射到用户对象中的 UserPrincipalName 以确定用户。 身份验证策略管理员可以替代默认值并创建自定义映射,如前面的步骤 4 中所述。
在启用新绑定之前,身份验证策略管理员必须确保在相应用户名绑定的用户对象属性 Certificate UserIds 中更新绑定的正确值。
- 对于仅限云的用户,请使用 Microsoft Entra 管理中心或 Microsoft Graph API 更新 CertificateUserIds 中的值。
- 对于本地同步的用户,请使用 Microsoft Entra Connect 按照 Microsoft Entra Connect 规则或同步 AltSecId 值中所述从本地同步值。
重要
Issuer、Subject 和 SerialNumber 值的格式应采用证书中格式的相反顺序。 请勿在 Issuer 或 Subject 值中添加空格。
颁发者和序列号手动映射
下面是颁发者和序列号手动映射的示例。 要添加的 Issuer 值为:
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 中要添加的 SerialNumber 值为:
b24134139f069b49997212a86ba0ef48
CertificateUserId:
X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48
颁发者和使用者手动映射
下面是颁发者和使用者手动映射的示例。 Issuer 值为:
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 值为:
CertificateUserId:
X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession
测试相关性绑定
至少以身份验证策略管理员的身份登录到 Microsoft Entra 管理中心。
浏览至 “保护”>“身份验证方法”>“策略”。
在“管理”下,选择“身份验证方法”>“基于证书的身份验证”。
选择“配置” 。
在租户级别设置所需的相关性绑定。
重要
请谨慎使用租户范围的相关性设置。 如果更改租户所需的相关性绑定,并且用户对象中没有适当的值,则可以锁定整个租户。 同样,如果创建一个应用于所有用户并且需要高相关性绑定的自定义规则,则可以锁定租户中的用户。
若要进行测试,请为“所需的相关性绑定”选择“低”。
添加类似于 SKI 的高相关性绑定。 在“用户名绑定”下选择“添加规则”。
选择“SKI”,然后选择“添加”。
完成后,规则如以下屏幕截图所示:
更新所有用户对象的 CertificateUserIds 属性,以从用户证书获取正确的 SKI 值。 有关详细信息,请参阅 certificateUserID 支持的模式。
为身份验证绑定创建自定义规则。
选择 添加 。
完成后,规则如以下屏幕截图所示:
使用策略 OID 9.8.7.5 从证书中更新具有正确 SKI 值的用户 CertificateUserId。
使用策略 OID 9.8.7.5 的证书进行测试,用户应使用 SKI 绑定进行身份验证,并仅使用证书获取 MFA。
使用 Microsoft Graph API 启用 CBA
若要使用 Graph API 启用 CBA 并配置用户名绑定,请完成以下步骤。
选择“登录到 Graph Explorer”,并登录到租户。
获取所有身份验证方法:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
获取 x509 证书身份验证方法的相关配置:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
默认情况下,x509 证书身份验证方法处于禁用状态。 要允许用户使用证书登录,必须启用身份验证方法,并通过更新操作配置身份验证和用户名绑定策略。 要更新策略,请运行 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 Power Shell 启用 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"