认证流程
| 角色 | 功能 |
|---|---|
| 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
该消息包括：
检索用户密钥
当 KDC 收到来自用户工作站上 Kerberos 客户端的请求时，KDC 会在其数据库中搜索该用户，提取帐户记录，并从记录中的字段中获取用户密钥
验证用户身份
KDC 解密预认证数据并评估其中的时间戳。如果时间戳通过测试，则 KDC 可以确信预认证数据是用用户密钥加密的，从而验证用户是真实的。
消息 2：身份验证服务回复(Authentication Service Reply)
也就是AS_REP
会回复两个消息
- Client NTLM Hash(Session Key)，用户与TGS一起使用的TGS会话密钥，使用用户的NTLM Hash进行加密；用于后续和TGS服务进行通信
- 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
可以从图中看出 发送过去的也有两部分
- TGT: 用户的TGT
- 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
会向服务器发送两条消息
- Service Ticket：用服务器Hash加密的票据
- 新的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中的时间进行比较。如果时间匹配，则客户知道该服务是真实的。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
