kerberos认证原理---讲的很是细致，易懂

前几天在给人解释Windows是如何经过Kerberos进行Authentication的时候，讲了半天也别把那位老兄讲明白，还差点把本身给绕进去。后来想一想缘由有如下两点：对于一个没有彻底不了解Kerberos的人来讲，Kerberos的整个Authentication过程确实很差理解——一下子以这个Key进行加密、一下子又要以另外一个Key进行加密，确实很容易把人给弄晕；另外一方面是我讲解方式有问题，一开始就从Kerberos的3个Sub-protocol全面讲述整个Authentication 过程，对于一个彻底不了解Kerberos的人来讲要求也忒高了点。为此，我花了一些时间写了这篇文章，尽可能以由浅入深、层层深刻的方式讲述我所理解的基于Kerberos的Windows Network Authentication，但愿这篇文章能帮助那些对Kerberos不明就里的人带来一丝帮助。对于一些不对的地方，欢迎你们批评指正。

1、 基本原理

Authentication解决的是“如何证实某我的确确实实就是他或她所声称的那我的”的问题。对于如何进行Authentication，咱们采用这样的方法：若是一个秘密（secret）仅仅存在于A和B，那么有我的对B声称本身就是A，B经过让A提供这个秘密来证实这我的就是他或她所声称的A。这个过程实际上涉及到3个重要的关于Authentication的方面：

• Secret如何表示。
• A如何向B提供Secret。
• B如何识别Secret。

基于这3个方面，咱们把Kerberos Authentication进行最大限度的简化：整个过程涉及到Client和Server，他们之间的这个Secret咱们用一个Key（KServer-Client）来表示。Client为了让Server对本身进行有效的认证，向对方提供以下两组信息：

• 表明Client自身Identity的信息，为了简便，它以明文的形式传递。
• 将Client的Identity使用 KServer-Client做为Public Key、并采用对称加密算法进行加密。

因为KServer-Client仅仅被Client和Server知晓，因此被Client使用KServer-Client加密过的Client Identity只能被Client和Server解密。同理，Server接收到Client传送的这两组信息，先经过KServer-Client对后者进行解密，随后将机密的数据同前者进行比较，若是彻底同样，则能够证实Client能过提供正确的KServer-Client，而这个世界上，仅仅只有真正的Client和本身知道KServer-Client，因此能够对方就是他所声称的那我的。

Keberos大致上就是按照这样的一个原理来进行Authentication的。可是Kerberos远比这个复杂，我将在后续的章节中不断地扩充这个过程，知道Kerberos真实的认证过程。为了使读者更加容易理解后续的部分，在这里咱们先给出两个重要的概念：

• Long-term Key/Master Key：在Security的领域中，有的Key可能长期内保持不变，好比你在密码，可能几年都未曾改变，这样的Key、以及由此派生的Key被称为Long-term Key。对于Long-term Key的使用有这样的原则：被Long-term Key加密的数据不该该在网络上传输。缘由很简单，一旦这些被Long-term Key加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是能够经过计算得到你用于加密的Long-term Key的——任何加密算法都不可能作到绝对保密。

在通常状况下，对于一个Account来讲，密码每每仅仅限于该Account的全部者知晓，甚至对于任何Domain的Administrator，密码仍然应该是保密的。可是密码却又是证实身份的凭据，因此必须经过基于你密码的派生的信息来证实用户的真实身份，在这种状况下，通常将你的密码进行Hash运算获得一个Hash code, 咱们通常管这样的Hash Code叫作Master Key。因为Hash Algorithm是不可逆的，同时保证密码和Master Key是一一对应的，这样既保证了你密码的保密性，有同时保证你的Master Key和密码自己在证实你身份的时候具备相同的效力。

• Short-term Key/Session Key：因为被Long-term Key加密的数据包不能用于网络传送，因此咱们使用另外一种Short-term Key来加密须要进行网络传输的数据。因为这种Key只在一段时间内有效，即便被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已通过期了。

2、引入Key Distribution: KServer-Client从何而来

