• Kerberos 委派故障诊断


    Kerberos 委派故障诊断


    发布日期: 2004年11月03日










    **


    下载





    下载Kerberos_Delegation.doc

    1524 KB
    Microsoft Word
    文件





    **

    本白皮书说明了如何对在 Kerberos 身份验证方案中可能出现的委派问题进行故障诊断。本白皮书总结了必需的基础结构,并描述了 Windows®
    身份验证方案的例子。其中心内容是围绕四个故障诊断清单来组织的:Active Directory®
    目录服务、客户端应用程序、中间层和后端各一个清单。附录中详细介绍了诊断工具,并给出了如何在典型的 IIS 到 SQL 委派方案中解决问题的例子。


    本页内容
































    简介简介
    基础结构的要求基础结构的要求
    Windows 身份验证方案Windows 身份验证方案
    配置 Kerberos 委派配置 Kerberos 委派
    诊断委派问题:四个清单诊断委派问题:四个清单
    总结总结
    附录 A:诊断工具附录 A:诊断工具
    附录 B:常见方案的配置示例附录 B:常见方案的配置示例
    附录 C:网络监视器捕获到的网络记录的示例 附录 C:网络监视器捕获到的网络记录的示例
    附录 D:相关信息附录 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 质询响应

    图 1 NTLM 质询响应



    较早版本的 Windows 操作系统使用 NTLM 来验证凭据。在 NTLM
    协议中,客户端将用户名发送到服务器;服务器生成一个质询并将其发送到客户端;客户端使用用户的密码加密这个质询;客户端将一个响应发送到服务器。质询响应机制根据帐户是本地用户帐户还是域用户帐户而有所不同。










    本地用户帐户。服务器将检查它的安全帐户管理器
    (SAM)。如果服务器计算出一个相似的结果,它将验证用户的响应,构建一个访问令牌,并为用户建立一个会话。


    域用户帐户。服务器将质询和客户端的响应一起转发到域控制器。域控制器对响应进行验证,并将客户端的组信息发送到服务器计算机。服务器使用此信息构建一个访问令牌,并为用户建立一个会话。


    图 2 使用 NTLM 验证到后端服务器

    图 2 使用 NTLM 验证到后端服务器



    作为零用户访问


    NTLM
    要求客户端在需要连接远程服务器时具有用户的密码,但是此密码从不传送到服务器。其缺点是前端服务器无法使用用户的身份访问后端服务器,这是因为前端服务器不具有用户的密码。


    因此,只要前端服务器以用户方式尝试连接到后端服务器,它就会作为零用户进行连接。(参见图 2。)当 System 帐户下运行的一个进程尝试使用 NTLM
    协议访问远程资源时,也会出现零用户。因此,如果遇到一条内容为“拒绝零用户访问”的错误消息,则可以假定连接使用的是 NTLM。


    在 NTLM
    身份验证中,当用户验证前端服务器后,如果前端服务器需要访问在后端服务器上运行的服务,则无法保存用户的凭据。后端服务器接收到一个来自前端服务器帐户的身份验证请求,但是后端服务器:













    无法确定用户是谁。


    无法区分两个用户的身份以确定哪个用户向前端服务器发出了请求。


    无法根据用户的身份提供对资源的不同的访问控制。


    使用 NTLM 身份验证或单帐户映射的 Kerberos 身份验证


    图 3 Kerberos 和 NTLM 混合身份验证

    图 3 Kerberos 和 NTLM 混合身份验证



    Kerberos
    身份验证可以增强安全性,这是因为可以建立审核和可计量性。然而,前端服务器可能会具有在高流量的情况下对成千个唯一用户进行身份验证而增加的负载。另一方面,如果使用
    NTLM,在对前端服务器进行最初的身份验证之后,将不再需要对用户进行身份验证,而只需要验证计算机帐户。图 3 中显示的身份验证方案结合了 NTLM 和
    Kerberos
    身份验证。用户的身份将传送到另一台计算机以允许跟踪和记录,但是最后一次转发将在此计算机帐户之下进行以监听前端服务器上的负载。然而,由于前面在零用户情形下给出的相同的原因(即后端服务器无法验证请求服务的用户的身份),不推荐采用这种方式。


    一个相似的方案是将前端服务器配置为使用单个帐户来访问后端服务器。这将出现同样的结果,即使在两次转发中都使用了 Kerberos 身份验证。


    由于在这两种方案中都没有使用用户的身份来访问后端服务器,所以不推荐采用这两种方案。


    Kerberos 身份验证


    只有在使用 Kerberos 协议时才可以使用委派。因此,委派方案中所涉及的所有部分都必须使用 Kerberos 协议。本节将介绍三种委派方案:













    Kerberos 身份验证


    使用约束委派的 Kerberos 身份验证


    使用约束委派和协议转换的 Kerberos 身份验证


    Kerberos 身份验证


    图 4 基本的 Kerberos 委派

    图 4 基本的 Kerberos 委派



    如果使用 Kerberos
    身份验证,当用户验证到前端服务器时,服务器将从在自己的服务帐户下运行切换到在用户的帐户下运行。然后前端服务器可以模仿用户来访问此用户有权访问的任意资源。而且,后端服务器可以验证此用户是请求访问的实体。


    委派使用户的凭据可以从一台服务器传送到另一台服务器,并使用户的身份可以在从一台计算机到另一台计算机请求服务时予以保存。因此,图 4
    中显示的前端服务器可以由多台中间层服务器代替,但是仍然需要模仿用户来与后端服务器进行通信。


    注意
    必须为委派信任所有的中间层服务器。


    使用约束委派的 Kerberos 身份验证


    在 Windows Server 2003 中,约束委派为域管理员提供了一种对委派信任的帐户可以访问的网络资源进行限制的方式。


    另一方面,在 Windows 2000 中 Windows
    不支持对委派的限制。在为委派信任一个帐户之后,此服务就可以使用用户的身份访问任意的网络资源。如果这项特定的服务受到了恶意用户的损坏,则将非常危险。


    注意
    只有当域处于 2003
    域功能级时,才可以使用约束委派。在图 5 所示的一个客户端从 Windows Server
    上升到前端服务器再到后端服务器的方案中,必须将前端服务器配置为只对后端服务器使用委派。


    图 5 约束委派

    图 5 约束委派



    为了限制服务可以以用户方式访问的资源,可以通过列出帐户可向其提交委派凭据的服务来配置约束委派。此列表的形式为允许用户委派到的 SPN。在约束委派中,Web
    服务的帐户只接收委派到后端服务器的 SPN 的权限。


    图 6 遭破坏的 Web 服务

    图 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

    图 7 Kerberos 协议转换的 SSL



    由于在 Internet 上执行 Kerberos 身份验证是不现实的,所以前端服务器必须使用安全套接字层 (SSL)
    等方法。然而,在前端服务器验证了用户的身份之后,前端服务器可以执行协议转换,并随后在公司网络内部使用所有的 Kerberos
    身份验证功能。因此,开发者不需要使整个身份验证过程依赖于单个身份验证协议。


    有关协议转换和约束委派的更多信息,请参见 Microsoft TechNet 上的“Kerberos 协议转换和约束委派”,位于:http://go.microsoft.com/fwlink/?LinkId=18156



    配置 Kerberos 委派


    Kerberos 委派需要 Kerberos 身份验证。因此,在对委派进行故障诊断之前,确保已满足了 Kerberos
    身份验证的基础结构的要求。更多信息请参见本白皮书的“基础结构的要求”。


    图 8 Kerberos 委派的基本要求

    图 8 Kerberos 委派的基本要求



    委派的要求



















    应用程序的域用户不能选中敏感帐户,不能被委派选项。


    必须为中间层服务器上的服务注册 SPN。如果此服务帐户是一个域用户帐户,则此服务的 SPN
    必须由域管理员注册。如果此服务帐户使用计算机的帐户,则此过程可以自己注册或者由本地管理员使用 Setspn 来注册。有关 Setspn 的更多信息,请参见“附录
    A:诊断工具”中的“Setspn”。


    必须为委派信任中间层服务帐户。


    必须在后端服务器上为服务注册一个 SPN。


    如果使用了约束委派,则中间层服务和后端服务必须位于同一个域中。



    诊断委派问题:四个清单


    以下各节可以帮助您诊断在客户端到中间层到后端委派方案中出现的问题。此外,以下各节还可以帮助您应对在建立此方案时常常遇到的困难。


    这些小节描述了可能发生的各种问题,讨论了这些问题可能的原因,并阐述了解决这些问题的步骤。讨论将以清单的形式进行,每个清单都包含一个“任务”列和一个“过程”列。在大多数情况下,“过程”列概述了为了完成任务所需做的工作。不过,过程的详细信息将在清单后的小节中进行说明。
















    清单 1 — Active Directory。 正确地配置 SPN 和帐户。


    清单 2 — 客户端应用程序。正确地配置应用程序并使用 Kerberos 身份验证。


    清单 3 — 中间层。为委派正确地配置服务并使用 Kerberos 身份验证。


    清单 4 — 后端。为 Kerberos 身份验证配置服务。


    在一些组织中,配置帐户的管理员与对委派问题进行故障诊断的人可能并不相同。因此,在一个清单中收集了 Active Directory 任务。


    其他三个清单是通过方案中的角色来组织的,其中包含与以下角色相关的帐户配置信息:













    客户端。用户由其提出请求的应用程序。


    中间层。 位于中间的以用户方式提出请求的服务。


    后端。 最终与模仿用户的中间层服务进行通信的服务。


    对于清单来说,参加委派的每个系统或服务只会应用一个清单。也就是说,无论环境有多复杂,对所有的客户端使用客户端清单,对所有的后端服务使用后端清单,并且对位于中间的所有服务使用中间层清单。


    图 9 显示了在委派方案中可能涉及到的元素。


    图 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
    Script。


    如果服务器正在运行 IIS,则客户端应用程序可以是 Internet Explorer。


    在典型的委派使用中,用户直接或通过 Web 服务方式验证到运行 IIS 并访问 SQL 数据库的服务器,如果使用委派,中间层服务可以模仿具有访问 SQL
    数据库中的数据的权限的用户。在这种情况下,经常使用约束委派来使用户可以访问在计算机上运行的特定服务。


    清单 1 — Active Directory


    Active Directory:正确配置 SPN 和帐户




































    任务过程完成的数据/执行人
    从命令提示符执行









    验证为中间层服务注册了 SPN。


    验证为后端服务注册了 SPN。










    1.


    在命令提示符下键入:


    setspn –L 帐户


    其中帐户是服务在其下运行的帐户的名称。


    2.


    验证存在服务帐户的以下两个 SPN:










    一个是 ServiceClass/Host:Port 的 SPN


    一个是 ServiceClass/FQDN
    SPN


    详细的指导请参见“验证中间层服务帐户的 SPN”。


    有关的例子请参见“附录 B”。


    ?

    从“Active Directory 用户和计算机”









    如果使用了约束委派:


    验证域功能级已设置为 Windows Server
    2003。


    详细的指导请参见“验证域功能级”。











    对于用户帐户:


    确认未选中“敏感帐户,不能被委派”选项。













    1.


    右键单击用户帐户,然后单击“属性”。


    2.


    单击“帐户”选项卡。


    3.


    在“帐户选项”框中,确认未选中“敏感帐户,不能被委派”。


    详细的指导请参见“验证帐户选项”。








    验证为中间层服务配置了委派。


    如果中间层服务使用的是计算机帐户:







    右键单击计算机帐户,然后单击“属性”。










    如果此帐户在 Windows 2000
    功能级域中,确认选中了“帐户可以委派其他帐户”选项。


    如果此帐户在 Windows Server 2003
    功能级域中,配置“委派”选项卡上的各个选项。


    如果中间层服务使用的是域用户帐户:







    右键单击服务帐户,然后单击“属性”。










    如果此服务帐户在 Windows 2000
    功能级域中,应该选中“帐户”选项卡上的“帐户可以委派其他帐户”选项。


    如果此计算机帐户在 Windows Server 2003
    功能级域中,配置“委派”选项卡上的各个选项。


    详细的指导请参见“验证中间层服务帐户的委派”。


    有关的例子请参见“附录 B”。


    ?







    如果使用“组策略”进行配置,验证中间层服务具有以下两种权限之一:










    作为操作系统的一部分


    在身份验证之后模仿一个客户端










    1.


    通过单击“开始”,“程序”,“管理工具”,然后单击“域安全策略”来打开域安全策略。


    2.


    单击“本地策略”,然后单击“用户权限分配”。


    详细的指导请参见“验证中间层服务权限”。


    ?



    图 10 Active Directory 帐户配置

    图 10 Active Directory 帐户配置



    以下任务具有常规的配置指导。可以在“附录 B”中找到在常见的方案中需要设置的选项的示例。


    验证中间层服务帐户的 SPN


    验证为此方案中的每个中间层服务帐户都注册了一个 SPN。如果中间层服务作为本地系统或网络服务运行,则不需要手动设置任何 SPN。这样,由于所有的 SPN
    都将自动设置,所以不需要验证是否正确地设置了 SPN。


    验证为服务帐户设置了 SPN

    在命令提示符下键入:


    setspn –L 帐户


    其中帐户是服务帐户的名称。


    应该最少列出两个 SPN,这是因为为了使委派正常工作,必须存在以下两个服务帐户的 SPN:










    ServiceClass/Host:Port,其中 ServiceClass
    是适当的服务类,Host 是主机的名称,Port 是运行服务的端口。


    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 域功能级

    图 11 Windows Server 2003 域功能级



    重要
    Windows 2000
    不支持约束委派。由于不受限的委派会降低安全性,所以应避免在 Windows 2000 环境中使用委派。


    要验证域控制器的功能级













    1.


    打开“Active Directory 用户和计算机”。


    2.


    右键单击“DomainName”,然后单击“属性”。


    3.


    确认在“域功能级”下列出了 Windows Server 2003。


    验证用户帐户选项


    确认未选中用户帐户的“敏感帐户,不能被委派”选项。


    要确认未选中“敏感帐户,不能被委派”选项:
















    1.


    打开“Active Directory 用户和计算机”。


    2.


    右键单击“UserAccount”,然后单击“属性”。


    3.


    单击“帐户”选项卡。


    图 12 用户帐户选项

    图 12 用户帐户选项



    4.


    在“帐户选项”框中,确认未选中“敏感帐户,不能被委派”。


    验证中间层服务帐户的委派


    验证为委派信任此方案中的每个中间层服务帐户。如果有一个中间层服务帐户不信任委派,则将收到类似如下的错误信息:


    零用户登录失败


    NT AUTHORITY\ANONYMOUS 用户登录失败


    尽管在 客户端和中间层服务之间或中间层服务和后端服务之间可以使用 Kerberos
    协议,但是如果一项中间层服务未受到委派信任,则此中间层服务将不具有客户端的 TGT。这样,身份验证将退回到
    NTLM。由于中间层服务不具有网络凭据(即用户的密码),所以它将成为零用户。


    有关的例子请参见“附录 B”。


    服务在计算机帐户下运行

    如果服务在计算机帐户下运行,则需要为委派的服务器配置此计算机帐户。


    为了验证中间层服务器计算机帐户受到委派信任













    1.


    打开“Active Directory 用户和计算机”。


    2.


    找到中间层服务器的计算机帐户。


    3.


    右键单击此帐户,然后单击“属性”。







    如果此计算机帐户在 Windows 2000 功能级域中,应该选中“常规”选项卡上的“信任计算机作为委派”选项。(参见图
    13。)


    图 13 为委派信任功能级 Windows 2000 域计算机帐户

    图 13 为委派信任功能级 Windows 2000 域计算机帐户








    如果此计算机帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 14 没有为委派信任 Windows Server 2003 功能级域计算机帐户

    图 14 没有为委派信任 Windows Server 2003 功能级域计算机帐户



    在“委派”选项卡上,如果选中了“不信任此计算机作为委派”,则选择以下两个“信任”选项之一:










    1.


    要将帐户配置为使用不受限的委派,选择信任此计算机来委派任何服务(仅 Kerberos)。不推荐选择此选项。


    2.


    要将帐户配置为使用受限的委派,选择仅信任此计算机来委派指定服务。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。前面曾经提到过,SPN 本身由三个信息段(即 ServiceClass/Host:Port)组成,其中:


    ServiceClass 是 SPN 的服务类。


    Host 是 SPN 所属的计算机。


    Port 是注册 SPN
    的服务在其上运行的端口。


    如果服务在域用户帐户下运行

    如果服务在域用户帐户下运行,则需要为委派配置服务帐户。


    为了验证为委派信任了中间层服务帐户










    1.


    打开“Active Directory 用户和计算机”。


    2.


    定位到所要配置的帐户,右键单击此帐户,然后单击“属性”。







    如果此计算机帐户在 Windows 2000 功能级域中,单击“帐户”选项卡。


    图 15 为委派信任服务帐户

    图 15 为委派信任服务帐户



    在“帐户选项”框中,确认选中了“敏感帐户,不能被委派”。







    如果此服务帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 16 不使用协议转换的服务帐户

    图 16 不使用协议转换的服务帐户



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将此帐户配置为使用不受限的委派,选择“信任此用户来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将此帐户配置为使用受限的委派,选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将此帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。(参见图 16。)


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成,其中:


    ServiceClass 是 SPN 的服务类。


    Host 是 SPN 所属的计算机。


    Port 是注册 SPN
    的服务在其上运行的端口。


    验证中间层服务权限


    由于模仿另一个用户的能力是委派的一个主要部分,所以如果一个过程没有所需的权限,它将无法委派。因此,验证委派方案中的每个中间层服务都具有以下两种权限之一:










    作为操作系统的一部分(在 Windows 2000 或 Windows Server 2003 中可用)


    在身份验证之后模仿一个客户端(在 Windows Server 2003 中新增)


    这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似,只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿,而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。


    默认情况下,为本地系统帐户分配“作为操作系统的一部分”权限。因此,如果中间层服务在本地系统帐户下运行,则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户,需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。如果使用组策略配置这些权限,则需要验证在域控制器上正确配置了策略。如果使用本地安全策略进行配置,在“清单
    3 — 中间层”中对此过程进行了介绍。


    如果使用了协议转换,中间层服务常常没有关于传入的用户身份的信息——也就是说,传入的用户在身份验证时所使用的协议可能没有提供与 Kerberos
    身份验证相同的一组完整的凭据。因此,需要为这些中间层服务分配“作为操作系统的一部分”权限。


    例如,尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户,但是它并没有正式对此用户进行身份验证。因此,运行 IIS
    的中间层服务必须具有“作为操作系统的一部分”权限,以便在一个用户请求 Web 服务或后端服务器时模仿此用户。


    这样,应该为第一个中间层服务配置“作为操作系统的一部分”权限。然而,由于“在身份验证之后模仿一个客户端”权限不能进行远程访问,所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限(如果使用的是
    Windows Server 2003)。


    为了验证服务帐户具有适当的权限










    1.


    通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。


    注意
    如果域控制器实施了组策略,则遵循步骤
    1 中的指导。如果本地计算机实施了策略,则必须在本地计算机上打开本地安全策略。关于本地安全策略的指导请参见“清单 3 — 中间层”。


    2.


    单击“本地策略”,然后单击“用户权限分配”。


    例如,图 17 显示了为 Tailspintoys\iisservice 分配了“在身份验证之后模仿一个客户端”权限。


    图 17 默认域安全设置中的用户权限分配

    图 17 默认域安全设置中的用户权限分配



    为了对服务帐户设置“在身份验证之后模仿一个客户端”权限
















    1.


    通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。(参见上方过程中的“注意”部分。)


    2.


    单击“本地策略”,再单击“用户权限分配”,然后单击“在身份验证之后模仿一个客户端”。


    3.


    添加所有需要委派凭据的帐户(例如 IIS 帐户)。


    4.


    由于更改是在域控制器上的域安全策略中进行的,接着在命令提示符下对客户端计算机运行 gpupdate
    /force
    ,以立即传播策略的更改。


    清单 2 — 客户端应用程序


    客户端应用程序:为 Kerberos 身份验证配置并使用此身份验证
























    任务过程完成的数据/执行人






    从“Active Directory 用户和计算机”:







    验证未选中此帐户的“敏感帐户,不能被委派”选项。(注意:如果完成了 Active Directory
    清单,就完成了此任务。)













    1.


    右键单击用户帐户,然后单击“属性”。


    2.


    单击“帐户”选项卡。


    3.


    在“帐户选项”框中,确认未选中“敏感帐户,不能被委派”。


    详细的指导请参见“验证用户帐户选项”。



    验证名称解析工作正常。













    1.


    使用 ping 来验证可用解析中间层服务器和后端服务器的 FQDN。


    2.


    验证客户端的本地 Hosts 文件不具有中间层服务器和后端服务器的短名称。


    3.


    如果客户端和服务器位于不同的域中,确保为连接使用服务器的
    FQDN。


    详细的指导请参见“验证名称解析”。



    验证为 Kerberos 协议配置了客户端应用程序。


    详细的指导请参见“验证为 Kerberos 协议配置了应用程序”。


    有关的例子请参见“附录 B”。



    验证客户端使用 Kerberos 身份验证来身份验证到服务。


    可以通过以下方式进行验证:










    为 NTLM 故障审核检查中间层服务器上的安全日志。


    使用 Kerberos Tray 在连接到服务器之前清除票证,然后观察票证以找到一个连接到服务器的票证。


    使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。


    详细的指导请参见“验证客户端使用的是 Kerberos 身份验证”。


    ?



    图 18 Kerberos 客户端应用程序

    图 18 Kerberos 客户端应用程序



    验证用户帐户选项


    验证未选中用户帐户的“敏感帐户,不能被委派”选项。注意:如果按顺序完成以上清单,则此任务已在 Active Directory
    清单中完成。


    要验证未选中“敏感帐户,不能被委派”选项
















    1.


    打开“Active Directory 用户和计算机”。


    2.


    右键单击 UserAccount,然后单击“属性”,


    3.


    再单击“帐户”选项卡。


    图 19 用户帐户选项

    图 19 用户帐户选项



    4.


    在“帐户选项”框中,确认未选中“敏感帐户,不能被委派”。


    验证名称解析


    验证名称解析工作正常。Kerberos 身份验证要求每台计算机都可以解析与之通信的下一台计算机的 DNS
    名称,而不论此计算机是位于中间层还是在后端。










    使用 ping 验证可以进行以下解析:










    从客户端解析中间层服务器的 FQDN。


    从中间层服务器解析后端服务器的 FQDN。


    Ping 通常返回服务器的 FQDN 及 IP 地址。确保客户端的本地 Hosts
    文件不具有中间层服务器或后端服务器的短名称。


    如果客户端和服务器位于不同的域中,为连接使用服务器的 FQDN。如果使用 NetBIOS
    名称,则客户端计算机可能会解析一个本地域主体。这可能会造成身份验证的失败,这是因为客户端在本地域中找到了服务器的不正确的 SPN
    并将其发送到远程的域目标。


    可以使用 Net view 从命令行验证以下问题。













    为测试 HOST/ServerName SPN 并验证到正确的 NetBIOS SPN 的解析,在命令提示符下键入:


    net view \\NetBIOSName


    注意
    如果为本地命名的主体 SPN
    而不是远程目标对名称进行解析,则身份验证将失败。在本地域中存在失效的或作废的对象时,这种情况很常见。经过 NetBIOS 和 FQDN
    的名称解析将解析到正确的远程目标,但是 SPN 查找将解析到本地主体。


    为了验证 HOST/FQDN SPN(在林中应是唯一的),从命令提示符键入:


    net view \\FQDN


    如果使用 NTLM 的 Net view 失败,则身份验证可能不是问题。为了验证 NTLM,从命令提示符键入:


    net view \\IPAddress


    例如,如果使用 NetBIOS 解析一个本地域主体,则 Net view 将给出以下结果:













    如果 SPN 查找解析到错误的本地主体并且 Kerberos 身份验证失败,则 net view \\NetBIOSName
    将由于拒绝访问而失败。


    如果 SPN 查找解析到正确的远程主体并且 Kerberos 身份验证成功,则 net view \\FQDN
    将成功完成。


    如果使用 NTLM,则 net view \\IPAddress
    将成功完成。


    验证为 Kerberos 协议配置了应用程序










    验证客户端应用程序支持 Kerberos 身份验证。


    注意
    Internet Explorer
    版本 5.5 及更高版本都支持 Kerberos 身份验证。


    验证为 Kerberos
    协议配置了客户端应用程序。这个过程将根据所使用的客户端应用程序而有所不同。


    有关的例子请参见“附录 B”。


    验证客户端使用的是 Kerberos 身份验证


    为了验证客户端使用 Kerberos 身份验证来验证服务,在域用户帐户下使用客户端身份验证连接到此服务。(Kerberos
    身份验证只能在域用户帐户下进行,而不能在本地计算机用户帐户下进行。)


    即使可以成功地连接,此连接也可能在 NTLM 上发生。因此,通过以下方式验证使用的是 Kerberos 身份验证数据包:













    为 NTLM 成功审核检查中间层服务器上的安全日志。有关启用审核和使用安全日志的更多信息,请参见“附录
    A:诊断工具”中的“安全事件日志”。


    在连接到服务器之前使用 Kerberos Tray 清除票证,然后观察票证以找到一个连接到服务器的票证。更多信息请参见“附录
    A:诊断工具”中的“Kerberos Tray”。


    使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。如果拥有一个 Kerberos
    分析程序,则可以很容易地观察流量并从流量中找出错误消息。此外,从域控制器到客户端的较大的流量表示一个成功的 Kerberos 连接。更多信息请参见“附录
    A:诊断工具”中的“网络监视器”。


    有关使用审核、调试输出和网络跟踪对 Kerberos 身份验证进行故障诊断的更多信息,请参见“故障诊断 Kerberos 错误”白皮书,位于:http://go.microsoft.com/fwlink/?LinkID=27176


    如果使用 Kerberos 协议建立了连接,确保用户具有访问服务器的权限。如果用户不具有此权限,则可能会收到类似“用户
    domain\UserName 不具有查看资源的权限”或“拒绝
    domain\UserName 访问”的错误。


    如果使用以下方式建立连接:










    Kerberos 协议,转到“清单 3 — 中间层”以继续诊断问题。


    NTLM,则两种可能的原因是:










    1.


    系统尝试使用 Kerberos 协议进行身份验证,但是返回了一条“帐户不在数据库中”错误消息或相关的错误消息。这样,系统将尝试使用 NTLM
    进行身份验证。Windows Server 2003 和 Windows 2000 使用一种名为 Negotiate (SPNEGO) XP 的算法以及
    Windows 来协商使用哪种身份验证协议。尽管 Kerberos 协议是默认协议,但是如果默认协议失败,Negotiate 将尝试 NTLM。有关故障诊断
    Kerberos 错误的更多信息,请参见“故障诊断 Kerberos 错误”白皮书,位于:http://go.microsoft.com/fwlink/?LinkID=27176


    2.


    调用 Negotiate 将返回 NTLM
    作为唯一可用的协议。


    如果发现仍然在使用 NTLM 身份验证,或者在应该使用 Kerberos 身份验证的情况下没有尝试 Kerberos
    身份验证,请联系“产品支持服务”以帮助诊断问题。


    清单 3 — 中间层


    如果中间层服务使用 NTLM 来验证下一项服务,则通常会收到类似如下的错误:


    零用户登录失败


    NT AUTHORITY\ANONYMOUS 用户登录失败


    如果已验证了每台计算机使用的都是 Kerberos
    协议,则此身份验证问题的一种可能的原因是没有为委派正确地配置中间层服务。在这种情况下,通常会收到类似如下的错误:


    UserName 登录失败


    中间层:配置服务以模仿用户




































    任务过程完成的数据/执行人






    验证中间层服务和服务器支持 Kerberos
    协议。









    从命令行提示符:







    验证为中间层服务注册了
    SPN。










    1.


    在命令提示符下键入:


    setspn –L 帐户


    其中帐户是服务在其下运行的帐户的名称。


    2.


    验证存在服务帐户的以下两个 SPN:










    一个是 ServiceClass/Host:Port
    SPN


    一个是 ServiceClass/FQDN
    SPN


    详细的指导请参见“验证中间层服务帐户的 SPN”。


    有关的例子请参见“附录 B”。








    从“Active Directory 用户和计算机”:







    验证为中间层服务配置了委派。(注意:如果按顺序完成以上清单,则此任务已在 Active Directory
    清单中完成。)


    如果中间层服务使用的是计算机帐户:







    右键单击计算机帐户,然后单击“属性”。










    如果此帐户在 Windows 2000
    功能级域中,验证选中了“帐户可以委派其他帐户”选项。


    如果此帐户在 Windows Server 2003
    功能级域中,配置“委派”选项卡上的选项。


    如果中间层服务使用的是域用户帐户:







    右键单击服务帐户,然后单击“属性”。










    如果此服务帐户在 Windows 2000
    功能级域中,验证选中了“帐户”选项卡上的“帐户可以委派其他帐户”选项。


    如果此服务在 Windows Server 2003
    功能级域中,配置“委派”选项卡上的各个选项。


    详细的指导请参见“验证中间层服务帐户的委派”。


    有关的例子请参见“附录 B”。








    从域安全策略组策略(如果完成了 Active Directory 清单,则已完成)或本地安全策略:







    验证中间层服务具有以下两种权限之一:










    作为操作系统的一部分


    在身份验证之后模仿客户端







    单击“本地策略”,然后单击“用户权限分配”。


    详细的指导请参见“验证中间层服务权限”。








    验证已授权用户访问中间层服务器上的所需的资源。









    验证为模仿配置了中间层服务。


    有关的例子请参见“附录 B”。








    验证中间层服务在连接到下一台服务器之前模仿用户。


    更多信息请参见“验证中间层服务模仿用户”。


    ?



    图 20 中间层服务支持 Kerberos 协议

    图 20 中间层服务支持 Kerberos 协议



    验证中间层支持 Kerberos 协议


    验证每个中间层服务或服务器都支持 Kerberos 协议。


    验证中间层的 SPN


    验证为每个中间层服务帐户都注册了一个 SPN。(注意:如果按顺序完成前面的全部清单,则此任务已在 Active Directory 清单中完成。)


    如果中间层服务作为本地系统或网络服务运行,则不需要手动设置任何 SPN。这样,由于所有的 SPN 都将自动设置,所以不需要验证是否正确地设置了
    SPN。


    验证为服务帐户设置了 SPN

    在命令提示符下键入:


    setspn –L帐户


    其中帐户是服务帐户的名称。


    应该至少列出两个 SPN,这是因为为了使委派正常工作,必须存在以下两个服务帐户的 SPN:










    ServiceClass/Host:Port,其中 ServiceClass
    是适当的服务类,Host 是主机的名称,Port 是运行服务的端口。


    ServiceClass/FQDN,其中 FQDN
    是主机的完全合格域名。


    疑难解答

    如果没有列出任何 SPN 或缺少一个 SPN,则使用 setspn –A 命令添加适当的 SPN。


    如果列出了重复的 SPN,则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。


    有关常见方案的例子请参见“附录 B”。


    验证域功能级


    如果配置的是约束委派,则需要验证域控制器在 Windows Server 2003 功能级上操作。(只有约束委派才需要此步骤。)


    注意:如果按顺序完成前面的全部清单,则此任务已在 Active Directory 清单中完成。


    图 21 Windows Server 2003 域功能级

    图 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.


    右键单击此帐户,然后单击“属性”。







    如果此计算机帐户在 Windows 2000 功能级域中,应该选中“常规”选项卡上的“信任计算机作为委派”选项。(参见图
    22。)


    图 22 为委派信任功能级 Windows 2000 域计算机帐户

    图 22 为委派信任功能级 Windows 2000 域计算机帐户








    如果此计算机帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 23 没有为委派信任 Windows Server 2003 功能级域计算机帐户

    图 23 没有为委派信任 Windows Server 2003 功能级域计算机帐户



    在“委派”选项卡上,如果选中了“不信任此计算机来委派”,则选择以下两个“信任”选项之一:










    1.


    要将帐户配置为使用不受限的委派,选择信任此计算机来委派任何服务(仅 Kerberos)。不推荐选择此选项。


    2.


    要将帐户配置为使用受限的委派,选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成,其中:


    ServiceClass 是 SPN 的服务类。


    Host 是 SPN 所属的计算机。


    Port 是注册 SPN
    的服务在其上运行的端口。


    服务在域用户帐户下运行

    如果服务在域用户帐户下运行,则需要为委派配置服务帐户。


    为了验证为委派信任了中间层服务帐户










    1.


    打开“Active Directory 用户和计算机”。


    2.


    定位到所要配置的帐户,右键单击此帐户,然后单击“属性”。







    如果配置的帐户在 Windows 2000 功能级域中,单击“帐户”选项卡。


    图 24 为委派信任服务帐户

    图 24 为委派信任服务帐户



    在“帐户选项”框中,确认选中了“敏感帐户,不能被委派”。







    如果此服务帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 25 不使用协议转换的服务帐户

    图 25 不使用协议转换的服务帐户



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将此帐户配置为使用不受限的委派,选择“信任此用户来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将此帐户配置为使用受限的委派,选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将此帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。(参见图 25。)


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成,其中:


    ServiceClass 是 SPN 的服务类。


    Host 是 SPN 所属的计算机。


    Port 是注册 SPN
    的服务在其上运行的端口。


    验证中间层服务权限


    注意:如果使用域安全策略进行配置,在“清单 1 — Active Directory”中对此过程进行了介绍。


    由于模仿另一个用户的能力是委派的一个主要部分,所以如果一个过程没有所需的权限,它将无法委派。因此,验证委派方案中的每个中间层服务都具有以下两种权限之一:










    作为操作系统的一部分(在 Windows 2000 或 Windows Server 2003 中可用)


    在身份验证之后模仿一个客户端(在 Windows Server 2003 中新增)


    这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似,只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿,而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。


    如果使用组策略配置这些权限,则需要验证在域控制器上正确配置了策略。


    默认情况下,为本地系统帐户分配“作为操作系统的一部分”权限。因此,如果中间层服务在本地系统帐户下运行,则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户,需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。


    如果使用了协议转换,中间层服务常常没有关于进来的用户身份的信息——也就是说,进来的用户在身份验证时所使用的协议可能没有提供与 Kerberos
    身份验证相同的一组完整的凭据。因此,需要为这些中间层服务分配“作为操作系统的一部分”权限。


    例如,尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户,但是它并没有正式对此用户进行身份验证。因此,运行 IIS
    的中间层服务必须具有“作为操作系统的一部分”权限,以便在一个用户请求 Web 服务或后端服务器时模仿此用户。


    这样,应该为第一个中间层服务配置“作为操作系统的一部分”用户权限设置。然而,由于“在身份验证之后模仿一个客户端”权限不能进行远程访问,所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限(如果使用的是
    Windows Server 2003)。


    为了验证服务帐户具有适当的权限










    1.


    通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”,打开本地安全策略。


    注意
    如果域控制器实施了策略,则遵循步骤 1
    中的指导。如果域控制器实施了策略,则必须打开域安全策略或组策略。


    2.


    单击“本地策略”,然后单击“用户权限分配”。


    例如,图 26 显示了为 Administrators 和 SERVICE 配置了“在身份验证之后模仿一个客户端”权限。


    图 26 本地安全设置中的用户权限分配

    图 26 本地安全设置中的用户权限分配



    为了为服务帐户设置“在身份验证之后模仿一个客户端”权限













    1.


    通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”,打开域安全策略。


    注意
    如果域控制器实施了策略,则遵循步骤 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。(注意:如果按顺序完成以上清单,则此任务已在 Active Directory
    清单中完成。)










    1.


    在命令提示符下键入:


    setspn –L 帐户


    其中帐户是服务在其下运行的帐户的名称。


    2.


    验证存在服务帐户的以下两个 SPN:










    一个是 ServiceClass/Host:Port
    SPN


    一个是 ServiceClass/FQDN
    SPN


    详细的指导请参见“验证后端服务帐户的 SPN”。


    有关的例子请参见“附录 B”。








    验证已授权用户访问后端服务器上的所需的资源。


    ?


    ?



    图 27 后端服务器

    图 27 后端服务器



    验证后端服务帐户的 SPN


    验证为方案中的每个后端服务帐户都注册了一个 SPN。(如果按顺序使用以上清单,则此任务已在 Active Directory 清单中完成。)


    如果后端服务作为本地系统或网络服务运行,则不需要手动设置任何 SPN。这样,由于所有的 SPN 都将自动设置,所以不需要验证是否正确设置了
    SPN。


    验证为服务帐户设置了一个 SPN

    在命令提示符下键入:


    setspn –L 帐户


    其中帐户是后端服务在其下运行的帐户的名称。







    验证存在使委派正常工作所需的以下两个后端服务帐户的 SPN:










    一个是 ServiceClass/Host:Port 的 SPN,其中 ServiceClass
    是适当的服务类,Host 是主机的名称,Port 是运行服务的端口。


    一个是 ServiceClass/FQDN 的 SPN,其中 FQDN
    是主机的完全合格域名。


    疑难解答

    如果没有列出任何 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
    /force
    ,以传播策略的更改。


    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 票证的加密类型。


    更新时间


    更新的票证的最大生存期(参见下面的表中的
    TicketFlags)。为了继续使用此票证,必须在到达已建立的结束时间之前以及在 RenewUntil
    中建立的过期数据之前对其进行更新。


    服务器


    票证的服务器和域。



    tgt

    列出初始的 Kerberos 票证授权票证 (TGT)。tgt显示了当前缓冲的票证的以下属性:











































    选项描述

    AltTargetDomainName


    为生成此票证的 InitializeSecurityContext 提供的名称,通常是一个
    SPN。


    DomainName


    服务的域名。


    结束时间


    票证失效的时间。在票证经过结束时间之后,将不能用于身份验证到服务。


    FullServiceName


    服务的帐户主体的规范名称。


    KeyExpirationTime


    来自 KDC 应答的过期时间。


    RenewUnitil


    更新的票证的最大生存期(参见 TicketFlags)。为了继续使用一个票证,必须对其进行更新。必须在结束时间和
    RenewUntil 中设置的过期时间之前更新票证。


    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-GuidObject-SidPwd-Last-Set
    SAM-Account-Type 属性。)


    -n


    省略二进制值的导出。


    -k


    忽略导入操作期间的错误并继续进行。以下是忽略的错误的一个完整的列表:






















    对象已是组的成员


    违反对象类(即指定的对象类不存在),如果导入的对象没有其他属性


    对象已存在


    违反约束条件


    属性或值已存在


    没有这样的对象


    -a UserDistinguishedName Password


    将命令设置为使用提供的 UserDistinguishedNamePassword
    运行。默认情况下,此命令将使用当前登录到网络的用户的凭据运行。


    -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.


    如果提示需要其他的文件,插入操作系统的安装光盘,或键入表示文件在网络上的位置的路径。


    注意
















    为了执行这个过程,您必须是本地计算机上的 Administrators 组的成员,或者必须已委派适当的权限。如果此计算机在一个域中,则 Domain
    Admins 组的成员可能可以执行此过程。


    要打开“Windows 组件向导”,依次单击“开始”、“控制面板”、“添加或删除程序”和“添加/删除
    Windows 组件
    ”。


    某些 Windows 组件需要在使用之前进行配置。如果安装了一个或多个这样的组件但是没有加以配置,则在单击“添加/删除 Windows
    组件
    ”时将显示一个需要配置的组件列表。要启动“Windows 组件向导”,单击“组件”。


    此过程将自动安装网络监视器驱动程序。


    如何在 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
    上网络监视是由 Netcap.exe 工具完成的。此工具只允许网络流量的捕获。而捕获的结果不能使用同一个工具查看。必须使用 Windows 2003
    家族上的网络监视器的 2000 或 Windows Server 完整版来查看捕获到的数据。


    如何在 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 身份验证。如果 NTLM 回退是在登录时或请求网络资源时发生的,则事件日志中可能包含有用的信息。更多信息请参见“故障诊断 Kerberos
    错误”白皮书,位于:http://go.microsoft.com/fwlink/?LinkID=27176


    网络监视器缓冲器溢出。在高流量的网络中,如果使用默认的缓冲器大小来配置此工具,则很容易出现这种情况。


    分析捕获到的 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 服务类。如果编写一个应用程序以利用
    Kerberos 身份验证和委派,则它将具有访问预先确定所需的特定类型的 SPN。


    例如,当 Internet Explorer 版本 5.5 及更高版本使用 Kerberos 协议来身份验证到 Web 服务时,此应用程序将查找 HTTP
    SPN。另一方面,SQL Server 客户端将查找 MSSQLSvc/ SPN。如果在一个 SPN 上使用了错误的服务类,则在一个服务搜索此
    SPN 时将无法定位此 SPN。


    Host。SPN 所属于的计算机是服务在其上运行的计算机可以参考的所有名称。这通常包含一个 NetBIOS 名称、一个完全合格的域名
    (FQDN) 和为此计算机指定的任意别名。需要为计算机所参考的每个名称设置一个独立的 SPN,并相应地更改
    Host参数。


    Port。服务在其上运行的端口。如果这是此服务的默认端口(例如 HTTP 的 80
    端口),则可以省略。然而,推荐不论运行的是什么服务都包含端口。


    AccountName。服务在其下运行的域帐户的名称。如果此服务作为本地系统或网络服务运行,则通常不需要为此服务显式地设置
    SPN,这是因为大多数常见的 SPN 服务类将自动映射到自动为每个计算机帐户生成的 HOST/
    SPN。



    附录 B:常见方案的配置示例


    Internet Explorer 到 IIS 再到 SQL Server


    图 28 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.


    单击“安全”选项卡,接着单击“本地
    Intranet
    ”,再单击“站点”,然后单击“高级”。


    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.


    右键单击此帐户,然后单击“属性”。










    如果 IIS 使用的是 Windows 2000
    功能级域中的帐户,应该选中“常规”选项卡上的“信任计算机作为委派”选项。(参见图 29。)


    图 29 为委派信任功能级 Windows 2000 域计算机帐户

    图 29 为委派信任功能级 Windows 2000 域计算机帐户



    如果 IIS 使用的是 Windows 2000
    功能级域中的帐户,单击“帐户”选项卡。在“帐户选项”框中,确认选中了“敏感帐户,不能被委派”选项。(参见图 30。)


    图 30 为委派信任服务帐户

    图 30 为委派信任服务帐户



    如果 IIS 帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 31 使用约束委派的 Windows Server 2003 功能级域用户帐户

    图 31 使用约束委派的 Windows Server 2003 功能级域用户帐户



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将此帐户配置为使用不受限的委派,选择“信任此用户来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将此帐户配置为使用受限的委派,选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成,在此情况下:


    MSSQLSvc 是 SQL Server 的服务类。


    SQLServer 是计算机的主机名。


    1433 是 SQL Server
    在其上运行的端口。


    验证为模仿配置了中间层服务。

    当运行 SQL 2000 时,必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。


    在中间层是 IIS 的例子中,必须只为网站启用集成的 Windows 身份验证选项。这确保了使用的是 Kerberos 协议而不是其他协议。


    要为只使用集成的 Windows 身份验证的网站配置目录安全性



















    1.


    打开“IIS 管理器”。


    2.


    单击运行 IIS 的计算机的名称,然后单击“网站”。


    3.


    右键单击网站的名称,然后单击“属性”。


    4.


    单击“目录安全性”选项卡,然后在“身份验证和访问控制”下单击“编辑...”。


    5.


    通过以下方式验证只选中了“集成的 Windows 身份验证”复选框:













    清除“启用匿名访问”。


    选择“集成的 Windows 身份验证”复选框。


    清除下面的这些复选框:


    Windows 域服务器的摘要式身份验证


    基本身份验证(以明文形式发送密码)


    .NET Passport 身份验证


    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 委派方案

    图 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.


    单击“安全”选项卡,接着单击“本地
    Intranet
    ”,再单击“站点”,然后单击“高级”。


    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.


    右键单击此帐户,然后单击“属性”。







    如果此计算机帐户在 Windows 2000 功能级域中,应该选中“常规”选项卡上的“信任计算机作为委派”选项。(参见图
    33。)


    图 33 为委派信任功能级 Windows 2000 域计算机帐户

    图 33 为委派信任功能级 Windows 2000 域计算机帐户








    如果此 IIS 帐户是 2000 功能级域中的用户帐户,单击 Windows“帐户”选项卡。


    图 34 为委派信任服务帐户

    图 34 为委派信任服务帐户



    在“帐户选项”框中,确认选中了“敏感帐户,不能被委派”。







    如果 IIS 使用的是 Windows Server 2003 功能级域中的计算机帐户或用户帐户,单击“委派”选项卡。


    图 35 IIS 服务器帐户委派到使用协议转换的 Web 服务

    图 35 IIS 服务器帐户委派到使用协议转换的 Web 服务



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将此帐户配置为使用不受限的委派,选择“信任此用户来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将此帐户配置为使用受限的委派,选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。这应该是 Web 服务帐户的 SPN(在 ASP.NET 方案下这应该是 ASP.NET
    在其下运行的帐户)。前面曾经提到过,SPN 本身由三个信息段(即 ServiceClass/Host:Port)组成,在 ASP.NET Web
    服务的情况下:


    HTTP 是 Web 服务的服务类。


    lisserver 是计算机的名称。


    80 端口是 Web
    服务在其上运行的端口。


    验证为 Web 服务帐户配置了委派

    通常 Web 服务在域用户帐户下运行。


    为了验证为委派信任了 Web 服务帐户













    1.


    打开“Active Directory 用户和计算机”。


    2.


    找到 Web 服务的帐户。


    3.


    右键单击此帐户,然后单击“属性”。







    如果此 Web 帐户使用的是 2000 功能级域中的用户帐户,单击 Windows“帐户”选项卡。


    图 36 为委派信任服务帐户

    图 36 为委派信任服务帐户



    在“帐户选项”框中,确认选中了“敏感帐户,不能被委派”。(参见图 36。)







    如果 Web 服务帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 37 Web 服务帐户委派到不使用协议转换的 SQL Server

    图 37 Web 服务帐户委派到不使用协议转换的 SQL Server



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将帐户配置为使用不受限的委派,选择“信任此计算机来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将帐户配置为使用受限的委派,选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成,在 SQL 服务的情况下:


    MSSQLSvc 是 SQL Server 的服务类。


    SQLServer 是计算机的主机名称。


    1433 是 SQL
    服务在其上运行的端口。


    验证为模仿配置了中间层服务

    当运行 SQL 2000 时,必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。


    当中间层是 IIS 和 ASP.NET Web 服务时,网站必须在“目录安全性”选项卡上只启用了“集成的 Windows
    身份验证
    ”选项。这确保了使用的是 Kerberos 协议而不是其他协议。此外,为了使委派可以与 ASP.NET Web
    服务一起工作,在此服务中必须开启身份模仿。


    要为只使用集成的 Windows 身份验证的网站配置目录安全性



















    1.


    打开“IIS 管理器”。


    2.


    单击运行 IIS 的计算机的名称,然后单击“网站”。


    3.


    右键单击网站的名称,然后单击“属性”。


    4.


    单击“目录安全性”选项卡,然后在“身份验证和访问控制”下单击“编辑...”。


    5.


    通过以下方式验证只选中了“集成的 Windows 身份验证”复选框:













    清除“启用匿名访问”。


    选择“集成的 Windows 身份验证”复选框。


    清除下面的这些复选框:


    Windows 域服务器的摘要式身份验证


    基本身份验证(以明文形式发送密码)


    .NET Passport 身份验证


    为了在 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

    图 38 Internet Explorer 到使用非 Microsoft Web 服务的 IIS 到
    SQL Server











    按照前面例子“Internet Explorer 到 IIS 再到 SQL Server”配置 Internet Explorer 6、IIS 和 SQL
    Server。


    配置非 Microsoft 的组件使用 Kerberos 协议来模仿用户。


    客户端到 SQL Server 再到 SQL Server


    图 39 SQL 到 SQL 委派方案

    图 39 SQL 到 SQL 委派方案



    客户端


    验证为 Kerberos 协议配置了客户端应用程序

    将客户端配置为使用 Kerberos 身份验证。


    注意
    当使用 SQL Server
    时,可以使用其他工具来帮助验证使用的是 TCP/IP 和 Kerberos 身份验证:













    客户端网络工具可以用来验证客户端可以使用 TCP/IP 与 SQL Server 进行通信。


    服务器网络工具可以用来验证 SQL Server 是否正在监听 TCP/IP。


    Osql 可以用来链接到 SQL Server。然后检查服务器上的网络流量或审核日志,以确定是否是使用 Kerberos
    身份验证程序包进行连接的。如果不是,查看网络记录中的 Kerberos 错误消息(如果启用了 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.


    右键单击此帐户,然后单击“属性”。







    如果此计算机帐户在 Windows 2000 功能级域中,验证选中了“常规”选项卡上的“信任计算机作为委派”选项。(参见图
    40。)


    图 40 为委派信任功能级 Windows 2000 域计算机帐户

    图 40 为委派信任功能级 Windows 2000 域计算机帐户








    如果此用户帐户在 Windows 2000 功能级域中,单击“帐户”选项卡。


    图 41 为委派信任服务帐户

    图 41 为委派信任服务帐户



    在“帐户选项框中”,确认选中了“敏感帐户,不能被委派”。







    如果此计算机或用户帐户在 Windows Server 2003 功能级域中,单击“委派”选项卡。


    图 42 使用约束委派的 Windows Server 2003 功能级域用户帐户

    图 42 使用约束委派的 Windows Server 2003 功能级域用户帐户



    在“委派”选项卡上,选择以下两个“信任”选项之一:










    1.


    要将此帐户配置为使用不受限的委派,选择“信任此用户来委派任何服务(仅 Kerberos)”。不推荐选择此选项。


    2.


    要将此帐户配置为使用受限的委派,选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换:










    要将帐户配置为使用约束委派而不进行协议转换,选择“仅使用 Kerberos”。


    要将帐户配置为使用约束委派并且进行协议转换,选择“使用任意身份验证协议”。


    注意
    在使用约束委派时,确认适当的 SPN
    在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过,SPN 本身由三个信息段(即
    ServiceClass/Host:Port)组成。在这种情况下:


    MSSQLSvc 是 SQL Server 的服务类。


    SQLServer 是 Host


    1433 是 SQL
    服务在其上运行的端口。


    验证为模仿和委派配置了中间层服务

    当运行 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)。


    要为模仿配置连接的服务器













    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

  • 相关阅读:
    数学
    数学
    Computer Science
    数学
    Computer Science
    元学习
    数学
    数学
    数学
    数学
  • 原文地址:https://www.cnblogs.com/liangqihui/p/2052060.html
Copyright © 2020-2023  润新知