这个主题将解释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协议规定了以下机制：
l 验证用户身份。当一个用户需要获取访问一个服务器的权利，服务器需要验证用户的身份，考虑一个场景，用户声称他是，比如，Alice@tailspintoys.com。因为访问资源是基于身份关联的许可，服务器必须确定用户就是他自己声称的用户。
l 安全的打包用户名，用户名(用户的主名，在本例中就是Alice@tailspintoys.com)，和用户的身份信任凭证（credentials）被打包在一个叫做票据（ticket）的数据结构中
l 安全的传送用户信任凭证。票据被加密后，Kerberos消息在网络上传送用户的信任凭证（credentials）。
注意：
虽然Kerberos协议验证用户的身份，它并不授权访问。这是个重要的区别。在其他情形中的票据，象驾驶执照，就同时提供了身份和驾驶车辆的许可。Kerberos的票据仅仅用来证明这个用户就是它自己声称的那个用户。在用户身份得以确认后，本地的安全权限将决定给予访问权限或者拒绝访问。
2.1、 密钥
Kerberos消息被多种加密密钥加密以确保没人能够篡改客户的票据或者Kerberos消息中的其他数据。
l 长期密钥（Long-term key）
一个密钥（只有目标服务器和KDC知道），并用来加密客户端访问这个目标服务器票据的密钥。
l Client/server会话密钥（session key）
一个短期的、单此会话的密钥，是在用户的身份和权限已经被确认后由KDC建立的用于这个用户的跟某个服务器之间的加密往来信息使用的密钥
l 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，包括：
l AD活动目录要求使用LDAP（Lightweight Directory Access Protocol）
l 使用RPC的远程服务或workstation management
l 客户－服务器身份验证
l 使用Common Internet File System/server message block (CIFS/SMB)的远程文件访问
l 分布式文件系统管理
l IIS的intranet身份验证
l Internet Protocol security (IPSec)的安全验证
l 为域用户和计算机发放证书的请求
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 身份验证就是不可能的。
二、 Kerberos V5身份验证协议如何工作
Kerberos V5身份验证协议（RFC 1510定义），提供一个在开放的、潜在不安全的网络环境中验证主体身份的方法。这一节讨论RFC标准的Kerberos V5在Windows Server 2003如何使用
这节分为以下四个子章节：
l Kerberos SSP结构：说明Windows Server 2003的SSPI怎样提供一个访问SSP的机制。
l Kerberos 物理结构：讨论Windows Server 2003中实现Kerberos 身份验证的组件。这些组件包括密钥、票据和密钥分发中心（KDC）
l Kerberos V5身份验证协议过程和相互作用：说明Kerberos 身份验证在不同的情形下怎样被使用，Kerberos 消息的细节，并讨论其他相关技术。例子将给出完整的过程，包括没有被Kerberos 身份验证协议定义的相关的组件和过程。一些过程（比如怎样发现一个验证服务，什么信任证书会被通过，信任证书被存放在哪）在Windows系统是特殊的，可能与其他的Kerberos 协议的实现有所不同。
l Kerberos V5协议使用的网络端口：以表格形式展现在Kerberos 身份验证期间使用到的端口。
1、 Kerberos SSP架构
Windows Server 2003 以Security Support Provider (SSP)来实现Kerberos V5身份验证协议，一个操作系统的动态链接库（DLL）。Windows Server 2003另外还包括针对NTLM的SSP。缺省的启动时Windows Server 2003的Local Security Authority (LSA) 把两个SSP都装载进来，系统能够两个SSP中的任意一个来验证网络登录和客户端/服务器的连接。使用哪一个SSP取决于连接另一端的机器的能力和个别应用的参数选择。
Microsoft SSPI是Windows Server 2003中身份验证的基础，就是说，要求身份验证的应用和底层服务都使用SSPI接口。
SSPI是Generic Security Service API (GSSAPI)在Windows Server 2003中的实现，关于GSSAPI的更多信息，请参考RFC 2743 和 RFC 2744。
Windows Server 2003中默认的SSPs（Negotiate (SPNEGO), Kerberos, NTLM, Schannel, 和摘要身份验证（Digest authentication protocols））以DLL的形式插入到SSPI，其它的SSP如果能够同SSPI交互也能被插进来。
SSPI 架构图示：
Windows Server 2003中的SSPI提供一个在客户端和服务端已存在的连接上传送身份验证令牌的机制。当两个实体为了能相互安全的通讯需要身份验证时，身份验证的请求被路由到SSPI，SSPI不管当前正在使用什么网络协议完成身份验证过程，并返回一个透明的（transparent）两进制大对象给连接的另一边的应用。SSPI允许一个应用在一个机器上或网络上使用多种安全模型而不用改变安全系统的接口。
下表是被插入到SSPI的组件的描述。表中的Windows Server 2003中的每个协议都以不同方法来提升不安全网络环境中的通信的安全性。
SSP 层组件：
|
组件
|
描述
|
|
Kerberos V5 身份验证
|
一个用口令或者智能卡交互登录的工业标准。它也是Windows 2000 and Windows Server 2003首选身份验证的方式。
|
|
NTLM 身份验证
|
一个质询回应（challenge-response）协议使用来提供比Windows 2000更早的系统的兼容性 |
|
摘要身份验证
|
用于Windows Server 2003 LDAP和web身份认证的工业标准，摘要身份的信任凭证被MD5散列后在网上传输。
|
|
Schannel
|
一个实现安全套接层（SSL）和传输层安全（TLS）因特网标准身份验证协议的SSP。Schannel被用于基于web的服务器身份验证，象当一个用户试图访问一个安全的web服务器。
|
|
Negotiate
|
被用于协商使用哪个特定协议的SSP。当一个应用通过SSPI登录到网络，它能够指定一个SSP处理这个登录请求，当应用指定Negotiate，Negotiate分析这个请求并选取对客户端配置的安全策略来说最好的SSP处理这个请求
|
2、 Kerberos 物理结构
Kerberos在开放的网络（在网络上传输的数据包可以被随意的监听和修改）上提供客户端和服务端双向的身份验证的机制。为了提供安全的身份验证，Kerberos身份验证使用对称密钥、加密的对象和Kerberos服务。
Kerberos 组件
2.1、 身份验证中使用的密钥
2.1.1 为什么需要密钥?
Kerberos协议严重的依赖于一个验证技术共享密钥。基本的共享密钥的概念十分简单：如果一个秘密只有两个人知道，任何一个人都可以通过他们之间共享的秘密来确定对方的身份。
比如，假设Alice经常给Bob传送信息，Bob在使用这个信息前需要确定这个信息真的就是Alice传送过来的。他们决定通过在他们选择一个只有他们两个人知道一个秘密来解决这个问题，如果一个信息声称来自Alice的，并能以某种方式出示发送者知道的密码，那Bob就能确信发送者就是Alice。
剩下的问题就是Alice和Bob需要解决Alice怎么出示她知道的密码。她可以把密码包含在她发送的信息里面，多半是在最后的签名 － Alice, Our$ecret。 这是简单而有效率的如果他们能确信没有人能够看到他们之间的传送的信息。不幸的是，他们的信息通过的网络上有个用户Carol，他用网络分析工具扫描网络通讯希望有一天能够发现这个密码。因此，Alice不能在她发送的信息里提供密码。为了保持密码的保密性，她必须要能出示这个密码但又不能暴露它。
Kerberos协议用密钥来解决这个问题。替代共享的密码，通讯的双方共享一个密钥，他们使用这个密钥的知识验证另一方的身份。为了使这个技术正常工作，他们共享的密钥必须是对称的，就是说，一个密钥既能够用来加密，又能够用于解密。密钥的一部分知识用来加密，另一部分知识用来解密。