对于Kerberos认证，可以大概如下图：
但是如果是详细的话，Kerberos认证过程可以分为三个部分，六个过程
1.AS-REQ&&AS-REP
1.AS-REQ
当域内某个用户输入了账号或者密码的时候，客户端就会发送一个authenticator的认证请求给KDC的AS，其中的authenticator包含了客户端用NTLM哈希加密的时间戳，用户名，主机IP，以及一些其他的信息
2.AS-REP
在KDC中的AS收到AS-REQ请求之后，KDC会先检查用户是否在白名单中，如果在，则会使用客户端的密钥对authenticator预认证（没有用到ntlm加密）进行解密，如果解密成功，则进行如下
- AS随机生成一个sessionkey，并且使用用户的密码的ntlm哈希对其进行加密
- 使用默认账户的krbtgt的ntlm哈希对sessionkey，客户端信息，时间戳，到期时间进行加密，得到TGT
然后包含以上发送包含以上两个东西的AS-REP的响应给客户端
2.TGS-REG&&TGS-REQ
1.TGS-REG
在接到KDC发来的响应包之后，客户端会用自己的ntlm哈希的密码生成的密钥对sessionkey部分进行解密，得到sessionkey，然后发送给KDC的TGS两个东西，分别是经过sessionkey加密后的ip，时间戳等，以及原封不动的TGT，和要访问的服务。
2.TGS-REG
在TGS接受到用户端的TGS-REQ之后，KDC中的TGS会用krbtgt中的密码生成的密钥对TGT进行解密，得到sessionkey，并且查看是否超时，在不超时的情况下，TGS会继续对客户端使用了sessionkey加密的部分解密，如果得到的数据和TGT中的数据完全相同，那么就会返回:
- ST（Server Ticket）用于客户端与服务端的通信，包含新的sessionkey
- 新的sessionkey，让客户端用于与目标服务器通信
- 一些用旧的sessionkey加密的东西
3.AP-REQ&&AP-REP
1.AP-REQ
在客户端收到TGS的响应之后，客户端会对一部分用旧的sessionkey进行解密，并且得到对应的时间信息，在对比时间信息无误之后，客户端就会对服务器发起请求！！！
通过新的sessionkey加密对应的主机信息和时间戳，然后将这一部分和ST发送给服务端
2.AP-REP
在服务端收到AP-ERQ之后，其会用自己的密钥对ST解密，得到新的sessionkey，然后再对另一部分用新得到的sessionkey解密，对比其与ST中的相应信息是否相同，如果相同则为校验成功，如果用户配置了校验服务端的话，服务端还会用新的sessionkey加密一段表示接受的信息返回个客户端，当客户端收到后进行解密后对比如果完全一样则知道服务器与自己有相同的sessionke有！！
明天讲啥呢？？？ 那就来讲黄金票据和白银票据吧，先消化一下今天所学的知识！！
