通过

配置 AD FS 以支持用户证书身份验证

本文介绍如何在 Active Directory 联合身份验证服务 (AD FS) 中启用用户证书身份验证。 本文还提供了有关此类身份验证的常见问题的故障排除信息。

用户证书身份验证有两个主要用例：

  • 用户使用智能卡登录其 AD FS 系统。
  • 用户使用预配到移动设备的证书。

先决条件

  • 使用 AD FS 对证书身份验证的备用主机名绑定的支持中所述的模式之一，确定要启用的 AD FS 用户证书身份验证模式。
  • 确保已安装用户证书信任链，并且所有 AD FS 和 Web 应用程序代理 (WAP) 服务器（包括任何中间证书颁发机构）都信任该证书链。 通常通过 AD FS 和 WAP 服务器上的组策略对象 (GPO) 执行此操作。
  • 确保用户证书信任链的根证书位于 Active Directory 的 NTAuth 存储中。
  • 如果在备用证书身份验证模式下使用 AD FS，请确保 AD FS 和 WAP 服务器具有安全套接字层 (SSL) 证书，这些证书包含前缀为“certauth”的 AD FS 主机名。例如 certauth.fs.contoso.com。 此外，请确保允许流向此主机名的流量通过防火墙。
  • 如果使用来自 Extranet 的证书身份验证，请确保证书中指定的列表中至少有一个机构信息访问 (AIA) 和至少一个 CRL 分发点 (CDP) 或联机证书状态协议 (OCSP) 位置可从 Internet 访问。
  • 如果要为 Microsoft Entra 证书身份验证配置 AD FS，请确保已配置证书颁发者和序列号所需的 Microsoft Entra 设置 和 AD FS 声明规则。
  • 如果正在为 Exchange ActiveSync 客户端使用 Microsoft Entra 证书身份验证，则客户端证书的“使用者可选名称”字段的主体名称或 RFC822 名称值必须为 Exchange Online 中用户的可路由电子邮件地址。 Microsoft Entra ID 会将 RFC822 值映射到目录中的“代理地址”属性。

注意

对于基于智能卡或证书的身份验证，AD FS 不支持用户名提示。

启用用户证书身份验证

使用 AD FS 管理控制台或 PowerShell cmdlet Set-AdfsGlobalAuthenticationPolicy，在 AD FS 中启用用户证书身份验证作为 Intranet 或 Extranet 身份验证方法。

可选注意事项包括：

  • 如果除了 EKU 声明类型 https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 之外，还想使用基于证书字段和扩展的声明，请在 Active Directory 声明提供程序信任上配置更多声明传递规则。 请参阅本文后面的可用证书声明的完整列表。

  • 如果需要根据证书类型限制访问，可以在应用程序的 AD FS 颁发授权规则中使用证书上的其他属性。 常见方案是仅允许移动设备管理 (MDM) 提供程序预配的证书，或仅允许智能卡证书。

    重要

    使用设备代码流进行身份验证并使用 Microsoft Entra ID 以外的标识提供程序（例如 AD FS）执行设备身份验证的客户无法对 Microsoft Entra 资源强制实施基于设备的访问。 例如，他们无法通过使用第三方 MDM 服务仅允许托管设备。

    若要帮助保护对 Microsoft Entra ID 中公司资源的访问并防止任何数据泄露，请配置基于 Microsoft Entra 设备的条件访问。 例如，使用“要求将设备标记为投诉”以在 Microsoft Entra 条件访问中授予控制权。

    按照 Schannel SSP 技术概述中“管理受信任的颁发者以进行客户端身份验证”下的指南，为客户端证书配置允许的证书颁发机构。

  • 考虑修改登录页面以满足用户在进行证书身份验证时的需求。 一种常见情况是将“使用 X509 证书登录”更改为更便于用户使用的方法。

为 Windows 桌面版 Chrome 浏览器配置无缝证书身份验证

如果计算机上有多个用户证书（例如 Wi-Fi 证书）可满足客户端身份验证目的，则 Windows 桌面版 Chrome 浏览器会提示用户选择合适的证书。 此提示可能会让用户感到困惑。 为了优化此体验，可以设置一个策略，让 Chrome 自动选择合适的证书。

可以通过更改注册表手动设置此策略，也可以通过 GPO 自动配置它（以设置注册表项）。 这要求针对 AD FS 进行身份验证的用户客户端证书具有与其他用例不同的颁发者。

有关为 Chrome 配置证书身份验证的详细信息，请参阅 Chrome Enterprise 策略列表。

排查证书身份验证问题

在为用户配置 AD FS 进行证书身份验证时，请使用以下信息排查常见问题。

检查是否在所有 AD FS 和 WAP 服务器中正确配置了信任的证书颁发者

如果未正确配置信任的证书颁发者，一个常见症状是 HTTP 204 错误：“没有来自 https://certauth.adfs.contoso.com." 的内容。”

AD FS 使用基础 Windows 操作系统来证明用户证书的所有权，并通过验证证书信任链来确保它与受信任的颁发者匹配。 若要匹配受信任的颁发者，需要确保在计算机证书颁发机构的本地存储中将所有根和中间颁发机构配置为受信任的颁发者。

若要自动验证这一点，请使用 AD FS 诊断分析器工具。 该工具查询所有服务器，并确保正确预配合适的证书。

  1. 下载并运行工具。
  2. 上传结果并查看是否有任何失败。

检查是否在 AD FS 身份验证策略中启用了证书身份验证

