Kerberos认证过程

1、Kerberos认证简介

Windows认证协议有两种NTLM（NT LAN Manager）和Kerberos， 前者主要应用于用于Windows NT 和 Windows 2000 Server（or Later） 工做组环境，然后者则主要应用于Windows 2000 Server（or Later） 域（Domain）环境。Kerberos较之NTLM更高效、更安全，同时认证过程也相对复杂。Kerberos这个名字来源于希腊神话，是冥界守护神 兽的名字。Kerberos是一个三头怪兽，之因此用它来命名一种彻底认证协议，是由于整个认证过程涉及到三方：客户端、服务端和KDC（Key Distribution Center）。在Windows域环境中，KDC的角色由DC（Domain Controller）来担当。

某个用户采用某个域账号登陆到某台主机，并远程访问处于相同域中另外一台主机时，如何对访问者和被访问者进行身份验证（这是一种双向的验证）？这就是Kerberos须要解决的场景。接下来我尽可能以比较直白的语言来介绍我所知道的Kerberos认证的整个流程。

Kerberos其实是一种基于票据（Ticket）的认证方式。客户端要访问服务器的资源，须要首先购买服务端承认的票据。也就是说，客户端在访问服务器以前须要预先买好票，等待服务验票以后才能入场。在这以前，客户端须要先买票，可是这张票不能直接购买，须要一张认购权证。客户端在买票以前须要预先得到一张认购权证。这张认购权证和进入服务器的入场券均有KDC发售。右图（点击看大图）一张图基本揭示了Kerberos整个认证的过程。

2、如何得到“认购权证”？

首先，咱们来看看客户端如何得到“认购权证”。这里的认购权证有个专有的名称——TGT（Ticket Granting Ticket），而TGT的是KDC一个重要的服务——认证服务（KAS：Kerberos Authentication Service）。当某个用户经过输入域账号和密码试图登陆某台主机的时候，本机的Kerberos服务会向KDC的认证服务发送一个认证请求。该请求主要包括两部份内容，明文形式的用户名和通过加密的用于证实访问者身份的Authenticator（我实在找不到一个比较贴切的中文翻译没，Authenticator在这里能够理解为仅限于验证双反预先知晓的内容，至关于联络暗号）。

当KDC接收到请求以后，经过AD获取该用户的信息。经过获取的密码信息生成一个秘钥对Authenticator进行解密。若是解密后的内容和已知的内容一致，则证实请求着提供的密码正确，即肯定了登陆者的真实身份。

KAS成功认证对方的身份以后，会先生成一个用于确保该用户和KDC之间通讯安全的会话秘钥——Logon Session Key，并采用该用户密码派生的秘钥进行加密。KAS接着为该用户建立“认购权证”——TGT。TGT主要包含两方面的内容：用户相关信息和Logon Session Key，而整个TGT则经过KDC本身的密钥进行加密。最终，被不一样密钥加密的Logon Session Key和TGT返回给客户端。（以上的内容对应流程图中的步骤一、2）

3、如何经过“认购权证”购买“入场券”？

通过上面的步骤，客户端获取了购买进入同域中其余主机入场券的“认购凭证”——TGT，以及Logon Session Key，它会在本地缓存此TGT和Logon Session Key。若是如今它须要访问某台服务器的资源，它就须要凭借这张TGT向KDC购买相应的入场券。这里的入场券也有一个专有的名称——服务票据（ST：Service Ticket）。

具体来讲，ST是经过KDC的另外一个服务TGS（Ticket Granting Service）出售的。客户端先向TGS发送一个ST购买请求，该请求主要包含以下的内容：客户端用户名；经过Logon Session Key加密的Authenticator；TGT和访问的服务器（实际上是服务）名。

TGS接收到请求以后，现经过本身的密钥解密TGT并获取Logon Session Key，而后经过Logon Session Key解密Authenticator，进而验证了对方的真实身份。

TGS 存在的一个根本的目有两点：其一是避免让用户的密码客户端和KDC之间频繁传输而被窃取。其二是由于密码属于Long Term Key（咱们通常不会频繁的更新本身的密码），让它做为加密密钥的安全系数确定小于一个频繁变换得密钥（Short Term Key）。而这个Short Term Key就是Logon Session Key，它确保了客户端和KDC之间的通讯安全。

TGS完成对客户端的认证以后，会生成一个用于确保客户端-服务器之间通讯安全的会话秘钥——Service Session Key，该会话秘钥经过Logon Session Key进行加密。而后出售给客户端须要的入场券——ST。ST主要包含两方面的内容：客户端用户信息和Service Session Key，整个ST经过服务器密码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST回复给客户端。（以上的内容对应流程图中的步骤三、4）

4、凭票入场

客户端接收到TGS回复后，经过缓存的Logon Session Key解密获取Service Session Key。同时它也获得了进入服务器的入场券——ST。那么它在进行服务访问的时候就能够借助这张ST凭票入场了。该Serivce Session Key和ST会被客户端缓存。

可是，服务端在接收到ST以后，如何确保它是经过TGS购买，而不是本身伪造的呢？这很好办，不要忘了ST是经过本身密码派生的秘钥进行加密的。具体的操做过程是这样的，除了ST以外，服务请求还附加一份经过Service Session Key加密的Authenticator。服务器在接收到请求以后，先经过本身密码派生的秘钥解密ST，并从中提取Service Session Key。而后经过提取出来的Service Session Key解密Authenticator，进而验证了客户端的真实身份。

实际上，到目前为止，服务端已经完成了对客户端的验证，可是，整个认证过程尚未结束。谈到认证，不少人都认为只是服务器对客户端的认证，实际上在大部分场合，咱们须要的是双向验证（Mutual Authentication）——访问者和被访问者互相验证对方的身份。如今服务器已经能够确保客户端是它所声称的那么用户，客户端尚未确认它所访问的不是一个钓鱼服务呢。

为了解决客户端对服务器的验证，服务要须要将解密后的Authenticator再 次用Service Session Key进行加密，并发挥给客户端。客户端再用缓存的Service Session Key进行解密，若是和以前的内容彻底同样，则能够证实本身正在访问的服务器和本身拥有相同的Service Session Key，而这个会话秘钥不为外人知晓（以上的内容对应流程图中的步骤五、6）