Kerberos 身份验证故障排除指南

本指南提供在解决 Kerberos 身份验证问题时要遵循的基本概念。

重要

本文提供一般指南。 在这里介绍的过程和示例可能需要进行调整，以适应您的特定配置。

故障排除清单

Kerberos 协议依赖于多个基础结构组件和服务。 如果其中任一组件或服务不可用或无法正常工作，则可能会遇到身份验证问题。

1.检查事件和日志

检查事件日志中是否有问题的迹象。 使用事件查看器查看身份验证作所涉及的系统上的安全和系统日志：

• 身份验证客户端
• 目标服务器或服务
• 域控制器

尤其要注意查找与 Kerberos 身份验证或其依赖的服务相关的事件的来源，例如来自以下来源的事件：

• Kerberos
• 密钥分发中心 （KDC）
• LSA （LsaSrv）
• Netlogon

在目标服务器上，检查安全日志中是否存在故障审核。 此类失败可能表明在发生身份验证失败时使用 Kerberos 协议。

某些事件或错误表示特定问题。 如果任何受影响的计算机记录了以下任何事件或错误，请选择链接以获取更详细的故障排除信息。

事件或错误	故障排除信息
事件 ID 4，错误KERB_AP_ERR_MODIFIED	客户端无法解密服务票证。 由于多个问题可能会导致此错误，请检查相关事件。 例如，此字符串可能意味着客户端和目标服务器时钟不同步，或者 SPN 不唯一。 在多域环境中，服务帐户名称在森林中可能不唯一（或其他受信任的森林）。 有关详细信息，请参阅 Kerberos 客户端从服务器收到 KRB_AP_ERR_MODIFIED 错误 和 Kerberos 生成 KDC_ERR_S_PRINCIPAL_UNKNOWN 或 KDC_ERR_PRINCIPAL_NOT_UNIQUE 错误。
事件 ID 4，错误KERB_AP_ERR_SKEW	确保计算机时钟已同步
事件 ID 14	访问受信任域中的资源时出现“不支持的 etype”错误
事件 ID 16 或事件 ID 27	如果禁用 Kerberos 的 DES，则会记录 KDC 事件 ID 16 或 27 Windows Server 2003 域控制器上的事件 ID 27 KDC 错误
错误 1069	由于未正确设置 SPN，服务登录失败
事件 ID 5719、错误 1311 或错误 1355	事件 ID 5719、错误 1311 或错误 1355 - 找不到域控制器或域

如果验证了知道如何修复的问题，请先修复该问题，然后重试进行身份验证，然后再继续。

2.检查基础结构

a。 确保客户端应用和目标服务不在同一台计算机上

默认情况下，如果客户端应用和目标服务安装在一台计算机上，则禁用 Kerberos。 如果无法在单独的计算机上安装客户端应用程序和目标服务，则必须在 Windows 中更改与安全相关的特定设置。 此外，可能需要更改注册表项。 有关与此方案相关的问题以及影响此方案的特定设置的详细信息，请在 尝试在本地访问服务器时看到错误消息。

如果进行了任何更改，请在继续之前重试进行身份验证。

b. 检查客户端计算机、目标服务器和资源服务器是否已加入相应的域

如有必要，将客户端计算机或目标服务器加入适当的域。 然后，重试进行身份验证。

注意

在此上下文中，“适当的域”是单个林或具有信任关系的一组林中的域。

选项c. 检查目标服务器的运行状况及其支持服务

确保应用程序或前端服务（如 Web 服务）和后端服务（如 SQL Server 服务）正在运行。

注意

你可能会收到类似于“服务已生成错误 1069：服务因登录失败而未启动”的消息。如果收到此消息，请参阅 “服务登录失败，因为未正确设置 SPN”。

d。 确保正确的端口可用

检查客户端计算机、域控制器和目标服务器之间的所有防火墙（包括每台计算机上的 Windows 防火墙）。 确保以下端口上允许流量。

注意

