Kerberos认证学习

2022-03-18 23:52:05 3 10020
简介
Kerberos协议是一种基于第三方可信主机的计算机网络协议，它允许两个实体之间在非安全网络环境（可能被窃听、被重放攻击）下以一种安全的方式证明自己的身份。
简单说，就是A和B之间有一个秘密，A需要向B证明自己是A。名词解释

Principal
一个用户会以一个独一无二的身份来被 KDC 认证，该身份被称为 Principal。
一个 Principal 由三个部分组成：primary, instance 以及 realm，
其组成形式为primary/instance@realm。

  • primary 可以是 OS 中的 username，也可以是 service name；
  • instance 用于区分属于同一个 user 或者 service 的多个 principals，该项为 optional；
  • realm 类似于 DNS 中的 domain，定义了一组 principals

kerberos几个重要组件
  • KDC（Key Distribution Center）密钥分发中心，里面包含两个服务：AS和TGS
    • AS（Authentication Server）身份认证服务器
    • TGS（Ticket Granting Server）票据授权服务器


  • Client：需要使用kerbores服务的客户端
  • Service：提供具体服务的服务端


kerberos中几个重要概念
  • Client master key: KDC中存储的Client的密钥
  • Server master key: KDC中存储的Server的密钥
  • Sclient-Server：Client与Server之间的会话密钥
  • Client Info：记录了Client本身的Ip等基本信息


其他名词解释

  • SS（Service Server） 特定服务提供端
  • TGT（Ticket Granting Ticket）由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时  
  • ST(Service Ticket) 由票据授权服务器提供的票据，用于特定服务
  • DC是Domain Controller的缩写,即域控制器;DC中有一个特殊用户叫做:krbtgt,它是一个无法登录的账户,是在创建域时系统自动创建的,在整个kerberos认证中会多次用到它的Hash值去做验证。
  • AD(Account Database)，它作为账户管理数据库，它存储了域中所有用户的密码Hash和白名单。只有账户密码都在白名单中的Client才能申请到TGT。


认证流程图示





Kerberos粗略的验证流程：

举个简单的栗子：如果把 Kerberos 中的票据一类比作一张门禁卡,那么 Client 端就是住客,Server 端就是房间,而 KDC 就是小区的门禁。住客想要进入小区,就需要手里的门禁卡与门禁想对应,只有通过门禁的检验,才能打开门禁进入小区。

需要注意的是,小区门禁卡只有一张,而Kerberos认证则需要两张票。






1.因为client要访问server(例如：server是打印服务器)然后要先取得身份凭证才能访问，因此要发送一个认证请求到AS获取认证凭证，然后client 发送一个认证请求里面包含了一些身份信息，例如：我是谁( client_principal(客户端的唯一名字)和 我要访问谁 (server_principal(服务器的唯一名字))给AS(身份认证服务器)等一些东西)


2.AS(身份认证服务器)接受到 Client发送过来的认证请求后会给 Client 返回一个包，这个包里面存有两条票据

(Tc,s和Ts,c)因为要对Client和Server的认证，所以AS上面是存有 Client 和 Server 的密码；

    • Tc,s={Kc,s;Server_principal,···} Kc   //这是给客户端的票据； Tc,s：表示AS给客户端c的票据，该票据包含有用于和服务器s通信认证的相关信息；{Kc,s;Server_principal,···}Kc：表示票据的内容，{} 里面的为具体内容。Kc为客户端的密码，表示该票据又客户端密码加密。其它类似
    • Ts,c = {Kc,s;client_principal,···}Ks   //这是给服务器的票据，同客户端的差不多，但是这条票据是使用服务端密码来加密的




3.Client收到AS服务器发送过来的两条票据之后(Tc 和 Ts)，因为有一条票据是使用的Client密码所加密的，所以客户端会用自己的密码用自己密码加密的票据(Tc)，然后票据里面有一段Server Key 这是用来生成 认证因素的 一段东西，客户端会利用它加密生成一段 认证因素(Authenticato[认证因素]：time_stamp=生成票据的实践戳，Server Key，c_checksum=随机数 )然后连同 另一条票据(Ts：Ts是用server的密码所加密的所以client是无法解开的) 发送给Server(Client会将Server的票据会原封不动的传给Server)


4.Server接收到Client发送过来的两个东西(认证因素和票据)之后，Server会使用自己的密码解开票据(因为客户端发过来这段票据是使用的Server密码加密的)，然取出票据里面的 Server Key 对发过来的认证因素进行解密，解开认证因素之后它会检查里面的内容，例如:(检查时间：Server会使用当前时间戳与认证因素的时间戳进行比较，如果没超过5分钟的话，那Server端就会认为这个认证是有效的)，(检查随机数)等一系列东西；当Server检查核对完之后都没问题那么Server就会返回一个认证(时间戳)给Client


