抗钓鱼身份验证保护：在 Entra ID 中实施证书身份验证的分步指南

证书身份验证 (CBA) 相比传统密码登录或常规 TOTP/OTP MFA 有显著提升，可为 Microsoft Entra ID（原 Azure AD）提供抗钓鱼、无密码访问，并帮助保护关键资产和服务。本指南参考 Microsoft 官方文档和行业实践，介绍如何为最终用户及应用程序 (service principals) 实施 CBA。

注意：原文示例展示了如何针对近期 Handala 威胁行为者关联的“Stryker”事件，为 Intune Admin Group 启用抗钓鱼 CBA。

网络威胁日益复杂，仅依靠密码或 OTP/TOTP MFA 风险较高。Microsoft Entra ID 的 CBA 允许用户和应用使用 X.509 数字证书验证身份，从而降低钓鱼和凭据窃取风险。本指南涵盖两种主要用例：用户身份验证（例如员工登录 Microsoft 365）以及应用程序或自动化工具通过 service principals 进行身份验证。

第一部分：为用户身份验证设置 CBA

此流程将您的 PKI 与 Microsoft Entra ID 建立信任关系，并配置证书与用户帐户之间的映射方式。

前提条件

• 已配置的 PKI：需要企业 PKI 为用户签发证书。
• 用户证书：证书必须在 Subject Alternative Name (SAN) 字段中包含 User Principal Name (UPN)，格式为 RFC822Name（电子邮件格式）或其他受支持标识符。
• 管理员访问权限：使用至少具有 Privileged Authentication Administrator 角色的帐户登录 Microsoft Entra admin center。
• Certificate Revocation Lists (CRL)：证书颁发机构 (CA) 必须在可从 Internet 访问的 URL 发布 CRL，以便 Microsoft Entra ID 检查证书是否已撤销。

步骤 1：配置证书颁发机构

Microsoft Entra ID 必须信任签发用户证书的 CA。您可以将 CA 证书上传到新的基于 PKI 的信任存储。

1. 在 Entra admin center 中，转到 Identity → Identity Secure Score → Public key infrastructure (PKI)。
2. 单击 + Create PKI，输入显示名称（例如“Contoso PKI”）并创建。
3. 选择该 PKI 容器，单击 + Add certificate authority，上传根 CA 或中间 CA 证书文件 (`.cer`)。
4. 指定该证书是否为 Root CA。
5. 输入可从 Internet 访问的 Certificate Revocation List (CRL) URL，以及可选的 Delta CRL URL。
6. 确认 Issuer hints 已启用（默认值），以筛选向用户显示的证书。
7. 单击 Save，并对证书链中的所有 CA 重复上述步骤。

注意：大型 PKI 部署可使用 Upload PKI 一次上传包含所有 CA 证书的 `.p7b` 文件。

步骤 2：在租户中启用和配置 CBA

信任 CA 后，启用 CBA 身份验证方法，并定义证书与用户帐户的映射方式。

1. 转到 Protection → Authentication methods → Certificate-based authentication。
2. 在 Enable and target 选项卡中启用策略，并选择允许使用 CBA 的用户或组（例如“Intune Admin Group”或“All Users”）。
3. 配置 Username binding (Mapping)，将证书字段映射到 Entra ID 用户属性。Microsoft 建议采用基于唯一且不可复用证书属性的高亲和度绑定。
4. 打开 Configuration 选项卡。在 Username binding 下单击 Add rule。
5. 对于高亲和度绑定，选择 IssuerAndSerialNumber 或 SHA1PublicKey，并映射到 CertificateUserIds 等用户属性。需在对应 Entra ID 用户对象上填入证书相关值。
6. 对于较低亲和度配置，可将证书中的 PrincipalName 或 RFC822Name (SAN) 映射到 Entra ID 的 userPrincipalName 属性。
7. 在同一 Configuration 选项卡的 Authentication binding 下，设置证书身份验证被视为单因素还是多因素身份验证。例如，可将密钥强度高于某个阈值（如 2048 位 RSA）的证书视为多因素身份验证 (MFA)。
8. 检查配置并单击 Save。

步骤 3：通过 Conditional Access 强制执行 CBA（可选，建议）

若要真正减少对密码的依赖，可创建 Conditional Access 策略，要求特定应用使用 CBA。

1. 转到 Protection → Conditional Access → Policies，单击 + New policy。
2. 在 Assignments 中选择适用的用户或组，以及要保护的云应用，例如 Office 365。
3. 在 Access controls → Grant 中选择 Require multi-factor authentication（CBA 可满足此要求）和/或 Require authentication strength。也可创建专门要求 CBA 的自定义身份验证强度。
4. 将 Enable policy 设置为 On，然后单击 Create。

完成这些步骤后，设备上安装有效且受信任证书的用户（例如在 Windows 证书存储中）即可无密码登录 Microsoft 365，或满足 MFA 要求。

第二部分：为应用程序设置 CBA (service principals)

自动化脚本和应用程序通常需要向 Azure 验证身份。使用证书比存储密码更安全。

步骤 1：准备证书

可以创建自签名测试证书，或使用 PKI 签发的现有证书。证书必须包含私钥，并采用受支持格式（`.pem`；公钥可使用 `.cer`）。

• 可使用 Azure CLI 或 OpenSSL 创建测试用自签名证书。
• 使用现有证书时，请准备好公钥文件 (`.cer`)。
• 要将 PKCS#12 (`.pfx`) 文件转换为所需 PEM 格式，可使用 OpenSSL：

openssl pkcs12 -in yourcert.pfx -clcerts -nodes -out cert.pem -passin pass:

步骤 2：使用证书创建 service principal

可通过 Azure CLI 创建 service principal 并上传证书。登录 Azure CLI 后，运行以下命令之一。

创建自签名证书和 service principal：

az ad sp create-for-rbac --name MyAppWithCert --create-cert --years 2

该命令会输出 `appId` 和包含证书及私钥的 `.pem` 文件位置。

使用现有公钥证书 (`.cer` 或 `.pem`)：

az ad sp create-for-rbac --name MyAppWithCert --cert @/path/to/publiccertificate.cer

重要：使用现有证书时，只将公钥（`.cer` 文件）上传到 Azure AD。私钥必须保存在本地安全位置或 Azure Key Vault 等安全存储中。

记下 `appId`（client ID）和 `tenantId`，后续身份验证会用到。

步骤 3：使用证书进行身份验证

应用程序可使用证书私钥进行身份验证。例如，使用 service principal 登录 Azure CLI：

az login --service-principal --username APP_ID --password /path/to/cert-with-privatekey.pem --tenant TENANT_ID

也可以在 PowerShell 或 MSAL (Microsoft Authentication Library) 等程序库中使用证书。应用程序必须能够访问私钥以创建签名身份验证断言。

结论

在 Microsoft Entra ID 中实施 CBA 有助于显著增强组织安全状况。减少用户和应用程序对密码的依赖，并补充或替代传统 TOTP/OTP MFA，可迈向抗钓鱼、无密码的身份验证。无论用于访问 Microsoft 365 的员工，还是自动化 DevOps 脚本，这些步骤都能帮助建立更安全、易管理的身份环境。