使用 Microsoft Entra 应用程序代理排查 Kerberos 约束委派 (KCD) 配置问题
单一登录方法因应用程序而异。 默认情况下，Microsoft Entra 应用程序代理提供 Kerberos 约束委派 (KCD)。 用户会使用 Kerberos 向专用应用程序进行身份验证。
本文提供了一个参考点，用于对最常见问题进行故障排除。 此外，本文还介绍如何诊断更复杂的实现问题。
本文作出以下假设。
- 部署 Microsoft Entra 应用程序代理和对非 KCD 应用程序的常规访问。 有关详细信息，请参阅应用程序代理入门。
- 发布的目标应用程序基于 Internet Information Services (IIS) 和 Kerberos 的 Microsoft 实现。
- 服务器和应用程序主机驻留在单个 Microsoft Entra 域中。 有关跨域和林方案的详细信息，请参阅 KCD 白皮书。
- 应用程序将在启用了预身份验证的 Microsoft Entra ID 租户中发布。 用户应使用基于窗体的身份验证进行身份验证。 本文不介绍丰富的客户端身份验证方案。
先决条件
造成大多数问题的原因可能是简单的配置错误或常规错误。 在进行故障排除之前，请先检查结合使用 KCD 单一登录和应用程序代理中的所有先决条件。
连接器主机不限于仅与特定的本地站点域控制器 (DC) 进行通信。 检查正在使用的 DC，因为它可能会发生更改。
跨域方案依赖于将连接器主机定向至 DC 的引荐，而这些 DC 可能不在本地网络外围内。 在这些情况下，将流量发送到表示其他各个域的 DC 同样重要。 如果未发送，则委派失败。
避免连接器主机和 DC 之间的活动入侵防护系统 (IPS) 或入侵检测系统 (IDS) 设备。 这些设备侵入性太强，会干扰核心远程过程调用 (RPC) 流量。
用简单方案测试委派。 引入的变量越多，可能需要应对的变量也越多。 为节省时间，将测试限制为在单个连接器中进行。 解决问题后，可添加更多连接器。
某些环境因素也可能导致问题。 若要避免这些因素，在测试期间尽可能最小化体系结构。 例如，内部防火墙访问控制列表 (ACL) 配置错误是很常见的。 如果可能，将所有流量从连接器直接发送到 DC 和后端应用程序。
放置连接器的绝对最佳位置应尽可能靠近目标。 测试时内联的防火墙会增加不必要的复杂性，并且会延长调查时间。
什么显示 KCD 问题？ 通过几个常见迹象可以判断 KCD 单一登录失败。 浏览器中显示问题的第一个迹象。
这两个图像都显示了相同的症状：单一登录失败。 拒绝用户访问应用程序。
疑难解答
请将故障排除分为三个阶段。
客户端预身份验证
外部用户通过浏览器进行身份验证。 要使 KCD 单一登录 (SSO) 正常运行，必须能够预先向 Microsoft Entra ID 进行身份验证。 测试此功能，如果存在任何问题，请解决问题。 预身份验证阶段与 KCD 或发布的应用程序无关。 通过检查 Microsoft Entra ID 中存在的使用者帐户可以轻松更正任何差异。 检查是否未禁用或未阻止应用程序。 浏览器中的错误响应提供了足够的描述，可解释原因。
委派服务
从 Kerberos 密钥发行中心 (KCD) 为用户获取 Kerberos 服务票证的专用网络连接器。
客户端和 Azure 前端之间的外部通信与 KCD 无任何关系。 这些通信仅确保 KCD 运行。 已向应用程序代理服务提供用于获取 Kerberos 票证的有效用户 ID。 如果没有此 ID，KCD 无法运行且发生故障。
浏览器错误消息可提供一些有关操作失败原因的良好线索。 记录响应中的 activity ID 和 timestamp 字段。 此信息有助于将行为与应用程序代理事件日志中的实际事件相关联。
在事件日志中看到的相应条目显示为事件 13019 或 12027。 在“应用程序和服务日志”>“Microsoft”>“Microsoft Entra 专用网络”>“连接器”>“管理员”中找到连接器事件日志。
- 将内部域名系统 (DNS) 中的 A 记录（而非
CName）用于应用程序地址。 - 再次确认连接器主机是否有权委托给指定目标帐户的服务主体名称 (SPN)。 再次确认已选择“使用任意身份验证协议”。 有关详细信息，请参阅 SSO 配置文章。
- 验证 Microsoft Entra 中是否只存在一个 SPN 实例。 在任何域成员主机上的命令提示符处发出
setspn -x。 - 检查是否强制执行了限制颁发的 Kerberos 令牌的最大大小的域策略。 如果令牌过多，此策略将阻止连接器获取令牌。
为了获取更多关于这些问题的低级别详细信息，下一步是使用网络跟踪捕获连接器主机和域 Kerberos 约束委托 (KDC) 之间的交换内容。 有关详细信息，请参阅深入进行故障排除白皮书。
如果票证看起来正常，则可在日志中看到一个事件，声明身份验证因应用程序返回 401 而失败。 此事件表示目标应用程序已拒绝票证。 转到下一阶段。
目标应用程序
连接器提供的 Kerberos 票证的使用者。 在此阶段，连接器应已将 Kerberos 服务票证发送到后端。 该票证是第一个应用程序请求中的标头。
通过使用门户中定义的应用程序内部 URL，验证该应用程序可从连接器主机上的浏览器直接访问。 然后就可以成功登录。 有关详细信息可在连接器“故障排除”页上找到。
确认浏览器和应用程序之间的身份验证是否使用 Kerberos。
在 Internet Explorer 中运行开发人员工具（“F12”），或从连接器主机上使用 Fiddler。 使用内部 URL 转到应用程序。 要确保存在协商或 Kerberos，请检查在应用程序的响应中返回的所提供的 Web 授权标头。
在从浏览器到应用程序的响应中返回的下一个 Kerberos Blob 以“YII”开头。 这些字母表示 Kerberos 正在运行。 另一方面，Microsoft NT LAN 管理器 (NTLM) 总是以“TlRMTVNTUAAB”开头，通过 Base64 解码后读作 NTLM 安全支持提供程序 (NTLMSSP)。 如果在 Blob 的开头看到“TlRMTVNTUAAB”，则该 Kerberos 不可用。 如果未看到“TlRMTVNTUAAB”，则 Kerberos 有可能可用。
注意
如果使用 Fiddler，则此方法需要暂时禁用针对 IIS 中的应用程序配置的扩展保护。
此图中的 Blob 不以“TIRMTVNTUAAB”开头。 因此，在此示例中，Kerberos 可用，并且 Kerberos Blob 不以“YII”开头。
将 NTLM 暂时从 IIS 站点上的提供程序列表中删除。 直接从连接器主机上的 Internet Explorer 访问应用。 NTLM 不再存在于提供程序列表中。 只可通过使用 Kerberos 来访问应用程序。 如果访问失败，则应用程序的配置可能出现了问题。 Kerberos 身份验证运行不正常。
如果 Kerberos 不可用，请检查 IIS 中应用程序的身份验证设置。 确保“Negotiate”列在顶部，NTLM 在其下方。 如果看到“Not Negotiate”、“Kerberos 或 Negotiate”或“PKU2U”，只要 Kerberos 正常运行，则继续操作。
设置 Kerberos 和 NTLM 后，暂时在门户中禁用应用程序的预身份验证。 尝试使用外部 URL 从 Internet 访问它。 系统将提示进行身份验证。 可以通过上一步中使用的同一帐户完成此操作。 如果不能，则后端应用程序而非 KCD 出现了问题。
在门户中重新启用预身份验证。 尝试通过外部 URL 连接到应用程序，以通过 Azure 进行身份验证。 如果 SSO 失败，则将在浏览器中看到禁止的错误消息，并在日志中看到事件 13022：
Microsoft Entra 专用网络连接器无法对用户进行身份验证，因为后端服务器对 Kerberos 身份验证尝试的响应为 HTTP 401 错误。
检查 IIS 应用程序。 请确保已配置的应用程序池和 SPN 配置为在 Microsoft Entra ID 中使用相同的帐户。 在 IIS 中导航，如下图所示。
了解标识后，确保使用上述 SPN 配置此帐户。 示例为
setspn –q http/spn.wacketywack.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 支持可提供帮助。 在门户内直接创建支持票证。
其他方案
在将请求发送至应用程序前，Microsoft Entra 应用程序代理将请求 Kerberos 票证。 一些应用程序不喜欢使用此身份验证方法。 这些应用程序希望进行更多常规协商。 首个请求为匿名请求，允许应用程序响应通过 401 支持的身份验证类型。 可使用本文档中概述的步骤启用此类型的 Kerberos 协商：用于单一登录的 Kerberos 约束委托。
多跃点身份验证通常用于分层应用程序的情况。 这些层包括后端和前端。 这两个层都需要进行身份验证。 例如，SQL Server Reporting Services。 有关详细信息，请参阅如何为 Web 注册代理页配置 Kerberos 约束委托。