- 参考链接：
详解kerberos认证原理，真的超级无敌详细~~~
kerberos认证的示意图
域控制器（AD）里面有两个重要的服务：Authentication Service(AS)、Ticket Granting Service(TGS)
角色：客户端，AD，服务端
KDC负责管理票据、认证票据、分发票据但是 。KDC 不是一个独立的服务它由以下服务组成：
AS：身份验证服务
TGS：票据分发服务
TGT：票据分发票据
KDC：密钥分发中心（这里理解为AD）
session key：AS随机生成的会话密钥
server session key：TGS随机生成的服务会话密钥
时间相关的信息：时间戳
目的：客户端要访问控制服务端，与服务端建立连接通信。
AS
-
AS-REQ：客户端发送自己的信息以及要连接的服务端信息给AS，AS去AD查看是否为白名单，验证通过，AS返回
session key和TGT1、TGT2
- TGT1(session key，TGS服务信息，结束信息)（使用客户端的NTLM hash加密）
- TGT2(session key，客户端信息，结束时间) （KDC NTLM hash加密）
-
AS-REP：客户端接收AS返回的session key及TGT1、TGT2，随后发送
认证因子+TGT2+客户端信息+服务端信息给TGS
- 使用自己客户端的NTML hash解密TGT1得到里面的session key，TGS服务信息，结束信息(应该会验证一下sessoin key是否一致)
- 使用解密出来的session key加密生成认证因子(客户端信息，当前时间...等信息)
TGS
-
TGS-REQ：TGS接收到 认证因子+TGT2+客户端信息+服务端信息，校验后，将生成的
TGT3和TGT4发送给客户端
- TGS会先用KDC NTLM hash解密TGT2，得到里面的 session key，客户端信息，结束时间
- 再利用session key解密认证因子，得到里面的 客户端信息，当前时间(时间戳)...等信息
- 校验：
当前系统时间和时间戳(对比未过期)；
(认证因子)客户端信息和(TGT2)客户端信息；
客户端访问服务端的权限；
......
- 生成server session key
- TGT3(sever session key，服务端信息，票据到期时间)（使用session key加密）
- TGT4(server session key，客户端信息，票据到期时间)（使用服务端NTLM hash加密）
-
TGS-REP：客户端接收到TGT3和TGT4后，将生成的
认证因子2+TGT4发送给服务端
- 使用session key解密TGT3(sever session key，服务端信息，票据到期时间)
- 使用解密出来的server session key加密生成认证因子2(服务器信息，票据到期时间...等信息)
Server
- AP-REQ：服务端接收到认证因子+TGT4，认证成功，服务端返回请求数据
- 使用自己服务端的NTML hash解密TGT4(server session key，客户端信息，票据到期时间)
- 使用解密出来的server session key解密认证因子2(服务器信息，票据到期时间...等信息)
- AP-REP：客户端接收数据，成功建立通信连接
kerberos认证的时序图
PAC
在 Kerberos 最初设计的几个流程里说明了如何证明 Client 是 Client 而不是由其他人来冒充的但并没有声明 Client 有没有访问 Server 服务的权限因为在域中不同权限的用户能够访问的资源是有区别的。
所以 Microsoft 为了解决这个问题在实现 Kerberos 时加入了 PAC 的概念PAC 的全称是 Privilege Attribute Certificate特权属性证书。
PAC 可以理解为一串校验信息为了防止被伪造和串改原则上是存放在 TGS 里并且 TGS 由 KDC hash 加密。同时尾部会有两个数字签名分别由 KDC 密码和 server 密码加密防止数字签名内容被篡改。
Ticket
