Windows协议 Kerberos篇

认证流程

角色	功能
Domain Controller	也就是域控
Key Distribution Center	秘钥分发中心，简称KDC，默认安装在域控里，包括AS、AD和TGS。
Account Database	类似于SAM的一个数据库(AD)，存储所有client的白名单，只有存 在于白名单的client才能顺利申请到TGT
Authentication Service	简称为AS，为client生成TGT的服务；也就是认证服务
Session Key	会话密钥
Session Key Distribution	会话密钥分发，当客户端想要连接到服务器时，客户端会向 KDC 发送请求，KDC 会分发一个唯一的短期会话密钥，供双方在相互验证时使用
Ticket	票据，是网络对象互相访问的凭证
Ticket Granting Ticket	票据授权票据（TGT）。TGT 使身份验证服务能够安全地将请求者的凭据传输到票证授予服务。
Ticket Granting Service:	简称为TGS，为client生成某个服务的ticket；也就是出票服务
User key	也就是用户的NTLM Hash

AS_REQ & AS_REP

从AS中获取TGT

消息 1：身份验证服务请求(Authentication Service Request)

也就是AS_REQ

client将消息发送到KDC

该消息包括：

1. 用户主体名称。
2. 帐户域的名称。
3. 使用从用户密码派生的用户密钥加密的预身份验证数据。(NTLM Hash(Timestamp))

检索用户密钥

当 KDC 收到来自用户工作站上 Kerberos 客户端的请求时，KDC 会在其数据库中搜索该用户，提取帐户记录，并从记录中的字段中获取用户密钥

验证用户身份

KDC 解密预认证数据并评估其中的时间戳。如果时间戳通过测试，则 KDC 可以确信预认证数据是用用户密钥加密的，从而验证用户是真实的。

消息 2：身份验证服务回复(Authentication Service Reply)

也就是AS_REP

会回复两个消息

1. Client NTLM Hash(Session Key)，用户与TGS一起使用的TGS会话密钥，使用用户的NTLM Hash进行加密；用于后续和TGS服务进行通信
2. TGT，使用TGS密钥加密
   
   TGT 包括：

• KDC 与用户一起使用的 TGS 会话密钥。
• 用户的授权数据。
• 授权数据包括：
• 用户帐户的 SID。
• 用户所在域 tailspintoys.com 中的安全组的 SID。
• 企业中通用组的 SID，包括用户或用户所属的域组之一。

当client收到server的回复时，用自己的NTLM Hash解密消息1，获得其中的Session Key

客户端不需要解密消息2(他也解密不了 没有key)，只需要消息1中的TGS Session Key就可以向TGS发起请求

TGS_REQ & TGS_REP

从TGS中获取ticket

消息 3：票据授予服务请求

也就是TGS_REQ



可以从图中看出 发送过去的也有两部分

1. TGT: 用户的TGT
2. Authenticator：在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp；Authenticator=Session Key(Client info + Timestamp)

消息 4：票据授予服务回复

也就是TGS_REP

当 KDC 收到 KRB_TGS_REQ 时，它用自己的密钥(TGS key)解密TGT，从TGT中提取到Session Key，再使用Session Key解密其他内容，解密出来的内容同TGT中的信息进行校验来评估客户端可不可信。

如果验证通过，KDC从TGT中提取用户的授权数据并创建另一个Session Key(Server Session Key)供客户端与服务一起使用。KDC使用用户的TGS里的Session Key加密这个Server Session Key(Session key(Server Session Key))。然后和用户的授权数据一起打包进Ticket中，并使用服务的密钥(Server Hash)加密Ticket(Server Hash(Ticket))。然后，KDC 在 Kerberos 票证授予服务回复 (KRB_TGS_REP) 中将这些凭据发送回客户

新的Server Session Key是客户端和服务端一起使用的

当Kerberos客户端收到回复时，它使用用户的TGS的Session Key解密Server Session Key以用于服务，并将密钥存储在其凭据缓存中。然后它提取服务的票证并将其存储在其缓存中。

AP-REQ & AP-REP

就是请求服务了

AP-REQ

会向服务器发送两条消息

1. Service Ticket：用服务器Hash加密的票据
2. 新的Authorization：里面存的是用户的数据+Timestamp，用Server Session Key加密

AP-REP

该服务接收 KRB_AP_REQ，解密Ticket，并提取用户的授权数据和Server Session Key。该服务使用Server Session Key解密用户的Authorization，然后评估其中的时间戳。如果身份验证器通过测试，则服务会在客户端的请求中查找相互身份验证标志。如果设置了该标志，则服务使用会话密钥对来自用户身份验证器的时间进行加密，并在 Kerberos 应用程序回复 (KRB_AP_REP) 中返回结果。如果未设置标志，则不需要响应。

当用户工作站上的客户端收到 KRB_AP_REP 时，它会使用与服务共享的Server Session Key解密服务的Authorization，并将服务返回的时间与客户端原始的Authorization中的时间进行比较。如果时间匹配，则客户知道该服务是真实的。