Kerberos协议流程

  • User 用户
  • KDC 域控制器，秘钥颁发中心
  • AP 应用服务器

image-20211225145652404

流程1

User向KDC请求访问某个应用，使用自己密码的hash去加密当前时间戳+用户名+SPN（服务主体名称）+随机数 发送给KDC。

image-20211225145747585

流程2

KDC收到消息后，先抽取username信息。因为KDC有所有人的用户信息，可以查询当前用户是否在数据库中。如果存在，会解密当前的数据包，并解出当前的时间戳。颁发一个TGT票据返回给当前用户。

TGT票据是使用KDC自己的密码hash去对右边的数据包进行加密。这个数据包只能是KDC去进行解密，别人无法解密。

（

  • Username 是KDC的用户名

  • Session key是User和KDC之间定义好的session key。就是左边那块User hash加密之后的内容

  • TGT expiration time 是定义票据过期时间

  • PAC是特权用户信息（是包含User的详情。固定的 User SID 和 Groups ID，还有其他一些时间等信息）是使用KDChash去加密的

）

User hash 左边部分是可以让User自己去解密的。使用的秘钥是用户自己密码的hash

  • User nonce 用户随机值。对应👆🏻的随机数

image-20211225150133550

流程3

当User解密出Session key之后。将Session key 作为加密秘钥加密（User用户名+时间戳） + 原封不到的TGT数据包 + SPN（想要访问的应用信息）+ 用户随机数 发送给KDC

image-20211225152757659

流程4

当KDC收到用户信息，用自己的krbtgt hash解密出TGT，再使用之前规划好的Session key解析出用户信息+时间戳。

确认用户身份，同时在服务器中找SPN所对应的服务。如果找到，并且用户信息对应没问题，KDC会将找到的SPN服务器信息加密成一个数据包

  • TGS expiration time 票据过期时间

  • PAC User的特权信息

  • Service session Key 不是之前的KDC和User协定的key了。是KDC和AP的Session key

  • Service owner hash 服务hash。User无法解密

    同时会使用解密出来的Session key 去加密左边信息

image-20211225153411856

流程5

User解出Session key加密的数据包后使用解密出的Service session key 去加密自己的用户名+时间戳

并将TGS原封不动发给AP

image-20211225155140954

流程6

AP自己拥有Service owner hash 解密TGS。可以解出PAC信息。获取User信息，过期时间，判断用户访问服务是否合法。

AP 正常情况不会和KDC发送信息去进行验证4个字段

PAC 不会通过AP发送给KDC（KDC的工作量会很大）

KDC 与AP 连接 ，KDC会发给AP一个token，包含KDC的签名信息

Kerberos协议中只负责认证，不负责鉴权。

posted @ 2022-01-06 09:29  how=time  阅读(225)  评论(0)  编辑  收藏  举报