排查 Kerberos 约束委派问题

2025-05-06

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

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

本文作出以下假设：

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

有关详细信息，请参阅应用程序代理入门。
已发布的应用程序基于 Internet Information Services（IIS）和 Kerberos 的Microsoft实现。
服务器和应用程序主机位于单个Microsoft Entra 域中。

有关跨域和森林场景的更多信息，请参阅白皮书理解应用程序代理与Kerberos约束委派。
该应用程序在启用了预身份验证的 Microsoft Entra 租户中发布。用户应使用基于表单的身份验证进行身份验证。

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

注意事项

以下列表介绍了 KCD 配置和使用时，需与 Microsoft Entra 应用程序代理一起考虑的基础注意事项：

基本配置错误或常规错误会导致大多数问题。在开始进行故障排除之前，请检查将 KCD SSO 与应用程序代理配合使用中的所有先决条件。
连接器主机不限于仅与特定的本地站点域控制器（DC）通信。检查使用的 DC，因为它可能会更改。
跨域方案依赖于将连接器主机定向到本地网络外围外部的 DC 的引荐。在这些情况下，向表示其他相应域的 DC 发送流量同样重要。如果你不这样做，委派会失败。
由于核心远程过程调用（RPC）流量受到干扰，在连接器主机和域控制器（DC）之间避免主动入侵防护系统（IPS）或入侵检测系统（IDS）设备。
在简单场景中测试委派。在方案中引入的变量越多，配置和故障排除越复杂。若要节省时间，请将测试限制为单个连接器。在解决问题后添加更多连接器。
环境因素可能导致问题的原因。为了避免这些因素，在测试期间尽可能尽量减少体系结构。例如，配置错误的内部防火墙访问控制列表（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 的值。此信息有助于将行为与应用程序代理事件日志中显示的事件相关联。

显示 Kerberos 约束委派配置错误消息的屏幕截图。

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

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

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

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

应用程序

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

若要排查应用程序问题，请执行以下操作。

确保应用程序可访问。使用 Azure 门户中定义的内部 URL 直接从连接器主机上的浏览器登录。如果登录成功，则应用程序可访问。
检查浏览器和应用程序是否使用 Kerberos 进行身份验证。在连接器主机中，使用 Internet Explorer 的开发者工具（按 F12）或 Fiddler 通过内部 URL 访问应用程序。在应用程序的响应中查找 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。
在 IIS 站点上，暂时从提供程序列表中删除 NTLM。直接从连接器主机上的 Internet Explorer 访问应用。 NTLM 不再位于提供程序列表中，因此只能使用 Kerberos 访问应用程序。如果访问失败，则指示应用程序配置出现问题。应用程序未处理 Kerberos 身份验证。
如果 Kerberos 不可用，请检查 IIS 中的应用程序的身份验证设置。请确保协商列在最上面，并且 NTLM 紧接在它的下面。如果看到Not Negotiate、Kerberos 或 Negotiate 或 PKU2U，则仅在 Kerberos 正常运行时才继续。
启用 Kerberos 和 NTLM 后，在门户中暂时停用应用程序的预身份验证功能。尝试使用外部 URL 在浏览器中访问应用程序。系统会提示你进行身份验证。使用在上一步中使用的同一帐户。如果无法进行身份验证和登录，那么问题出在后端应用程序，而不是 KCD。
在门户中重新启用预身份验证。通过 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.
检查 IIS 应用程序。确保配置的应用程序池和 SPN 都使用 Microsoft Entra ID 中的同一帐户。在 IIS 中，转到文件夹，如以下屏幕截图所示：

检查标识，并确保此帐户已配置 SPN。例如，在命令提示符下，运行 setspn –q http/spn.contoso.com。
在门户中，根据应用程序设置检查定义的 SPN。确保应用程序的应用池使用为目标Microsoft Entra 帐户设置的相同 SPN。
在 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))}
```
如果启用了内核模式，则 Kerberos 操作会得到改进。但是，请求的服务票证也必须使用计算机帐户进行解密。此帐户也称为 本地系统。将此值设置为 True ，以在服务器场中的多个服务器上托管应用程序时中断 KCD。
作为另一个检查，请禁用扩展保护。在某些测试方案中，扩展保护在特定配置中启用时会中断 KCD。在这些情况下，应用程序作为默认网站的子文件夹发布。此应用程序仅配置为匿名身份验证。所有对话都处于非活动状态，没有可用的选择，这表明子对象不会继承任何活动设置。建议您进行测试，但如果可能，别忘了将此值还原为启用。

此额外检查将帮助您使用已发布的应用程序。可以生成更多连接器，这些连接器同样配置为委托。有关详细信息，请阅读更深入的技术演练，排查Microsoft Entra 应用程序代理问题。

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

其他方案

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

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

在托管域上设置 KCD

通过