发布日期： 2004年12月02日

发布者 Frederick Chong，Microsoft Corporation 的软件设计工程师

本文档涉及包含在 Windows Server 2003 标准版、Windows Server 2003 企业版以及

Windows Server 2003 数据中心版中的各种功能。您可以在 Windows Server 2003 Web

版操作系统上运行本文档中所讨论的绝大多数功能，而 Active Directory 和 Kerberos 密钥分发中心 (KDC)

除外。

本页内容

针对 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 应用程序可以使用 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 应用程序要求在各个身份验证层进行防火墙友好的身份验证

•

委派是 n 层 Web 应用程序经常需要的安全功能

理想的状况是：Web 应用程序使用的身份验证协议具有全部所需的 Kerberos 安全属性，并且可以轻松在 Internet

中进行部署。要排除上述某些限制，请考虑以下工程方法：

•

修改现有的身份验证协议(如 Basic、Digest 和

SSL)以使它们支持委派和相互身份验证。由于每个受支持的身份验证协议所需的设计和工程工作的范围不同，因此该方法并不可行。

•

修改 Kerberos 协议以使其穿过企业防火墙。该方法(或至少是与其功能等同的方法)并不可用。

•

执行足够的工程工作以使 Kerberos 协议成为在企业防火墙之后使用的默认身份验证协议，并且不依赖在 Web

服务器身份验证层使用以验证 Internet 用户的协议。该方法已经在 Windows Server 2003

系列中采用，用于帮助解决 Web 应用程序所遇到的委派问题。新的 Kerberos 协议扩展在不修改已部署的 Web

身份验证协议功能的情况下为 Web 应用程序提供重要的安全保障。

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

•

协议转换：协议转换扩展允许某项使用 Kerberos 的服务代表 Kerberos 主体获得某项服务的

Kerberos 服务票证，而无需该主体最初使用凭据进行 Kerberos 密钥发行中心 (KDC) 验证。

•

受限委派：受限委派扩展允许某项服务在通过 TGS_REQ 协议(如 IETF RFC 1510

中所定义)或在协议转换扩展中获得服务票证之后再针对其他服务的子集获得服务票证(使用委派用户标识)。

