Kerberos 委派故障诊断
|
本白皮书说明了如何对在 Kerberos 身份验证方案中可能出现的委派问题进行故障诊断。本白皮书总结了必需的基础结构，并描述了 Windows®
身份验证方案的例子。其中心内容是围绕四个故障诊断清单来组织的：Active Directory®
目录服务、客户端应用程序、中间层和后端各一个清单。附录中详细介绍了诊断工具，并给出了如何在典型的 IIS 到 SQL 委派方案中解决问题的例子。
本页内容
 | 简介 |
| 基础结构的要求 |
| Windows 身份验证方案 |
| 配置 Kerberos 委派 |
| 诊断委派问题：四个清单 |
| 总结 |
| 附录 A：诊断工具 |
| 附录 B：常见方案的配置示例 |
| 附录 C：网络监视器捕获到的网络记录的示例 |
| 附录 D：相关信息 |
简介
本白皮书讨论了对委派问题进行故障诊断的各种方法。由于通常 Kerberos 委派与 Internet 信息服务 (IIS) 和 SQL Server
一起使用，所以本白皮书在“附录 B”中详细介绍了 IIS/SQL 委派方案的例子。
本白皮书假定您已经了解 Kerberos 身份验证的工作原理。有关 Kerberos 协议和操作的更多信息，请参见：
| • | Microsoft Windows Server 2003 技术参考，位于：http://go.microsoft.com/fwlink/?LinkId=21711 |
| • | Microsoft 知识库中的“Windows 2000 中的 Kerberos 用户身份验证协议概述”，位于：http://go.microsoft.com/fwlink/?LinkId=24922 |
基础结构的要求
Kerberos 身份验证的问题常常涉及到 Kerberos SSP 所依赖的技术，或者源于 Kerberos
设置的配置中那些很容易纠正的疏忽。本节将回顾依存关系，并总结每种依存关系怎样与 Kerberos 身份验证的故障诊断相关。
操作系统
Kerberos 身份验证依赖于在 Microsoft® Windows Server™ 2003 操作系统、Microsoft Windows® XP
操作系统和 Microsoft Windows® 2000
操作系统中内置的客户端功能。如果一个客户端、域控制器或目标服务器运行的是较早的操作系统，则它本身不能使用 Kerberos 身份验证。
TCP/IP 网络连接
为了使 Kerberos 身份验证发挥作用，在客户端、域控制器和目标服务器之间必须存在 TCP/IP 网络连接。
如果使用了防火墙，确保在网络中启用了 Kerberos 端口。有关域控制器所使用的公共端口，请参见 Microsoft 知识库中的“Windows
Server 域控制器默认端口列表”，位于：http://go.microsoft.com/fwlink/?LinkId=22894。
注意
可以使用缓存的凭据登录的用户可能不会意识到连接问题。
域名系统
客户端使用完全合格的域名 (FQDN) 来访问域控制器。
| • | DNS 必须运行以使客户端可以获得 FQDN。 |
| • | 为了得到最好的结果，不要使用具有 DNS 的 Hosts 文件。 |
关于 DNS 的信息，请参见“Microsoft Windows Server 2003 部署工具包”中的“部署 DNS 的过程”，位于：http://go.microsoft.com/fwlink/?LinkId=23041。
Active Directory 域
较早的操作系统（如 Microsoft® Windows NT® 4.0 操作系统）并不支持 Kerberos 身份验证。必须使用 Active
Directory® 目录服务中的用户和计算机帐户来使用 Kerberos 身份验证。本地帐户和 Windows NT 域帐户不能用于 Kerberos
身份验证。
时间服务
为了使 Kerberos 身份验证正常工作，使网络中的计算机上的时间同步（即网络中所有的域和林使用同一个时间源）非常重要。一个 Active
Directory 域控制器将作为它的域的授权时间源，这保证了整个域具有相同的时间。更多信息请参见 Microsoft TechNet 上的“Windows
时间服务技术参考”，位于：http://go.microsoft.com/fwlink/?LinkId=25393。
服务主体名称
服务主体名称 (SPN) 是服务器上所运行的服务的唯一标识符。需要为每个使用 Kerberos 身份验证的服务设置一个
SPN，以使客户端可以在网络中识别此服务。如果没有为一个服务设置 SPN，则客户端将无法定位此服务。如果未正确设置 SPN，则将不可能进行 Kerberos
身份验证。
如果未正确设置 SPN 并且一个客户端尝试获取一个服务票证，则一般的结果是出现 KDC_ERR_C_PRINCIPAL_UNKNOWN 或
KDC_ERR_S_PRINCIPAL_UNKNOWN 错误。此外，还有许多由于没有或不正确地设置 SPN 而造成的其他错误。
一般来讲，可以在创建服务帐户或在一台新的计算机上安装服务时设置 SPN。SPN
标识了服务在哪台计算机上运行、服务在哪个帐户下运行以及服务在哪个端口上运行等详细信息。因此，设置一个服务帐户的 SPN
的安全性几乎与创建此帐户的安全性相同。为一个没有设置 SPN 的服务创建的服务帐户将不会在 2003
功能级域中发布使用它的服务密钥加密的服务票证。相反，Windows Server 将使用用户对用户模式。有关用户对用户身份验证的更多信息，请参见“Windows
Server 2003 技术参考”中的“Kerberos Version 5 身份验证协议的工作原理”，位于：http://go.microsoft.com/fwlink/?LinkID=27175，在其中搜索“用户对用户身份验证的过程”。
表 1 中列出了计算机帐户所识别的内建 SPN。如果计算机具有一个 HOST SPN，则计算机帐户可以识别这些 SPN。除非在对象上显式地放置了这些
SPN，否则 HOST SPN 可以代替表中所列出的任意 SPN。
表 1 计算机帐户可识别的内置 SPN
| SPN | ? | ? | ? |
alerter | http | policyagent | scm |
appmgmt | ias | protectedstorage | seclogon |
browser | iisad | rasman | snmp |
cifs | min | remoteaccess | spooler |
cisvc | messenger | replicator | tapisrv |
clipsrv | msiserver | rpc | time |
dcom | mcsvc | rpclocator | trksvr |
dhcp | netdde | rpcss | trkwks |
dmserver | netddedsm | rsvp | ups |
dns | netlogon | samss | w3svc |
dnscache | netman | scardsvr | wins |
eventlog | nmagent | scesrv | www |
eventsystem | oakley | schedule |
|
fax | plugplay |
|
|
SPN 在 Active Directory 中的一个用户帐户下作为名为 Service-Principal-Name 的属性注册。SPN
将分配到此 SPN 所标识的服务在其下运行的帐户上。任何服务都可以查找另一个服务的 SPN。当一个服务要对另一个服务进行身份验证时，它将使用此服务的 SPN
来区分此服务和在此计算机上运行的所有其他服务。
SPN 对于约束委派非常重要。在为委派设置域计算机或用户帐户时，其中的一个步骤就是列出此计算机允许委派到的其他计算机上的服务的 SPN。这个列表构成了一种
ACL。在其他计算机上运行的服务由为这些服务指定的 SPN 标识。
设置 SPN 时所需的权限
为了在给定计算机帐户上写入任意的 SPN，需要“写入
ServicePrincipalName”权限，此权限不会默认授予创建此帐户的人。创建者具有“已验证的对服务主体名称的写入”权限。
为了在用户帐户上写入 SPN，“写入公共信息”权限授予了安全主体创建任意 SPN 的能力。
表 1 影响 SPN 的创建的默认 Active Directory 权限
| 安全主体 | 计算机帐户对象 | 用户帐户对象 |
帐户创建者 | 已验证的对服务主体名称的写入 | 写入公共信息 |
自身 | 已验证的对服务主体名称的写入 | 无 |
帐户操作者 | 写入 servicePrincipalName 已验证的对服务主体名称的写入 | 写入公共信息 |
管理员 | 写入 servicePrincipalName 已验证的对服务主体名称的写入 | 写入公共信息 |
身份验证的用户 | 无 | 无 |
因此，计算机帐户可以写入经验证的 SPN，而不是任意的 SPN。
设置 SPN 的要求
多项服务可以在同一个帐户下同时运行。因此，对于每个已设置的 SPN，都需要以下四个唯一的信息段：
| • | 服务的类型，正式的名称是服务类。此信息段使用户可以区分在同一个帐户下运行的多项服务。 |
| • | 服务在其下运行的帐户。 |
| • | 运行服务的计算机，包括指向此计算机的所有别名。 |
| • | 服务在其上运行的端口。 |
这四个信息段唯一地标识了在网络上运行的所有服务，并且可以用于对任意服务进行手动身份验证。
SPN 本身由三个信息段组成，即 ServiceClass/Host:Port，其中：
| • | ServiceClass 是 SPN 的服务类。 |
| • | Host 是 SPN 所属的计算机的名称。 |
| • | Port 是注册 SPN 的服务所运行的端口。 |
有关如何使用 Setspn 工具操作帐户的服务主体名称的更多信息，请参考“附录 A：诊断工具”中的“Setspn”。
Windows 身份验证方案
使用 Windows 操作系统可以有很多不同的身份验证方案。Kerberos
身份验证以委派为特征，这种特征使得可以跨多台服务器模仿用户身份。Windows Server 2003 中引入了约束委派。
本白皮书将集中讨论 Kerberos 委派的故障诊断问题。理解 Kerberos
身份验证怎样使用约束委派和协议转换进行操作，有助于在解决问题时对配置选项做出选择。
委派提供了与 NTLM 所提供的质询响应方法不同的身份验证方法。以下各节将介绍 NTLM 身份验证、使用 NTLM 身份验证的 Kerberos
身份验证以及涉及 Kerberos 身份验证的三种不同的委派方案。
NTLM 身份验证
图 1 NTLM 质询响应
较早版本的 Windows 操作系统使用 NTLM 来验证凭据。在 NTLM
协议中，客户端将用户名发送到服务器；服务器生成一个质询并将其发送到客户端；客户端使用用户的密码加密这个质询；客户端将一个响应发送到服务器。质询响应机制根据帐户是本地用户帐户还是域用户帐户而有所不同。
| • | 本地用户帐户。服务器将检查它的安全帐户管理器 |
| • | 域用户帐户。服务器将质询和客户端的响应一起转发到域控制器。域控制器对响应进行验证，并将客户端的组信息发送到服务器计算机。服务器使用此信息构建一个访问令牌，并为用户建立一个会话。  图 2 使用 NTLM 验证到后端服务器 |
作为零用户访问
NTLM
要求客户端在需要连接远程服务器时具有用户的密码，但是此密码从不传送到服务器。其缺点是前端服务器无法使用用户的身份访问后端服务器，这是因为前端服务器不具有用户的密码。
因此，只要前端服务器以用户方式尝试连接到后端服务器，它就会作为零用户进行连接。（参见图 2。）当 System 帐户下运行的一个进程尝试使用 NTLM
协议访问远程资源时，也会出现零用户。因此，如果遇到一条内容为“拒绝零用户访问”的错误消息，则可以假定连接使用的是 NTLM。
在 NTLM
身份验证中，当用户验证前端服务器后，如果前端服务器需要访问在后端服务器上运行的服务，则无法保存用户的凭据。后端服务器接收到一个来自前端服务器帐户的身份验证请求，但是后端服务器：
| • | 无法确定用户是谁。 |
| • | 无法区分两个用户的身份以确定哪个用户向前端服务器发出了请求。 |
| • | 无法根据用户的身份提供对资源的不同的访问控制。 |
使用 NTLM 身份验证或单帐户映射的 Kerberos 身份验证
图 3 Kerberos 和 NTLM 混合身份验证
Kerberos
身份验证可以增强安全性，这是因为可以建立审核和可计量性。然而，前端服务器可能会具有在高流量的情况下对成千个唯一用户进行身份验证而增加的负载。另一方面，如果使用
NTLM，在对前端服务器进行最初的身份验证之后，将不再需要对用户进行身份验证，而只需要验证计算机帐户。图 3 中显示的身份验证方案结合了 NTLM 和
Kerberos
身份验证。用户的身份将传送到另一台计算机以允许跟踪和记录，但是最后一次转发将在此计算机帐户之下进行以监听前端服务器上的负载。然而，由于前面在零用户情形下给出的相同的原因（即后端服务器无法验证请求服务的用户的身份），不推荐采用这种方式。
一个相似的方案是将前端服务器配置为使用单个帐户来访问后端服务器。这将出现同样的结果，即使在两次转发中都使用了 Kerberos 身份验证。
由于在这两种方案中都没有使用用户的身份来访问后端服务器，所以不推荐采用这两种方案。
Kerberos 身份验证
只有在使用 Kerberos 协议时才可以使用委派。因此，委派方案中所涉及的所有部分都必须使用 Kerberos 协议。本节将介绍三种委派方案：
| • | Kerberos 身份验证 |
| • | 使用约束委派的 Kerberos 身份验证 |
| • | 使用约束委派和协议转换的 Kerberos 身份验证 |
Kerberos 身份验证
图 4 基本的 Kerberos 委派
如果使用 Kerberos
身份验证，当用户验证到前端服务器时，服务器将从在自己的服务帐户下运行切换到在用户的帐户下运行。然后前端服务器可以模仿用户来访问此用户有权访问的任意资源。而且，后端服务器可以验证此用户是请求访问的实体。
委派使用户的凭据可以从一台服务器传送到另一台服务器，并使用户的身份可以在从一台计算机到另一台计算机请求服务时予以保存。因此，图 4
中显示的前端服务器可以由多台中间层服务器代替，但是仍然需要模仿用户来与后端服务器进行通信。
注意
必须为委派信任所有的中间层服务器。
使用约束委派的 Kerberos 身份验证
在 Windows Server 2003 中，约束委派为域管理员提供了一种对委派信任的帐户可以访问的网络资源进行限制的方式。
另一方面，在 Windows 2000 中 Windows
不支持对委派的限制。在为委派信任一个帐户之后，此服务就可以使用用户的身份访问任意的网络资源。如果这项特定的服务受到了恶意用户的损坏，则将非常危险。
注意
只有当域处于 2003
域功能级时，才可以使用约束委派。在图 5 所示的一个客户端从 Windows Server
上升到前端服务器再到后端服务器的方案中，必须将前端服务器配置为只对后端服务器使用委派。
图 5 约束委派
为了限制服务可以以用户方式访问的资源，可以通过列出帐户可向其提交委派凭据的服务来配置约束委派。此列表的形式为允许用户委派到的 SPN。在约束委派中，Web
服务的帐户只接收委派到后端服务器的 SPN 的权限。
图 6 遭破坏的 Web 服务
在使用约束委派时，如果一个恶意用户破坏了 Web 服务帐户，则这个恶意用户只能访问后端服务器。（参见图 6。）
有关 SPN 的更多信息，请参见本白皮书前面的“服务主体名称”。
有关约束委派的更多信息，请参见 Microsoft TechNet 上的“Kerberos 协议转换和约束委派”，位于：http://go.microsoft.com/fwlink/?LinkId=18156。
使用约束委派和协议转换的 Kerberos 身份验证
在 Windows Server 2003 中，即使初始的身份验证使用另一种 SSP 来代替 Kerberos SSP（例如，NTLM 或
Schannel），协议转换也可以使委派发生。
图 7 Kerberos 协议转换的 SSL
由于在 Internet 上执行 Kerberos 身份验证是不现实的，所以前端服务器必须使用安全套接字层 (SSL)
等方法。然而，在前端服务器验证了用户的身份之后，前端服务器可以执行协议转换，并随后在公司网络内部使用所有的 Kerberos
身份验证功能。因此，开发者不需要使整个身份验证过程依赖于单个身份验证协议。
有关协议转换和约束委派的更多信息，请参见 Microsoft TechNet 上的“Kerberos 协议转换和约束委派”，位于：http://go.microsoft.com/fwlink/?LinkId=18156。
配置 Kerberos 委派
Kerberos 委派需要 Kerberos 身份验证。因此，在对委派进行故障诊断之前，确保已满足了 Kerberos
身份验证的基础结构的要求。更多信息请参见本白皮书的“基础结构的要求”。
图 8 Kerberos 委派的基本要求
委派的要求
| • | 应用程序的域用户不能选中敏感帐户，不能被委派选项。 |
| • | 必须为中间层服务器上的服务注册 SPN。如果此服务帐户是一个域用户帐户，则此服务的 SPN |
| • | 必须为委派信任中间层服务帐户。 |
| • | 必须在后端服务器上为服务注册一个 SPN。 |
| • | 如果使用了约束委派，则中间层服务和后端服务必须位于同一个域中。 |
诊断委派问题：四个清单
以下各节可以帮助您诊断在客户端到中间层到后端委派方案中出现的问题。此外，以下各节还可以帮助您应对在建立此方案时常常遇到的困难。
这些小节描述了可能发生的各种问题，讨论了这些问题可能的原因，并阐述了解决这些问题的步骤。讨论将以清单的形式进行，每个清单都包含一个“任务”列和一个“过程”列。在大多数情况下，“过程”列概述了为了完成任务所需做的工作。不过，过程的详细信息将在清单后的小节中进行说明。
| • | 清单 1 — Active Directory。 正确地配置 SPN 和帐户。 |
| • | 清单 2 — 客户端应用程序。正确地配置应用程序并使用 Kerberos 身份验证。 |
| • | 清单 3 — 中间层。为委派正确地配置服务并使用 Kerberos 身份验证。 |
| • | 清单 4 — 后端。为 Kerberos 身份验证配置服务。 |
在一些组织中，配置帐户的管理员与对委派问题进行故障诊断的人可能并不相同。因此，在一个清单中收集了 Active Directory 任务。
其他三个清单是通过方案中的角色来组织的，其中包含与以下角色相关的帐户配置信息：
| • | 客户端。用户由其提出请求的应用程序。 |
| • | 中间层。 位于中间的以用户方式提出请求的服务。 |
| • | 后端。 最终与模仿用户的中间层服务进行通信的服务。 |
对于清单来说，参加委派的每个系统或服务只会应用一个清单。也就是说，无论环境有多复杂，对所有的客户端使用客户端清单，对所有的后端服务使用后端清单，并且对位于中间的所有服务使用中间层清单。
图 9 显示了在委派方案中可能涉及到的元素。
图 9 客户端到中间层再到后端的委派方案
在上面的例子中，客户端具有客户端角色；中间层服务器 1 具有中间层角色；后端服务器 1 到 n 具有后端角色；位于中间的中间层服务器 2 到 n
具有中间层和后端角色。对于这些清单来说，将中间层服务器 n 作为中间层服务器的原因是后端服务所需的任务是中间层服务的任务的一个子集。
故障诊断的策略
一些错误消息可能会帮助诊断发生问题的位置，但是有时这些消息起不到帮助作用。有关故障诊断 Kerberos 错误的更多信息，请参见“故障诊断
Kerberos 错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。
在进行故障诊断时，确保使用 Kerberos 协议验证到每项服务。不过需要注意的是，在对每项服务进行故障诊断时，可能需要使用不同的应用程序。例如：
| • | 如果服务器正在运行 SQL Server，则客户端应用程序可以是 Query Analyzer、osql.exe 或使用 ADO 的 VB |
| • | 如果服务器正在运行 IIS，则客户端应用程序可以是 Internet Explorer。 |
在典型的委派使用中，用户直接或通过 Web 服务方式验证到运行 IIS 并访问 SQL 数据库的服务器，如果使用委派，中间层服务可以模仿具有访问 SQL
数据库中的数据的权限的用户。在这种情况下，经常使用约束委派来使用户可以访问在计算机上运行的特定服务。
清单 1 — Active Directory
Active Directory：正确配置 SPN 和帐户
| 任务 | 过程 | 完成的数据/执行人 | ||||||||||||||
| 从命令提示符执行 | ||||||||||||||||
|
详细的指导请参见“验证中间层服务帐户的 SPN”。 有关的例子请参见“附录 B”。 | ? | ||||||||||||||
| 从“Active Directory 用户和计算机” | ||||||||||||||||
| 详细的指导请参见“验证域功能级”。 |
| ||||||||||||||
|
详细的指导请参见“验证帐户选项”。 |
| ||||||||||||||
| 如果中间层服务使用的是计算机帐户：
如果中间层服务使用的是域用户帐户：
详细的指导请参见“验证中间层服务帐户的委派”。 有关的例子请参见“附录 B”。 | ? | ||||||||||||||
|
详细的指导请参见“验证中间层服务权限”。 | ? |
图 10 Active Directory 帐户配置
以下任务具有常规的配置指导。可以在“附录 B”中找到在常见的方案中需要设置的选项的示例。
验证中间层服务帐户的 SPN
验证为此方案中的每个中间层服务帐户都注册了一个 SPN。如果中间层服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN
都将自动设置，所以不需要验证是否正确地设置了 SPN。
验证为服务帐户设置了 SPN
在命令提示符下键入：
setspn –L 帐户
其中帐户是服务帐户的名称。
应该最少列出两个 SPN，这是因为为了使委派正常工作，必须存在以下两个服务帐户的 SPN：
| • | ServiceClass/Host:Port，其中 ServiceClass |
| • | ServiceClass/FQDN， 其中 FQDN |
疑难解答
如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。如果列出了重复的 SPN，则使用
Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
有关的例子请参见“附录 B”。
验证后端服务帐户的 SPN
验证为方案中的每个后端服务帐户都注册了一个 SPN。如果后端服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN
都将自动设置，所以不需要验证是否正确地设置了 SPN。
如果后端服务使用的是域用户帐户，则验证为服务帐户设置了 SPN。
有关的例子请参见“附录 B”。
验证域功能级
如果配置的是约束委派，则需要验证域控制器在 Windows Server 2003 功能级上操作。（注意：只有约束委派才需要此步骤。）
图 11 Windows Server 2003 域功能级
重要
Windows 2000
不支持约束委派。由于不受限的委派会降低安全性，所以应避免在 Windows 2000 环境中使用委派。
要验证域控制器的功能级
1. | 打开“Active Directory 用户和计算机”。 |
2. | 右键单击“DomainName”，然后单击“属性”。 |
3. | 确认在“域功能级”下列出了 Windows Server 2003。 |
验证用户帐户选项
确认未选中用户帐户的“敏感帐户，不能被委派”选项。
要确认未选中“敏感帐户，不能被委派”选项：
1. | 打开“Active Directory 用户和计算机”。 |
2. | 右键单击“UserAccount”，然后单击“属性”。 |
3. | 单击“帐户”选项卡。  图 12 用户帐户选项 |
4. | 在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。 |
验证中间层服务帐户的委派
验证为委派信任此方案中的每个中间层服务帐户。如果有一个中间层服务帐户不信任委派，则将收到类似如下的错误信息：
零用户登录失败
NT AUTHORITY\ANONYMOUS 用户登录失败
尽管在 客户端和中间层服务之间或中间层服务和后端服务之间可以使用 Kerberos
协议，但是如果一项中间层服务未受到委派信任，则此中间层服务将不具有客户端的 TGT。这样，身份验证将退回到
NTLM。由于中间层服务不具有网络凭据（即用户的密码），所以它将成为零用户。
有关的例子请参见“附录 B”。
服务在计算机帐户下运行
如果服务在计算机帐户下运行，则需要为委派的服务器配置此计算机帐户。
为了验证中间层服务器计算机帐户受到委派信任
1. | 打开“Active Directory 用户和计算机”。 | ||||
2. | 找到中间层服务器的计算机帐户。 | ||||
3. | 右键单击此帐户，然后单击“属性”。
|
在“委派”选项卡上，如果选中了“不信任此计算机作为委派”，则选择以下两个“信任”选项之一：
1. | 要将帐户配置为使用不受限的委派，选择信任此计算机来委派任何服务（仅 Kerberos）。不推荐选择此选项。 | ||||
2. | 要将帐户配置为使用受限的委派，选择仅信任此计算机来委派指定服务。通过选择以下两个选项之一来配置协议转换：
|
如果服务在域用户帐户下运行
如果服务在域用户帐户下运行，则需要为委派配置服务帐户。
为了验证为委派信任了中间层服务帐户
1. | 打开“Active Directory 用户和计算机”。 | ||
2. | 定位到所要配置的帐户，右键单击此帐户，然后单击“属性”。
|
在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。
| • | 如果此服务帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。  图 16 不使用协议转换的服务帐户 |
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证中间层服务权限
由于模仿另一个用户的能力是委派的一个主要部分，所以如果一个过程没有所需的权限，它将无法委派。因此，验证委派方案中的每个中间层服务都具有以下两种权限之一：
| • | 作为操作系统的一部分（在 Windows 2000 或 Windows Server 2003 中可用） |
| • | 在身份验证之后模仿一个客户端（在 Windows Server 2003 中新增） |
这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似，只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿，而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。
默认情况下，为本地系统帐户分配“作为操作系统的一部分”权限。因此，如果中间层服务在本地系统帐户下运行，则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户，需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。如果使用组策略配置这些权限，则需要验证在域控制器上正确配置了策略。如果使用本地安全策略进行配置，在“清单
3 — 中间层”中对此过程进行了介绍。
如果使用了协议转换，中间层服务常常没有关于传入的用户身份的信息——也就是说，传入的用户在身份验证时所使用的协议可能没有提供与 Kerberos
身份验证相同的一组完整的凭据。因此，需要为这些中间层服务分配“作为操作系统的一部分”权限。
例如，尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户，但是它并没有正式对此用户进行身份验证。因此，运行 IIS
的中间层服务必须具有“作为操作系统的一部分”权限，以便在一个用户请求 Web 服务或后端服务器时模仿此用户。
这样，应该为第一个中间层服务配置“作为操作系统的一部分”权限。然而，由于“在身份验证之后模仿一个客户端”权限不能进行远程访问，所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限（如果使用的是
Windows Server 2003）。
为了验证服务帐户具有适当的权限
1. | 通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。
|
2. | 单击“本地策略”，然后单击“用户权限分配”。 |
例如，图 17 显示了为 Tailspintoys\iisservice 分配了“在身份验证之后模仿一个客户端”权限。
图 17 默认域安全设置中的用户权限分配
为了对服务帐户设置“在身份验证之后模仿一个客户端”权限
1. | 通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。（参见上方过程中的“注意”部分。） |
2. | 单击“本地策略”，再单击“用户权限分配”，然后单击“在身份验证之后模仿一个客户端”。 |
3. | 添加所有需要委派凭据的帐户（例如 IIS 帐户）。 |
4. | 由于更改是在域控制器上的域安全策略中进行的，接着在命令提示符下对客户端计算机运行 gpupdate |
清单 2 — 客户端应用程序
客户端应用程序：为 Kerberos 身份验证配置并使用此身份验证
| 任务 | 过程 | 完成的数据/执行人 | ||||||||||
|
详细的指导请参见“验证用户帐户选项”。 | |||||||||||
验证名称解析工作正常。 |
详细的指导请参见“验证名称解析”。 | |||||||||||
验证为 Kerberos 协议配置了客户端应用程序。 | 详细的指导请参见“验证为 Kerberos 协议配置了应用程序”。 有关的例子请参见“附录 B”。 | |||||||||||
验证客户端使用 Kerberos 身份验证来身份验证到服务。 | 可以通过以下方式进行验证：
详细的指导请参见“验证客户端使用的是 Kerberos 身份验证”。 | ? |
图 18 Kerberos 客户端应用程序
验证用户帐户选项
验证未选中用户帐户的“敏感帐户，不能被委派”选项。注意：如果按顺序完成以上清单，则此任务已在 Active Directory
清单中完成。
要验证未选中“敏感帐户，不能被委派”选项
1. | 打开“Active Directory 用户和计算机”。 |
2. | 右键单击 UserAccount，然后单击“属性”， |
3. | 再单击“帐户”选项卡。  图 19 用户帐户选项 |
4. | 在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。 |
验证名称解析
验证名称解析工作正常。Kerberos 身份验证要求每台计算机都可以解析与之通信的下一台计算机的 DNS
名称，而不论此计算机是位于中间层还是在后端。
| • | 使用 ping 验证可以进行以下解析：
Ping 通常返回服务器的 FQDN 及 IP 地址。确保客户端的本地 Hosts | ||||||||||||
| • | 如果客户端和服务器位于不同的域中，为连接使用服务器的 FQDN。如果使用 NetBIOS 可以使用 Net view 从命令行验证以下问题。
例如，如果使用 NetBIOS 解析一个本地域主体，则 Net view 将给出以下结果：
|
验证为 Kerberos 协议配置了应用程序
| • | 验证客户端应用程序支持 Kerberos 身份验证。
|
| • | 验证为 Kerberos |
有关的例子请参见“附录 B”。
验证客户端使用的是 Kerberos 身份验证
为了验证客户端使用 Kerberos 身份验证来验证服务，在域用户帐户下使用客户端身份验证连接到此服务。（Kerberos
身份验证只能在域用户帐户下进行，而不能在本地计算机用户帐户下进行。）
即使可以成功地连接，此连接也可能在 NTLM 上发生。因此，通过以下方式验证使用的是 Kerberos 身份验证数据包：
| • | 为 NTLM 成功审核检查中间层服务器上的安全日志。有关启用审核和使用安全日志的更多信息，请参见“附录 |
| • | 在连接到服务器之前使用 Kerberos Tray 清除票证，然后观察票证以找到一个连接到服务器的票证。更多信息请参见“附录 |
| • | 使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。如果拥有一个 Kerberos |
有关使用审核、调试输出和网络跟踪对 Kerberos 身份验证进行故障诊断的更多信息，请参见“故障诊断 Kerberos 错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。
如果使用 Kerberos 协议建立了连接，确保用户具有访问服务器的权限。如果用户不具有此权限，则可能会收到类似“用户
domain\UserName 不具有查看资源的权限”或“拒绝
domain\UserName 访问”的错误。
如果使用以下方式建立连接：
| • | Kerberos 协议，转到“清单 3 — 中间层”以继续诊断问题。 | ||||
| • | NTLM，则两种可能的原因是：
|
如果发现仍然在使用 NTLM 身份验证，或者在应该使用 Kerberos 身份验证的情况下没有尝试 Kerberos
身份验证，请联系“产品支持服务”以帮助诊断问题。
清单 3 — 中间层
如果中间层服务使用 NTLM 来验证下一项服务，则通常会收到类似如下的错误：
零用户登录失败
NT AUTHORITY\ANONYMOUS 用户登录失败
如果已验证了每台计算机使用的都是 Kerberos
协议，则此身份验证问题的一种可能的原因是没有为委派正确地配置中间层服务。在这种情况下，通常会收到类似如下的错误：
UserName 登录失败
中间层：配置服务以模仿用户
| 任务 | 过程 | 完成的数据/执行人 | ||||||||||||||||
|
|
| ||||||||||||||||
|
详细的指导请参见“验证中间层服务帐户的 SPN”。 有关的例子请参见“附录 B”。 | |||||||||||||||||
| 如果中间层服务使用的是计算机帐户：
如果中间层服务使用的是域用户帐户：
详细的指导请参见“验证中间层服务帐户的委派”。 有关的例子请参见“附录 B”。 |
| ||||||||||||||||
|
详细的指导请参见“验证中间层服务权限”。 | |||||||||||||||||
| ||||||||||||||||||
| 有关的例子请参见“附录 B”。 |
| ||||||||||||||||
| 更多信息请参见“验证中间层服务模仿用户”。 | ? |
图 20 中间层服务支持 Kerberos 协议
验证中间层支持 Kerberos 协议
验证每个中间层服务或服务器都支持 Kerberos 协议。
验证中间层的 SPN
验证为每个中间层服务帐户都注册了一个 SPN。（注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。）
如果中间层服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN 都将自动设置，所以不需要验证是否正确地设置了
SPN。
验证为服务帐户设置了 SPN
在命令提示符下键入：
setspn –L帐户
其中帐户是服务帐户的名称。
应该至少列出两个 SPN，这是因为为了使委派正常工作，必须存在以下两个服务帐户的 SPN：
| • | ServiceClass/Host:Port，其中 ServiceClass |
| • | ServiceClass/FQDN，其中 FQDN |
疑难解答
如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
有关常见方案的例子请参见“附录 B”。
验证域功能级
如果配置的是约束委派，则需要验证域控制器在 Windows Server 2003 功能级上操作。（只有约束委派才需要此步骤。）
注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。
图 21 Windows Server 2003 域功能级
重要
Windows 2000
不支持约束委派。由于不受限的委派会降低安全性，所以应避免在 Windows 2000 环境中使用委派。
要验证域控制器的功能级
1. | 打开“Active Directory 用户和计算机”。 |
2. | 右键单击 DomainName，然后单击“属性”。 |
3. | 验证在“域功能级”下列出了 Windows Server 2003。 |
验证中间层服务帐户的委派
注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。
验证为委派信任此方案中的每个中间层服务帐户。如果没有为委派信任此中间层服务帐户，则将收到类似如下的错误信息：
零用户登录失败
NT AUTHORITY\ANONYMOUS 用户登录失败
尽管在 客户端和中间层服务之间或中间层服务和后端服务之间可以使用 Kerberos
协议，但是如果没有为委派信任此中间层服务，则此中间层服务将不具有客户端的 TGT。这样，身份验证将退回到
NTLM。由于中间层服务不具有网络凭据（即用户的密码），所以它将成为零用户。
有关的例子请参见“附录 B”。
服务在计算机帐户下运行
如果服务在计算机帐户下运行，则需要为委派的服务器配置此计算机帐户。
为了验证为委派信任中间层服务器计算机帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||
2. | 找到中间层服务器的计算机帐户。 | ||||
3. | 右键单击此帐户，然后单击“属性”。
|
在“委派”选项卡上，如果选中了“不信任此计算机来委派”，则选择以下两个“信任”选项之一：
1. | 要将帐户配置为使用不受限的委派，选择信任此计算机来委派任何服务（仅 Kerberos）。不推荐选择此选项。 | ||||
2. | 要将帐户配置为使用受限的委派，选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
服务在域用户帐户下运行
如果服务在域用户帐户下运行，则需要为委派配置服务帐户。
为了验证为委派信任了中间层服务帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||
2. | 定位到所要配置的帐户，右键单击此帐户，然后单击“属性”。
在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。
|
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证中间层服务权限
注意：如果使用域安全策略进行配置，在“清单 1 — Active Directory”中对此过程进行了介绍。
由于模仿另一个用户的能力是委派的一个主要部分，所以如果一个过程没有所需的权限，它将无法委派。因此，验证委派方案中的每个中间层服务都具有以下两种权限之一：
| • | 作为操作系统的一部分（在 Windows 2000 或 Windows Server 2003 中可用） |
| • | 在身份验证之后模仿一个客户端（在 Windows Server 2003 中新增） |
这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似，只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿，而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。
如果使用组策略配置这些权限，则需要验证在域控制器上正确配置了策略。
默认情况下，为本地系统帐户分配“作为操作系统的一部分”权限。因此，如果中间层服务在本地系统帐户下运行，则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户，需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。
如果使用了协议转换，中间层服务常常没有关于进来的用户身份的信息——也就是说，进来的用户在身份验证时所使用的协议可能没有提供与 Kerberos
身份验证相同的一组完整的凭据。因此，需要为这些中间层服务分配“作为操作系统的一部分”权限。
例如，尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户，但是它并没有正式对此用户进行身份验证。因此，运行 IIS
的中间层服务必须具有“作为操作系统的一部分”权限，以便在一个用户请求 Web 服务或后端服务器时模仿此用户。
这样，应该为第一个中间层服务配置“作为操作系统的一部分”用户权限设置。然而，由于“在身份验证之后模仿一个客户端”权限不能进行远程访问，所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限（如果使用的是
Windows Server 2003）。
为了验证服务帐户具有适当的权限
1. | 通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开本地安全策略。
|
2. | 单击“本地策略”，然后单击“用户权限分配”。 |
例如，图 26 显示了为 Administrators 和 SERVICE 配置了“在身份验证之后模仿一个客户端”权限。
图 26 本地安全设置中的用户权限分配
为了为服务帐户设置“在身份验证之后模仿一个客户端”权限
1. | 通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开域安全策略。
|
2. | 单击“本地策略”，再单击“用户权限分配”，然后单击“在身份验证之后模仿一个客户端”。 |
3. | 添加所有需要委派凭据的帐户（例如 IIS 帐户）。 |
验证用户身份验证
验证已授权用户访问中间层服务器上的所需的资源。
验证中间层服务配置
验证为模仿配置了此方案中的每个中间层服务。根据服务的不同也许有必须配置的设置或元数据，以便中间层服务使用 Kerberos 协议。
注意
可以将 IIS 配置为同时使用
Negotiate 和 NTLM。更多信息参见 Microsoft 知识库中的“HOW TO：将 IIS 配置为同时支持 Kerberos 和 NTLM
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=24925。
有关的例子请参见“附录 B”。
验证中间层服务模仿用户
验证中间层服务在连接到下一个服务之前模仿用户。例如，ASP.NET 应用程序或 COM+ 应用程序可以在 domain\UserName
下运行以代替模仿真正的用户，并且可以在 domain\UserName 下连接到后端服务器。这会造成类似如下的错误：
domain\UserName登录失败
拒绝 domain\UserName 访问。
清单 4 — 后端
后端：为 Kerberos 身份验证配置服务。
| 任务 | 过程 | 完成的数据/执行人 | ||||||||||||
|
详细的指导请参见“验证后端服务帐户的 SPN”。 有关的例子请参见“附录 B”。 | |||||||||||||
| ? | ? |
图 27 后端服务器
验证后端服务帐户的 SPN
验证为方案中的每个后端服务帐户都注册了一个 SPN。（如果按顺序使用以上清单，则此任务已在 Active Directory 清单中完成。）
如果后端服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN 都将自动设置，所以不需要验证是否正确设置了
SPN。
验证为服务帐户设置了一个 SPN
在命令提示符下键入：
setspn –L 帐户
其中帐户是后端服务在其下运行的帐户的名称。
| • | 验证存在使委派正常工作所需的以下两个后端服务帐户的 SPN：
|
疑难解答
如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。中间层服务需要以上两个 SPN
以正确地对后端服务使用委派凭据。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
有关的例子请参见“附录 B”。
验证已授权用户访问后端服务器的资源
例如，如果后端服务器是 SQL Server，确保授权用户访问 SQL 数据库。如果没有对用户进行授权，可能会收到类似如下的错误：
UserName 登录失败
拒绝 UserName 访问
注意
后端服务帐户不需要设置委派，这是因为它将身份验证到或将凭据委派到其他服务。
总结
本白皮书讨论了对 Kerberos 委派问题进行故障诊断的各种方法。前面各节详细介绍了在设置这些方案时经常出现的错误以及解决这些问题的方式。
由于最常见的 Kerberos 委派的使用是使用 IIS 和 SQL 的委派方案，所以“附录 B”对 IIS/SQL 委派方案进行了更详细的介绍。
附录 A：诊断工具
一些用于诊断 Kerberos 错误的工具（例如事件查看器和网络监视器）与用于其他与网络相关的或身份验证的问题的工具相同。其他的特定工具（例如
Kerberos List 和 Kerberos Tray）可以用于详细的特定于 Kerberos 的信息。本节提供了有关故障诊断工具的信息。
事件查看器
在 Windows Server 2003 和 Windows 2000 中都包括事件查看器。系统日志 XP 以及 Windows 和安全日志将包含
Kerberos 错误代码和其他与身份验证相关的事件。有关使用事件查看器进行故障诊断的更多信息，请参见 Microsoft 知识库的“HOW TO：在
Windows Server 2003 中使用事件查看器诊断系统问题”，位于：http://go.microsoft.com/fwlink/?LinkId=23046。
安全事件日志
安全事件日志中包含可以说明 Kerberos
身份验证是否发生故障或使用的是否是其他身份验证协议的信息。用户的特定登录/注销事件的详细信息将显示所使用的身份验证协议。
尽管推荐使用 Kerberos 身份验证，但是系统可能会在发生错误或故障时转到 NTLM。这种转换会引起更多的问题，这是因为用户将不会获得任何
Kerberos 票证并且可能无法访问 Kerberos 知道的服务或不具有在整个网络中进行单次登录的功能。
NTLM 或 Kerberos 协议
怎样可以知道登录时使用的是 NTLM 还是 Kerberos 协议？所有在运行 Windows Server 2000 的计算机上进行的帐户登录都应该使用
Kerberos 2003 或 Windows 协议（或 Negotiate，可以表示使用了 Kerberos
协议）。为了捕获这些事件，需要启用对成功的用户身份验证的帐户登录事件和计算机身份验证的登录事件的审核。
“登录类型”域有助于确定哪种事件适用于登录尝试的类型。表 2 中列出了“登录类型”域中可能的值。
表 2 登录类型
2 | Interactive（交互登录） |
3 | Network（通过网络访问系统） |
4 | Batch（作为批处理作业启动） |
5 | Service（由服务控制器启动的 Windows 服务） |
6 | Proxy NT or Windows（代理登录；在 Windows 2000 中未使用） |
7 | Unlock（解除对工作站的锁定） |
8 | NetworkCleartext（使用纯文本凭据的网络登录） |
9 | NewCredentials（由 RunAs 在使用 /netonly |
如果安全日志显示使用的是 NTLM 并且存在与身份验证相关的问题，则需要通过使用本节中介绍的工具进行诊断。
启用故障审核
默认情况下，Windows Server 2003
只记录成功的审核。通常，这种默认设置将妨碍查找身份验证问题，这是因为在日志中很多失败的身份验证尝试都没有显示。启用故障审核将显示失败的身份验证，并因此会提供一些有关错误源的额外信息。
为了启用故障审核
1. | 通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开本地安全策略。
|
2. | 单击“本地策略”，然后单击“审核策略”。 |
3. | 右键单击“审核帐户登录事件”。 |
4. | 选择“定义这些策略设置”。 |
5. | 在“审核这些尝试：”下确保选中了“成功”和“失败”选项。 |
6. | 单击“确定”。 |
7. | 重复步骤 3 到 6 以使“审核登录事件”记录成功和失败事件。 |
8. | 如果更改是在域控制器上的域安全策略中进行的，在命令提示符下对客户端计算机运行 gpupdate |
Klist.exe: Kerberos List
Kerberos List 是一个命令行工具，可以用来查看和删除已授予当前的登录会话的 Kerberos 票证。为了使用 Kerberos List
来查看票证，必须在一台是 Kerberos 领域的成员的计算机上运行此工具。
当从客户端运行 Kerberos List 时，将显示以下信息：
| • | Windows 中的 Kerberos 密钥分发中心 (KDC) 的票证授权票证 (TGT)。 |
| • | UNIX 上的 Ksserver 的票证授权票证 (TGT)。 |
如何安装 Kerberos List
Windows Server 2003、Windows 2000.XP 和 Windows 都支持 Kerberos List
可以从 Microsoft 下载中心下载 Klist.exe 和其他“Windows Server 2003 资源工具包工具”，位于：http://go.microsoft.com/fwlink/?LinkID=16544。
如何使用 Kerberos List
Kerberos List 是一个命令行工具，此工具使用以下语法：
klist [tickets | tgt | purge] [-?]
要运行 Kerberos List：
1. | 依次单击“开始”、“所有程序”、“附件”和“命令提示符”。 |
2. | 在命令提示符窗口中，键入： klist.exe参数 然后按 ENTER 键。 |
Kerberos List 的参数
票证
列出在登录之后身份验证到的服务的当前缓存的票证。“票证”可以用于验证为用户发出了一个 Kerberos
票证。在一个身份验证请求之后，应该出现多个票证。此命令还将显示有关获取的票证的详细信息，包括这些票证发布到的服务器、有效期和票证选项。
“票证”显示所有缓存票证的以下属性：
| 选项 | 描述 |
结束时间 | 票证失效的时间。在票证经过这段时间之后，将不能用于身份验证到服务。 |
KerbTicket 加密类型 | 用于加密 Kerberos 票证的加密类型。 |
更新时间 | 更新的票证的最大生存期（参见下面的表中的 |
服务器 | 票证的服务器和域。 |
tgt
列出初始的 Kerberos 票证授权票证 (TGT)。tgt显示了当前缓冲的票证的以下属性：
| 选项 | 描述 |
AltTargetDomainName | 为生成此票证的 InitializeSecurityContext 提供的名称，通常是一个 |
DomainName | 服务的域名。 |
结束时间 | 票证失效的时间。在票证经过结束时间之后，将不能用于身份验证到服务。 |
FullServiceName | 服务的帐户主体的规范名称。 |
KeyExpirationTime | 来自 KDC 应答的过期时间。 |
RenewUnitil | 更新的票证的最大生存期（参见 TicketFlags）。为了继续使用一个票证，必须对其进行更新。必须在结束时间和 |
ServiceName | TGT 是密钥分发中心 (KDC）服务的票证。TGT 的服务名称是 krbtgt。 |
StartTime | 票证生效的时间。 |
TargetDomainName | 对于跨领域的票证，此领域是票证有效的领域，而不是发出票证的领域。 |
TargetName | 请求票证的服务名称。这是目录中的一个帐户的 servicePrincipalName |
TicketFlags | 在当前的票证上设置的十六进制的 Kerberos 票证标记。Kerberos Tray |
TimeSkew | 票证的客户端计算机和服务器计算机之间的报告时间之差。 |
清除
删除用户所拥有的所有 Kerberos
票证。“票证”将破坏所有已缓存的票证，所以谨慎使用此选项。此选项可能会使用户不能再身份验证到资源。如果出现这种情况，则必须注销，然后重新登录。
-?
显示命令行帮助。
Kerbtray.exe: Kerberos Tray
Kerberos Tray 是一个图形用户界面工具，此工具将显示运行 Kerberos 版本 5 身份验证协议的 Microsoft
实现的计算机的票证信息。Windows Server 2003、Windows XP 和 Windows 2000 都支持 Kerberos Tray。
可以通过使用位于桌面的通知区域中的 Kerberos Tray 工具图标来查看和清除票证缓存。通过将光标放置在此图标上，可以查看初始的票证授权票证
(TGT) 过期前还有多少时间。此图标还将在本地安全机构 (LSA) 更新票证之前以小时为单位变化。
如何安装 Kerberos Tray
Kerberos Tray 包含在“Windows Server 2003 资源工具包”和“Windows 2000 资源工具包”中。
可以从 Microsoft 下载中心下载 Kerbtray.exe 和其他“Windows Server 2003 资源工具包工具”，位于：http://go.microsoft.com/fwlink/?LinkID=16544。
如何使用 Kerberos Tray
1. | 为运行 Kerberos Tray，双击 Kerbtray文件。Kerbtray 图标将出现在通知区域中。 |
2. | 为了在运行 Kerberos Tray 之后打开主 Kerbtray |
3. | 为了清除票证，在通知区域中右键单击 Kerbtray 图标并单击清除票证。 |
Ldifde
可以使用 Ldifde 来创建、修改和删除运行 Windows Server 2003 或 Windows XP Professional
的计算机上的目录对象。还可以使用 Ldifde 来扩展方案，将 Active Directory
用户和组信息导出到其他应用程序或服务，以及使用来自其他目录服务的数据填充 Active Directory。
Ldifed.exe 位于域控制器上，但是不能复制到运行 Windows XP 和 Windows Server 2003
的客户端计算机或在这些计算机上使用。
Ldifed 提供了一种快速提取和显示一个林或域中特定 SPN 的方法。在以下情况下这将非常有用：
| • | 在林中有多个对象具有相同的 HOST/NetBIOSname SPN，可能会造成 Kerberos 身份验证故障。 |
| • | 在帐户上注册了多个（因此无效）MSSQL SPN。 |
语法
ldifde [-i] [-f FileName]
[-s ServerName] [-c String1 String2]
[-v] [-j Path] [-t PortNumber]
[-d BaseDN] [-r LDAPFilter] [-p Scope]
[-l LDAPAttributeList] [-o LDAPAttributeList]
[-g] [-m] [-n] [-k]
[-a UserDistinguishedName Password]
[-b UserName Domain Password] [-?]
参数
-i
指定导入模式。如果没有指定，则默认的模式是导出。
-f FileName
确定导入或导出的文件名。
-s ServerName
指定执行导入或导出操作的域控制器。默认情况下，Ldifde 将在安装 Ldifde 的域控制器上运行。
-cString1String2
使用 String2 代替所有出现的 String1。此参数通常在从一个域将数据导入到另一个域并且导出域的可分辨名称
(String1) 需要使用导入域的可分辨名称 (String2) 来代替时使用。
-v
设置详细的模式。
-j Path
设置日志文件的位置。默认位置为当前路径。
-t PortNumber
指定一个 LDAP 端口号。默认的 LDAP 端口是 389。全局的目录端口是 3268。
-d BaseDN
设置数据导出的搜索库的可分辨名称。
-r LDAPFilter
为数据导出创建一个 LDAP 搜索筛选器。例如，为了使用特定的姓氏导出所有用户，可以使用以下筛选器：
-r (and(objectClass=User)(sn=Surname))
-p Scope
设置搜索范围。搜索范围选项是 Base、OneLevel 或 SubTree。
-l LDAPAttributeList
设置在导出查询的结果中所返回属性的列表。如果省略了此参数，则返回所有属性。
-o LDAPAttributeList
设置在导出查询的结果中所省略的属性的列表。此参数通常在从 Active Directory 导出对象然后将其导入到另一个遵循 LDAP
的目录时使用。如果另一个目录不支持一些属性，则可以使用此选择从结果集中省略这些属性。
-g
省略分页的搜索。
-m
省略只应用于 Active Directory
对象的属性。（例如，Object-Guid、Object-Sid、Pwd-Last-Set 和
SAM-Account-Type 属性。）
-n
省略二进制值的导出。
-k
忽略导入操作期间的错误并继续进行。以下是忽略的错误的一个完整的列表：
| • | 对象已是组的成员 |
| • | 违反对象类（即指定的对象类不存在），如果导入的对象没有其他属性 |
| • | 对象已存在 |
| • | 违反约束条件 |
| • | 属性或值已存在 |
| • | 没有这样的对象 |
-a UserDistinguishedName Password
将命令设置为使用提供的 UserDistinguishedName 和 Password
运行。默认情况下，此命令将使用当前登录到网络的用户的凭据运行。
-b UserName Domain Password
将命令设置为使用提供的 UserName Domain Password
运行。默认情况下，此命令将使用当前登录到网络的用户的凭据运行。
-?
显示命令菜单。
示例
最初使用计算机帐户安装 SQL Server 以启动服务（从而获得了所需的
SPN）。随后，将配置一个域帐户来启动服务，这样就会出现身份验证问题。产生问题的原因可能是在多个对象上注册了 MSSQL SPN。以下命令将生成一个在林中注册了
MSSQL SPN 的对象的列表：
LDIFDE –f filename.txt –t 3268 –d
“DC=forest,DC=Root,DC=com”
–l serviceprincipalname –r ”(serviceprincipalname=MSSQLSvc/*)”
–p subtree
在这个例子中，参数的作用如下：
-f filename.txt
将输出写入到指定的文件。
-t 3268
可选参数，指定全局目录端口。
-d “DC=forest,DC=Root,DC=com”
为搜索起始点使用所需的林或域的可分辨名称。
-l serviceprincipalname
限制服务主体名称的输出。
-r ”(serviceprincipalname=MSSQLSvc/*)”
将 SQL 服务指定为要查找的 SPN。
-p subtree
将搜索范围设置为子树。
网络监视器
可以使用网络监视器工具，通过捕获网络记录并随后检查跨网络发送的真正的 Kerberos 包，来获取比事件日志所提供的信息更详细的信息。
注意
有关网络监视器的完整信息，请参见
Microsoft TechNet 上的“网络监视器”，位于：http://go.microsoft.com/fwlink/?LinkId=23049。与网络监视器相关联的最佳做法和过程，请参见
Microsoft TechNet 上的“清单：监视本地计算机上的网络流量”，位于：http://go.microsoft.com/fwlink/?linkid=23047。
网络监视器的完整版本包含在 Microsoft 系统管理服务器 (SMS) 中。而 Windows 2000、Windows XP 和 Windows
Server 2003 家族则包含了此工具的一个限制版本。从 Microsoft 产品支持服务也可以获得此工具。
如何在 Windows Server 2003 上安装网络监视器
1. | 打开“Windows 组件向导”。 | ||||||||
2. | 在“Windows 组件向导”中，单击“管理和监视工具”，然后单击“详细信息”。 | ||||||||
3. | 在“管理和监视工具的子组件”中，选择“网络监视工具”复选框，然后单击“确定”。 | ||||||||
4. | 如果提示需要其他的文件，插入操作系统的安装光盘，或键入表示文件在网络上的位置的路径。
|
如何在 Windows XP 上安装网络监视器
网络监视器包含在 Windows XP 支持工具中。
1. | 在驱动器中插入 Windows XP CD-ROM。 |
2. | 双击“我的电脑”，右键单击光盘驱动器，然后单击“资源管理器”。 |
3. | 转到Support\Tools，然后双击Setup.exe。 |
4. | 当“Windows 支持向导”启动时，单击“下一步”。 |
5. | 在最终用户许可协议上单击“我同意”。 |
6. | 键入名称和组织，然后单击“下一步”。 |
7. | 单击“典型”或“完全”安装类型，然后单击“下一步”。 |
8. | 验证安装位置，然后单击“安装”。 |
如何在 Windows 2000 上安装网络监视器
1. | 单击“开始”，指向“设置”，然后单击“控制面板”。 |
2. | 双击“添加或删除程序”。 |
3. | 单击“添加/删除 Windows 组件”。 |
4. | 单击“管理和监视工具”，然后单击“详细信息”。 |
5. | 单击以选中“网络监视工具”复选框，然后单击“确定”。 |
6. | 单击“下一步”。
|
如何在 Windows XP 中捕获网络流量
如果使用在 Windows XP 支持工具中提供的 Netcap.exe 版本，使用以下过程：
1. | 依次单击“开始”、“所有程序”、“附件”和“命令提示符”。 |
2. | 在命令提示符窗口中，键入： Netcap.exe /c:path 其中path是要存储此网络记录的目录和文件名的完全路径，然后按 ENTER 键。 |
3. | 在复制错误之后，键入： Netcap.exe /remove 然后按 ENTER 键。这将停止网络捕获。 |
在 Windows 2000 中捕获网络流量的过程和在 Windows 和 Windows Server 2003 中捕获网络流量的过程与 Windows
XP 的过程不同。对这些操作系统使用如下过程：
如何在 Windows 和 Windows Server 2003 家族中捕获网络流量
1. | 依次单击“开始”、“控制面板”、“性能和维护”和“管理工具”，然后双击“网络监视器”。 |
2. | 单击“启动”按钮开始捕获网络流量。 |
3. | 复制错误。 |
4. | 单击“停止”按钮以停止捕获网络流量。 |
5. | 在右侧的捕获统计信息中，验证没有因为缓冲器溢出而丢失数据包。如果丢失了任何数据包，在“捕获”菜单上的“缓冲器设置”对话框中增加缓冲器的大小，并重新执行捕获。 |
更多信息请参见 Microsoft TechNet 上的“捕获网络帧”，位于：http://go.microsoft.com/fwlink/?LinkId=23052。
如何筛选特定于 Kerberos 的网络流量
可以筛选出来自除 Kerberos 协议之外的所有协议的包。为了应用一个只显示与 Kerberos
协议相关的网络流量的筛选器，在网络监视器中执行以下捕获：
1. | 单击“捕获”，然后单击“显示捕获的数据”。 |
2. | 单击“漏斗”按钮，然后双击协议 == 任何。 |
3. | 单击“禁用全部”。 |
从列表中选择
Kerberos，然后单击“启用”。单击“确定”，然后再次单击“确定”。在执行此过程之后，将只会出现 Kerberos
数据包。
如果在应用此筛选器之后没有出现数据包
可能的原因是：
| • | Kerberos 票证已发出或已缓存。可以使用 Kerberos List 来显示当前在计算机上发出的所有票证。还可以使用 Kerberos List |
| • | 没有尝试 Kerberos 身份验证协议。安全日志中相关的登录事件应该指出对用户进行身份验证所使用的协议。如果列出了 NTLM，则没有尝试 |
| • | 网络监视器缓冲器溢出。在高流量的网络中，如果使用默认的缓冲器大小来配置此工具，则很容易出现这种情况。 |
分析捕获到的 Kerberos 流量
在捕获了一些 Kerberos
包之后，可以通过确定捕获到的数据与成功的身份验证之间的区别来对问题进行诊断。在大多数情况下，诊断将涉及到以下包交换并在捕获的数据中查找 KRB_ERROR
包。不过在一些情况下，特别是在一切都正常的情况下，需要进行更深入的分析。“附录
C”中提供了几个捕获的网络数据的例子，这些例子说明了成功的登录并显示了常见的失败。对捕获的数据进行了注释，以帮助说明每个帧对身份验证尝试的成功或失败的影响。
更多信息请参见：
| • | Microsoft 知识库中的“如何使用网络监视器查看 HTTP 数据帧”，位于：http://go.microsoft.com/fwlink/?LinkId=23055。 |
| • | Microsoft 知识库中的“有关网络监视器的常见问题”，位于：http://go.microsoft.com/fwlink/?LinkId=23056。 |
Setspn
Setspn 工具设置 SPN。由于 SPN 是安全敏感的，所以如果具有域管理员权限，则只能为用户对象设置 SPN。
如何安装 Setspn
Setspn 工具包含在 Windows Server 2003 支持工具中。
如何使用 Setspn
| • | 为了添加一个 SPN，可以在命令提示符下键入以下命令： |
setspn –A ServiceClass/Host:Port AccountName
| • | 为了删除一个 SPN，可以在命令提示符下键入以下命令： |
setspn –D ServiceClass/Host:Port AccountName
| • | 为了查看为一个帐户注册的 SPN，可以在命令提示符下键入以下命令： |
setspn –L AccountName
| • | 为了重新设置一个帐户的主机名称的默认 SPN 注册，可以在命令提示符下键入以下命令： |
setspn –R AccountName
以下各节将讨论上面所列出的参数。
| • | ServiceClass。SPN 的种类有很多，应该为一台计算机上的每个服务都指定一个适当的 SPN 服务类。如果编写一个应用程序以利用 例如，当 Internet Explorer 版本 5.5 及更高版本使用 Kerberos 协议来身份验证到 Web 服务时，此应用程序将查找 HTTP |
| • | Host。SPN 所属于的计算机是服务在其上运行的计算机可以参考的所有名称。这通常包含一个 NetBIOS 名称、一个完全合格的域名 |
| • | Port。服务在其上运行的端口。如果这是此服务的默认端口（例如 HTTP 的 80 |
| • | AccountName。服务在其下运行的域帐户的名称。如果此服务作为本地系统或网络服务运行，则通常不需要为此服务显式地设置 |
附录 B：常见方案的配置示例
Internet Explorer 到 IIS 再到 SQL Server
图 28 Internet Explorer 到 IIS 再到 SQL Server
Internet Explorer 6
验证为 Kerberos 协议配置了客户端应用程序
这个过程将根据所使用的客户端应用程序而有所不同。对于 Internet Explorer 6，必须确保配置了集成的 Windows
身份验证并且站点位于本地 Intranet 区域中。
要配置集成的 Windows 身份验证
1. | 在 Internet Explorer 中的“工具”菜单上，单击“Internet |
2. | 在“安全”列表框中，选择“启用集成的 Windows |
3. | 重新启动 Internet Explorer。 |
有关此问题的信息，请参见 Microsoft 知识库中的“在升级到 Internet Explorer 6 之后无法协商 Kerberos
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=23045。
验证网站位于本地 Intranet 区域中
如果 Internet Explorer 尝试访问一个位于 Internet 区域的站点，则将不会使用 Kerberos 协议。Internet
区域站点不能使用集成的 Windows 身份验证，其原因包括这些协议通常通过 Web 代理工作等。如果站点位于 Internet 区域中，Internet
Explorer 将不会尝试使用 Kerberos 身份验证，并且将自动尝试 NTLM。在 Internet Explorer 的所有版本中，当访问一个希望使用
Kerberos 身份验证的网站时，必须验证此网站位于本地 Intranet 区域中。
注意
Internet Explorer
窗口的右下角中的一个图标指示了网站所处于的区域。此图标将为 Internet 区域显示“Internet”，为 Intranet 区域显示“本地
Intranet”。如果网站位于 Internet 区域中，则必须手动将站点添加到本地 Intranet 站点列表中。
要将一个站点添加到本地 Intranet 站点列表中
1. | 在 Internet Explorer 中，单击“工具”，然后单击“Internet 选项”。 |
2. | 单击“安全”选项卡，接着单击“本地 |
3. | 在将该网站添加到区域中：文本框中，键入要使用 Kerberos |
4. | 单击“确定”。 |
有关添加本地 Intranet 站点的自动过程，请参见 Microsoft TechNet 上的“管理 Internet Explorer
增强的安全性配置”白皮书中的以下主题，位于：http://go.microsoft.com/fwlink/?LinkId=26091。
| • | “使用组策略从安全区域添加或删除站点” |
| • | “使用 Internet Explorer 维护来执行受信任的站点和安全设置” |
IIS
验证为运行 IIS 的服务设置了一个 SPN
在命令提示符下键入：
setspn –L 帐户
其中帐户是运行 IIS 的服务器在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 IIS 帐户的 SPN：
| • | 一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。 |
| • | 一个是 HTTP/FQDN 的 SPN，其中 FQDN |
在大多数情况下，将为 IIS 自动使用 HOST/Host 和 HOST/FQDN。如果 IIS
作为本地系统或网络服务运行，则不需要手动设置任何 SPN。如果运行 IIS 的服务器的主机名具有一个别名，则通常要求注册 SPN。
疑难解答
如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这些 SPN 对于
Internet Explorer 正确地身份验证到 Web 服务器来说是必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
验证为 IIS 帐户配置了委派
通常情况下，IIS 在 本地系统或网络服务帐户下运行。
为了验证为委派信任了 IIS 帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||
2. | 找到 IIS 的服务帐户。 | ||||
3. | 右键单击此帐户，然后单击“属性”。
|
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证为模仿配置了中间层服务。
当运行 SQL 2000 时，必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。
在中间层是 IIS 的例子中，必须只为网站启用集成的 Windows 身份验证选项。这确保了使用的是 Kerberos 协议而不是其他协议。
要为只使用集成的 Windows 身份验证的网站配置目录安全性
1. | 打开“IIS 管理器”。 | ||||||
2. | 单击运行 IIS 的计算机的名称，然后单击“网站”。 | ||||||
3. | 右键单击网站的名称，然后单击“属性”。 | ||||||
4. | 单击“目录安全性”选项卡，然后在“身份验证和访问控制”下单击“编辑...”。 | ||||||
5. | 通过以下方式验证只选中了“集成的 Windows 身份验证”复选框：
|
SQL Server
验证为 SQL Server 帐户设置了一个 SPN
如果 SQL Server 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。
在命令提示符下键入：
setspn –L 帐户
其中帐户是 SQL Server 在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 SQL 服务的 SPN：
| • | 一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host |
| • | 一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server |
在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。
疑难解答
如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这些 SPN 是
Web 服务器或 Web 服务正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
Internet Explorer 到使用 ASP.NET Web 服务的 IIS 到 SQL Server
有关为委派配置 ASP.NET 应用程序的更多信息，请参见 Microsoft 知识库中的“如何为委派方案配置 ASP.NET 应用程序”，位于：http://go.microsoft.com/fwlink/?LinkId=24926。
图 32 Internet Explorer-ASP.NET-SQL Server 委派方案
Internet Explorer 6
验证为 Kerberos 协议配置了客户端应用程序
这个过程将根据所使用的客户端应用程序而有所不同。对于 Internet Explorer 6，必须确保配置了集成的 Windows
身份验证并且站点位于本地 Intranet 区域中。
要配置集成的 Windows 身份验证
1. | 在 Internet Explorer 中的“工具”菜单上，单击“Internet |
2. | 在“安全”列表框中，选择“启用集成的 Windows |
3. | 重新启动 Internet Explorer。 |
有关此问题的信息，请参见 Microsoft 知识库中的“在升级到 Internet Explorer 6 之后无法协商 Kerberos
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=23045。
验证网站位于本地 Intranet 区域中
如果 Internet Explorer 尝试访问一个位于 Internet 区域中的站点，则将不会使用 Kerberos 协议。Internet
区域站点不能使用集成的 Windows 身份验证，其原因包括这些协议通常通过 Web 代理进行工作等。如果站点位于 Internet 区域中，则
Internet Explorer 将不会尝试使用 Kerberos 身份验证，并且将自动尝试 NTLM。在 Internet Explorer
的所有版本中，当访问一个希望使用 Kerberos 身份验证的网站时，必须验证此网站位于本地 Intranet 区域中。
注意
Internet Explorer
窗口的右下角中的一个图标指示了网站所处于的区域。此图标将为 Internet 区域显示“Internet”，为 Intranet 区域显示“本地
Intranet”。如果网站位于 Internet 区域中，则必须手动将站点添加到本地 Intranet 站点列表中。
要将一个站点添加到本地 Intranet 站点列表中
1. | 在 Internet Explorer 中，单击“工具”，然后单击“Internet 选项”。 |
2. | 单击“安全”选项卡，接着单击“本地 |
3. | 在“将该网站添加到区域中：”文本框中，键入要使用 Kerberos |
4. | 单击“确定”。 |
有关添加本地 Intranet 站点的自动过程，请参见 Microsoft TechNet 上的“管理 Internet Explorer
增强的安全性配置”白皮书中的以下主题，位于：http://go.microsoft.com/fwlink/?LinkId=26091。
| • | “使用组策略从安全区域添加或删除站点” |
| • | “使用 Internet Explorer 维护来执行受信任的站点和安全设置” |
IIS/Web 服务
在 Internet Explorer 到 IIS 到 ASP.NET Web 服务再到 SQL Server 方案中，需要为 IIS 帐户、Web
服务帐户和 SQL 服务帐户注册 SPN。
验证为 IIS 帐户设置了一个 SPN
在命令提示符下键入：
setspn –L 帐户
其中帐户是运行 IIS 的服务器在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 IIS 帐户的 SPN：
| • | 一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。 |
| • | 一个是 HTTP/FQDN 的 SPN，其中 FQDN |
在大多数情况下，将为 IIS 自动使用 HOST/Host 和 HOST/FQDN。如果 IIS
作为本地系统或网络服务运行，则不需要手动设置任何 SPN。然而，如果运行 IIS 的服务器的主机名具有一个别名，则通常要求注册 SPN。
疑难解答
如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这些 SPN 对于
Internet Explorer 正确地身份验证到 Web 服务器来说是必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
验证为 Web 服务帐户设置了一个 SPN
在命令提示符下键入：
setspn –L帐户
其中帐户是 Web 服务在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 Web 服务帐户的 SPN：
| • | 一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。 |
| • | 一个是 HTTP/FQDN 的 SPN，其中 FQDN |
疑难解答
如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这两个 SPN 是必需的，以使
Web 服务器可以正确地将凭据委派到 Web 服务。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
验证为 IIS 服务器帐户配置了委派
通常情况下，IIS 在本地系统或网络服务帐户下运行。
为了验证为委派信任了 IIS 帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||||
2. | 找到 IIS 服务的帐户。 | ||||||
3. | 右键单击此帐户，然后单击“属性”。
在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。
|
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证为 Web 服务帐户配置了委派
通常 Web 服务在域用户帐户下运行。
为了验证为委派信任了 Web 服务帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||
2. | 找到 Web 服务的帐户。 | ||||
3. | 右键单击此帐户，然后单击“属性”。
在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。（参见图 36。）
|
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将帐户配置为使用不受限的委派，选择“信任此计算机来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将帐户配置为使用受限的委派，选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证为模仿配置了中间层服务
当运行 SQL 2000 时，必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。
当中间层是 IIS 和 ASP.NET Web 服务时，网站必须在“目录安全性”选项卡上只启用了“集成的 Windows
身份验证”选项。这确保了使用的是 Kerberos 协议而不是其他协议。此外，为了使委派可以与 ASP.NET Web
服务一起工作，在此服务中必须开启身份模仿。
要为只使用集成的 Windows 身份验证的网站配置目录安全性
1. | 打开“IIS 管理器”。 | ||||||
2. | 单击运行 IIS 的计算机的名称，然后单击“网站”。 | ||||||
3. | 右键单击网站的名称，然后单击“属性”。 | ||||||
4. | 单击“目录安全性”选项卡，然后在“身份验证和访问控制”下单击“编辑...”。 | ||||||
5. | 通过以下方式验证只选中了“集成的 Windows 身份验证”复选框：
|
为了在 ASP.NET 应用程序中为每个页面的请求模仿 IIS 身份验证的用户，必须在此应用程序的 Web.config 文件中包含一个
<identity> 标记，并将 Impersonate 属性设置为 True。此文件可以在网站和 Web
服务的虚拟根目录中找到。确保在 Web.config 文件中包含以下 <identity> 标记：
<identity impersonate=”true” />
如果 Web.config 文件中没有此标记，将其添加到此文件的 <system.web> 部分。
更多信息请参见 Microsoft 知识库中的“信息：在 ASP.NET 应用程序中执行模仿”，位于：http://go.microsoft.com/fwlink/?LinkId=24923。
SQL Server
验证为 SQL Server 帐户设置了一个 SPN
如果 SQL Server 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。
在命令提示符下键入：
setspn –L 帐户
其中帐户是 SQL Server 在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 SQL 服务帐户的 SPN：
| • | 一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host |
| • | 一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server |
在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。
疑难解答
如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这些 SPN 是
Web 服务器或 Web 服务正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
Internet Explorer 到使用非 Microsoft Web 服务的 IIS 再到 SQL Server
如果中间层是使用非 Microsoft Web 服务的 IIS，则网站必须启用了"集成的 Windows
身份验证"选项。（参见前面例子中的过程。）这确保了使用的是 Kerberos 协议而不是其他协议。其他 Web 服务也需要配置为模仿用户。
图 38 Internet Explorer 到使用非 Microsoft Web 服务的 IIS 到
SQL Server
| • | 按照前面例子“Internet Explorer 到 IIS 再到 SQL Server”配置 Internet Explorer 6、IIS 和 SQL |
| • | 配置非 Microsoft 的组件使用 Kerberos 协议来模仿用户。 |
客户端到 SQL Server 再到 SQL Server
图 39 SQL 到 SQL 委派方案
客户端
验证为 Kerberos 协议配置了客户端应用程序
将客户端配置为使用 Kerberos 身份验证。
注意
当使用 SQL Server
时，可以使用其他工具来帮助验证使用的是 TCP/IP 和 Kerberos 身份验证：
| • | 客户端网络工具可以用来验证客户端可以使用 TCP/IP 与 SQL Server 进行通信。 |
| • | 服务器网络工具可以用来验证 SQL Server 是否正在监听 TCP/IP。 |
| • | Osql 可以用来链接到 SQL Server。然后检查服务器上的网络流量或审核日志，以确定是否是使用 Kerberos |
SQL 服务 1
验证为 SQL 服务帐户 1 设置了一个 SPN
如果 SQL Server 1 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。
在命令提示符下键入：
setspn –L 帐户
其中帐户是 SQL Server 在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 SQL 服务帐户的 SPN：
| • | 一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host |
| • | 一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server |
在 SQL 2000 中，如果 SQL Server 帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。
疑难解答
如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这两个 SPN
是客户端正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
验证为 SQL 服务帐户 1 配置了委派
最佳的情况是，为委派信任 SQL 服务帐户 1，并为 SQL 服务帐户 2 的约束委派设置此帐户。
为了验证为委派信任了 SQL 服务帐户
1. | 打开“Active Directory 用户和计算机”。 | ||||||
2. | 找到 SQL 服务帐户 1 的帐户。 | ||||||
3. | 右键单击此帐户，然后单击“属性”。
在“帐户选项框中”，确认选中了“敏感帐户，不能被委派”。
|
在“委派”选项卡上，选择以下两个“信任”选项之一：
1. | 要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。 | ||||
2. | 要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：
|
验证为模仿和委派配置了中间层服务
当运行 SQL 2000 时，必须在运行 SQL Server 的服务器上使用 MDAC 2.6 或更高版本。
为了验证将连接的服务器配置为模仿用户，可以使用以下 TSQL 命令：
sp_helplinkedsrvlogin
此命令提供了有关对特定的连接服务器定义的用于分布式查询和远程存储过程的登录映射的信息。
语法
sp_helplinkedsrvlogin [ 'rmtsrvname' ] [
'locallogin' ]
参数
'rmtsrvname'应用登录映射的连接服务器的名称。rmtsrvname 是
sysname，默认值为 NULL。如果此参数的值为 NULL，则将返回所有对在运行 SQL Server
的本地计算机中定义的连接服务器定义的登录映射。
'locallogin'SQL Server 登录到具有一个到连接服务器
rmtsrvname 的映射的本地服务器。locallogin 是 sysname，默认值为 NULL。NULL 指定了返回在
rmtsrvname上定义的所有登录映射。如果不是 NULL，则必须已存在一个从 locallogin 到
rmtsrvname的映射。locallogin 可以是一个 SQL Server
登录或一个域用户。域用户必须被授予直接访问或通过已授予访问权限的组中的成员身份来访问 SQL Server 的权限。
要验证连接的服务器的设置
1. | 执行以下 TSQL 命令： sp_helplinkedsrvlogin 'SQLServer2' 此命令应该返回以下输出： Linked Server Local Login Is Self Mapping Remote Login ---------------- ------------- --------------- -------------- SQL Server 2 NULL 1 NULL (1 row(s) affected) |
2. | 在上面的输出中，验证用户不具有相关联的远程访问以及为模仿配置了客户端。（即，将 Is Self Mapping 设置为 |
要为模仿配置连接的服务器
1. | 展开一个服务器组，然后展开一个服务器。 |
2. | 展开“安全性”，右键单击“连接的服务器”，选择适当的连接服务器，然后单击“属性”。 |
3. | 在“安全性”选项卡上，选择“使用登录的当前安全上下文生成”，然后单击“确定”。 |
有关前面两个过程以及如何设置安全性以确保只有授权用户才能访问 SQL Server 中存储的数据和对象的更多信息，请参见 MSDN
中的“管理安全性”，位于：http://go.microsoft.com/fwlink/?LinkId=26092。
或者，可以通过从查询分析器运行以下命令来创建一个连接的服务器：
sp_addlinkedsrvlogin 'SQLServer2', 'true'
SQL 服务 2
验证为 SQL 服务帐户 2 设置了一个 SPN
如果 SQL Server 2 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。
在命令提示符下键入：
setspn –L 帐户
其中帐户是 SQL Server 2 在其下运行的帐户的名称。
为了使委派正常工作，必须存在以下两个 SQL 服务帐户 2 的 SPN：
| • | 一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host |
| • | 一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server 2 |
在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。
疑难解答
如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这两个 SPN
是中间层 SQL Server 正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。
如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。
附录 C：网络监视器捕获到的网络记录的示例
注意
下面的记录已经过更改以删除不相关的或不必要的信息。
在正常登录期间进行 Kerberos 身份验证
在这个例子中，Kerberos 客户端从 KDC 获取了一个 TGT 和会话票证。
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 7027; Total IP Length = 333; Options = No Options
UDP: Src Port: Unknown (1676); Dst Port: Kerberos (88); Length = 313 (0x139)
KERBEROS: KRB_AS_REQ
KERBEROS: Realm (realm[2]) =multi
KERBEROS: Server name (sname[3]) =krbtgt/multi
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/multi
KERBEROS: Host addresses (addresses[9])
KERBEROS: Host address =NetBIOS: IIS
*******************************************************************************
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 14792; Total IP Length = 1457; Options = No Options
UDP: Src Port: Kerberos (88); Dst Port: Unknown (1676); Length = 1437 (0x59D)
KERBEROS: KRB_AS_REP
KERBEROS: Client realm (crealm[3]) =MULTI.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =aaa
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =aaa
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/MULTI.EXAMPLE.COM
*******************************************************************************
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 7028; Total IP Length = 1436; Options = No Options
UDP: Src Port: Unknown (1677); Dst Port: Kerberos (88); Length = 1416 (0x588)
KERBEROS: KRB_TGS_REQ
KERBEROS: Pre-authentication Data (padata[3])
KERBEROS: Data type = PA-{AP|TGS}-REQ
KERBEROS: Ticket (ticket[3])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST
(Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Realm (realm[2]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[3]) =host/iis.multi.example.com
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_HST
(Serv with host name as instance)
KERBEROS: Principal name value (name-string[1]) =host/iis.multi.example.com
*******************************************************************************
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 14793; Total IP Length = 1422; Options = No Options
UDP: Src Port: Kerberos (88); Dst Port: Unknown (1677); Length = 1402 (0x57A)
KERBEROS: KRB_TGS_REP
KERBEROS: Client realm (crealm[3]) =MULTI.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =aaa
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =aaa
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =host/iis.multi.example.com
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_HST (Serv with host name as instance)
KERBEROS: Principal name value (name-string[1]) =host/iis.multi.example.com
一个成功的登录将包含初始的 KRB_AS_REQ 和 KRB_AS_REP 来获取 TGT。（这只会在第一次身份验证时发生。在客户端拥有一个 TGT
之后，在此 TGT 过期之前协议将不会在请求 TGT。）在交换 AS 消息之后，对于用户尝试访问的任意服务都将有一个服务票证的 KRB_TGS_REQ 和
KRB_TGS_REP。请注意在此交换中可以查看领域名称、发出请求的用户名、时间以及 SPN。在诊断 kerberos
身份验证的问题时，此信息常常是必需的。上面例子的数据包在剪裁之后只显示了必需的数据。在真正的网络捕获中，将显示更多的数据，其中包括票证选项和加密类型等。
IIS 到 SQL 的委派
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 7646; Total IP Length = 351; Options = No Options
+ UDP: Src Port: Unknown (2415); Dst Port: Kerberos (88); Length = 331 (0x14B)
KERBEROS: KRB_AS_REQ
KERBEROS: Request body (req-body[4])
+ KERBEROS: Client name (cname[1]) =Administrator
KERBEROS: Realm (realm[2]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[3]) =krbtgt/DOMXFLXD1.EXAMPLE.COM
*******************************************************************************
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 18180; Total IP Length = 1399; Options = No Options
+ UDP: Src Port: Kerberos (88); Dst Port: Unknown (2415); Length = 1379 (0x563)
KERBEROS: KRB_AS_REP
KERBEROS: Client realm (crealm[3]) =DOMXFLXD1.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =Administrator
KERBEROS: Principal name value (name-string[1]) =Administrator
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[2]) =krbtgt/DOMXFLXD1.EXAMPLE.COM
*******************************************************************************
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 7647; Total IP Length = 1380; Options = No Options
+ UDP: Src Port: Unknown (2416); Dst Port: Kerberos (88); Length = 1360 (0x550)
KERBEROS: KRB_TGS_REQ
KERBEROS: Realm (realm[2]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[3]) =MSSQLSvc/xflxe3.domxflxd1.example.com:1433
*******************************************************************************
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 18182; Total IP Length = 1370; Options = No Options
+ UDP: Src Port: Kerberos (88); Dst Port: Unknown (2416); Length = 1350 (0x546)
KERBEROS: KRB_TGS_REP
KERBEROS: Client realm (crealm[3]) =DOMXFLXD1.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =Administrator
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =Administrator
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[2]) =MSSQLSvc/xflxe3.domxflxd1.example.com:1433
这是一个客户端请求特定服务（在此例中是 SQL Server）的票证的一个典型的例子。客户端（作为 Administrator
运行的发出此请求的计算机）首先从 KDC 请求一个 TGT。然后，请求一个 SQL Server 的 SPN 的票证。所有的 SQL SPN 都属于服务类
MSSQLSvc。这个特定的服务器在主机 xflxe3.domxflxd1.example.com 上运行。请求被批准，并且客户端收到一个给予其运行 SQL
Server 的服务器的票证的应答。
附录 D：相关信息
| • | Microsoft TechNet 上的“管理权限的身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=25038 |
| • | Microsoft 知识库中的“Kerberos 常见问题解答”，位于：http://go.microsoft.com/fwlink/?LinkId=25039 |
| • | Microsoft 知识库中的“Windows 2000 中的 Kerberos 用户身份验证协议概述”，位于：http://go.microsoft.com/fwlink/?LinkId=24922 |
| • | Windows Server 2003 技术参考，位于：http://go.microsoft.com/fwlink/?LinkId=21711 |
感谢
Vincent Abella, Technical Editor, Microsoft Corporation
Leon Arber, University of Illinois at Urbana-Champaign
David Christiansen, Software Design Engineer, Microsoft Corporation
Mike Danseglio, Technical Writer, Microsoft Corporation
Xin Fan, Software Test Engineer, Microsoft Corporation
JK Jaganathan, Program Manager, Microsoft Corporation
Willis Johnson, Lead Programmer Writer, Microsoft Corporation
Steve Light, Escalation Engineer, Microsoft Corporation
David Longmuir, Technical Editor, Volt
Bala Neerumalla, Software Design Engineer, Microsoft Corporation
Michiko Short, Technical Writer, Microsoft Corporation
Tim Springston, Support Professional, Microsoft Corporation
Todd Stecher, Development Lead, Microsoft Corporation
Liqiang (Larry) Zhu, Software Design Engineer, Microsoft Corporation