Kerberos认证

理解Kerberos

如果您每次上班时都必须到某个安全官员那里，让他给您签到并发给您一个夹式胸卡，有了这个胸卡才被允许进入大楼到达办公桌，而这个胸卡并无其他用处，这样感觉如何？如果又必须每个小时到那个官员处登记并更新胸卡呢？

如果每次使用公司的资源时，例如需要文件库或复印机，都需要去那个官员处办理新的胸卡，您又感觉如何？那么如果我们告诉您必须向每个资源的门卫出示这个胸卡以便检验访问的合法性，你又会怎么想？

你可能会说，“哇，这太过分了，为什么这里的安全措施这么严格？”，在这种环境工作一定很困难。但如果几个公司或整个城市都采用了这样严格的安全措施又如何呢？这个城市中的生活一定会很安全，以至于公司之间会对共享资源非常相互信任。但从整体上看来，在这样的环境下工作还是太难受了。

然而，这就是Kerberos的工作方式。唯一的区别就是安全性签到和胸卡发放工作是由基础协议透明处理的，一切都发生在网络传输中。用户对发生在网络底层的这些工作毫无感觉。

Kerberos是以票证（ticket）系统为基础的，票证是密钥分发中心（Key Distribution Center，KDC）发出的一些加密数据包，密钥分发中心就好像上面的发卡官员。“票证”就是通行“护照”，它带有无数安全信息。每个KDC负责一个领域（realm）的票证发放。Windows 2003中，每个域也是一个Kerberos领域，每个Active Directory域控制器（DC）就是一个KDC。

登录到Windows时，WinLogon和LSA首先将用户领到KDC（参见第2章）进行身份验证。KDC提供一个称为票证授予票证（Ticket Granting Ticket，TGT）的初始票证。它类似于游乐场中的通行权配给票和护照。然后，在需要访问网络上的资源时，将TGT提交给DC并请求访问资源的票证。这个资源票证被称为“服务票证”（Service Ticket，ST）。在需要访问资源时，处理环境会将ST提交给资源，然后就会获准依照ACL保护进行资源访问。

Kerberos在Windows 2003中的执行完全符合Internet工程任务组（IETF）的Kerberos V5规范，该规范由MIT开发。这项规范得到了广泛的支持，这意味着Windows 2003域（现在也称为Kerberos领域）发出的票证可以在其他领域中使用，例如运行Mac OS、Novell NetWare、UNIX、AIX、IRIX等等的网络。

因此，可以在不同领域的KDC之间建立信任关系。这就像Windows NT系统中的信任关系一样，建立于每个域的主域控制器（PDC）之间。此外，由于Windows 2003仍然使用NT局域网管理器（NTLM），所以信任在遗留Windows域上仍然有效。

但是与使用NTLM管理Windows NT域相比，管理Kerberos域需要更多的精力。这是因为一天之中用户要到KDC登记好几次。例如，如果您登录在线12个小时，在这段时间内可能需要到KDC登记12～15次。如果域支持1200个用户，那么会有大约要到KDC登记18000次。

此外，异构网络之间的信任并不像Active Directory域之间的信任那么透明。在Active Directory域中控制器能明确地为用户提供担保。Windows 2003林之间、Windows 2003和Windows NT之间、Windows 2003和其他域之间的信任关系需要各自的域管理员之间进行手动设置协调。对UNIX或IRIX领域的设置过程可能会和对Windows 2003领域之间的设置过程非常不同。

在设计网络的物理布局时，如果有通过WAN通信的多个域，为了保证身份验证不在拥挤的网络信息流中陷入困境，需要考虑建立能够使票证在域之间传输的最佳可能路径。

注意：如果由于网络间的链接较慢而使身份验证过程很慢，那么最好将站点建成一个新域。关于确定何时创建新域的更多信息，请参阅第7章。

Kerberos是一个速度很快的协议，是在网络身份验证方面执行单一登录范式的理想环境。

3.6.1  Kerberos和单一登录动议

单一登录早就该使用了。从安全的角度来看，单一登录有很大的好处。如果一个用户拥有6、7个密码，这就意味着他有6次或7次或更多的泄密机会。很多人对要记住不同的密码感到很烦，他们宁愿一个密码都没有才好。在系统中还有一个问题，密码的创建和应用都是由用户控制的。语音邮件系统就是一个很好的例子。许多系统要求用户的密码不能设成1234或空格，但是如果查看一个系统的密码，通常情况下很多密码都是空格或是1234。