此列表使用 server：client 端口，服务器端口 格式。

• DHCP： 67（UDP）、67（UDP）
• DNS： 49152 -65535（TCP、UDP）、53（TCP、UDP）
• HTTPS，包括基于证书的身份验证： 443（TCP）、443（TCP）
• Kerberos： 49152 -65535（TCP、UDP）、88（TCP、UDP）
• Kerberos 密码更改： 49152 -65535（TCP）、464（TCP、UDP）
• LDAP，包括 DC 定位符： 49152 -65535（TCP，UDP），389（TCP，UDP）
• LDAP SSL： 49152 -65535 （TCP）、636 （TCP）
• SMB： 49152 -65535（TCP、UDP）、445 （TCP）
• RPC 终结点映射器： 49152 -65535（TCP）、135 （TCP）
• RPC for LSA， SAM， NetLogon： 49152 -65535 （TCP）， 49152-65535 （TCP）
• W32Time： 49152 -65535（UDP），123（UDP）

如果更改了任何防火墙设置，请尝试再次进行身份验证。

e。 检查域控制器是否可用

当客户端尝试联系服务或应用程序（称为“目标服务器”），客户端和目标服务器都需要域控制器来促进身份验证、授权和委派。

在客户端计算机上，打开提升的命令提示符窗口，然后运行以下命令：

nltest /dsgetdc:<DomainName> /force /kdc

注意

在此命令中， <DomainName> 表示要从中查询的计算机的域的名称。

该 nltest 命令检索可用域控制器的列表（尽管该列表可能不包含所有可用的域控制器）。 记录这些域控制器的完全限定的域名和 IP 地址，以便在后续过程中使用。

如果客户端或目标服务器无法联系域控制器，则会收到类似于以下内容的消息（有时标记为“错误 1355”）：

指定的域不存在，或无法访问。

如果收到此消息，请参阅 事件 ID 5719、错误 1311 或错误 1355 - 找不到域控制器或域 以获取更多故障排除信息。 否则，请继续完成此清单。

f。 检查 DNS 是否在客户端和目标服务器之间工作

在客户端计算机上，打开管理命令提示符窗口，然后运行以下命令：

nslookup <TargetName>

注意

在此命令中， <TargetName> 表示目标服务器的 NetBIOS 名称。

nslookup如果命令正确解析目标服务器名称，则 DNS 配置正确。 如果命令不解析目标服务器名称，请按照以下步骤检查客户端计算机的网络适配器配置：

1. 在客户端计算机上运行以下命令：

   ipconfig /all
   

2. 在命令输出中，确定正在使用哪个网络适配器。 检查以下适配器设置：

   • 客户端 IP 地址

   • 子网掩码

   • 默认网关

   • 特定于连接的 DNS 后缀

   • DNS 服务器 IP 地址

     记录 IP 地址，并记下首选 DNS 服务器和辅助服务器。 此信息可用于以后的故障排除。

   如果其中任何设置不正确，请修复这些设置，或联系 DNS 管理员以获取帮助。 如果进行了任何更改，请再次运行 nslookup <TargetName> 。

如果 DNS 仍然无法正常工作，请执行以下步骤：

1. 在客户端计算机上运行以下命令：

   nslookup <ClientName> <DNSIPAddress>
   

   注意

   在此命令中，<ClientName> 表示客户端计算机的 NetBIOS 名称，DNSIPAddress <> 表示客户端配置为使用的 DNS 服务器的 IP 地址。 首先，使用在上一过程中记录的首选 DNS 服务器的 IP 地址。 如果命令不起作用，请使用客户端辅助 DNS 服务器的 IP 地址重试。

   例如，如果客户端计算机的名称为“client1”，并且客户端首选 DNS 服务器的 IP 地址为 10.0.0.1，请运行以下命令：

   nslookup client1 10.0.0.1
   

