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

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

<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />6.7.3 Kerberos身份认证在域用户工作站登录中的应用

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 
假设用户在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身份验证时重新快速找回。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
6-11  域用户工作站登录所需Kerberos密钥

为了快速确认用户登录信息,建立用户登录会话,LSA必须包括以下两个部分:
n         允许进入票汇证许可服务的TGT票证。
n         允许进入计算机的服务票证。
TGT用于身份验证交换,而服务票证用于TGS交换。LSA利用这些票证与用来在tailspintoys.com域中KDC直接交换消息的Kerberos SSP一起工作(工作站通过DNS查询定位KDC。每个域控制器都是一个KDC,并在DNS中注册他们的角色。)
2. 在身份验证服务交换中得到TGT

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

n         身份验证服务请求(Authentication Service RequestKRB_AS_REQ

n         身份验证服务应答(Authentication Service ReplyKRB_AS_REP

n         票证许可服务请求(Ticket-Granting Service RequestKRB_TGS_REQ

n         票证许可服务应答(Ticket-Granting Service ReplyKRB_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 nameUPN

n      域账户

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

2)找回用户密钥。
KDC从用户账户数据库中的用户记录可以得到用户密钥副本。当KDC接收到从用户工作站的Kerberos客户端请求时,KDC会在账户数据库中搜索该用户,取出其中的用户记录,然后再从记录中的信息的字段中取出用户密钥。
如果用户以前登录过网络,KDC会从密码中得到的密钥副本,并且从账户数据库中得到的其他密钥副本。当用户密码被接受,而且得到用户的长效密钥,在工作站上的Kerberos客户端会立即向KDC请求服务票证和TGS会话密钥,以便在后面的登录会话过程中使用。
3)校验用户标识。
KDC解密预身份验证数据和评估时间戳是否在有效期内。如果时间戳通过测试,KDC可以确认这个预身份验证数据是以用户密钥加密的,并确认用户是真实的。
在校验完用户标识后,KDC创建可以提供票证许可服务的Kerberos客户端的凭证。
4KDC以包含它自己的票证服务的身份验证服务应答(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域中KDCTGT,是以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从缓存中取出相应的登录会话密钥,用于下面的身份验证,然后发送认证符和TGTKDC,连同为该服务所申请的服务票证请求。换句话说,也就是获准进入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共享的会话密钥加密的认证符
7KDC以票证许可服务响应(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 用户登录过程
展开阅读全文

没有更多推荐了,返回首页