通过

为用户证书身份验证配置 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>。

提示

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

检查 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_applicationGUID}。

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

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

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

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

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

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

在极少数情况下，客户端设备会更新为仅支持更高版本的 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 列表很长，尝试下载时可能会超时。 在这种情况下，需要按照 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