2. 从目标服务器运行相同的命令。 它现在类似于以下命令：

   nslookup <TargetName> <DNSIPAddress>
   

   注意

   在此命令中，<TargetName> 表示目标服务器的 NetBIOS 名称，DNSIPAddress <> 表示目标服务器配置为使用的 DNS 服务器的 IP 地址。 首先，使用在上一过程中记录的首选 DNS 服务器的 IP 地址。 如果命令在首次运行时不起作用，请使用目标服务器的辅助 DNS 服务器的 IP 地址重试。

   例如，如果目标服务器的名称为“WebServer1”，并且目标服务器的首选 DNS 服务器的 IP 地址为 10.0.0.1，请运行以下命令：

   nslookup WebServer1 10.0.0.1
   

   下表总结了查询的可能结果 nslookup 及其含义。

   	目标查询 继任	目标查询 失败
   客户端查询 成功	无 DNS 问题	影响目标或至少一个 DNS 服务器的问题
   客户端查询 失败	影响客户端或至少一个 DNS 服务器的问题	影响一个或多个 DNS 服务器的问题

如果查询结果指示 DNS 问题，请参阅以下文章以获取更多帮助：

• 排查域名系统（DNS）问题
• 排查 DNS 客户端问题
• 排查 DNS 服务器 问题

如果解决了 DNS 问题，但 Kerberos 问题仍然存在，请尝试以下故障排除方法。

g。 确保计算机时钟已同步

客户端计算机或目标服务器可以缓存票证以供将来使用。 但是，每个票证都有确定生存时间（TTL）的时间戳。 在域控制器上运行的 Kerberos 密钥分发中心服务设置时间戳。

域控制器与客户端计算机或目标服务器之间的时间差异必须小于 5 分钟。 通常，如果时钟未同步，Windows 可以自动重新同步它们。 有两种情况可能需要采取行动：

• 时钟不同步的时间超过 48 小时。
• 不同步时钟在其域中不使用域控制器作为时间服务器，也不使用与这些域控制器相同的时间服务器。

若要解决此问题，受影响的计算机必须重新检查时间服务器的网络，然后重新同步其自己的时钟。 若要启用这些作，请打开管理命令提示符窗口，然后运行以下命令：

w32tm /resync /computer:<Target> /rediscover

注意

在此命令中， <Target> 表示要配置的计算机。 该 /rediscover 选项指示计算机检查网络是否有新的或更新的时间源。

有关可用于 w32tm 命令的选项的详细信息，请参阅 Windows 时间服务工具和设置：W32Time 的命令行参数。

如果重新同步时钟，请尝试再次进行身份验证。

h. 检查 Windows 更新状态

确保所有域控制器、客户端计算机和目标服务器都具有相关的 Windows 更新。

如果安装了任何更新，请重启受影响的计算机，然后重试进行身份验证。

一. 检查应用程序更新状态

确保客户端和服务器应用程序在客户端计算机和目标服务器上是最新的。 如果安装任何更新，请重启受影响的计算机，然后重试进行身份验证。

j. 重启计算机

如果尚未重启客户端计算机、目标服务器或域控制器，请立即重启它们。 计算机重启后，重试进行身份验证。

如果基础结构正常，但仍有问题，请继续执行更高级的故障排除过程。

3.收集跟踪和票证数据

以下过程使用免费的 网络监视器 工具。 在客户端计算机和目标服务器上下载并安装该工具。 有关如何使用网络监视器收集跟踪数据和识别 Kerberos 消息的示例，请参阅 网络捕获中的 Kerberos 错误。

a。 收集网络同时追踪数据

在客户端计算机上，执行以下步骤：

1. 执行下列操作之一：

   • 重新启动客户端计算机。
   • 注销用于故障排除的帐户，然后再次登录。
   • 关闭客户端应用程序，然后重新打开它。

2. 开始跟踪。 为此，请执行以下步骤：

   1. 选择 “开始”，然后键入 netmon。
   2. 在搜索结果中，右键单击 Microsoft网络监视器 3.4，然后选择“ 以管理员身份运行 ”（在“用户帐户控制”窗口中选择“ 是 ”）。
   3. 在网络监视器中，选择“ 开始”。