上面咱们讨论了Kerberos Authentication的基本原理：经过让被认证的一方提供一个仅限于他和认证方知晓的Key来鉴定对方的真实身份。而被这个Key加密的数据包须要在Client和Server之间传送，因此这个Key不能是一个Long-term Key，而只多是Short-term Key，这个能够仅仅在Client和Server的一个Session中有效，因此咱们称这个Key为Client和Server之间的Session Key（SServer-Client）。

如今咱们来讨论Client和Server如何获得这个SServer-Client。在这里咱们要引入一个重要的角色：Kerberos Distribution Center-KDC。KDC在整个Kerberos Authentication中做为Client和Server共同信任的第三方起着重要的做用，而Kerberos的认证过程就是经过这3方协做完成。顺便说一下，Kerberos起源于希腊神话，是一支守护着冥界长着3个头颅的神犬，在keberos Authentication中，Kerberos的3个头颅表明中认证过程当中涉及的3方：Client、Server和KDC。

对于一个Windows Domain来讲，Domain Controller扮演着KDC的角色。KDC维护着一个存储着该Domain中全部账户的Account Database（通常地，这个Account Database由AD来维护），也就是说，他知道属于每一个Account的名称和派生于该Account Password的Master Key。而用于Client和Server相互认证的SServer-Client就是有KDC分发。下面咱们来看看KDC分发SServer-Client的过程。

经过下图咱们能够看到KDC分发SServer-Client的简单的过程：首先Client向KDC发送一个对SServer-Client的申请。这个申请的内容能够简单归纳为“我是某个Client，我须要一个Session Key用于访问某个Server ”。KDC在接收到这个请求的时候，生成一个Session Key，为了保证这个Session Key仅仅限于发送请求的Client和他但愿访问的Server知晓，KDC会为这个Session Key生成两个Copy，分别被Client和Server使用。而后从Account database中提取Client和Server的Master Key分别对这两个Copy进行对称加密。对于后者，和Session Key一块儿被加密的还包含关于Client的一些信息。

KDC如今有了两个分别被Client和Server 的Master Key加密过的Session Key，这两个Session Key如何分别被Client和Server得到呢？也许你 立刻会说，KDC直接将这两个加密过的包发送给Client和Server不就能够了吗，可是若是这样作，对于Server来讲会出现下面 两个问题：

• 因为一个Server会面对若干不一样的Client, 而每一个Client都具备一个不一样的Session Key。那么Server就会为全部的Client维护这样一个Session Key的列表，这样作对于Server来讲是比较麻烦而低效的。
• 因为网络传输的不肯定性，可能出现这样一种状况：Client很快得到Session Key，并将这个Session Key做为Credential随同访问请求发送到Server，可是用于Server的Session Key确尚未收到，而且颇有可能承载这个Session Key的永远也到不了Server端，Client将永远得不到认证。

为了解决这个问题，Kerberos的作法很简单，将这两个被加密的Copy一并发送给Client，属于Server的那份由Client发送给Server。

可能有人会问，KDC并无真正去认证这个发送请求的Client是否真的就是那个他所声称的那我的，就把Session Key发送给他，会不会有什么问题？若是另外一我的（好比Client B）声称本身是Client A，他一样会获得Client A和Server的Session Key，这会不会有什么问题？实际上不存在问题，由于Client B声称本身是Client A，KDC就会使用Client A的Password派生的Master Key对Session Key进行加密，因此真正知道Client A 的Password的一方才会经过解密得到Session Key。 

3、引入Authenticator - 为有效的证实本身提供证据

经过上面的过程，Client实际上得到了两组信息：一个经过本身Master Key加密的Session Key，另外一个被Sever的Master Key加密的数据包，包含Session Key和关于本身的一些确认信息。经过第一节，咱们说只要经过一个双方知晓的Key就能够对对方进行有效的认证，可是在一个网络的环境中，这种简单的作法是具备安全漏洞，为此,Client须要提供更多的证实信息，咱们把这种证实信息称为Authenticator，在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp（关于这个安全漏洞和Timestamp的做用，我将在后面解释）。

