排查 Kerberos 约束委派问题

单一登录（SSO）方法因应用程序而异。 默认情况下，Microsoft Entra 应用程序代理提供 Kerberos 约束委派（KCD）。 在应用程序代理中，用户使用 Kerberos 向专用应用程序进行身份验证。

本文介绍如何排查 KCD 配置中最常见的问题。 它包括可用于更复杂的实现的诊断步骤。

本文假设以下几点：

• Microsoft Entra 应用程序代理已部署，并且对非 KCD 应用程序具有常规访问权限。

  有关详细信息，请参阅 应用程序代理入门。

• 已发布的应用程序基于 Internet Information Services（IIS）和 Microsoft 的 Kerberos 实现。

• 服务器和应用程序主机位于单个Microsoft Entra 域中。

  有关跨域和域林方案的更多信息，请参阅白皮书《通过应用程序代理了解 Kerberos 约束委派》。

• 该应用程序在启用了预身份验证的 Microsoft Entra 租户中发布。 用户应使用基于表单的身份验证进行身份验证。

  本文未介绍丰富的客户端身份验证方案。

注意事项

以下列表描述了配置 KCD 以及与 Microsoft Entra 应用程序代理一起使用时的基本考量：

• 基本配置错误或常规错误会导致大多数问题。 在开始进行故障排除之前，请检查 将 KCD SSO 与应用程序代理配合使用中的所有先决条件。

• 连接器主机不仅限于只能与特定的本地站点域控制器（DC）通信。 检查您使用的数据中心，因为它可能会发生变化。

• 跨域方案依赖于将连接器主机定向到本地网络外围外部的 DC 的引荐。 在这些情况下，向表示其他相应域的 DC 发送流量同样重要。 如果你不这样做，委派会失败。

• 由于主动入侵防护系统（IPS）或入侵检测系统（IDS）设备可能会干扰核心远程过程调用（RPC）流量，因此应避免在连接器主机和域控制器（DC）之间使用这些设备。

• 在简单场景中测试委派。 在方案中引入的变量越多，配置和故障排除越复杂。 若要节省时间，请将测试限制为单个连接器。 在解决问题后添加更多连接器。

• 环境因素可能导致问题的原因。 为了避免这些因素，在测试期间尽可能尽量减少体系结构。 例如，配置错误的内部防火墙访问控制列表（ACL）很常见。 如果可能，请将来自连接器的所有流量直接发送到 DC 和后端应用程序。

• 定位连接器的最佳位置尽可能接近其目标。 测试连接器时内联的防火墙会增加不必要的复杂性，并延长调查时间。

• 什么表明存在 KCD 问题？ 几个常见错误表示 KCD SSO 失败。 问题的第一个迹象显示在浏览器中。

  以下两个屏幕截图都显示了 SSO 失败的相同症状：拒绝用户访问应用程序。

  

  

故障排除

可以在三个阶段对 KCD 问题进行故障排除。 按以下顺序检查 KCD 过程的以下部分：

• 客户端预身份验证
• 委派服务
• 目标应用程序

客户端预身份验证

客户端预身份验证 是指通过浏览器在应用程序中进行身份验证的外部用户。 KCD SSO 要正常工作，需要事先对 Microsoft Entra ID 进行身份验证。

首先测试客户端预身份验证，并解决任何问题。 预身份验证阶段与 KCD 或已发布的应用程序无关。 通过检查主题帐户是否存在于 Microsoft Entra ID 中，可以轻松更正任何差异。 检查应用程序是否不可用或被阻止。 浏览器中的错误响应通常具有足够的描述性来解释原因。

委派服务

Kerberos 委派服务是专用网络连接器，它从 Kerberos 密钥分发中心（KDC）获取 Kerberos 服务票证。 应用用户通过票证向应用程序进行身份验证。

客户端与 Azure 前端之间的外部通信对约束委派没有影响。 这些通信仅确保 KCD 正常工作。 应用程序代理服务提供一个有效的用户 ID，用于获取 Kerberos 票证。 如果没有此 ID，则无法发生 KCD，SSO 失败。

浏览器错误消息提供有关登录失败的原因的有用信息。 记录应用程序登录的响应中 TransactionID 和 Timestamp 的值。 此信息有助于将行为与应用程序代理事件日志中显示的事件相关联。

事件日志中的相应条目是事件 ID 13019 或 12027。 若要查看连接器事件日志，请转到 应用程序和服务日志>Microsoft Microsoft>Entra 专用网络>连接器>管理员。

若要排查受约束委派问题，请执行以下步骤：

1. 在应用程序地址的内部域名系统（DNS）中，使用 A 记录，而不是 CNAME 记录。
2. 验证连接器主机是否已配置为有权委托给目标帐户的服务主体名称（SPN）。 验证是否选择了 “使用任何身份验证协议 ”。 有关详细信息，请参阅 SSO 配置。
3. 验证在 Microsoft Entra ID 中仅存在 SPN 的唯一一个实例。 若要验证单个 SPN，请在任何域成员主机上的命令提示符下运行 setspn -x。
4. 检查是否强制实施限制 已颁发 Kerberos 令牌的最大大小的 域策略。 如果令牌大小超过设置最大值，则策略会阻止连接器获取令牌。
5. 运行捕获连接器主机与域 KCD 之间的交换的网络跟踪是获取有关此问题的更多详细信息的下一步。 有关详细信息，可以查看关于排查 Microsoft Entra 应用程序代理问题的详细白皮书。