3. 打开管理命令提示符窗口，然后按顺序运行以下命令：

   ipconfig /flushdns
   nbtstat -RR
   klist purge
   klist -li 0x3e7 purge
   

在目标服务器上，执行以下步骤：

1. 以管理员身份打开网络监视器，然后选择“ 开始”。

2. 打开管理命令提示符窗口，然后按顺序运行以下命令：

   ipconfig /flushdns
   nbtstat -RR
   klist purge
   klist -li 0x3e7 purge
   

尝试重现问题，然后在客户端计算机和目标服务器上停止并保存跟踪。 为此，请在网络监视器中选择“ 停止”，然后选择“ 另存为”。

b. 记录票证信息

重现问题并停止跟踪后，请检查记录跟踪数据时生成的 Kerberos 票证。 在客户端计算机和目标服务器上的命令提示符处，运行以下命令：

klist tickets

此命令生成票证列表。 可以将此信息复制到另一个应用程序（如记事本），以便在后续的故障排除过程中使用它。

4.检查 Kerberos 消息的跟踪数据

可以使用网络监视器查看、筛选和搜索捕获文件中的数据。 具体而言，查找使用“KerberosV5”标记的事件。这些事件提供状态信息。 它们还可以列出已联系的域控制器的名称或 IP 地址，以及客户端尝试访问的服务的服务主体名称（SPN）。

包含类似于以下内容的字符串的事件说明是典型的 Kerberos 函数的一部分：

• KerberosV5：KRB_Error -KDC_ERR_PREAUTH_REQUIRED
• KerberosV5：AS 请求
• KerberosV5：AS 响应
• KerberosV5：TGS 请求
• KerberosV5：TGS 响应
• KerberosV5：AP 请求
• KerberosV5：AP 响应

注意

还可以使用网络监视器检查 HTTP GET 请求中票证信息的跟踪数据。 如果 GET 请求中缺少票证信息，则使用 Kerberos 身份验证时出现问题。

包含类似于以下内容的字符串的事件说明意味着出现问题。 以下列表包括一些最常见的错误。 如果看到其中一个字符串，请记下任何服务器名称、IP 地址和 SPN 供以后使用。

• KDC_ERR_PRINCIPAL_NOT_UNIQUE 或 KDC_ERR_S_PRINCIPAL_UNKNOWN。 请求的 SPN 与多个帐户相关联，或与任何帐户无关。 有关解决这些问题的帮助，请参阅 Kerberos 生成 KDC_ERR_S_PRINCIPAL_UNKNOWN 或 KDC_ERR_PRINCIPAL_NOT_UNIQUE 错误。

• KRB_AP_ERR_MODIFIED。 客户端无法解密服务票证。 多个问题可能会导致此错误。 审查跟踪数据，查找伴随KRB_AP_ERR_MODIFIED的其他错误。 检查事件 ID 4 和其他相关事件的事件日志，如 1 中所述。检查事件和日志。

• ERB_AP_ERR_SKEW。 客户端和目标服务器时钟不同步。有关详细信息，请参阅 确保计算机时钟已同步。

• KDC_ERR_ETYPE_NOTSUPP。 身份验证中涉及的一个或多个组件使用为其他组件禁用的加密类型。 请查看事件日志，了解有关涉及哪些组件和哪些加密类型的详细信息，如 1 中所述。检查事件和日志。

常见问题和解决方案

HTTP 400 - 错误请求（请求标头过长）问题

如果用户属于大量组（例如超过 1,000 个组），Kerberos 可能会拒绝用户访问，因为它无法正确处理请求。 有关此问题的详细信息，请参阅以下文章：

• 用户属于多个组时 Kerberos 身份验证的问题。

• 在属于超过 1,010 个组的成员的用户帐户上的登录可能会在基于 Windows Server 的计算机上失败。

服务问题

