对 Kerberos 认证的简单介绍
认证流程
Kerberos 认证由 KDC（Key Distribution Center）服务提供，以下为 Kerberos 认证流程：
大致分为三大步：AS、TGS、AP
三大步骤
AS 的过程
这一步向 AS（Authentication Services）发送请求，获取 TGT（Ticket-granting ticket），AS 会向 AD（Account Database）请求账户对应的密钥，对 Authenticator 进行解密获得时间戳，如果时间戳的值在一定范围内，则认证成功（也称预认证），之后 AS 会生成一个随机的 Session Key，在发送响应时会使用用户的密钥加密它，TGT 中的部分内容会使用 krbtgt 的密钥进行加密
其中 AS-REP 的 PAC（Privilege Attribute Certificate 特权属性证书）是微软在 Kerberos 协议里扩展的一个模块，在最初的 Kerberos 认证流程里，只说明如何认证客户端的真实身份，并没有说明客户端是否有权限访问该服务，所以微软扩展该模块来实现，这样的好处就在于服务端接收到客户端的请求时不再需要借助 KDC 提供的授权信息来完成用户的权限判断，而只需要根据请求里包含的 PAC 信息直接和本地 ACL 相比来做出判断，在 PAC 中包含着用户的 User RID 和 Group RID等，服务主要靠这些信息来判断用户的访问权限
客户端拿到 AS 的响应后，会缓存 TGT 和 Session key，客户端能够通过密钥解密出 Session Key，而不能解密 TGT 中由 krbtgt 密钥解密的部分
TGS 的过程
在这一步，客户端向 TGS（Ticket-Granting-Service）发送请求，尝试获取 ST，TGS 收到请求后，会解密 TGT 加密的部分，并对时间戳进行验证，确保会话的安全，TGS-REP 中，KDC 不会验证客户端是否具有权限访问客户端，因此，不管用户有没有访问服务的权限，只要 TGT 正确，均会返回 ST
其中 ST 的结构和上一步返回的 TGT 的结构很相似，从图中可见明显的区别只有把 Logon Session Key 换为了 Service Session Key，这个 Session Key 由 KDC 随机生成
AP 的过程
客户端拿到 TGS 的回复后，会解密得到 Service Session Key，同时拿到 ST，这些数据会被客户端缓存，下一步发起 AP-REQ，AP-REQ 是可选的，服务端拿到请求后，通过解密 ST 拿到 Service Session Key，再解密加密的时间戳，判断是否合法，合法即验证了客户端的身份，服务端从 ST 中取出 PAC 的信息，再与请求的服务的 ACL 进行比较，生成对应的访问令牌，如果客户端声明想要验证服务端，则服务端会使用 Service Session Key 加密时间戳返回给客户端，让客户端进行验证
Kerberos 协议的安全问题
如下图：
本文参考链接：
域渗透攻防指南（谢兆国、张秋圆 著）