绍本地登录、域登录、单域身份认证、域用户的工作站登录。

5.7.1  本地登录示例
   用户可以使用域账户或本地计算机账户登录计算机。当用户以本地计算机账户登录时，用户凭证是通过本地账户数据库进行鉴别的。因为本地计算机不能担当KDC角色，同时，本地登录不需要网络访问（如与KDC联系），所以本地身份认证是使用NTLM来验证账户的。
   本地登录的身份认证过程如图5-9所示。
 
 
图5-9  本地登录的Kerberos身份认证过程
具体的步骤如下（对应图中的序号）。
（1）在图形识别化与验证（Graphical Identification and Authentication ，GINA）动态链接库连接收集到用户登录信息后，它将传递这些信息到LSA，以便进行身份认证。
（2）LSA简单地传递这些信息到SSPI。该接口负责与Kerberos和NTLM服务沟通。
（3）SSPI不能确定用户是本地登录还是域账户进行域登录。因为SSP是默认的身份认证程序，身份认证请求首先传递到Kerberos SSP。
（4）Kerberos SSP校验登录的目标名称是本地计算机名。如果是这样，即用户不是登录域，Kerberos SSP返回一个错误消息到SSPI，交回给GINA处理，使服务器登录不可用。如果是想登录域，Kerberos SSP将继续处理。
（5）如果登录本地计算机，GINA将会让提交请求。SSPI现在可以发送请求到下一个安全提供程序--NTLM。NTLM SSP会将请求交给Netlogon服务针对LSAM（Local Security Account Manager，本地安全账户管理器）数据库进行身份认证。使用NTLM SSP的身份认证过程与Windows NT系统的身份认证方法是相同的。
5.7.2  域登录示例
如果用户是域成员，账户数据库是位于域控制器上的。如果你正在你所属域的域控制器上登录域，则就像本地登录过程一样；如果你是在成员服务器，或者其他域的域控制器上登录域，则Kerberos身份认证将在可能时使用。
用户从不直接访问系统，系统会按照相应用户的资源许可模仿用户访问系统资源。这是所有版本的Windows NT、Windows 2000和Windows Server 2003系统的标准安全特征。用户登录到一个工作站后，从不直接访问，即使是本地资源，本地系统会模仿用户，就像远程系统访问一样。
因为本地系统是通过模仿为用户完成资源访问的，登录到域中的用户就必须进行身份认证，以避免非法用户进入。这时仅需要在域登录过程中添加一个新的子过程，那就是在创建访问令牌前进行Kerberos身份认证。
域用户访问他们自己工作站的身份认证过程与访问网络资源的身份认证是一样，也就是说，用户必须获得本地工作站的有效票证。域用户在本地工作站的域登录过程如下。
（1）客户端发送Kerberos身份认证请求，然后从KDC中获得TGT票证。
（2）客户端利用TGT票证来向KDC发送本地工作站的服务票证请求，然后得到本地工作站的服务票证。
（3）网络资源的服务票证将依据访问的是系统资源，还是服务资源来决定采用系统或者服务密钥进行加密。工作站在加入域时就已创建了系统密钥，工作站的服务票证是用系统密钥加密的。
（4）ISA（本地安全认证机构）从服务票证包括的凭证中创建访问令牌，以许可或者禁止用户访问。
5.7.3  域用户的工作站登录
假设用户在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）中各自所拥有的密钥如图5-10所示，在工作站（Workstaion）端包括用户凭据缓存中的用户密钥（User Key）和工作站凭据缓存中的系统密钥（System Key），在域控制器（Domain Controller）中拥有3个密钥，分别是用户密钥（User Key）、票证许可服务密钥（Ticket-Granting Service Key）和系统密钥（System Key），它们是在域控制器的账户数据库中的。
 
 
图5-10  域用户工作站登录所需的Kerberos密钥
  用户密钥是由密码得到的，当用户密码接收到带有用户登录数据的数据结构后，LSA就会把纯文本的密码通过加密功能转换成密钥，加密的结果就是用户密钥（User Key）。
  LSA保存用户密钥在用户的凭证缓存中，它可以在TGT更新或者进行NTLM身份认证时重新快速找回。
为了快速确认用户登录信息，建立用户登录会话，LSA必须包括以下两个部分。
  允许进入票证许可服务的TGT票证。
  允许进入计算机的服务票证。
  TGT用于身份认证交换，而服务票证用于TGS交换。LSA利用这些票证与用来在tailspintoys.com域中KDC直接交换消息的Kerberos SSP一起工作（工作站通过DNS查询定位KDC。每个域控制器都是一个KDC，并在DNS中注册它们的角色）。
