Kerberos身份认证在域用户工作站登录中的应用

以下内容摘自由笔者编写,并将在明年初出版的《网络工程师必读――网络安全系统设计》一书中（书名可能会更改）。

 

6.7.3 Kerberos身份认证在域用户工作站登录中的应用

 

假设用户在 tailspintoys.com 域中有自己的网络账户。用户自己的工作站也属于 tailspintoys.com 域。用户通过按下【 CTRL 】 + 【 ALT 】 + 【 DEL 】组合键登录界面登录域网络（这是在计算机上使用的是标准 Windows 配置中的安全口令序列（ Secure Attention Sequence ， SAS) ）。

作为 SAS 的响应，工作站的 Winlogon 服务切换登录桌面，而且调用 Winlogon 进程组件 ――GINA 链接文件。 GINA （ 图形识别化与验证 ）从封装在用户数据结构中收集登录数据，然后发送这些数据到 LSA 进行校验。也可以是由其他部分（如 MSGINA 链接文件）来替换 GINA 链接文件，但这是在操作系统已提供标准的 MSGINA 组件时登录的情况下。 Winlogon 服务将调用它，然后 GINA 在对话框中显示标准的登录信息。

用户输入用户名和密码，在域列表中选择要登录的域 tailspintoys.com 。当用户按下 “ 确认 ” 按钮后， MSGINA 返回登录信息到 Winlogon 服务。再由 Winlogon 发送这些信息到 LSA ，以确认是否为合法用户。这个过程是所有用户的标准登录过程，不管所用的身份验证方法是什么。

在此， LSA 就开始使用 Kerberos v5 身份验证协议进行身份验证。

1. Kerberos 密钥

在本节前面，我们已对 Kerberos 密钥进行了详细介绍，包括各种 Kerberos 密钥种类和密钥长度等。在此仅介绍域用户的工作登录过程中 Kerberos 密钥是如何使用的。针对本示例域用户登录过程（仅工作站与域控制器之间的身份验证），初始状态下，工作站与域控制器（也是 KDC ）中各自所拥有的密钥如图 6-11 所示，在工作站（ Workstaion ）端包括用户凭据缓存中的用户密钥（ User Key ）和工作站凭据缓存中的系统密钥（ System Key ），在域控制器（ Domain Controller ）中拥有三个密钥，分别是：用户密钥（ User Key ）、票证许可服务密钥（ Ticket- ）和系统密钥（ System Key ），它们是在域控制器的账户数据库中的。

用户密钥是由密码得到的，当用户密码接收到带有用户登录数据的数据结构后， LSA 就会把纯文本的密码通过加密功能转换密钥。加密的结果就是用户密钥（ user key ）。

LSA 保存用户密钥在用户的凭证缓存中，它可以在 TGT 更新或者进行 NTLM 身份验证时重新快速找回。

图 6-11  域用户工作站登录所需 Kerberos 密钥

为了快速确认用户登录信息，建立用户登录会话， LSA 必须包括以下两个部分：

n         允许进入票汇证许可服务的 TGT 票证。

n         允许进入计算机的服务票证。

TGT 用于身份验证交换，而服务票证用于 TGS 交换。 LSA 利用这些票证与用来在 tailspintoys.com 域中 KDC 直接交换消息的 Kerberos SSP 一起工作（工作站通过 DNS 查询定位 KDC 。每个域控制器都是一个 KDC ，并在 DNS 中注册他们的角色。）

2. 在身份验证服务交换中得到 TGT

在身份验证服务交换中，包括了四条消息，其实也就是四个主要的步骤。它们分别是：

n         身份验证服务请求（ Authentication Service Request ， KRB_AS_REQ ）

n         身份验证服务应答（ Authentication Service Reply ， KRB_AS_REP ）

n         票证许可服务请求（ Ticket-Granting Service Request ， KRB_TGS_REQ ）

n         票证许可服务应答（ Ticket-Granting Service Reply ， KRB_TGS_REP ）

