UML软件工程组织

微软Windows Server 2003操作系统实现Kerberos 版本5的身份认证协议。Windows Server 2003同时也实现了公钥身份认证的扩展。Kerberos身份验证的客户端实现为一个SSP（security support provider），能够通过SSPI（Security Support Provider Interface）进行访问。最初的用户身份验证是跟Winlogon的单点登录架构集成在一起的。Kerberos的KDC（Key Distribution Center）跟Windows Server 2003的域控制器DC（domain controller）上的安全服务集成在一起，KDC使用域的活动目录数据库作为它的安全帐户数据库，缺省的Kerberos实现要求活动目录的支持。

这个主题将解释Windows Server 2003是怎样支持Kerberos V5协议及其扩展的。

一、什么是 Kerberos 身份验证

Kerberos V5身份验证协议提供一个在客户端跟服务器端之间或者服务器与服务器之间的身份验证机制（并且是相互的身份验证机制）

Windows Server 2003把Kerberos V5身份验证协议实现为一个能够通过SSPS（Security Support Provider Interface）的SSP（security support provider），另外，Windows Server 2003还通过使用智能卡的公共密钥证书（public key certificates）进行初始身份验证来扩展此协议。

Kerberos的密钥分发中心 KDC（Key Distribution Center）使用活动目录的服务数据库作为自己安全帐户数据库。NTLM 和 Kerberos的缺省实现都需要活动目录的支持。

Kerberos V5协议假设客户端和服务端的最初信息交换发生在开放的网络环境中，在网上传输的数据包能够被监视并能被任意修改。这个假设的环境，跟现在的因特网非常相似，攻击者可以非常容易的伪装为一个客户端或者一个服务器，也能很容易的窃听和篡改合法客户端和服务端之间的通讯。

微软的Kerberos V5协议实现是：

Windows Server 2003的缺省身份认证

Kerberos V5协议成为Windows 2003的缺省身份验证，Windows Server 2003还为了能支持Windows NT Server 4.0等非Kerberos的操作系统还支持NTLM协议。

基于RFC 1510及其修订草案

Kerberos协议是成熟的、广泛应用的、开放的标准，微软Kerberos V5协议的实现遵循RFC的标准，因此能提供跟其他实现的互操作。

可扩展性

Kerberos 架构允许你指定另外的或者可以替换的安全方案。并且，可以通过智能卡的公钥/私钥来提供缺省的共享安全密钥过程。

1、 Kerberos身份认证带来的好处

Kerberos V5协议比NTLM协议更安全、更灵活，更有效，用Kerberos身份验证能够获得的好处是：

1.1、身份委派

当Windows的服务为某个客户端访问资源时会扮演这个客户端，在多数情况下，在本机上一个服务能够为客户端完成访问资源的工作，因为NTLM和Kerberos都能为服务提供需要扮演客户端的信息。可是，在分布式应用被设计为前端服务扮演客户端连接到在其他服务器上的后端服务，Kerberos V5协议包括一个允许服务扮演客户端连接到其他服务器上的服务的代理机制，NTLM则没有这样的功能。

Interoperability.

1.2、互操作

微软的Kerberos V5实现是基于IETF的推荐标准规范。这样，Windows Server 2003的Kerberos V5实现就为其他使用Kerberos V5协议的网络的互操作打下了基础。

1.3、更高效率的身份验证

对于NTLM，为了验证每一个客户端，应用服务器必须连接到域控制器以证实客户端身份。对于Kerberos V5身份验证协议，服务器不用去连接域控制器，相应的，服务器可以检验客户端提供的验证票。客户端可以为特定的服务获取一次验证票并在一次登录过程中反复使用这个验证票。可更新的会话票据（session tickets）替代了pass-through authenticatio（不知道怎么翻译）。

1.4、相互身份验证

通过使用Kerberos协议，在网络连接的一端都可以验证网络另一端的声明是它自己的实体。虽然NTLM允许服务器验证客户端的身份，但是它没有提供客户端验证服务端身份的功能，也没有提供服务器验证另一个服务器身份的功能。NTLM被设计为假设服务器都是真实的网络环境，Kerberos则没有这个假设。

2、 Kerberos V5协议标准

Kerberos身份验证协议几十年前起源于麻省理工学院，是由“Athena”项目的工程师开发的。第一个公开发行的版本是Kerberos版本4。在被广泛的使用后，协议的开发者发布了Kerberos第五版本。

Kerberos V5现在成为IETF的标准，Windows Server 2003中Kerberos V5的实现严格的遵循了RFC 1510定义的标准，另外，Kerberos消息中的安全令牌（security tokens）的格式和机制遵循RFC 1964定义的标准。

Kerberos V5协议规定了以下机制：

验证用户身份。当一个用户需要获取访问一个服务器的权利，服务器需要验证用户的身份，考虑一个场景，用户声称他是，比如，Alice@tailspintoys.com。因为访问资源是基于身份关联的许可，服务器必须确定用户就是他自己声称的用户。
安全的打包用户名，用户名(用户的主名，在本例中就是Alice@tailspintoys.com)，和用户的身份信任凭证（credentials）被打包在一个叫做票据（ticket）的数据结构中
安全的传送用户信任凭证。票据被加密后，Kerberos消息在网络上传送用户的信任凭证（credentials）。

注意：

虽然Kerberos协议验证用户的身份，它并不授权访问。这是个重要的区别。在其他情形中的票据，象驾驶执照，就同时提供了身份和驾驶车辆的许可。Kerberos的票据仅仅用来证明这个用户就是它自己声称的那个用户。在用户身份得以确认后，本地的安全权限将决定给予访问权限或者拒绝访问。