有关 RFC 1510 的更多信息，请参阅 IETF Web 站点 (http://www.ietf.org)。

注意：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 身份验证协议进行验证。

•

在步骤 2 中，当身份验证完成时，安全程序包会为经过身份验证的用户创建 Windows 用户令牌。请注意，如果用户通过

Kerberos 协议进行验证，则用户令牌间接链接到用户的 Kerberos 服务票证。如果用户未通过 Kerberos

进行验证，则没有与用户令牌相关联的服务票证。

•

在步骤 3 中，应用程序将模拟用户并连接到需要 Kerberos 进行身份验证的数据库服务器。

•

在步骤 4 中，Kerberos 安全程序包检测到用户令牌中没有 Kerberos 票证。

•

在步骤 5 中，Kerberos 安全支持提供程序 (SSP) 通过请求用于模拟用户的服务票证来自动启动协议转换。

图 1：Windows 集成的身份验证协议的协议转换

查看全尺寸图片。

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

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

•

您必须在运行 Windows Server 2003 的计算机上运行可启动协议转换的操作系统进程

•

服务和用户帐户信任路径域中用于协议转换的所有域控制器都必须运行 Windows Server

2003。有两种方法可完成此操作，您可以选择其中一种：

•

您可以将域中的所有域控制器都升级到运行 Windows Server 2003 的计算机

•

您可以将 Active Directory 站点(其中域控制器用于协议转换)中的所有域控制器都升级到运行 Windows

Server 2003 的计算机

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

•

两个 Active Directory 目录林都必须以 Windows Server 2003 目录林功能级别运行

•

目录林之间必须建立双向信任

受限委派扩展

通过说明在 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

身份验证凭据不可用，您也可以执行这些与安全相关的操作。例如，您可以：

•

获得用户的权限和授权信息。

•

通过使用用户标识运行应用程序请求来模拟用户。

•

使用给定的用户标识远程呼叫一组预先配置的 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。

示例方案一

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

1.

用户最初通过非 Kerberos Windows 身份验证协议验证到 Web 服务。该示例方案使用超文本传送协议 (HTTP)

简要身份验证。

2.

Web 服务先模拟经过身份验证的 Windows 用户，然后再连接到 SQL Server。

3.

Web 服务尝试打开到 SQL Server 的连接，并需要证明其标识。

4.

与 Web 服务在同一台计算机上运行的 Kerberos 身份验证程序包无法找到模拟用户的 Kerberos

票证，因此，在模拟用户上下文中使用协议转换获得用于 Web 服务的服务票证。

5.

Web 服务使用受限委派获得用于 SQL Server 的服务票证。在这种情况下，会使用模拟用户标识完成身份验证。

为了进行演示，Web 服务使用 HTTP 简要身份验证进行初始用户身份验证。尽管该示例使用简要身份验证，但是您可以通过更改

IIS 目录安全配置来轻松修改该示例，以支持经由其他 Windows 集成的身份验证协议进行协议转换。

示例 Web 服务支持浏览器客户端所调用的公共 TestKerbSfu 方法。该 Web 服务方法然后会调用

GetUserInfo SQL server 存储过程，该过程会返回调用存储过程之用户的标识。Web

方法最终返回值是一个字符串，其中包含 Web

服务和存储过程的调用方标识。如果您已建立本文档中所述的示例，则返回字符串中的两个用户标识便会相同，并且它们会反映运行 Web

服务和存储过程代码所使用的域用户帐户。

在本方案中：

1.

浏览器会通过 URL(例如

http://www.fabrikam.com/KerbExtWebSvc/authxws.asmx?op=TestKerbSfu)访问

Web 服务。

2.

浏览器会显示身份验证对话框，提示输入用户名和密码以验证到 Web 服务器。

3.

用户名和身份验证凭据发送到运行 IIS 以宿主 Web 服务的服务器。

4.

IIS 先执行 HTTP 简要身份验证然后再将 Web 服务请求转发给 .NET Framework .asmx

处理程序。

5.

在建立到 SQL Server 的连接之前，Web 服务通过获得用于 Web 服务的 Kerberos

服务票证来模拟经过身份验证的用户并转换到 Kerberos 协议。

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

图 3：示例方案

查看全尺寸图片。

示例方案二

示例方案二展示出一种略有不同的方法，您可以通过该方法来使用 Kerberos 协议转换扩展。在本方案中，以使用基于

ASP.NET 窗体之身份验证的 ASP.NET Web 应用程序替换 Web 服务来验证用户。Web

应用程序执行一系列交互式步骤，向您展示应用程序如何使用未集成到 Windows 操作系统中的身份验证协议来验证 Web

用户、然后转换到 Kerberos 以验证到后端服务，例如在示例方案一中使用的 SQL Server。

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

1.

浏览器客户端浏览至示例的虚拟目录并重定向到登录 Web 窗体。

2.

用户在登录 Web 窗体中键入用户名和密码，然后单击 Login。

3.

登录 Web 页使用自定义身份验证机制(例如，通过检查存储在 SQL Server

数据库中的哈希密码)验证用户，然后当身份验证成功后向浏览器发出登录 cookie。然后，用户重定向到 Web 应用程序的默认 Web

页。

4.

用户键入要用于 Kerberos 协议转换的唯一主要名称 (UPN)，然后单击Do protocol

transition。

5.

Web 应用程序使用指定的 UPN 转换到 Kerberos，然后将 Kerberos 安全上下文保存在 Web

应用程序会话状态中。

6.

如果用户单击 Invoke SQL Server，便可连接到 SQL Server。当用户单击该选项时，Web

应用程序会从应用程序会话状态中检索用户上下文，接着 Web 应用程序先模拟用户然后再连接到 SQL Server。

7.

当 SQL Server 要求 Web 应用程序进行验证时，Web 应用程序会借助模拟用户标识使用 Kerberos

受限委派来获得用于 SQL Server 的服务票证。

8.

Web 应用程序会返回响应字符串，该字符串显示模拟用户标识以及在 SQL Server 上进行验证的用户标识。

本节中的示例使用 Microsoft Visual Studio .NET 并参考 Windows Server 2003 中

.NET Framework 运行时的实施。Windows Server 2003 中的 .NET Framework

运行时版本不同于 Visual Studio .NET 所包含的运行时版本。

文件和文件夹 说明

Authxws\*

包含 ASP.NET Web 服务的实施。您需要创建一个指向 Authxws 文件夹的 IIS /Authxws

虚拟目录，以便可成功启动 Visual Studio .NET 项目。

WebApp\*

包含 ASP.NET Web 应用程序的实施。您需要创建一个指向 WebApp 文件夹的 WebApp IIS

虚拟目录，以便可成功启动 Visual Studio .NET 项目。

KerbExtWebSvc\*

包含 Visual Studio .NET 部署项目，该项目会生成可用于创建 ASP.NET Web 服务的安装程序。

KerbExtWebApp\*

包含 Visual Studio .NET 部署项目，该项目会生成用于创建 ASP.NET Web 应用程序的安装程序。

Sql\*

包含可建立示例数据库和存储过程的 SQL 脚本。

SfuIdentity\*

包含通过 LsaLogonUser 函数展示 Kerberos 协议转换的托管 C++

代码。请注意，示例的其余部分并没有使用本文件夹中的代码。该代码是需要使用本机 Win32 函数(而非

WindowsIdentity 类)之应用程序的示例代码。

示例方案配置任务

注意：要完成以下配置步骤，您必须具有 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 键(在

部分中)的值，以便指向运行 SQL

Server 的计算机。例如，如果运行 SQL Server 之计算机的名称为

computer_name，则请打开文本编辑器(例如记事本)，然后打开位于安装有 Web 服务之文件夹中的

Web.config 文件。搜索

，然后对文件进行以下更改：

value="computer_name"

/>

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 存储过程的权限：

1.

打开 "SQL Server Enterprise Manager" MMC 管理单元。

2.

右键单击 Logins，然后单击 New Login。

3.

在 SQL Server Login Properties New Login 对话框中单击 Windows

Authentication，在 Domain 框中单击用户登录域，在 Name 框中键入您在步骤

5 中创建的用户帐户，单击 Grant access，然后在 Database 框中，单击

Database 框中的 KerbS4uDB。

4.

单击 Database Access 选项卡，选中 KerbS4uDB 复选框，在

Database roles for KerbS4uDB 框中单击 public 行，然后单击

Properties。

5.

在 Database Role Properties public 对话框中，单击

Permissions。

6.

在 Exec 列中，选中 GetUserInfo 复选框，然后单击 OK。

运行示例

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

运行示例方案一

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

1.

启动 Internet Explorer，然后在 Address 框中键入 Web 服务方法的 URL。例如，键入

http://www.fabrikam.com/kerbextwebsvc/authxws.asmx?op=testkerbsfu。

2.

在简要身份验证的 Enter Network Password 对话框中，键入域用户名和密码，然后单击

OK。

3.

单击 Invoke 以发送对 TestKerbSfu Web

方法的测试调用。当该调用成功运行时，您会收到与以下返回字符串相似的返回字符串：

?>

xmlns=http://fabrikam.com/>web

method user context: FABRIKAM\jeffpike;

AuthenticationType: Digest; Sql server user

context:

FABRIKAM\jeffpike

注意：出于安全原因，仅当浏览器客户端与 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 函数时，会执行多个处理步骤：

1.

当 Web 服务连接到 SQL Server 时，会调用 Kerberos SSP。Kerberos SSP

查找模拟用户的模拟级别用户令牌；但是，Kerberos SSP 不会查找可供用户使用的 Kerberos 票证。

2.

Kerberos SSP 启动协议转换，然后以模拟用户的身份获得用于 Web 服务的服务票证。

3.

Kerberos SSP 通过受限委派获得用于 SQL Server 的服务票证。

运行示例方案二

要运行示例方案二，请启动 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(); } ...

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

协议转换

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

•

协议转换扩展可以通过两种方法启动：

•

以编程方式通过 LsaLogonUser 函数或 WindowsIdentity

类对象启动。当初始用户身份验证机制并不是 Windows 集成的身份验证协议之一时，建议使用该方法。进程对该函数必须具有 Act

as part of the operating system 权限以便创建模拟级别令牌。如果进程没有 Act as

part of the operating system 权限，便会创建标识级别令牌。

•

使用现有的 Windows 集成的身份验证协议以及凭据执行初始用户登录过程，并使用 Kerberos

协议转换执行其他服务的后续用户身份验证。如果您为初始登录创建的用户令牌是模拟级别令牌，则 Kerberos SSP

会启动协议转换扩展。

•

您必须在运行 Windows Server 2003 的计算机上运行可启动协议转换的操作系统进程。

•

您可以在 Active Directory 目录林中以及跨目录林使用协议转换。

•

当您在 Active Directory

目录林中使用协议转换时，位于用户和服务帐户信任路径中以及用于协议转换进程的所有域控制器都必须运行 Windows Server

2003。要满足此要求，请使用以下方法之一：

•

将参与协议转换之域中的所有域控制器都升级到运行 Windows Server 2003

的计算机。此方法要求域中的所有域控制器都运行 Windows Server 2003。

或者

•

将参与协议转换之 Active Directory 站点中的所有域控制器都升级到运行 Windows Server 2003

的计算机。此方法并不要求域中的所有域控制器都运行 Windows Server

2003。建议在以下情况下使用此方法：如果您无法将域中的所有域控制器升级到 Windows Server

2003，以及如果您可以将需要协议转换扩展的应用程序单独放在特定数量的 Active Directory

站点(您可以为其升级所有域控制器)中。

•

当您跨 Active Directory 目录林使用协议转换时，这两个目录林必须以 Windows Server 2003

目录林功能级别运行，而且它们之间必须建立双向信任。

受限委派

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

•

受限委派扩展受以下在 Active Directory 中设置的域策略的影响：

•

如果 Kerberos 并未用作初始用户身份验证协议，则请求服务必须受信受限委派(必须为请求服务设置 T2A4D

标志)。

•

请求服务必须经过授权以委派给目标服务(目标服务必须位于请求服务 A2D2 列表上)。

•

您无法跨域边界使用受限委派。受限委派限于单个域中的服务。域中的所有域控制器都必须运行 Windows Server

2003，而且域必须以 Windows Server 2003 功能级别运行。

委派是 n 层应用程序中经常出现的一种安全模式。在本文档发布之时，Kerberos

是唯一一种广为采用的具有委派属性的身份验证协议。在本文档中，讨论了运行 Windows Server 2003 之计算机上的

Kerberos 扩展。本文档还描述了扩展如何允许多个应用程序使用身份验证协议。示例代码展示了 n 层 Web

服务和应用程序如何使用新功能。

通过在用户身份验证层启用应用程序以支持不同的身份验证机制，以及通过在后面的应用程序层中切换到 Kerberos

协议以使用安全功能(例如相互身份验证和受限委派)，协议转换为应用程序设计器提供了更大的灵活性和安全性，。

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