在这个基础上，咱们再来看看Server如何对Client进行认证：Client经过本身的Master Key对KDC加密的Session Key进行解密从而得到Session Key，随后建立Authenticator（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC得到的、被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。咱们把经过Server的Master Key加密过的数据包称为Session Ticket。

当Server接收到这两组数据后，先使用他本身的Master Key对Session Ticket进行解密，从而得到Session Key。随后使用该Session Key解密Authenticator，经过比较Authenticator中的Client Info和Session Ticket中的Client Info从而实现对Client的认证。

为何要使用Timestamp？

到这里，不少人可能认为这样的认证过程完美无缺：只有当Client提供正确的Session Key方能获得Server的认证。可是在现实环境中，这存在很大的安全漏洞。

咱们试想这样的现象：Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位本身的Credential冒充该Client对Server进行访问，在这种状况下，依然能够很顺利地得到Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。

在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较以前，会先提取Authenticator中的Timestamp，并同当前的时间进行比较，若是他们之间的误差超出一个能够接受的时间范围（通常是5mins），Server会直接拒绝该Client的请求。在这里须要知道的是，Server维护着一个列表，这个列表记录着在这个可接受的时间范围内全部进行认证的Client和认证的时间。对于时间误差在这个可接受的范围中的Client，Server会从这个这个列表中得到最近一个该Client的认证时间，只有当Authenticator中的Timestamp晚于经过一个Client的最近的认证时间的状况下，Server采用进行后续的认证流程。

Time Synchronization的重要性

上述 基于Timestamp的认证机制只有在Client和Server端的时间保持同步的状况才有意义。因此保持Time Synchronization在整个认证过程当中显得尤其重要。在一个Domain中，通常经过访问同一个Time Service得到当前时间的方式来实现时间的同步。

双向认证（Mutual Authentication）

Kerberos一个重要的优点在于它可以提供双向认证：不但Server能够对Client 进行认证，Client也能对Server进行认证。

具体过程是这样的，若是Client须要对他访问的Server进行认证，会在它向Server发送的Credential中设置一个是否须要认证的Flag。Server在对Client认证成功以后，会把Authenticator中的Timestamp提出出来，经过Session Key进行加密，当Client接收到并使用Session Key进行解密以后，若是确认Timestamp和原来的彻底一致，那么他能够认定Server正式他试图访问的Server。

那么为何Server不直接把经过Session Key进行加密的Authenticator原样发送给Client，而要把Timestamp提取出来加密发送给Client呢？缘由在于防止恶意的监听者经过获取的Client发送的Authenticator冒充Server得到Client的认证。


4、引入Ticket Granting  Service

经过上面的介绍，咱们发现Kerberos实际上一个基于Ticket的认证方式。Client想要获取Server端的资源，先得经过Server的认证；而认证的先决条件是Client向Server提供从KDC得到的一个有Server的Master Key进行加密的Session Ticket（Session Key + Client Info）。能够这么说，Session Ticket是Client进入Server领域的一张门票。而这张门票必须从一个合法的Ticket颁发机构得到，这个颁发机构就是Client和Server双方信任的KDC， 同时这张Ticket具备超强的防伪标识：它是被Server的Master Key加密的。对Client来讲， 得到Session Ticket是整个认证过程当中最为关键的部分。

上面咱们只是简单地从大致上说明了KDC向Client分发Ticket的过程，而真正在Kerberos中的Ticket Distribution要复杂一些。为了更好的说明整个Ticket Distribution的过程，我在这里作一个类比。如今的股事很火爆，上海基本上是全民炒股，我就举一个认股权证的例子。有的上市公司在股票配股、增发、基金扩募、股份减持等状况会向公众发行认股权证，认股权证的持有人能够凭借这个权证认购必定数量的该公司股票，认股权证是一种具备看涨期权的金融衍生产品。

而咱们今天所讲的Client得到Ticket的过程也和经过认股权证购买股票的过程相似。若是咱们把Client提供给Server进行认证的Ticket比做股票的话，那么Client在从KDC那边得到Ticket以前，须要先得到这个Ticket的认购权证，这个认购权证在Kerberos中被称为TGT：Ticket Granting Ticket，TGT的分发方仍然是KDC。

