比来一段时候都在折腾安然(Security)方面的东西，好比Windows认证、非对称加密、数字证书、数字签名、TLS/SSL、WS-Security等。假定时候承诺，我很甘愿答应写一系列的文章与广大年夜网友分享、交换。对良多读者来讲，今天会商的多是一个既熟谙、又目生的话题——Windows认证。
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返回给客户端。(以上的内容对应流程图中的步调1、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答复给客户端。(以上的内容对应流程图中的步调3、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，而这个会话秘钥不为外人知晓(以上的内容对应流程图中的步调5、6)
以上的内容仅仅讲述的是基于Kerberos的Windows认证的大年夜体流程，其实不触及到一些细节的东西，好比若何确保时候的同步，若何抵抗Replay Attack等。别的，因为本文对Windows底层的常识有限，不克不及确保所有的内容都是完全准确，如有弊端，还往不吝斧正。