Kerberos 协议转换和受限委派

本页内容

	简介
	验证 Web 应用程序用户
	Windows Server 2003 Kerberos 扩展
	示例方案源文件
	小结
	结论

简介

针对 Internet 上所部署的 Web 应用程序的安全威胁数量日益增加。在 Internet 上部署 Web 应用程序的企业必须处理各种安全问题，例如拒绝服务攻击、标识欺骗以及未经授权访问程序功能等等。您可以通过用户身份验证和授权过程来减少某些类型的安全风险，例如未经授权访问数据。本文档分析了您可以用于验证 Web 应用程序用户的各种要求，并讨论了 Microsoft Windows Server 2003 标准版、Windows Server 2003 企业版以及 Windows Server 2003 数据中心版中 Kerberos 身份验证协议的新扩展如何满足这些要求。请注意，本文档并非一种协议扩展规范，因此，对协议消息流和数据结构的详细解释并不在本文档范围之内。如果您熟悉扩展的功能并需要有关实施扩展的总结，则可以跳至文档结尾处的“小结”一节。

本文假设您基本了解 Kerberos 身份验证协议和 Windows 安全概念，例如用户权限和令牌。有关 Kerberos 协议基本知识，请参阅位于 Microsoft Web 站点的 "Exploring Kerberos, the Protocol for Distributed Security in Windows 2000" (http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx）。

本文档中的示例方案和示例代码采用了 Microsoft ASP.NET 编程的一些基本知识。

返回页首

验证 Web 应用程序用户

本节讨论了 Web 应用程序的某些特性，这些特性强调了 Web 应用程序身份验证协议的一些关键要求。

Web 应用程序可以使用各种协议来验证用户。例如，Web 应用程序可以使用 HTTP 支持的身份验证协议，或者 Web 应用程序还可以依靠与现有 Web 服务器基础结构配合使用的自定义身份验证机制（例如基于窗体和基于 cookie 的身份验证）。但是，并非所有身份验证机制都具有相同的安全属性；某些身份验证机制具有比其他身份验证机制更强的安全属性。例如，Kerberos 支持相互身份验证，而基于 cookie 的身份验证方案则不支持。

可伸缩且稳定的 Web 应用程序的设计器通常遵循提倡分层应用程序方法的设计原则。例如，基于 Web 的业务 (LOB) 应用程序可能包括表示层、业务逻辑层和数据层。通常，分层方法会引入基础网络和操作系统安全基础结构应能支持的委派要求。委派允许某项服务代表其他安全原则运作，从而能够访问全部网络资源。N 层应用程序可以使用委派来满足各种应用程序要求（例如，在原始用户上下文中进行审核或作出授权决策）。

一个更具体的示例便是基于 Web 的银行帐户提款应用程序，该应用程序的业务组件位于业务层中。该应用程序会验证 Web 用户是否具有从给定银行帐户中提取所请求金额 $1,000 US 的权限。该业务组件需要知道应用程序用户的标识以允许进行交易。在理想的方案中，身份验证协议会在整个端到端应用程序流中传播原始用户上下文，即使该流可能跨越计算机的物理边界。然后，位于各层的应用程序组件便可以检索原始用户上下文并相应地进行授权。

在本文档发布之时，Kerberos 是唯一一种广为采用的能够执行委派的身份验证协议。当 n 层应用程序不使用启用委派的身份验证协议时，通常会设计经由应用程序消息正文传递的用户标识符。如果在应用程序消息传送期间不对其采取进一步的安全措施，该方法便很容易造成消息修改，如此便会导致标识符被修改，进而导致违反安全性（例如标识欺骗）。除了委派之外，Kerberos 的其他好处在于能够使通讯的各方进行相互验证，并通过数据加密使应用程序消息在传送期间得到保护。

Kerberos 并非 Web 应用程序所使用的默认身份验证协议，因为 Kerberos 所使用的端口 88 通常会被企业防火墙所阻塞。由于此端口限制，很难在 Internet 环境中成功部署 Kerberos。

请注意：

理想的状况是：Web 应用程序使用的身份验证协议具有全部所需的 Kerberos 安全属性，并且可以轻松在 Internet 中进行部署。要排除上述某些限制，请考虑以下工程方法：

返回页首

Windows Server 2003 Kerberos 扩展

在 Windows Server 2003 中实施 Kerberos 协议时会有两种新的扩展：

注意：Web 地址可能会更改，因此您可能无法连接到此处提到的 Web 站点。

本文档的以下各节会描述 Windows Server 2003 中所包含的扩展。

协议转换扩展

如上一节所提到的那样，协议转换扩展允许某项服务代表 Kerberos 安全主体获得某项服务的 Kerberos 服务票证。该转换无需用户凭据。应用程序可以通过本节中描述的两种机制转换到 Kerberos。

用于转换到 Kerberos 协议的第一种方法是调用 LsaLogonUser Win32 函数或直接实例化 WindowsIdentity 类对象。已经定义了新的 KerbS4ULogon 登录消息类型和 KERB_S4U_LOGON 登录信息结构，以便通过 LsaLogonUser 函数支持协议转换。成功调用 LsaLogonUser 函数会返回 Windows 用户令牌。

Microsoft .NET Framework 程序集中具有新的 WindowsIdentity 类构造函数，该函数可以摘录 LsaLogonUser 函数以帮助托管代码应用程序使用 Kerberos 协议扩展功能。本文中的示例使用这一新的 WindowsIdentity 类。

根据调用程序进程是否具有 Act as part of the operating system 权限，可以返回两个用户令牌变体。当从不具有 Act as part of the operating system 权限的进程中进行调用时，会返回一个标识令牌。当调用程序进程指派有 Act as part of the operating system 权限时，会返回一个模拟令牌。Windows Server 2003 系列包括新的 SeImpersonatePrivilege 权限。只有具有该权限的进程才能获得模拟级别令牌，并使用这些令牌模拟用户执行某些操作系统功能。要使用通过协议转换获得的模拟级别令牌的全部功能，使用协议转换的调用程序进程必须具有 SeImpersonatePrivilege 和 Act as part of the operating system 权限。如果调用程序进程仅具有 Act as part of the operating system 权限，则当该进程尝试使用令牌进行模拟时，模拟级别令牌会降级为标识级别令牌。基本上，标识令牌允许进程确定与用户相关联的标识和权限，但是模拟令牌也允许进程具有令牌用户标识并使用该用户标识进行操作。用户令牌的级别不会直接决定调用程序进程是否可以随后使用受限委派来调用其他服务。如果您正确配置了服务帐户以使用 Kerberos 受限委派扩展，则调用程序进程可以使用通过协议转换获得的服务票证来获得用于其他服务的服务票证。（下一节将更加详细地讨论受限委派扩展。）

上述编程机制允许应用程序启动协议转换。此外，您还应该配置应用程序以使其作为使用 Kerberos 的服务运行。本文档的后面部分将更加详细地讨论编程和配置任务。

可用于将应用程序转换到 Kerberos 的第二种方法是通过其他现有的 Windows 集成的身份验证协议来实现，例如 HTTP 基本、简要或安全套接字层/传输层安全 (SSL/TLS)。有些应用程序设计为：当 Kerberos 协议不是用户身份验证层上的最佳选项时，使用非 Kerberos 的 Windows 集成的身份验证协议。如果需要或可能，后面的应用程序层可以切换到 Kerberos。图 1 中说明了此概念：

图 1：Windows 集成的身份验证协议的协议转换
查看全尺寸图片。

注意：本文档的后面部分将讨论两个可用于 Kerberos 协议转换的示例 Web 方案。

如果您是在 Active Directory 目录林中使用协议转换，则必须满足以下网络和操作系统要求：

要跨 Active Directory 目录林使用协议转换，还必须满足以下附加要求：

受限委派扩展

通过说明在 Windows 2000 中实施 Kerberos 委派的局限性，便能够最好地解释为何在 Windows Server 2003 中引入受限委派扩展。在 Windows 2000 Kerberos 委派模式中，Kerberos 密钥分发中心 (KDC) 不会限制 Kerberos 主体标识可以委派的服务作用域。换言之，当服务帐户受信委派之后，该帐户便可以代表经过身份验证的用户请求任何其他服务帐户的服务票证。（请参阅位于 MSDN Web 站点的 Windows 2000 Kerberos 身份验证白皮书，以获得有关委派方法的更多技术信息，地址为：http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx。）该委派方法不会为应用程序提供明确的机制，以指定将成为受信委派的服务帐户子集。本质上，应用程序会面临更多的跨越各种资源域的模拟风险，这些资源域具有不同级别的安全策略要求；某些安全策略并非像应用程序安全要求那样严格。从域管理员的角度来看，在企业中启用非受限 Kerberos 委派具有很大风险，因为无法从参与委派的服务器中排除不可信的服务器。

借助受限委派，域管理员可以配置服务帐户，以使它们只能委派给特定的服务帐户集。在运行 Windows Server 2003 的 Active Directory 上，将新的 Allowed-to-Delegate-to (A2D2) Active Directory 属性添加到服务帐户以帮助执行受限委派。A2D2属性列出了指定服务帐户允许委派的其他服务帐户的服务主体名称 (SPN)。当 Windows Server 2003 KDC 使用受限委派扩展处理服务票证请求时，KDC 会验证目标服务帐户是否在 A2D2 属性中列出。包括受限委派在内，运行 Windows Server 2003 的计算机支持两种委派模式：Kerberos 非受限委派和 Kerberos 受限委派。Kerberos 非受限委派在以下情况下受到支持：如果用户最初提供用户凭据以获得授予票证的票证 (TGT)（该票证可以转发给受信委派的服务）。这种操作与 Windows 2000 实施 Kerberos 的操作相同。某项服务可以在以下情况下使用受限委派：如果该服务可以针对要委派安全上下文的用户获得自己的 Kerberos 服务票证。既可以是用户直接通过 Kerberos 进行验证来获得服务票证，也可以是服务代表用户通过协议转换扩展来获得服务票证。请注意，受限委派仅在域内有效。

对于同时使用协议转换和受限委派的服务帐户而言，您必须在 Active Directory 中的服务帐户上设置新的控制标志 Trusted-to-Authenticate-for-Delegation (T2A4D)。只有域管理员才能更改控制标志值。如果为服务帐户设置了标志，则该帐户便可使用协议转换扩展来获得服务票证，并在以后使用该票证获得用于预先配置服务（使用 Kerberos）子集的服务票证。此外，您不能将模拟用户帐户标记为无法委派的敏感帐户。

通过扩展配置启用用户标识、模拟以及委派

您可以使用本文档中已讨论的扩展来执行多个与安全相关的操作。即使用户 Kerberos 身份验证凭据不可用，您也可以执行这些与安全相关的操作。例如，您可以：

应用程序是否可以执行上述一项或全部操作取决于您对服务帐户的配置。正如本文前面所讨论的那样，应用程序可以使用两种机制启动协议转换：通过编程方式调用 LsaLogonUser 函数或自动通过 Kerberos SSP。两种机制启动协议转换的必要条件有所不同。

图 2a、图 2b、图 2c 和图 2d 中的方案 A、方案 B、方案 C 和方案 D 显示了当您使用不同的服务帐户配置调用 LsaLogonUser 函数时的成功结果。

在图 2a 的方案 A 中，协议转换允许不具有 Act as part of the operating system 权限的服务获得仅用于作出应用程序授权决策的标识级别令牌。在该方案中，Act as part of the operating system 服务帐户不具有 Trusted-to-Authenticate-for-Delegation (T2A4D) 权限，并且已颁发的服务票证也没有设置 Forwardable 标志。没有设置 Forwardable 标志的票证无法用于受限委派操作。

图 2：a 方案 A：服务帐户不具有 TCB 并且未设置 T2A4D 标志
查看全尺寸图片。

在图 2b 的方案 B 中，服务帐户具有 Act as part of the operating system 权限，并且协议转换允许该服务获得模拟令牌。正如前面所述，服务进程还必须具有 SeImpersonatePrivilege 权限以使用模拟令牌，从而可以使用用户标识来运行。您一定不希望任意服务都能进行模拟并作为其他用户来运行。鉴于此，服务必须具有只能由本地管理员组的成员指派的 Act as part of the operating system 和 SeImpersonatePrivilege 权限。只有本地管理员才能赋予这些服务在运行它们的计算机上模拟用户的能力。与图 2a 中的方案 A 相同，通过方案 B 中的服务帐户获得的 Kerberos 服务票证没有设置 Forwardable 标志，因此该票证无法用于受限委派。

图 2：b 方案 B：服务帐户具有 TCB 并且未设置 T2A4D 标志
查看全尺寸图片。

该 T2A4D 控制标志由域管理员在 Active Directory 上针对服务帐户而设置，并且不依赖本地计算机上的 Act as part of the operating system 权限。在图 2c 的方案 C 中，当使用协议转换扩展处理服务票证请求时，颁发服务票证的 KDC 不会检查调用进程是否具有 Act as part of the operating system 或 SeImpersonatePrivilege 权限。鉴于此，KDC 会在设置 T2A4D 控制标志的情况下颁发已设置 Forwardable 标志的服务票证。如果请求服务和目标服务位于同一个域中，并且目标服务 (SPN) 在 Active Directory 中请求服务 A2D2 属性中列出，则 KDC 便会接受该服务票证作为受限委派请求。

图 2：c 方案 C：服务帐户具有 TCB 并且已设置 T2A4D 标志
查看全尺寸图片。

在图 2d 的方案 D 中，所颁发的服务票证已设置 Forwardable 标志，并且所创建的用户令牌为标识级别令牌，因为服务不具有 Act as part of the operating system 权限。尽管服务票证允许受限委派，但是服务无法使用标识级别令牌来模拟用户。多数实际的应用程序都需要模拟级别令牌以便在验证为委派用户之前执行与网络相关的操作。鉴于此，服务无法模拟用户并针对多数应用程序使用用于受限委派的服务票证。

图 2：d 方案 D：服务帐户不具有 TCB 并且已设置 T2A4D 标志
查看全尺寸图片。

如图 1 的方案中所示，如果协议转换由 Kerberos 安全支持提供程序 (SSP) 启动（例如，并未通过直接调用 LsaLogonUser 函数或 WindowsIdentity 类对象启动），则在 Kerberos SSP 尝试执行协议转换之前，该用户的模拟级别用户令牌必须已经存在。可以在之前通过任何 Windows 集成的 SSP 创建模拟级别用户令牌。服务还必须具有 SeImpersonatePrivilege 权限以模拟用户并通过 Kerberos SSP 启动协议转换扩展。随后，由 Active Directory 策略和通过协议转换颁发的服务票证中 Forwardable 标志的状态来确定服务执行受限委派的能力。KDC 用于发行针对受限委派启用的服务票证的 Active Directory 策略检查与前面所述的标志相同（例如，T2A4D 和 A2D2 标志）。

示例 Web 服务方案

图 3 显示了两个简单的 Web 服务方案，这两个方案展示了 Kerberos 功能的工作方法。

第一个示例方案展示出 Kerberos SSP 启动协议转换的位置。该方案包含调用 ASP.NET Web 服务的浏览器客户端，该服务接着会在运行 Microsoft SQL Server 的计算机上调用存储过程。

第二个示例方案展示出协议转换如何通过编程方式实例化 WindowsIdentity 类对象进行工作的。在该方案中，浏览器客户端用于浏览 ASP.NET Web 应用程序，该应用程序会调用与第一个示例方案中所调用存储过程相同的 SQL Server 存储过程。

两个方案均经过配置以结合使用 Active Directory 目录林和单个域 Kerberos 密钥分发中心 (KDC)。请注意，您可以从同一台运行 Microsoft Internet 信息服务 (IIS) 的计算机的不同虚拟目录同时运行 ASP.NET Web 服务和应用程序。

要使示例方案生效，Active Directory 必须在 Windows Server 2003 标准版、Windows Server 2003 企业版或 Windows Server 2003 数据中心版上运行。同样，IIS 也必须在 Windows Server 2003 标准版、Windows Server 2003 企业版、Windows Server 2003 数据中心版或 Windows Server 2003 Web 版上运行。运行 SQL Server 2000 的计算机必须运行 Windows 2000 Professional、Windows 2000 Server、Windows 2000 Advanced Server、Windows 2000 Datacenter Server 或更高版本的 Windows。

示例方案一

示例方案一展示出以下身份验证流程：

为了进行演示，Web 服务使用 HTTP 简要身份验证进行初始用户身份验证。尽管该示例使用简要身份验证，但是您可以通过更改 IIS 目录安全配置来轻松修改该示例，以支持经由其他 Windows 集成的身份验证协议进行协议转换。

示例 Web 服务支持浏览器客户端所调用的公共 TestKerbSfu 方法。该 Web 服务方法然后会调用 GetUserInfo SQL server 存储过程，该过程会返回调用存储过程之用户的标识。Web 方法最终返回值是一个字符串，其中包含 Web 服务和存储过程的调用方标识。如果您已建立本文档中所述的示例，则返回字符串中的两个用户标识便会相同，并且它们会反映运行 Web 服务和存储过程代码所使用的域用户帐户。

在本方案中：

Web 服务使用 Kerberos 受限委派借助经过验证的浏览器用户标识获得用于 SQL Server 的服务票证。

图 3：示例方案
查看全尺寸图片。

示例方案二

示例方案二展示出一种略有不同的方法，您可以通过该方法来使用 Kerberos 协议转换扩展。在本方案中，以使用基于 ASP.NET 窗体之身份验证的 ASP.NET Web 应用程序替换 Web 服务来验证用户。Web 应用程序执行一系列交互式步骤，向您展示应用程序如何使用未集成到 Windows 操作系统中的身份验证协议来验证 Web 用户、然后转换到 Kerberos 以验证到后端服务，例如在示例方案一中使用的 SQL Server。

Web 应用程序展示出以下身份验证流程：

返回页首

示例方案源文件

本节中的示例使用 Microsoft Visual Studio .NET 并参考 Windows Server 2003 中 .NET Framework 运行时的实施。Windows Server 2003 中的 .NET Framework 运行时版本不同于 Visual Studio .NET 所包含的运行时版本。

您可以从 Microsoft 下载中心 Web 站点获得示例方案中的源代码和安装程序，地址为：http://download.microsoft.com/download/8/9/7/89734348-63AB-4F55-B11B-8C0AC50612B1/KerberosProtocolExtensions.msi。文件包含以下各项：

示例方案配置任务

注意：要完成以下配置步骤，您必须具有 Active Directory 的域管理员权限、ASP.NET Web 服务的本地管理员权限以及 SQL Server 的管理权限。

要建立示例，请执行以下步骤：

1.	配置域以便以 Windows Server 2003 功能级别运行： 1. 打开 "Active Directory Users and Computers" 管理控制台 (MMC) 管理单元。 2. 在控制台树中，右键单击 Active Directory User and Computers server_name，指向 All Tasks，然后单击 Raise Domain Functional Level。 3. 在 Select an available domain functional level 框中，单击 Windows Server 2003。
2.	为承载 ASP.NET Web 服务和应用程序的 IIS 进程池创建两个域用户帐户： 注意：虽然您可以使用安装有 IIS 之服务器上的默认 Network Service 帐户（所有新创建的 Web 应用程序都使用该帐户）运行示例 Web 服务和应用程序，但是 Network Service 帐户通常用于运行其他服务和 Web 应用程序。这意味着如果您赋予 Network Service 帐户使用协议转换和受限委派扩展的能力，则使用该帐户运行的其他进程也可以利用其他与 Kerberos 扩展相关的权限。这并不是所需的行为，因此，您应该将使用 Kerberos 扩展的能力单独赋予运行 Windows Server 2003 之计算机上的某个特定域用户帐户。 1. 打开 "Active Directory Users and Computers" MMC 管理单元。 2. 在控制台树中，双击 Active Directory Users and Computers server_name。 3. 在详细信息窗格中，右键单击 Users，指向 New，然后单击 User。 4. 在 New Object User 框中，键入适当的信息，然后完成该过程。 5. 对于第二个用户帐户，重复步骤 c 和步骤 d。
3.	为 SQL Server 服务创建域用户帐户。要执行此操作，请重复步骤 2 中的指示。
4.	为您在前面两个步骤中创建的用户帐户注册 Kerberos 服务主要名称 (SPN)。 要使用您创建为 Kerberos 服务帐户的域帐户，您必须使用 Setspn (Setspn.exe) 命令行工具为该帐户创建 SPN。例如，要为 kerbsfuidentity 域帐户添加名为 ws/kerbsfuidentity 的 SPN，请在命令提示下键入以下命令： setspn a ws/kerbsfuidentity kerbsfuidentity 要通过使用 sqlservice 服务帐户为在 sqlcomputer.devdomain.fabrikam.com 上运行的 SQL Server 服务创建 SPN，请在命令提示下键入以下命令： setspn a MSSQLSvc/sqlcomputer.devdomain.fabrikam.com:1433 sqlservice 注意：有关如何配置用于 KerberosFor 身份验证的 SQL Server 服务的更多信息，请参阅 MSDN Web 站点上的 Microsoft SQL Server 2000 Security (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_security2000.asp）。
5.	创建一个域用户帐户，该帐户将要用作方案一中 Web 浏览器用户身份验证以及方案二中协议转换的用户帐户。要创建域用户帐户，请重复步骤 2 中所述的过程。
6.	配置将要受信受限委派给 SQL Server 的服务帐户。 在示例方案中，您需要限制该服务帐户的功能，以便仅向特定的 SQL Server 服务帐户展示委派凭据。使用以下过程将特定的服务添加到您在步骤 2 中创建之服务帐户上的 A2D2 属性中： 1. 右键单击该用户帐户，然后单击 Properties。 2. 在 Properties 对话框中，单击 Delegation 选项卡，然后单击 Trust this user for delegation to specified services only。 3. 单击 Use any authentication protocol，然后单击 Add。 4. 单击您在步骤 4 中注册的 SQL Server 服务 SPN。 注意：仅当您已经为用户帐户创建 SPN 时，该用户帐户的 Delegation Property 选项卡才可用。步骤 4 描述了如何创建 SPN。
7.	在 Active Directory 中，授予服务帐户读取 tokenGroupsGlobalAndUniversal 用户对象属性的权限。 在 Active Directory 中，执行协议转换过程的服务帐户必须具有读取 tokenGroupsGlobalAndUniversal 用户对象属性的权限。要授予服务帐户读取权限，请执行以下步骤： 1. 打开 "Active Directory Users and Computers" MMC 管理单元。 2. 在控制台树中，单击 Builtin。 3. 在结果窗格中，右键单击 Windows Authorization Access Group，然后单击 Properties。 4. 单击 Members 选项卡，然后单击 Add。 5. 在 Enter the object names to select (examples) 框中，键入您在步骤 2 中创建的第一个服务帐户的名称，然后单击 OK。 6. 对于您在步骤 2 中创建的第二个服务帐户，重复步骤 7d 和步骤 7e。
8.	在运行 ASP.NET Web 服务和应用程序的计算机上，将服务帐户添加到 IIS 辅助进程组中： 1. 单击 Start，指向 Administrative Tools，然后单击 Computer Management。 2. 在控制台树中，单击 Local Users and Groups，然后单击 Groups。 3. 在结果窗格中，右键单击 IIS_WPG，然后单击 Add to Group。 4. 单击 Add，在 Enter the object names to select (examples) 框中键入服务帐户的名称，然后单击 OK。 注意：在本文档发布之时，您还需要手动配置服务帐户，使其可以访问 %SystemRoot%/Temp 文件夹，以便您可以运行 ASP.NET。请确认服务帐户具有对 %SystemRoot%/Temp 文件夹进行 List Folder\Read Data 和 Delete 的权限。
9.	部署 ASP.NET Web 服务： 1. 创建新的 IIS 进程池： 单击 Start，指向 Administrative Tools，然后单击 Computer Management。 在控制台树中，双击 Services and Applications，然后双击 Internet Information Services (IIS) Manager。 在控制台树中，右键单击 Application Pools，指向 New，然后单击 Application Pool。 在 Application Pool ID 框中，键入新应用程序池的名称，然后单击 OK。 2. 对于承载 ASP.NET Web 服务的进程池，将进程池标识设为您在步骤 2 中创建的用户帐户之一： 在 Application Pools 窗格中，右键单击您在前面步骤中创建的应用程序池，然后单击 Properties。 单击 Identity 选项卡，单击 Configurable，然后键入正确的用户名和密码。
10.	为 ASP.NET Web 服务创建新的虚拟目录。要执行此操作，请运行 KerbExtWebSvc 文件夹中的 Setup.exe 程序，以便启动可帮助您为 Web 服务建立虚拟目录的向导。
11.	配置 Web 服务以使用简要身份验证： 1. 单击 Start，依次指向 Programs、Administrative Tools，然后单击 Internet Information Services (IIS) Manager。 2. 右键单击 Web 服务虚拟目录，然后单击 Properties。 3. 单击 Directory Security t选项卡，然后在 Authentication and access control 框中单击 Edit。 4. 在 Authentication Methods 框中，确认 Digest authentication for Windows domain servers 复选框为选定的唯一复选框，单击 OK，然后单击 Apply。
12.	配置 Web 服务以使用您在步骤 9a 中创建的进程池： 1. 在 IIS 管理器中，右键单击 Web 服务虚拟目录，然后单击 Properties。 2. 单击 Virtual Directory 选项卡，单击 Application Pool，然后单击您在步骤 9a 中创建的应用程序池。
13.	在 Web 服务的 Web.config 文件中，配置运行 SQL Server 之计算机的名称。 Web 服务使用 Web.config 文件中的应用程序配置节来查找运行 SQL Server 之计算机的名称。鉴于此，您需要在 Web.config 文件中修改 sqlServer 键（在 <appSettings> 部分中）的值，以便指向运行 SQL Server 的计算机。例如，如果运行 SQL Server 之计算机的名称为 computer_name，则请打开文本编辑器（例如记事本），然后打开位于安装有 Web 服务之文件夹中的 Web.config 文件。搜索 <appSettings>，然后对文件进行以下更改： <appSettings> <add key="sqlServer" value="computer_name" /> </appSettings>
14.	部署 ASP.NET Web 应用程序： 1. 将 Act as part of the operating system 权限指派给您在步骤 2 中创建的用户帐户之一。该帐户应该不同于您在步骤 9b 中使用的帐户： 在承载 Web 应用程序的计算机上，单击 Start，指向 Administrative Tools，然后单击 Local Security Policy。 在控制台树中，双击 Local Policies，然后双击 User Rights Assignment。 右键单击 Act as part of the operating system 策略，指向 Properties，然后单击 Add user or Group。 键入您在步骤 2 中为承载 ASP.NET Web 应用程序之 IIS 进程池创建的用户帐户，然后单击 OK。 2. 为 Web 应用程序创建新的 IIS 进程池。要执行此操作，请重复步骤 9a 中的过程。 3. 将进程池标识设为在步骤 14a 中指派有 Act as part of the operating system 权限的用户帐户。要设置您在前面步骤中创建之进程池的标识，请重复步骤 9b 中的过程。 4. 为 ASP.NET Web 应用程序创建新的虚拟目录。要执行此操作，请运行 KerbExtWebApp 文件夹中的 Setup.exe 以启动向导。 5. 启用对 Web 应用程序的匿名访问： 使用 IIS 管理器，右键单击 Web 应用程序虚拟目录，然后单击 Properties。 单击 Directory Security 选项卡，然后在 Authentication and access control 框中单击 Edit。 在 Enable anonymous access 对话框中，确认 Authentication Methods 复选框为选定的唯一复选框，单击 OK，然后单击 Apply。 6. 配置 Web 应用程序以使用您在步骤 14b 中创建的进程池。要执行此操作，请重复步骤 12 中的过程，然后当系统提示时，请指定您在步骤 14b 中创建的进程池。
15.	在 Web 应用程序的 Web.config 文件中，配置运行 SQL Server 之计算机的名称。
16.	配置运行 SQL Server 的计算机： 1. 配置 SQL Server 以使用集成 Windows 验证： 单击 Start，依次指向 Programs、Microsoft SQL Server，然后单击 Enterprise Manager。 右键单击您要管理的 SQL Server 的实例，然后单击 Properties。 单击 Security 选项卡，然后单击 Windows only。 单击 This account，键入域用户名和密码以配置启动服务帐户从而使用您在步骤 3 中创建的用户帐户，然后单击 OK。 2. 通过运行 Kerbs4u.sql 脚本文件建立示例数据库和存储过程： 要运行 Kerbs4u.sql 脚本文件，请单击 Start，依次指向 Programs、Microsoft SQL Server，然后单击 Query Analyzer。 要连接到目标 SQL Server 计算机，请在 Connect to SQL Server 框中单击您要连接的 SQL Server，然后单击 OK。 在 File 菜单上，单击 Open。浏览至包含 Kerbs4u.sql 文件的示例文件夹，单击 Kerbs4u.sql 文件，然后单击 Open。 按 F5 键运行 SQL Server 脚本。 当您运行该脚本时，会创建 KerbS4uDB 数据库和 GetUserInfo 存储过程。当您成功运行该脚本时，SQL 查询分析器会返回与图 4 中输出相似的输出。 为您在步骤 5 中创建的用户帐户授予权限。 图 4：建立示例数据库和存储过程 查看全尺寸图片。

在以下配置步骤中，您将授予用户帐户登录 KerbS4uDB 的权限，然后添加权限以便用户具有运行 GetUserInfo 存储过程的权限：

运行示例

以下各节描述如何测试示例方案。

运行示例方案一

要运行示例方案一，请执行以下步骤：

<?xml version="1.0" encoding="utf-8" ?> 
<string xmlns=http://fabrikam.com/>web method user context: 
FABRIKAM\jeffpike; AuthenticationType: Digest; Sql server user 
context: FABRIKAM\jeffpike</string> 

注意：出于安全原因，仅当浏览器客户端与 Windows Server 2003 中的 Web 服务在同一台计算机上运行时，您才可以调用该 Web 方法。

返回字符串表明 fabrikam\jeffpike 域用户已经由 Digest 身份验证协议进行了验证。用于验证 SQL Server 连接的用户帐户通过 GetUserInfo 存储过程返回。要确认您已成功使用受限委派连接到 SQL Server，请查看运行 SQL Server 之计算机上的安全事件日志，以验证用户帐户已使用 Kerberos 身份验证程序包成功登录到网络。要查看安全事件日志，请右键单击 My Computer，单击 Manage，单击以展开 Event Viewer，然后单击 Security。图 5 显示了此登录事件的一个示例。在 Event Properties 对话框的底部显示转换服务信息。转换服务信息显示使用受限委派之服务的标识。请注意，必须配置计算机以便审核成功的登录从而捕获该事件。您可以通过 "Local Security Policy" MMC 管理单元中的 Audit Policy 选项启用该配置。

图 5：Kerberos 用户登录事件日志
查看全尺寸图片。

示例方案一代码演练

在示例方案一中，通过 HTTP 简要身份验证对用户进行验证。ASP.NET Framework 运行时会为经过身份验证的用户自动实例化 WindowsIdentity 对象。随后，Web 服务方法先模拟用户然后再验证到 SQL Server。以下代码示例提供了如何使用示例方案一的编程代码执行协议转换的一个示例：

[WebMethod]
public string TestKerbSfu()
{

    //
    // impersonate the user before connecting to the SQL database
    //
    
    WindowsIdentity userIdentity = Context.User.Identity as WindowsIdentity;
    WindowsImpersonationContext impContext = userIdentity.Impersonate();
    
    string userName = ConnectToSql( sqlServer );
    
    if( impContext != null )
    {
        impContext.Undo();
    }
    
}

private string ConnectToSql( string sqlServer )
{
    ...
    try
    {
        string connString = "integrated security=SSPI;initial
catalog=KerbS4uDB;data source=" + sqlServer + ";Connect Timeout=30";
        connection = new SqlConnection( connString );
        connection.Open();
        ...
     }
}

当调用 SqlConnection.Open 函数时，会执行多个处理步骤：

运行示例方案二

要运行示例方案二，请启动 Internet Explorer，在 Address 框中键入 Web 应用程序的 URL（例如，键入 http://www.fabrikam.com/KerbExtWebApp），然后按 ENTER 键。

Web 应用程序将浏览器重定向到用户登录页面。请注意，示例代码不会验证在登录页面中键入的用户和密码信息。通常，使用基于 ASP.NET 窗体之身份验证的 Web 应用程序先验证用户名和密码均有效然后再允许该用户使用 Web 应用程序。用户登录之后，浏览器会重定向到 Web 应用程序默认页面。默认页面是您键入想要 Web 应用程序用于协议转换的用户帐户所在的页面。当协议转换成功时，下一个 Web 页允许您通过受限委派连接到 SQL Server。当 SQL 存储过程返回时，浏览器会显示模拟和委派用户标识。与示例方案一相似，您可以检查运行 SQL Server 之计算机上的安全事件日志，以便查看在 SQL 连接身份验证期间记录的与 Kerberos 相关的事件。

示例方案二代码演练

方案二有两个您应该查看的代码示例。第一个代码示例用于启动 Kerberos 协议转换，第二个代码示例演示如何使用受限委派连接到 SQL Server。

以下代码示例显示了如何通过创建新的 WindowsIdentity 类对象实例来启动协议转换：

private void DoProtocolTransition_Click(
object sender, System.EventArgs e)
{
    ...
    WindowsIdentity newIdentity = new WindowsIdentity( UserAccount.Value );
    
    if( null == newIdentity )
    {
        Msg.Text = "Cannot do protocol transition, please try again";
        return;
    }
    
    //
    // Store this user as part of the HTTP session state
    //
    
    HttpContext.Current.Session.Add( "KerberosIdentity", ( object )newIdentity );
    ...
}

请注意，Web 浏览器用户可以在该 Web 应用程序中指定用于协议转换的 Kerberos 安全主体。通常，Web 应用程序可以使用用户映射表来确定将用作进行 Kerberos 协议转换的用户标识的 Kerberos 安全主体。上述代码显示了为您在 UserAccount.Value 变量中指定之用户创建的新 WindowsIdentity 类对象。类对象创建之后，WindowsIdentity 对象便会存储在 ASP.NET HTTP 会话状态中。当 Web 应用程序需要模拟用户并使用受限委派以验证到 SQL Server 的连接时，它可以从 HTTP 会话状态中检索该 WindowsIdentity 对象。以下代码示例显示了 Web 应用程序如何执行协议转换和受限委派：

...
//
// Get the user's Kerberos identity from the HTTP session state
//
WindowsIdentity user = ( WindowsIdentity )HttpContext.Current.Session[
                       "KerberosIdentity" ];
...
//
// impersonate the user before connecting to the SQL database
//

WindowsImpersonationContext impContext = user.Impersonate();
string userName = ConnectToSql( sqlServer );

Identity.Text = "Impersonated user identity = " + user.Name + "; SQL
Server user identity = " + userName;
if( impContext != null )
{
    impContext.Undo();
}
...

返回页首

小结

本节总结和定义了新协议扩展的一些要点。

协议转换

以下各项总结了本文档中所述的协议转换实施详细信息：

受限委派

以下各项总结了本文档中所述的受限委派实施详细信息：

返回页首

结论

委派是 n 层应用程序中经常出现的一种安全模式。在本文档发布之时，Kerberos 是唯一一种广为采用的具有委派属性的身份验证协议。在本文档中，讨论了运行 Windows Server 2003 之计算机上的 Kerberos 扩展。本文档还描述了扩展如何允许多个应用程序使用身份验证协议。示例代码展示了 n 层 Web 服务和应用程序如何使用新功能。

通过在用户身份验证层启用应用程序以支持不同的身份验证机制，以及通过在后面的应用程序层中切换到 Kerberos 协议以使用安全功能（例如相互身份验证和受限委派），协议转换为应用程序设计器提供了更大的灵活性和安全性，。

通过限制应用程序服务能够以用户身份运行的作用域，受限委派赋予管理员指定和强制应用程序信任边界的能力。通过减少受不可信服务损坏的机会，这种限制服务授权的灵活性有助于改善应用程序安全设计。

返回页首