咱们如今来看看Client是如何从KDC处得到TGT的：首先Client向KDC发起对TGT的申请，申请的内容大体能够这样表示：“我须要一张TGT用以申请获取用以访问全部Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通讯的Session Key（SKDC-Client）。为了保证该Session Key仅供该Client和本身使用，KDC使用Client的Master Key和本身的Master Key对生成的Session Key进行加密，从而得到两个加密的SKDC-Client的Copy。对于后者，随SKDC-Client一块儿被加密的还包含之后用于鉴定Client身份的关于Client的一些信息。最后KDC将这两份Copy一并发送给Client。这里有一点须要注意的是：为了免去KDC对于基于不一样Client的Session Key进行维护的麻烦，就像Server不会保存Session Key（SServer-Client）同样，KDC也不会去保存这个Session Key（SKDC-Client），而选择彻底靠Client本身提供的方式。

当Client收到KDC的两个加密数据包以后，先使用本身的Master Key对第一个Copy进行解密，从而得到KDC和Client的Session Key（SKDC-Client），并把该Session 和TGT进行缓存。有了Session Key和TGT，Client本身的Master Key将再也不须要，由于此后Client可使用SKDC-Client向KDC申请用以访问每一个Server的Ticket，相对于Client的Master Key这个Long-term Key，SKDC-Client是一个Short-term Key，安全保证获得更好的保障，这也是Kerberos多了这一步的关键所在。同时须要注意的是SKDC-Client是一个Session Key，他具备本身的生命周期，同时TGT和Session相互关联，当Session Key过时，TGT也就宣告失效，此后Client不得不从新向KDC申请新的TGT，KDC将会生成一个不一样Session Key和与之关联的TGT。同时，因为Client Log off也致使SKDC-Client的失效，因此SKDC-Client又被称为Logon Session Key。

接下来，咱们看看Client如何使用TGT来从KDC得到基于某个Server的Ticket。在这里我要强调一下，Ticket是基于某个具体的Server的，而TGT则是和具体的Server无关的，Client可使用一个TGT从KDC得到基于不一样Server的Ticket。咱们言归正传，Client在得到本身和KDC的Session Key（SKDC-Client）以后，生成本身的Authenticator以及所要访问的Server名称的并使用SKDC-Client进行加密。随后连同TGT一并发送给KDC。KDC使用本身的Master Key对TGT进行解密，提取Client Info和Session Key（SKDC-Client），而后使用这个SKDC-Client解密Authenticator得到Client Info，对两个Client Info进行比较进而验证对方的真实身份。验证成功，生成一份基于Client所要访问的Server的Ticket给Client，这个过程就是咱们第二节中介绍的同样了。 

5、Kerberos的3个Sub-protocol：整个Authentication

经过以上的介绍，咱们基本上了解了整个Kerberos authentication的整个流程：整个流程大致上包含如下3个子过程：

1. Client向KDC申请TGT（Ticket Granting Ticket）。
2. Client经过得到TGT向DKC申请用于访问Server的Ticket。
3. Client最终向为了Server对本身的认证向其提交Ticket。

不过上面的介绍离真正的Kerberos Authentication仍是有一点出入。Kerberos整个认证过程经过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面列出的3个子过程。这3个sub-protocol分别为：

1. Authentication Service Exchange
2. Ticket Granting Service Exchange
3. Client/Server Exchange

下图简单展现了完成这个3个Sub-protocol所进行Message Exchange。

1． Authentication Service Exchange

经过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程以下：

Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于本身和KDC知道，Client使用本身的Master Key对KRB_AS_REQ的主体部分进行加密（KDC能够经过Domain 的Account Database得到该Client的Master Key）。KRB_AS_REQ的大致包含如下的内容：

• Pre-authentication data：包含用以证实本身身份的信息。说白了，就是证实本身知道本身声称的那个account的Password。通常地，它的内容是一个被Client的Master key加密过的Timestamp。
• Client name & realm: 简单地说就是Domain name\Client
• Server Name：注意这里的Server Name并非Client真正要访问的Server的名称，而咱们也说了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name其实是 KDC的Ticket Granting Service的Server Name。

