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
会回复两个消息
Windows内网协议学习Kerberos篇

  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
Windows内网协议学习Kerberos篇
可以从图中看出 发送过去的也有两部分

  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是客户端和服务端一起使用的

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

AP-REQ & AP-REP

就是请求服务了

AP-REQ

会向服务器发送两条消息
Windows内网协议学习Kerberos篇

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

AP-REP

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

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

Windows内网协议学习Kerberos篇

上一篇:color xml arm相关


下一篇:PHP快递查询接口api和快递单号智能判断PHP代码-快递100