有一些用户又会走向另一个极端，他们将密码记录到一个密码数据库或电子数据表中，甚至输入到简单的文本文件中。入侵者可以顺利地找到保存密钥的文档。密码数据库文件简直就是罪魁祸首，入侵者只需几秒种就可以破译出锁住文件的密码。

有了单一登录，用户只要验证一次，其他网络应用程序和服务就认可它。由于Kerberos和Active Directory的支持，SQL Server.NET和Exchange.NET也可以支持单一登录，同时在Windows 2003和其他操作系统之间建立的信任域也支持单一登录。这也正是Windows 2003中信任可在同一根或同一林的域之间传递的原因。

3.6.2　Kerberos的工作方式

Kerberos是基于“共享秘密”的思想而建立的。换句话说，如果只有两个人知道某个秘密，则其中一人就可以通过确认另一个人是否知道这个秘密来鉴别另一个人的身份。在Kerberos中，共享秘密存在于Kerberos和安全主体（security principal，真人用户或设备）之间。

依此类推，有两个人定期给对方发电子邮件，需要确保每个电子邮件都不被对方否认，或者要确保没有其他人冒充成发送方。为了确定发送方或接收方就是他们自己所说的那个人，于是商议将往来信息中的某些内容作为确定对方就是“那个人”的凭证。但是，如果有人分析了这些电子邮件并发现其字词的排列顺序，不会花费很长时间就能发现隐藏在其中的确认信息。在网络验证机制中，这是一个很大的问题。因为不会花很长时间就可以截取信息，然后欺骗验证服务程序。

通信双方应该如何设计方案来确定它们的身份呢？答案是对称密钥加密技术。共享密钥必须秘密保存，否则任何人都可以给信息解密。正如前文所述，对称密钥是能够同时加密和解密的单密钥。也就是说，只要通信双方共享同一个密钥，他们就可以给信息加密，而且确保对方能够进行解密。

注意：保密密钥（secret key）和对称密钥（symmetric key）这两个术语在讨论使用单密钥给文档加密和解密中可以互换。但是，保密密钥完全可能落到错误的人手中。

密钥加密技术不是什么新技术。它的产生可以追溯到冷战之前，那时就有了比较完善的密钥技术和密码科学。但是在实施Kerberos中，只要信息被解密，或只要双方中的一方首先能够通过拥有解密密钥证明他们是真实的，那么验证就已经完成了。但是如果网络上有人窃取了这个密钥，或者设法复制了以前的验证对话又怎么办呢？Kerberos将会利用那个不可改变的要素——时间，来解决这个问题。

3.6.3  时间验证

从字面上看，Kerberos验证从用户登录域的那一刻开始。Kerberos接收到验证请求时，将按照以下步骤进行处理：

1．查找该用户并载入它与该用户共享的解密密钥，对验证消息进行解密。

2．查看消息中的信息项。它查阅的第一项就是时间戳，该项记录的是用户请求登录验证所在工作站或机器的时钟时间。如果发送方时钟的时间与同步信号的偏差多于5分钟（由于不同的时区和夏令时带来的时差，Kerberos会相应地补偿），Kerberos将会拒绝这条消息，并不再理会。如果时差在允许的5分钟这个偏差范围内，Kerberos将接受这条消息。

3．Kerberos查看时间是否与以前从发送方收到的验证时间一致，或比之更早。如果时间戳不晚于并且不同于前一次验证的时间，Kerberos将允许用户通过验证进入该域。

但是知道这种验证是相互的也很重要。Kerberos将会发回一条消息证明它能够对用户消息解密。Kerberos只返回选择过的信息，其中最重要的一项是它从用户最初的验证中获得的时间戳。如果时间戳与用户的信息相匹配，则用户可确定是Kerberos发送的消息，而不是冒名顶替者解密了消息。

3.6.4　密钥分发

对于域的验证，Kerberos验证的效果很好。但客户在登录后访问资源时又怎么办呢？这时Kerberos将使用域资源验证。那么客户在访问其他网络资源时又怎么进行验证呢？

Kerberos可以分发密钥。换句话说，它充当了经纪人的角色。事实上，这就是Kerberos这个名称的由来。在古希腊神话中，Kerberos是守卫在地狱门口的那只三头犬。Kerberos协议也具有三个头：客户端、服务器和一个中间人（或称为代理）。代理就是通常所说的密钥分发中心（KDC），它将密钥分发给各方。在Windows 2003中密钥分发中心安装在Active Directory域控制器上。

