域认证体系
Active Directoru(活动目录)
存储了域中相关的网络对象
网络对象：用户，用户组，计算机，域，组织单位及其他安全策略
AD安装在域控上。
Kerberos协议
参与角色
Clint 客户端
Server 服务端
DC 域控制器，DC中包含AD和KDC
KDC中包含Authentication Service(AS)和Ticket Granting Service(TGS)
AS为客户端生成TGT,TGS负责为客户端生成某个服务的ticket
AD存储所有客户端得白名单，只有在白名单里得客户端才能顺利得申请到TGT
Kerberos认证粗略流程
1． 首先，客户端向域控请求，域控需要检查该客户端是否在AD当中，这一步是由AS来完成得。
2． 如果请求的客户端在AD当中，则反会AS和TGT给客户端。
3． 客户端获取TGT后，继续向域控申请某个服务的访问权限，这一步的认证是由TGS完成的。
4． 域控向客户端发送某一个服务的ticket
5． 客户端获取ticket后，可以访问服务器了，这个ticket只针对于该服务器，如果要访问其他服务器，还需要重新申请。
6． 服务器响应
Kerberos认证流程详解
对比上述粗略流程，对每一步进行剖析
1. 客户端发送KRB_AS_REQ。
该步骤目的是为了获取AS和TGT
发送的请求被称为KRB_AS_REQ,其中包含以下三个信息
1、 Pre-authentication data，这是使用客户端NTLM hash加密的一个时间戳，用于KDC验证客户端身份。
2、 客户端信息，代表客户端的一个标识，用于KDC查找客户端的HTML hash
3、 服务器信息，代表KDC当中的TGS
2. KDC向客户端回复KRB_AS_REP
KDC向客户端下发AS和TGT,这两部分需要拆分剖析
AS中包含一个被客户端的NTLM hash加密的seesion key，这个seesion key 是KDC随机生成的，AS就是将这个seesion key用客户端发送的用户名的NTLM hash加密后的产物，如果认证通过，KDC将会把这个被加密的值发送给客户端，并继续申请TGT，这个值用来后续与TGS进行通信。
TGT,是客户端向TGS申请票据的凭证，其中包含session key，这个session key跟AS中的session key是一样的，其次包含客户端的用户名，域名等相关信息，还包含一个TGT的到期时间，这个时间一般为8小时。KDC会使用自己的NTML hash，加密session key和客户端的信息，发送给客户端。这里KDC的hash，是指KDC中krbtgt用户的hash
注意，客户端获取AS和TGT以后，是可以解密AS获取session key的，因为AS本身就是用的客户端的NTLM hash加密的，但客户端无法解密TGT,因为是TGT是用KDC的NTLM hash加密的。
3. 客户端向TGS通信申请ticket
客户端需要将三个信息发送给TGS，第一部分就是刚才KDC给分发的TGT,客户端需要将这个TGT原封不动的发送给TGS,第二部分就是用session key加密的客户端信息和时间戳，第三部分客户端信息和服务端信息。
TGS接收到这些请求后，首先回解密TGT，来获取Session key以及TGT中包含的客户端信息和时间戳，然后使用session key来解密客户端发来的第二部分信息，将这部分信息与TGT当中的客户端信息，时间戳进行对比，如果客户端信息，时间戳都没有问题，则认证通过，最后在校验第三部分，判断客户端是否有权限访问服务端，如果这几步都通过，则分发ticket。
4. TGS将ticket分发给客户端
在所有认证完成后，TGS向客户端分发ticket。会下发两部分内容，一部分是用session key加密server session key得到的一个值，这个server session key是TGS重新生成得一个session key，表现形式上与session key相同，都是随机的，但server session key和session key并不相同。
第二部分，根据客户端发来的服务端信息，TGS会寻找对应服务端的NTLM hash，并使用这个hash和部分信息生成ticket，ticket的详细剖析如下：
Ticket的内容就是使用server hash来加密server session key，客户端信息，结束时间的值。
至此，客户端获取ticket成功，客户端与KDC之间的通信就此结束。
5. 客户端向服务端通信，发送KRB_AP_REQ
KRB_AP_REQ包含两部分信息，第一部分就是TGS发送的ticket，第二部分，是使用session key将TGS发送的加密的server session key解密 ，然后使用server session key来加密客户端信息和时间戳，这两部分构成KRB_AP_REQ发送给服务端。
6. 服务端校验客户端所发内容
服务端通过使用自己的NTLM hash来解密ticket，获取server session key，再使用server session key来解密客户端发送的客户端信息和时间戳。
对比ticket中与客户端所发信息中的客户端信息是否相同，时间戳是否过期，符合要求则认证通过，至此整个认证过程完成。