如果票务系统正常工作，日志可能会显示一个事件，指示身份验证失败，因为应用程序返回了401错误。 此事件指示目标应用程序拒绝了票证。 转到下一阶段的故障排除。

应用程序

目标应用程序处理连接器提供的 Kerberos 票证。 在此阶段，连接器在向后端发出的第一个应用程序请求中包含 Kerberos 服务票证作为标头。

若要排查应用程序问题，请按照以下步骤执行：

1. 确保应用程序可访问。 使用 Azure 门户中定义的内部 URL 直接从连接器主机上的浏览器登录。 如果登录成功，则应用程序可访问。

2. 检查浏览器和应用程序是否使用 Kerberos 进行身份验证。 在连接器主机上，通过内部 URL 使用 Internet Explorer 的 DevTools（按 F12）或 Fiddler 访问应用程序。 在应用程序的响应中查找 Web 授权标头中的“协商”或“Kerberos”。

   应用程序的浏览器响应包括一个以YII开头的 Kerberos blob，确认 Kerberos 正在运行。 相比之下，Microsoft NT LAN 管理器（NTLM）的响应始终以 TlRMTVNTUAAB 开始。 从 Base64 解码时，此响应显示为 NTLM 安全支持提供程序（NTLMSSP）。 如果 Blob 以 TlRMTVNTUAAB 开头，则 Kerberos 不可用。 否则，Kerberos 可能可用。

   注释

   如果使用 Fiddler，则必须在 IIS 中的应用程序配置上暂时禁用扩展保护。

   

   此屏幕截图中的 blob 不以 TIRMTVNTUAAB 开始。 因此，在此示例中，Kerberos 是可用的，并且 Kerberos blob 并未以 YII 开头。

3. 在 IIS 站点上，暂时从提供程序列表中删除 NTLM。 直接从连接器主机上的 Internet Explorer 访问应用。 NTLM 不再位于提供程序列表中，因此只能使用 Kerberos 访问应用程序。 如果访问失败，则指示应用程序配置出现问题。 应用程序未处理 Kerberos 身份验证。

4. 如果 Kerberos 不可用，请检查 IIS 中的应用程序的身份验证设置。 请确保 协商 列在顶部，并且 NTLM 紧接在其下面。 如果看到“未协商”、“Kerberos 或协商”或“PKU2U”，仅当 Kerberos 功能正常时才继续。

   

5. 在 Kerberos 和 NTLM 已就位的情况下，在门户中暂时禁用应用程序的预身份验证。 尝试使用外部 URL 在浏览器中访问应用程序。 系统会提示您进行身份验证。 使用在上一步中使用的同一帐户。 如果无法进行身份验证和登录，那么是后端应用程序出现了问题，而不是 KCD。

6. 在门户中重新启用预身份验证。 通过 Azure 进行身份验证，方法是尝试通过其外部 URL 连接到应用程序。 如果 SSO 失败，在浏览器中看到“禁止”错误消息，日志中的事件 ID 为 13022：

   Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

   

7. 检查 IIS 应用程序。 确保配置的应用程序池和 SPN 都在 Microsoft Entra ID 中使用相同的用户帐户。 在 IIS 中，转到文件夹，如以下屏幕截图所示：

   

   检查标识，并确保此帐户已配置 SPN。 例如，在命令提示符下，运行 setspn -q http/spn.contoso.com。

   

8. 请在门户中将已定义的 SPN 与应用程序设置进行核对。 确保应用程序的应用池使用为目标Microsoft Entra 帐户设置的相同 SPN。

9. 在 IIS 中，选择应用程序的 配置编辑器 选项。 转到 system.webServer/security/authentication/windowsAuthentication。 确保 UseAppPoolCredentials 的值为 True。

   

   根据需要将值更改为 True 。 运行以下命令，从后端服务器中删除所有缓存的 Kerberos 票证：

   Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
   

10. 如果启用了内核模式，Kerberos 作业能改进。 但是，请求的服务票证也必须使用计算机帐户进行解密。 此帐户也称为 本地系统。 将此值设置为 True ，以在服务器场中的多个服务器上托管应用程序时中断 KCD。

11. 作为另一个检查，请禁用扩展保护。 在某些测试方案中，扩展保护在特定配置中启用时会中断 KCD。 在这些情况下，应用程序作为默认网站的子文件夹发布。 此应用程序仅配置为匿名身份验证。 所有对话都处于非活动状态，没有可用的选择，这表明子对象不会继承任何活动设置。 建议您进行测试，但在可能的情况下，请不要忘记将此值恢复为启用。

    此额外检查使你能够跟踪使用已发布的应用程序。 可以生成更多配置为委托功能的连接器。 有关详细信息，请阅读更深入的技术演练《Microsoft Entra 应用程序代理疑难解答》。

如果仍无法解决应用程序身份验证问题，请直接在门户中创建支持票证。

其他情景

Microsoft Entra 应用程序代理在向应用程序发送请求之前请求 Kerberos 票证。 某些应用程序不支持此方法进行身份验证。 这些应用程序设置为响应更传统的身份验证步骤。 第一个请求是匿名的，它允许应用程序通过 401 错误响应它支持的身份验证类型。 可以通过完成 Kerberos 约束委派中针对 SSO 的步骤来设置这种类型的 Kerberos 协商。

在应用程序分层时，通常使用多层跳跃身份验证。 这些层包括后端和前端。 这两个层都需要身份验证。 例如，可以使用 SQL Server Reporting Services 创建分层应用程序。 有关详细信息，请参阅 如何为 Web 注册代理页配置 Kerberos 约束委派。

相关内容

• 在托管域上设置 KCD