【说明】以上四条消息在 6.5 节也有介绍，是整体六条消息中的前面四条，用于客户端与 KDC 之间的身份验证。本节只是针对具体的示例专门进行介绍。

（ 1 ）发送服务认证服务请求消息。使用 Kerberos 进行身份验证的客户端在工作站上发送 KRB_AS_REQ 消息到 tailspintoys.com 域的 KDC 中。发送过程及消息所包括的内容如图 6-12 所示。

图 6-12 客户端向 KDC 发送 KRB_AS_REQ 消息

KRB_AS_REQ 消息包括以下几部分 ：

消息内容是预身份验证数据（ Pre-authencation Data ），具体包括：

n      用户主体名称 （ user principal name ， UPN ）

n      域账户

n      以从用户密码中得到的用户密钥加密的预身份验证数据 （ Pre-authentication data ） 。

（ 2 ）找回用户密钥。

KDC 从用户账户数据库中的用户记录可以得到用户密钥副本。当 KDC 接收到从用户工作站的 Kerberos 客户端请求时， KDC 会在账户数据库中搜索该用户，取出其中的用户记录，然后再从记录中的信息的字段中取出用户密钥。

如果用户以前登录过网络， KDC 会从密码中得到的密钥副本，并且从账户数据库中得到的其他密钥副本。当用户密码被接受，而且得到用户的长效密钥，在工作站上的 Kerberos 客户端会立即向 KDC 请求服务票证和 TGS 会话密钥，以便在后面的登录会话过程中使用。

（ 3 ）校验用户标识。

KDC 解密预身份验证数据和评估时间戳是否在有效期内。如果时间戳通过测试， KDC 可以确认这个预身份验证数据是以用户密钥加密的，并确认用户是真实的。

在校验完用户标识后， KDC 创建可以提供票证许可服务的 Kerberos 客户端的凭证。

（ 4 ） KDC 以包含它自己的票证服务的身份验证服务应答（ KRB_AS_REP ）消息进行应答。发送过程及消息内容如图 6-13 所示。这个特殊的服务票证称之为票证许可票证（ TGT ）。像普通的服务票证一样， TGT 包含用户会话服务所需的会话密钥副本。这个返回 TGT 给用户的消息也包括用户可以用来与 KDC 会话的会话密钥副本。 TGT 是以 KDC 长效密钥进行加密的。用户会话密钥副本是以用户长效密钥加密的。

图 6-13   KDC 响应客户端的 KRB_AS_REP 消息发送过程

KRB_AS_REP 消息包括如图 6-14 所示的内容。具体如下：

图 6-14  KRB_AS_REP 消息内容

n      用户使用 TGS 时所需的 TGS 会话密钥（ Ticket-Granting Service Seesion Key ），是以从用户密码中转换而来的用户密钥进行加密的。

n         在 tailspintoys.com 域中 KDC 的 TGT ，是以 TGS 密钥加密的。 TGT 包括：

Ø              KDC 用来与用户交互的 TGS 会话密钥

Ø              用户身份验证数据（ Authorization data ）

而认证符又包括：

ü    用户账户 SID

ü    用户所属 tailspintoys.com. 域中安全组的 SID

ü    包括该用户或者该用户所属域组的企业通用组 SID

（ 5 ）当客户端收到来自 KDC 基于原始请求响应时，客户端使用它自己缓存中的用户密钥副本进行解密，得到 TGS 会话密钥副本。此时就可以丢弃从用户密码中得来的用户密钥，因为在有了 TGS 会话密钥后，用户密钥已不再需要了。在后面与 KDC 的所有交换中，客户端都是使用 TGS 会话密钥的。就介其他会话密钥一样， TGS 会话密钥也是临时的，仅在 TGT 过期前，或者关机前有效。所以 TGS 会话密钥通常称之为 “ 登录会话密钥 ” ，这也是在 6.5 节我们都把这个会话密钥称之为 “ 登录会话密钥 ” ，而没有叫 “TGS 会话密钥 ” 的原因。