缺陷：每次Client要访问提供服务的Server时就要去访问一次AS做一次认证，如果说在某一次中Client并没有访问到AS则没办法去访问Server，这相对来说就会显得比较麻烦


Kerberos 详解认证流程：当 Client 想要访问 Server 上的某个服务时,需要先向 AS 证明自己的身份,验证通过后AS会发放的一个TGT,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST(服务票据：可复用，有了ST就不用每次访问Server的时候都要去向AS申请认证了),最后Client向Server 发起认证请求,这个过程分为三块：
  • Client 与 AS(身份认证服务器) 的交互
  • Client 与 TGS(票据授权服务器) 的交互
  • Client 与 Server 的交互




PS：可以看到下图中的 AS 和 TGS 是圈在一块的，因为这两个服务同属一台服务器(域控服务器)





1.Client 向 AS发送认证请求，请求里带有 客户端唯一名称和 票据服务唯一名称 等一系列东西
2.AS 返回 给Client 两条票据，一条是使用Client密码加密的，另一条使用 TGS密码加密
3.Client 用自己密码解开票据之后拿着里面的 Server Key 生成一段认证因素，然后将生成的认证因素连同另一条票据发送给TGS，不同于 简略步骤的是这次发送增加了 Server_principal(服务端唯一名称)
4.TGS收到Client发送过来的认证因素和票据之后同样会对它们进行检验，当检验通过之后会返回两条票据给Client ，但是这两条票据里面的Session Key 并不是之前 AS 生成的那段，而是 TGS 生成的
5.Client收到TGS发过来的两条票据之后同之前一样还是会解开自己密码加密的那条票据然后生成一段认证因素，接着将 认证因素和另一条票据发送给Server
6.Server接收 Client 发送过来的认证因素和票据之后就解开票据使用里面的Session Key 解开认证因素，然后检验认证因素里面的内容，通过之后就发送一段时间戳给Client 告知它认证通过你可以访问我了
7.之后如果Client再访问Server的话就使用 TGS 生成的那条TGT(黄金票据)直接访问Server就可以了，不用再重新认证了


Kerberos 完整认证流程



1.Client 向 KDC的 AS 发送一个As-req的认证请求，请求中包含了：
    • Client的用户名
    • Client的主机名
    • Client的加密类型


1.1、KDC(As)接收到Client请求后会通过AD(活动目录)去查询Client密码的Hash值，然后拿着这个Hash值去解开Client发送过来的请求，如果能够使用Client Hash解开这个请求那就说明这个密码是正确的，认证通过；在这一步的时候 As 已经会校验时间戳了，它在这里校验时间戳主要是为了防止重放攻击


2.AS认证通过之后会返回一个 TGT(票据) 给Client ，其中TGT包含了(经过KDC中的krbtgt的密码HASH加密的 Login Session Key(登录会话密钥) 和 TimeStamp(时间戳)、TGS会话密钥、用户信息、TGT到期时间)


3.Client 拿到TGT后会先使用自己的密码解开第一条票据获取 Login Session Key 然后生成认证因素，接下来就是将 认证因素和 TGT(这条TGT是使用 TGS 密码来加密的Client无法解开)发送给 TGS，这个请求中除了认证因素和TGT还包含了Client Info 、TGT的认购凭证、TGT的认证回购、Server的名称和其它一些信息


4.TGS接收到请求之后会检查自身是否存在Client要访问的Server，如果存在那么就会用krbtgt的hash来解密TGT 来获取 Login Session Key ，再通过 Login Session Key 来解密认证因素，如果解密成功那说明Client的身份没有问题，之后还会核验 时间戳、TGT的原始地址；验证都通过的话会发给Client两项东西：
  • 一个用 Login Session Key 加密后的 Server Ssession Key会话密钥(包含了服务身份信息等)用于Server和Client 之间的通信安全
  • 还会为Client 生成 一条 ST服务票据




5.Client接收到TGS的返回之后使用缓存的Login Session Key 将TGT解密获得里面的 Server Session Key ，然后将 Server Session Key 和 ST 缓存在Client的内存中


6.第六步和第七步是Server端拿到这些认证因素核查没问题之后还会再跟DC验证一遍 Client是否在DC的活动目录中、主机名是否正确，如果都正确的话DC会返回一个信息给 Server 告诉它验证成功





PS：第一次发文有什么地方不好的请师傅们多指点一下，如果文章太水的话师傅们也轻点喷


TCV:1





类别 渗透测试

关于作者

badking2篇文章27篇回复

badking
3

评论3次

要评论？请先  登录  或  注册