服务问题通常涉及 SPN 和服务帐户。 例如，SPN 可能不正确、缺少、在错误的帐户上配置，或者在多个帐户上配置。 本文中的故障排除清单a、在本文较早的部分中收集同时网络监测。 如果已确定常见的 SPN 问题，请参阅以下文章：

• Kerberos 生成 KDC_ERR_S_PRINCIPAL_UNKNOWN 或 KDC_ERR_PRINCIPAL_NOT_UNIQUE 错误。

• 由于未正确设置 SPN，服务登录失败。

• kerberos 客户端从服务器收到KRB_AP_ERR_MODIFIED错误。

单一登录 （SSO） 问题

单一登录是一种身份验证方法，允许用户使用一组凭据登录到单个 Intranet 中的多个系统或应用程序。 若要正常工作，目标服务（或目标服务的前端组件）和客户端必须具有正确的设置。 有关如何排查这些设置的信息，请参阅 排查 Kerberos 单一登录问题。

委托问题

当目标服务具有单独的前端和后端组件时，Kerberos 可以将客户端凭据（包括访问权限）委托给服务帐户。 简单而言，客户端访问前端服务，然后前端服务代表客户端访问后端服务。

Kerberos 支持三种类型的委派：

• 不受约束的委派。 客户端访问前端服务后，前端服务可以代表客户端访问任何其他服务。 此配置是最容易实现的，但也是最不安全的配置。 不建议使用不受约束的委派，因为它不会限制经过身份验证的帐户可以与之交互的服务。
• 约束委派。 前端服务维护一份服务列表，用于代客户端进行访问。
• 基于资源的约束委派（RBCD）。 后端服务维护前端服务的允许列表，这些服务可以代表客户端请求访问后端服务。

注意

如果在将约束委派与 CIFS 一起使用时遇到问题，请参阅 约束委派与 CIFS 一起使用时失败并出现 "ACCESS_DENIED" 错误。

重要

• 不要在同一组前端和后端服务器上配置受限委派和 RBCD。

  约束委派和 RBCD 是不同的配置，它们相互排斥。 当前端服务向后端服务请求票证时，KDC 会首先检查前端服务是否符合约束委派的条件。 如果未为前端服务配置约束委派，KDC 会检查后端服务是否具有基于资源的受约束委派。 由于此顺序，约束委派优先于基于资源的委派。

• 默认情况下，Microsoft Edge 不支持不受约束的委派。 如果使用不受约束的委派，请参阅 使用 Microsoft Edge （Chromium） 的 Kerberos 不受约束的双跃点身份验证 ，了解有关所需配置的详细信息。

• 不建议使用不受约束的委派，因为它不会限制经过身份验证的帐户可以与之交互的服务。

支持的拓扑类型

不同的委派类型对拓扑有不同的要求。 下表列出了三种常见类型的拓扑，以及每种类型支持哪种类型的委派（如果有）。

拓扑类型	不受约束的委派	约束委派	RBCD
所有服务都驻留在单个域中	支持（不建议）	已支持	已支持
前端和后端服务驻留在不同的域中	支持（不建议）	不支持	已支持
前端和后端服务驻留在不同的（受信任的）林中	* 支持（不建议）	不支持	支持*

^* 确保前端服务的服务帐户可以通过与受信任域控制器的信任关系进行身份验证。

排查特定委派类型问题

委派的配置详细信息因所使用的委派类型以及前端服务使用的帐户类型而异。 若要进一步排查委派问题，请参阅以下文章，视情况而定：

• 排查使用内置服务帐户时 Kerberos 约束委派的问题。
• 对 Kerberos RBCD 进行故障排除（如果使用内置服务帐户）。
• 使用自定义服务帐户时进行 Kerberos 约束委派的故障排除。
• 使用自定义服务帐户时，排查 Kerberos RBCD 问题。

使用日志分析测试方案排查 Kerberos 身份验证问题

有关高级 Kerberos 测试和故障排除，请参阅 使用日志分析测试方案对 Kerberos 身份验证进行故障排除。