AS（Authentication Service）经过它接收到的KRB_AS_REQ验证发送方的是不是在Client name & realm中声称的那我的，也就是说要验证发送放是否知道Client的Password。因此AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，若是是一个合法的Timestamp，则能够证实发送放提供的是正确无误的密码。验证经过以后，AS将一份Authentication Service Response（KRB_AS_REP）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）和被本身（KDC）加密的TGT。而TGT大致又包含如下的内容：

• Session Key: SKDC-Client：Logon Session Key
• Client name & realm: 简单地说就是Domain name\Client
• End time: TGT到期的时间。

Client经过本身的Master Key对第一部分解密得到Session Key（SKDC-Client：Logon Session Key）以后，携带着TGT即可以进入下一步：TGS（Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange经过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request（KRB_TGS_REQ）开始。KRB_TGS_REQ大致包含如下的内容：

• TGT：Client经过AS Exchange得到的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
• Authenticator：用以证实当初TGT的拥有者是否就是本身，因此它必须以TGT的办法方和本身的Session Key（SKDC-Client：Logon Session Key）来进行加密。
• Client name & realm: 简单地说就是Domain name\Client。
• Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。

TGS收到KRB_TGS_REQ在发给Client真正的Ticket以前，先得整个Client提供的那个TGT是不是AS颁发给它的。因而它不得不经过Client提供的Authenticator来证实。可是Authentication是经过Logon Session Key（SKDC-Client）进行加密的，而本身并无保存这个Session Key。因此TGS先得经过本身的Master Key对Client提供的TGT进行解密，从而得到这个Logon Session Key（SKDC-Client），再经过这个Logon Session Key（SKDC-Client）解密Authenticator进行验证。验证经过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有两部分组成：使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client）和使用Server的Master Key进行加密的Ticket。该Ticket大致包含如下一些内容：

• Session Key：SServer-Client。
• Client name & realm: 简单地说就是Domain name\Client。
• End time: Ticket的到期时间。

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后得到Session Key（SServer-Client）。有了Session Key和Ticket，Client就能够之间和Server进行交互，而无须在经过KDC做中间人了。因此咱们说Kerberos是一种高效的认证方式，它能够直接经过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要经过一个双方信任的第3方来完成。

咱们如今来看看 Client若是使用Ticket和Server怎样进行交互的，这个阶段经过咱们的第3个Sub-protocol来完成：CS（Client/Server ）Exchange。

3． CS（Client/Server ）Exchange

这个已经在本文的第二节中已经介绍过，对于重复发内容就再也不累赘了。Client经过TGS Exchange得到Client和Server的Session Key（SServer-Client），随后建立用于证实本身就是Ticket的真正全部者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket做为Application Service Request（KRB_AP_REQ）发送给Server。除了上述两项内容以外，KRB_AP_REQ还包含一个Flag用于表示Client是否须要进行双向验证（Mutual Authentication）。

Server接收到KRB_AP_REQ以后，经过本身的Master Key解密Ticket，从而得到Session Key（SServer-Client）。经过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问须要访问的资源，不然直接拒绝对方的请求。

对于须要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于Client验证Server的身份。


6、User2User Sub-Protocol：有效地保障Server的安全

经过3个Sub-protocol的介绍，咱们能够全面地掌握整个Kerberos的认证过程。实际上，在Windows 2000时代，基于Kerberos的Windows Authentication就是按照这样的工做流程来进行的。可是我在上面一节结束的时候也说了，基于3个Sub-protocol的Kerberos做为一种Network Authentication是具备它本身的局限和安全隐患的。我在整篇文章一直在强调这样的一个原则：以某个Entity的Long-term Key加密的数据不该该在网络中传递。缘由很简单，全部的加密算法都不能保证100%的安全，对加密的数据进行解密只是一个时间的过程，最大限度地提供安全保障的作法就是：使用一个Short-term key（Session Key）代替Long-term Key对数据进行加密，使得恶意用户对其解密得到加密的Key时，该Key早已失效。可是对于3个Sub-Protocol的C/S Exchange，Client携带的Ticket倒是被Server Master Key进行加密的，这显现不符合咱们提出的原则，下降Server的安全系数。