2.1、密钥

Kerberos消息被多种加密密钥加密以确保没人能够篡改客户的票据或者Kerberos消息中的其他数据。

长期密钥（Long-term key）
一个密钥（只有目标服务器和KDC知道），并用来加密客户端访问这个目标服务器票据的密钥。

Client/server会话密钥（session key）
一个短期的、单此会话的密钥，是在用户的身份和权限已经被确认后由KDC建立的用于这个用户的跟某个服务器之间的加密往来信息使用的密钥

KDC/用户会话密钥（session key）.
是KDC跟用户共享的一个密钥，被用于加密这个用户跟KDC之间的消息。

Kerberos V5协议使用了对称加密和非对称加密两种加密技术

因为大多数Kerberos的加密方式是基于只用于KDC和用户之间或者KDC和网络服务之间的密钥，Kerberos V5被设计为采用对称加密，即使用同一个密钥来加密和加密消息。

微软的Kerberos协议实现能够使用有限的非对称加密，一个私钥/公钥对被用于加密和解密来自客户端或者网络服务的初始验证信息。

2.2、 Kerberos 身份验证防止数据包重用

Kerberos身份验证机制建立并安全的传送一个带有客户票据的信任凭证（通常基于一个唯一的时间戳），信任凭证是唯一并且一次使用有效。这个限制使有人获取并重用客户端票据或者尝试偷取客户的身份的可能性降到最小。

3、 Kerberos V5协议的扩展

Windows Server 2003实现Kerberos V5协议的扩展，这个扩展在初始身份认证时采用公钥证书来替代常规的对称加密密钥。这个改进允许协议支持用智能卡交互登录。公钥身份验证扩展是基于IETF工作组的草案协议。

4、 Kerberos身份验证的相关技术

下图显示了Windows Server 2003中Kerberos身份验证同其它技术如何配合的。依赖是客户端或服务端应用是用户模式（user-mode）还是核心模式（kernel-mode）的应用，他们分别使用Secur32.dll 或者Ksecdd.sys，调用SSPI跟Local Security Authority Subsystem (LSASS)通讯

下表是参与kerberos身份验证的组件的描述

Component	Description
Kerberos.dll	被用来口令或者智能卡交互式登录实现工业标准的协议SSP。它也是Windows 2000 和 Windows Server 2003首选的身份验证方式。
Kdcsvc.dll	Kerberos密钥分发中心（KDC）服务，它回应客户端票据授权票（ticket-granting tickets）的申请
Ksecdd.sys	在核心模式（kernel-mode）下用户跟LSASS通讯的核心安全设备驱动
Lsasrv.dll	LSA服务，强制安全策略和担当LSA安全包管理器
Secur32.dll	Secur32.dll 是在用户模式（user mode）下实现SSPI的组件

Windows Server 2003是用SSP来实现Kerberos V5身份验证协议，是操作系统提供的一个动态链接库（DLL），系统使用Kerberos SSP, Kerberos.dll，是身份验证的第一选择。在LSA为一个交互式登录的用户建立了一个安全的上下文，为了支持Kerberos信息的签名和封装，正在运行的用户安全上下文装载另外一个Kerberos SSP实例

因为Kerberos身份验证协议是Windows Server 2003首选协议，所有域服务都支持Kerberos SSP，包括：

AD活动目录要求使用LDAP（Lightweight Directory Access Protocol）
使用RPC的远程服务或workstation management
客户－服务器身份验证
使用Common Internet File System/server message block (CIFS/SMB)的远程文件访问
分布式文件系统管理
IIS的intranet身份验证
Internet Protocol security (IPSec)的安全验证
为域用户和计算机发放证书的请求

5、 Kerberos 身份验证依赖于

本节讨论和该书Kerberos身份验证依赖项以及和他们的关系

5.1、操作系统

Kerberos 身份认证依赖于客户端功能，这些功能内建于Windows Server 2003、Windows XP、Windows 2000操作系统。如果一个客户端、域控制器或者目标服务器运行于更早的操作系统下，那它就不天然的支持Kerberos 身份验证。

5.2、 TCP/IP网络连通性

一旦Kerberos 身份认证发生，在客户端、域控制器和目标服务器之间必须有TCP/IP网络连接，关于TCP/IP更多的信息，参考“TCP/IP Technical Reference.”

5.3、域名系统

客户端使用全限定名fully qualified domain name（FQDN）访问域控制器，DNS必须能够保证客户端能够获得这个域控制器的地址。最好不要使用DNS主机文件，关于DNS的更多信息，参看“DNS Technical Reference.”

5.4、域活动目录

Kerberos 身份验证不支持更糟的操作系统，比如Windows NT 4.0。你必须使用活动目录服务中的用户和计算机，本地帐户和Windows NT域帐户不能被由于Kerberos 身份验证

5.5、时间服务

为了Kerberos 身份验证能正常的发挥作用，在网络中的所有域和森林使用相同的时间源以保证网络中的所有计算机时间同步。一个活动目录域控制器担当权威的时间源，它保证所有的域具有相同的时间。更多信息，参看“Windows Time Service Technical Reference.”

5.6、服务主体名

服务主体名(SPNs) 是运行在服务器上服务的唯一标识符。每一个使用Kerberos 身份验证的服务都需要有个SPN以使客户端能够在网络上标识这个服务。没有正确的设置SPNs, Kerberos 身份验证就是不可能的。