2. 在身份认证服务交换中得到TGT
在身份认证服务交换中，包括了4条消息，其实也就是4个主要的步骤，它们分别如下。
身份认证服务请求（Authentication Service Request，KRB_AS_REQ）。
身份认证服务响应（Authentication Service Reply，KRB_AS_REP）。
票证许可服务请求（Ticket-Granting Service Request，KRB_TGS_REQ）。
票证许可服务响应（Ticket-Granting Service Reply，KRB_TGS_REP）。
以上4条消息在5.6节也有介绍，是整体6条消息中的前4条，用于客户端与KDC之间的身份认证。本节只是针对具体的示例专门进行介绍。
（1）发送服务认证服务请求消息。使用Kerberos进行身份认证的客户端在工作站上发送KRB_AS_REQ消息到tailspintoys.com域的KDC中，发送过程及消息所包括的内容如图5-11所示。
 
 
图5-11  客户端向KDC发送KRB_AS_REQ消息
KRB_AS_REQ消息内容是预身份认证数据（Pre-authencation Data），具体包括以下几个部分。
用户主体名称（User Principal Name，UPN）。
域账户。
以从用户密码中得到的用户密钥加密的预身份认证数据（Pre-authentication Data）。
（2）找回用户密钥。
KDC从用户账户数据库中的用户记录可以得到用户密钥副本。当KDC接收到从用户工作站发送的Kerberos客户端请求时，KDC会在账户数据库中搜索该用户，取出其中的用户记录，然后再从记录中的信息字段中取出用户密钥。
如果用户以前登录过网络，KDC会从密码中得到密钥副本，并且从账户数据库中得到其他密钥副本。当用户密码被接受，而且得到用户的长效密钥，在工作站上的Kerberos客户端会立即向KDC请求服务票证和TGS会话密钥，以便在后面的登录会话过程中使用。
（3）校验用户标识。
KDC解密预身份认证数据和评估时间戳是否在有效期内。如果时间戳通过测试，KDC可以确认这个预身份认证数据是以用户密钥加密的，并确认用户是真实的。
在校验完用户标识后，KDC创建可以提供票证许可服务的Kerberos客户端的凭证。
（4）KDC以它自己的票证服务的身份认证服务应答（KRB_AS_REP）消息进行应答。发送过程及消息内容如图5-12所示。这个特殊的服务票证称为票证许可票证（TGT），像普通的服务票证一样，TGT包含用户会话服务所需的会话密钥副本。这个返回TGT给用户的消息也包括用户可以用来与KDC会话的会话密钥副本。TGT是以KDC长效密钥进行加密的，用户会话密钥副本是以用户长效密钥进行加密的。
 
 
图5-12  KDC响应客户端的KRB_AS_REP消息发送过程及消息内容
KRB_AS_REP消息包括如图5-13所示的内容。
 
 
图5-13  KRB_AS_REP消息内容
具体内容如下。
用户使用TGS时所需的TGS会话密钥（Ticket-Granting Service Seesion Key），是从用户密码中转换而来的用户密钥进行加密的。
在tailspintoys.com域中KDC的TGT，是以TGS密钥进行加密的。TGT包括以下两个。
KDC是用来与用户交互的TGS会话密钥。
用户身份认证数据（Authorization Data）。
而认证数据又包括以下3方面。
用户账户SID。
用户所属tailspintoys.com.域中安全组的SID。
包括该用户或者该用户所属域组的企业通用组SID。
（5）当客户端接收到来自KDC基于原始请求响应时，客户端使用它自己缓存中的用户密钥副本进行解密，得到TGS会话密钥副本。此时就可以丢弃从用户密码中得来的用户密钥，因为在有了TGS会话密钥后，用户密钥已不再需要了。在后面与KDC的所有交换中，客户端都是使用TGS会话密钥的。就像其他会话密钥一样，TGS会话密钥也是临时的，仅在TGT过期前或者关机前有效。所以TGS会话密钥通常被称为"登录会话密钥"，这也是在5.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。发送过程及消息所包括的内容如图5-14所示。
 
 
图5-14  客户端向KDC发送KRB_TGS_REQ消息过程及消息内容
 