因此咱们必须寻求一种解决方案来解决上面的问题。这个解决方案很明显：就是采用一个Short-term的Session Key，而不是Server Master Key对Ticket进行加密。这就是咱们今天要介绍的Kerberos的第4个Sub-protocol：User2User Protocol。咱们知道，既然是Session Key，仅必然涉及到两方，而在Kerberos整个认证过程涉及到3方：Client、Server和KDC，因此用于加密Ticket的只多是Server和KDC之间的Session Key（SKDC-Server）。

咱们知道Client经过在AS Exchange阶段得到的TGT从KDC那么得到访问Server的Ticket。原来的Ticket是经过Server的Master Key进行加密的，而这个Master Key能够经过Account Database得到。可是如今KDC须要使用Server和KDC之间的SKDC-Server进行加密，而KDC是不会维护这个Session Key，因此这个Session Key只能靠申请Ticket的Client提供。因此在AS Exchange和TGS Exchange之间，Client还得对Server进行请求已得到Server和KDC之间的Session Key（SKDC-Server）。而对于Server来讲，它能够像Client同样经过AS Exchange得到他和KDC之间的Session Key（SKDC-Server）和一个封装了这个Session Key并被KDC的Master Key进行加密的TGT，一旦得到这个TGT，Server会缓存它，以待Client对它的请求。咱们如今来详细地讨论这一过程。

上图基本上翻译了基于User2User的认证过程，这个过程由4个步骤组成。咱们发现较之我在上面一节介绍的基于传统3个Sub-protocol的认证过程，此次对了第2部。咱们从头至尾简单地过一遍：

1. AS Exchange：Client经过此过程得到了属于本身的TGT，有了此TGT，Client可凭此向KDC申请用于访问某个Server的Ticket。
2. 这一步的主要任务是得到封装了Server和KDC的Session Key（SKDC-Server）的属于Server的TGT。若是该TGT存在于Server的缓存中，则Server会直接将其返回给Client。不然经过AS Exchange从KDC获取。
3. TGS Exchange：Client经过向KDC提供本身的TGT，Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket。KDC使用先用本身的Master Key解密Client的TGT得到SKDC-Client，经过SKDC-Client解密Authenticator验证发送者是不是TGT的真正拥有者，验证经过再用本身的Master Key解密Server的TGT得到KDC和Server 的Session Key（SKDC-Server），并用该Session Key加密Ticket返回给Client。
4. C/S Exchange：Client携带者经过KDC和Server 的Session Key（SKDC-Server）进行加密的Ticket和经过Client和Server的Session Key（SServer-Client）的Authenticator访问Server，Server经过SKDC-Server解密Ticket得到SServer-Client，经过SServer-Client解密Authenticator实现对Client的验证。

这就是整个过程。

7、Kerberos的优势

分析整个Kerberos的认证过程以后，咱们来总结一下Kerberos都有哪些优势：

1．较高的Performance

虽然咱们一再地说Kerberos是一个涉及到3方的认证过程：Client、Server、KDC。可是一旦Client得到用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每一个彻底依赖Trusted Third Party的NTLM比较，具备较大的性能提高。

2．实现了双向验证（Mutual Authentication）

传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，因此NTLM未曾提供双向验证的功能。这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源以前，能够要求对Server的身份执行认证。

3．对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation容许Server在本地使用Logon 的Account执行某些操做，Delegation需用Server将logon的Account带入到另过一个Context执行相应的操做。NTLM仅对Impersonation提供支持，而Kerberos经过一种双向的、可传递的（Mutual 、Transitive）信任模式实现了对Delegation的支持。

4．互操做性（Interoperability）

Kerberos最初由MIT独创，如今已经成为一行被普遍接受的标准。因此对于不一样的平台能够进行普遍的互操做。