默认情况下，AD FS 在端口 49443 上执行用户证书身份验证，所用主机名与 AD FS 相同（例如 adfs.contoso.com）。 还可以使用备用 SSL 绑定将 AD FS 配置为使用端口 443（默认 HTTPS 端口）。 但是，此配置中使用的 URL 是 certauth.<adfs-farm-name>（例如 certauth.contoso.com）。 有关详细信息，请参阅 AD FS 对证书身份验证的备用主机名绑定的支持。

注意

在 Windows Server 2016 上的 AD FS 中，现在支持两种模式。 第一种模式使用主机 adfs.contoso.com 以及端口 443 和 49443。 第二种模式使用主机 adfs.contoso.com 和 certauth.adfs.contoso.com 以及端口 443。 需要 SSL 证书才能支持 certauth.\<adfs-service-name> 作为备用使用者名称。 可以在创建场时执行此操作或稍后通过 PowerShell 执行。

网络连接问题最常见的情况是防火墙配置不正确，阻止进行用户证书身份验证的流量。 出现此问题时，通常会看到空白屏幕或 500 服务器错误。 要修复此问题，请执行以下操作：

  1. 记下在 AD FS 中配置的主机名和端口。
  2. 确保 AD FS 或 WAP 前面的任何防火墙都配置为允许 AD FS 场的 hostname:port 组合。 网络工程师必须执行此步骤。

检查 CRL 连接

证书吊销列表 (CRL) 是编码到用户证书中的终结点，用于执行运行时吊销检查。 例如，如果包含证书的设备被盗，管理员可以将该证书添加到吊销的证书列表中。 之前接受此证书的任何终结点现在都会使相关身份验证失败。

每个 AD FS 和 WAP 服务器都需要访问 CRL 终结点，以验证提供给它的证书是否仍然有效且尚未吊销。 CRL 验证可以通过 HTTPS、HTTP、LDAP 或 OCSP 进行。 如果 AD FS 和 WAP 服务器无法访问终结点，身份验证将失败。 使用以下步骤进行故障排除：

  1. 咨询公钥基础结构 (PKI) 工程师，以确定哪些 CRL 终结点用于从 PKI 系统吊销用户证书。
  2. 在每个 AD FS 和 WAP 服务器上，确保可以通过使用的协议（通常是 HTTPS 或 HTTP）访问 CRL 端点。
  3. 对于高级验证，请在每台 AD FS 和 WAP 服务器上启用 CAPI2 事件日志记录。
  4. 检查 CAPI2 操作日志中的事件 ID 41（验证吊销）。
  5. 检查 <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>。

提示

可以通过配置指向特定服务器的 DNS 解析（Windows 上的主机文件），将单个 AD FS 或 WAP 服务器作为目标，以便更轻松地进行故障排除。 使用此方法，可通过以服务器为目标来启用跟踪。

检查 SNI 问题

AD FS 要求客户端设备（或浏览器）和负载均衡器支持服务器名称指示 (SNI)。 某些客户端设备（例如较旧版本的 Android）可能不支持 SNI。 此外，负载均衡器可能不支持 SNI，或者可能未针对 SNI 进行配置。 在这些情况下，用户认证可能会失败。

若要解决此问题，请与网络工程师协作，确保 AD FS 和 WAP 的负载均衡器支持 SNI。 如果 SNI 不受支持，请在 AD FS 中使用以下解决方法：

  1. 在主 AD FS 服务器上打开提升的命令提示符窗口。
  2. 输入 Netsh http show sslcert。
  3. 复制联合身份验证服务的应用程序 GUID 和证书哈希。
  4. 输入 netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}。

检查客户端设备是否已正确预配证书

你可能会注意到，某些设备工作正常，但其他设备却没有。 在大多数情况下，这意味着某些客户端设备上未正确预配用户证书。 执行以下步骤:

  1. 如果问题特定于 Android 设备，则最常见的原因是证书链在设备上不完全受信任。 请咨询 MDM 供应商，确保已正确预配证书，并且整个链在 Android 设备上完全受信任。

    如果问题特定于 Windows 设备，则通过检查登录用户（而不是系统或计算机）的 Windows 证书存储来检查是否正确预配了证书。

  2. 将客户端用户证书导出为 .cer 文件并运行命令 certutil -f -urlfetch -verify certificatefilename.cer。

检查 AD FS/WAP 服务器和客户端设备之间的 TLS 版本是否兼容

在极少数情况下，客户端设备会更新为仅支持较高版本的 TLS（例如 1.3）。 或者可能遇到相反的问题，即 AD FS 和 WAP 服务器已更新为仅使用较高版本的 TLS，而客户端设备不支持该版本。

可以使用联机 SSL 工具来检查 AD FS 和 WAP 服务器，并查看它们是否与设备兼容。 有关如何控制 TLS 版本的详细信息，请参阅管理 AD FS 的 SSL/TLS 协议和密码套件。

检查是否已在联合域设置上正确配置 Microsoft Entra PromptLoginBehavior

许多 Office 365 应用程序将 prompt=login 发送到 Microsoft Entra ID。 Microsoft Entra ID 默认将其转换为 AD FS 的新密码登录。 因此，即使在 AD FS 中配置了证书身份验证，用户也只能看到密码登录。 若要修复此问题：

  1. 使用 Get-MgDomainFederationConfiguration cmdlet 获取联合域设置。
  2. 确保 PromptLoginBehavior 参数设置为 Disabled 或 NativeSupport。

有关详细信息，请参阅 AD FS prompt=login 参数支持。

更多故障排除方法

在极少数情况下，如果 CRL 列表很长，尝试下载时可能会超时。 在这种情况下，需要更新 MaxFieldLength 和 MaxRequestByte，如用于 Windows 的 Http.sys 注册表设置中所述。

参考：用户证书声明类型和示例值的完整列表

声明类型 示例值
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4