此计算机未配置为允许委派用户凭据,Kerberos 协议转换和受限委派
发布日期： 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 目录林使用协议转换，还必须满足以下附加要求：