现在您可能已经开始想下面的步骤了，您也许会说：“太好了，消息解密和检查时间戳这些无聊的过程只需要在客户端和服务器之间重复”。如果您能想到以下内容就更对了：密钥分发中心的工作就是给每个用户分配网络资源访问密钥。但这只在理论上正确而已，因为大量的密钥分配将是资源的极大流失。每台服务器都不得不在内存中为潜在的成千上万的用户存储密钥。而实际上真正的实施是非常简化而巧妙的。

3.6.5　会话票证

事实上，KDC并不按照上面的逻辑假设同时将会话密钥发送给客户端和服务器，而是将这两个会话密钥都发送给客户就不管了。客户端一直持有服务器的会话密钥直到它准备好连接服务器，通常这个过程在几毫秒内完成。图3-1中的说明可能会有助于理解。

图3-1  密钥分发和相互验证

当客户申请访问资源（A）时，KDC会创建一个会话密钥，在会话密钥中嵌入会话票证（B）。嵌入的会话票证实际上属于服务器，它是服务器与客户端进行通信的会话密钥。实际上，KDC在客户端和需要访问的资源之间进行的秘密密钥协商中担当了经纪人或代理的角色。

客户端从KDC接收到信息后，它取出票证和它的会话密钥副本，并将其保存在安全的非易失内存中。然后在客户端和服务器（C）进行联系时，它将一条消息发送给服务器，这条消息中包含用服务器的秘密密钥加密过的票证和用会话密钥加密过的时间验证器。票证和时间验证器组成了客户端凭据（credentials），这与登录身份验证的方式一样。

如果通过了一切检验，服务器将准许访问客户端（D），因为服务器了解这是权威的KDC发出的凭据。只要客户端结束了对服务器的访问，服务器便可以将客户端用来和服务器通信的会话密钥删除。客户端则一直持有这个会话密钥，并在每次需要访问的时候将它提交给服务器。

会话票证也能够重用，但是为了防止被盗，会话票证具有有效期限。这个有效期限在域安全策略中指定，域安全策略将在本章后面部分讨论。通常情况下，会话票证的有效期限为平均登录时间，即大约8小时。在用户注销退出系统时，会话票证的缓存会被刷新，所有的会话票证和密钥都被废除。

3.6.6  Kerberos和信任

将刚刚讨论过的概念扩展到域边界之外，就是Kerberos信任的实现。在作为连续命名空间（Active Directory树）组成部分的域之间将自动建立信任，此时这两个域之间共享一个域间密钥，其中一个KDC成为另一个KDC的代理，反之亦然。

在这个域间密钥建立起来后，每个域中的票证授予服务会在另一个域的KDC中注册为安全主体，并允许它发出推荐票证（ticket referrals）。本地域中的客户端在访问外部资源时仍然与本域中的KDC进行联系。本地KDC确认客户端要访问的资源位于其他域后，向客户端发出一个推荐票证。然后客户端连接另一个域的KDC并发出那个推荐票证。远程KDC对用户进行验证或开始一个会话票证交换，以允许客户端连接远程域中的资源。

3.6.7  定位KDC

DNS为Kerberos提供定位服务。RFC 1510中指定了DNS应该如何将KDC主机域名解析成IP地址。客户端计算机需要将它们的信息发送到这一IP地址。如果不能解析KDC的IP地址，将会生成一个错误信息返回给客户端，指出无法定位该域。

在Windows 2003域中，KDC通常安装在Active Directory服务器上。它们不会按照应用程序进程进行连接，而是作为单独的服务进程运行。但由于KDC总是安装在DC上，所以可通过查找DC的主机地址来解析KDC域名。

将Windows 2003服务器安装在非Windows 2003域中也是可以的，Windows 2003服务器仍然能够进行Kerberos验证。但要保证其域名能被正确地解析成对应主机地址。这时再查找Active Directory DC的IP地址的做法就不正确了。有一个名为ksetup.exe的实用程序，可以用来在非Windows 2003域中配置客户和服务器加入Kerberos域。

很明显，实际上有关Kerberos的内容要比这里所讨论的多得多。但是那已经超出了本书的范围。有很多专门为Kerberos编写的书籍。无论如何，Kerberos事实上成为Windows 2003域中最为广泛使用的安全保护机制。Kerberos是尽快转向本机域的绝好理由。虽然传说中的三头犬很丑陋，但这个守卫网络的三头犬却是Windows 2003域中非常受欢迎的一部分。