记录一下我对Kerberos协议比较深入的理解吧，放一个别人的图便于捋清思路。
第一次请求：AS_REQ Client向KDC的AS发送请求
发送：Client的NTLM-Hash加密的时间戳以及Client-info、Server-info等数据以及一些其他信息
第一次返回：AS_REP KDC的AS向Client返回数据
AS向AD验证此Client用户，取出此用户NTML-Hash解密接收到的信息，得到上面的时间戳以及Client-info、Server-info等信息，若时间戳未超过五分钟，则预认证成功。
返回：下面三部分合起来返回给Client
（1）生成的临时密钥Session-Key AS，使用客户端Client的NTML-Hash加密Session-Key AS
（2）TGT：使用域内Krbtgt用户的NTML-Hash加密的Session-Key AS、时间戳、Client-info
（3）PAC：用户的 SID、用户所在的组等一些信息（PAC只有KDC知道，客户端伪造——MS14-068）
第二次请求：TGS_REQ Client向KDC的TGS发送请求
发送：下面两部分合起来发送给TGS
（一）客户端用自己的NTML-Hash解密获得Session-Key AS，并将Session-Key AS缓存在本地，然后用Session-Key AS加密时间戳、Client-info、Server-info
（二）TGT，就是第一次返回的TGT
第二次返回：TG-REP KDC的KGS向Client返回数据
KGS拿到Client第二次的请求的数据后，用Krbtgt用户的NTML-Hash解密TGT，得到Session-Key AS、时间戳、Client-info，并将这里解密得到的信息和第二次请求发送的内容中的第一部分的信息（这里会先使用Session-Key AS解开这部分），再进行对比，如果两部分相等则认证成功。
返回：下面两部分合并起来返回给Client
（一）KGS生成一个Session-Key TGS，并用Session-Key AS加密Session-Key TGS作为返回的第一部分
（二）使用Server段的NTML-Hash加密的Session-Key TGS、时间戳、Client-info等数据生成的ST
第三次请求：AP-REQ Client向服务端发送请求
Client拿到第二次返回的数据后，先使用本地预先缓存的Session-Key AS接开Session-Key TGS，并把ST和Session-Key TGS缓存在本地。
发送：下面两部分合并起来发给Server
（一）使用Session-Key TGS加密Client-info、时间戳等信息
（二）ST，第二次返回的时候Client接收到的ST
第三次返回：AP-REP 服务端向Client返回并建立通信
Server收到Client发送的请求后，用自身的NTML-Hash解密ST，获得Session-Key TGS、时间戳、Client-info，然后再将请求中的第一部分的内容用Session-Key TGS解密，获得Client-info、时间戳等信息，两者对比（时间戳的有效期一般为8小时），如果相同，则认证成功。Server会用PAC去向DC查询该用户是否具有访问该Server的权限，如果具备权限，则返回AP-REP并建立通信。
总结
为什么要这么麻烦呢？这么多次的验证，我们简单分析一下这样做的意义。
拿第一次返回的时候返回的数据来举例：
（1）生成的临时密钥Session-Key AS，使用客户端Client的NTML-Hash加密Session-Key AS
（2）TGT：使用域内Krbtgt用户的NTML-Hash加密的Session-Key AS、时间戳、Client-info
首先一部分是保证客户端能够解密的，以便后续再用解密出来的Session-Key AS去加密下一步认证要用的信息，而TGT是客户端不能解密的，也就保证了下一步Client向TGS验证身份时，一部分信息是自己用Session-Key AS去加密的，还有一部分信息是TGT，这样KGS就可以自己解密TGT，再用TGT中无法伪造的Session-Key AS去解密Client发送的第一部分信息并进行对比
小结一下就是：一部分客户端可控，能解密能修改，另一部分只有下一步认证的接收方才可以解密（TGT），其中包括了客户端发送来的第一部分的加密用的Session-Key AS，再用这个Client去解密，能解开的话，并且数据能够比对成功，就能保证Client发送的数据不是伪造的
再看第二次返回的时候返回的数据：
（一）KGS生成一个Session-Key TGS，并用Session-Key AS加密Session-Key TGS作为返回的第一部分
（二）使用Server段的NTML-Hash加密的Session-Key TGS、时间戳、Client-info等数据生成的ST
这里也是一样道理，Session-Key TGS使用Session-Key AS加密，那么客户端是可以解密并获得Session-Key TGS的，然后下一步发送请求时再用Session-Key TGS来加密自身信息
对比第三次发送请求的数据
（一）使用Session-Key TGS加密Client-info、时间戳等信息
（二）ST，第二次返回的时候Client接收到的ST
服务端接收到之后，首先是解开ST，并获取ST中包含的Session-Key TGS，然后再用这个Session-Key TGS去解密（一）中的信息，可以解密，再去拿ST中的Client-info和时间戳等和（一）中解密的信息对比，也就能保证Client发送过来的信息是可信的。
综上，每一次认证中，都分别使用了客户端能够解开的和不能解开的方式发送了两部分信息，下一段认证中，客户端需要发送重新加密的信息和上一段不能解开的而服务端可以解开的数据（TGT和ST）给服务端（KGS和Server），以便服务端保证有一部分数据是绝对可信的，再去和客户端发送的另一部分进行对比，对比无误则认证通过