KRB_TGS_REQ消息内容包括以下几个方面。
目标计算机名。
目标计算机所在域名。
用户TGT。
以用户与KDC共享的会话密钥加密的认证符。
（7）KDC以票证许可服务响应（KRB_TGS_REP）消息的方式把两份会话密钥副本都发送到用户。用户自己的那个副本是由KDC和用户共享的密钥加密的，工作站的那份会话密钥副本是与用户信息一起植入到服务票证的数据结构中的。整个数据结构也是用KDC与用户共享的密钥加密的。发送过程及KRB_TGS_REP消息包括的内容如图5-15所示。
 
 
图5-15  KDC向客户端发送KRB_TGS_REP消息过程及消息内容
KRB_TGS_REP消息内容包括（具体如图5-16所示）以下几方面。
用户和计算机共享的会话密钥，是以用户和KDC共享的会话密钥进行加密的。
用户服务票证，是以计算机加密密钥进行加密的。
服务票证又包括以下两点。
用户和计算机共享的会话密钥。
从用户TGT中复制的身份认证数据。
当Kerberos客户端接收到KDC的响应时，它解密其票证和用户的会话密钥副本，把它保存在凭据缓存中（是一种非永久性存储器，并非磁盘）。
 
 
 
 
图5-16  KRB_TGS_REP消息内容
（8）获得用户凭据进行登录。在凭证到达工作站后，Windows Server 2003访问令牌的创建过程与Windows NT版本是一样的。工作站上的LSA接收到用户服务票证，并以存储在凭证缓存中的系统密钥（System Key）进行解密，然后取出身份认证数据。特权属性证书（PAC）从服务票证中取出，并用来创建用户访问令牌。然后LSA查询本地SAM数据库，以发现用户是否是计算机上任何安全组的成员，是否是在本地计算机上获得了特殊权限的组的成员。查询后，会在从票证中的身份认证数据得到的令牌列表中添加相应的SID。整个列表被用来构建访问令牌，以及返回到Windlogon的令牌访问句柄。
Winlogon创建Windows位置和用户的几个桌面对象，关联用户访问令牌，开始外壳程序进程，用户进入目标计算机。
当用户注销登录后，凭证缓存将全部清空，所有服务票证包括会话密钥都将被销毁。
完整的用户登录的过程如图5-17所示。
 
 
图5-17  用户登录过程
 
5.7.4  单域身份认证示例
在下面的示例中，用户和服务都是在tailspintoys.com域中的，用户已经登录（登录过程参见上节介绍），而且用户已为工作站请求和接收了票证。客户端想要访问\server\shared文件夹中的文件。
这部分所需用到的Kerberos密钥如图5-18所示。
 
（3）当Kerberos客户端收到响应的KRB_TGS_REP后，使用用户的TGS会话密钥解密服务会话密钥，以备应用服务时所需，同时在凭证缓存中存储这个服务会话密钥。用户工作站的Kerberos客户端以发送Kerberos应用请求（KRB_AP_REQ）消息方式向服务器发出服务请求。KRB_AP_REQ请求发送过程及所包括的内容如图5-21所示。
KRB_AP_REQ消息包括以下内容（如图5-22所示）。
指示是否使用服务会话密钥的应用标志（Flag）选项（这项设置在配置Kerberos应用时是一个可选项，用户从不会请求的）。
指示客户端是否要相互身份认证（Mutual Authentication）的应用选项标志。
在TGT交换中获得的服务票证。
以服务会话密钥加密的认证符。
 
 
图5-21  KRB_AP_REQ消息发送
 
 
 
图5-22  KRB_AP_REQ消息内容
（4）当Kerberos服务器接收到KRB_AP_REQ请求后，解密票证，并从中取出用户的身份认证数据和服务会话密钥。服务使用这个会话密钥解密用户认证符，然后评估其中的时间戳。如果认证符通过评估，服务会在客户端请求中查找相互身份认证标志。如果设置了相互身份认证标志，服务使用会话密钥加密从用户认证符中得到的时间戳，并以发送Kerberos 应用响应（KRB_AP_REP）请求的方式响应客户端。如果没有找到相互身份认证标志，则无须响应。KRB_AP_REP消息发送过程及所包括的内容如图5-23所示。
 
 
图5-23  KRB_AP_REP消息发送过程及内容
（5）当用户工作站中的客户端接收到服务器端发来的KRB_AP_REP响应消息后，它以与服务共享的服务会话密钥解密服务的认证符，并且与客户端原始认证符中的时间戳进行比较，如果一致，则客户端知道服务是真实的。
（6）然后客户端从Kerberos服务票证中构建服务访问令牌，Windows Server 2003的令牌创建进程与早期的Windows系统一样。然后服务器使用Kerberos身份认证协议进行身份认证，PAC是从服务票证中得到的，并且用于创建用户访问令牌。