从客户端来看， TGT 仅是另一个票证。在客户端试图连接任何服务器之前，客户端首先要检查用户凭据缓存，看是否有用于该服务连接的服务票证。如果没有，则客户端会在凭据缓存中检查是否有 TGT 。如果找到 TGT ，则 LSA 从缓存中取出相应的登录会话密钥，用于下面的身份验证，然后发送认证符和 TGT 到 KDC ，连同为该服务所申请的服务票证请求。换句话说，也就是获准进入 KDC 与获准进入域中其他任何服务一样，都需要会话密钥、认证符和票证（在与 KDC 连接中，是需要 TGT ）。

从 KDC 端来看， TGT 可以避免因每请示一个服务都需要找查用户长效密钥（通常是指用户密码）而造成性能上的损失。在获得了 TGT 后， KDC 仅查找用户密钥一次，就可以应用于多个服务请求。所用户之间的所有交换， KDC 可以以自己的长效密钥解密 TGT ，从而得到登录会话密钥，以此进行身份验证。

（ 6 ）在票证许可服务交换中获得服务票证。 Kerberos 发送票证许可服务请求（ KRB_TGS_REQ ）消息到 tailspintoys.com 域中的 KDC 。发送过程，以及消息所包括的内容如图 6-15 所示。

图 6-15 客户端向 KDC 发送 KRB_TGS_REQ 消息

KRB_TGS_REQ 消息内容包括：

n      目标计算机名

n      目标计算机所在域名

n      用户 TGT

n      以用户与 KDC 共享的会话密钥加密的认证符

（ 7 ） KDC 以票证许可服务响应（ KRB_TGS_REP ）消息的方式把两份会话密钥副本都发送到用户。用户自己的那个副本是由 KDC 和用户共享的密钥加密的，工作站的那份会话密钥副本是与用户信息一起植入的到服务票证的数据结构中。整个数据结构也是用 KDC 与用户共享的密钥加密的。发送过程及 KRB_TGS_REP 消息包括的内容如图 6-16 所示。

图 6-16  KDC 向客户端发送 KRB_TGS_REP 消息

KRB_TGS_REP 消息内容包括（具体如图 6-17 所示）：

n      用户和计算机共享的会话密钥，是以用户和 KDC 共享的会话密钥进行加密的。

n         用户服务票证，是以计算机加密密钥进行加密的。

服务票证又包括：

Ø              用户和计算机共享的会话密钥 .

Ø              从用户 TGT 中复制的身份验证数据

当 Kerberos 客户端接收到 KDC 的响应，它解密其票证和用户的会话密钥副本，把它保存在凭据缓存中（是一种非永久性存储器，并非磁盘）。

图 6-17  KRB_TGS_REP 消息内容

（ 8 ）获得用户凭据进行登录。在凭证到达工作站后， Windows Server 2003 访问令牌的创建过程与 Windows NT 版本是一样的。工作站上的 LSA 接收到用户服务票证，并以存储在凭证缓存中的系统密钥（ system key ）进行解密，然后取出身份验证数据。特权属性证书（ PAC ）从服务票证中取出，并用来创建用户访问令牌。然后 LSA 查询本地 SAM 数据库，以发现用户是否是计算机上任何安全组的成员，是否是在本地计算机上获得了特殊权限的组的成员。查询后，会在从票证中的身份验证数据得到的令牌列表中添加相应的 SID 。整个列表被用来构建访问令牌，以及返回到 Windlogon 的令牌访问句柄。

Winlogon 创建 Windows 位置和用户的几个桌面对象，关联用户访问令牌，开始外壳程序进程，用户进入目标计算机。

当用户注销登录，凭证缓存将全部清空，所有服务票证，包括会话密钥都将销毁。

完整的用户登录的过程如图 6-18 所示。

图 6-18 用户登录过程

本文出自 “王达博客” 博客，转载请与作者联系！