在 Windows 中的身份认证方式有很多，也在不断的升级，但是在域中，依旧使用的是 Kerberos 认证。
Kerberos 是一种网络认证协议，它的实现 不依赖 于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据，也就是说它的认证完全是从一个 不安全 的网络环境出发进行认证的，它是拥有第三方信托机构的，与上一篇主机间的交互是不同的。
Kerberos 这个名字来源于希腊神话，是冥界守护神兽的名字
其实看到这张图后，也就能明白 Kerberos 认证的是由三方来完成的，他们分别是client、server、KDC(Key Distribution Center)。
其中 KDC 是由两种服务所构成的，AS(Authentication Service)和TGS(Ticket Granting Service)
AS 是用来为 client 生成 TGT 的，TGS 是用来为 client 生成某个服务的 Ticket 的，TGT(Ticket Granting Ticket)是用来获取 Ticket 的临时凭证，Ticket 是用来访问某种服务所必须使用的票据
只有 用户 TGT 才能获取 Ticket，才能去访问 server 上的服务。
而在 Windows 当中，域控 DC(Domain Controller)充当了 KDC 的角色，还有一点需要注意的是，它有一个类似于本地 SAM 一样的数据库 AD(Account Database)，里面存储着所有 client 的名单，只有存在于 client 中的用户才能申请到 TGT。
从物理层面看，AD 与 KDC 均为域控制器 DC(Domain Controller)。
域认证的大致流程是这样的：
** client 先向 DC 请求，要求获取访问 server 的权限，当 DC 接收到请求之后，先由 AS 向 AD 发起请求，查看此 client 是否在白名单中，成功后，则由 AS 将 TGT 返回给 client。
** 然后 client 带着 TGT 继续向 DC 发起请求，要求获取访问 server 的权限，当 DC 接收到请求后，TGS 会通过 TGT 判断此 client 是否有获取 server 服务的权限，成功后，则将 Ticket 返回给 client。
** 然后 client 凭借 Ticket 去访问所请求的 server，这个 Ticket 只对该 server 有效，如果要访问其他 server，需要重新申请。
结合下面的图片，分析大致流程效果更佳，文章最后有用通俗的语言解释过程的。
接下来我们走一遍完整的数据请求流程
先说一下这次实验中所使用的机器
DC 192.168.5.130
Client 192.168.5.238
计算机名：SECQUAN_WIN7-PC
域用户：win7
Server 192.168.5.239
计算机名：SECQUAN_WIN7
域用户：win71以下的讲解中的 Kerberos 数据包是通过网络共享服务来抓取的
首先，我们来看第一步的流程
Client 发送自己的身份信息给 KDC，KDC 验证成功后，会在本地生成一个 随机 字符串 session key，然后返回给 client 两个信息。
** 一个是由 client 提供的用户名所对应的 NTLM hash 对 session key 进行加密后得到的，那么为什么 KDC 可以用 client 用户的 NTLM hash 来进行加密呢，在 AD 中储存了所有域用户的账号密码等信息，当 client 发送过身份信息之后，AS 会先向 AD 请求，询问是否有此用户，如果有的话，就会取出它的 NTLM hash，然后对所生成的 session key 进行加密然后作为返回数据包中的一个内容。
** 另一个就是 KDC 中的一个特定用户的 NTLM hash 对 session key 和 client 所发送的用户信息进行加密后得到的，其中这个特定用户就是 krbtgt（krbtgt 是在创建域控的时候自动生成的，并且由系统给他随机分配一个密码）；这个加密数据的内容其实就是后面请求中所使用的 TGT。
- 这两个中间所用到的 session key 是相同的。
接下来再详细理一遍每一个请求所传输的具体内容
先看一下 client 发送身份信息的时候，都传输了哪些内容
他发送一个 KRB_AS_REQ 的一个请求，包含了 被 client 加密 的 timestamp，还有自己的名字等信息，还有请求域时候的服务器信息
我们来看一下他中间所有的数据包
当 KDC 验证成功后，给 client 返回一个 KRB_AS_REP 的请求，它所包含的详细内容是这样的
再从数据包中对应一下
到这里为止，Kerberos 请求的第一步过程就结束了，此时 已经获取到了所需要的 TGT，接下来就是通过 TGT 来请求 ticket。
** 这里还有一点需要注意的是，返回的两个内容，第一个 client hash，client 可以通过自己的 NTLM hash 解密，得到其中的 session key，但是 client 是没有 KDC 的 hash，也就是 client 不知道 krbtgt 用户的密码，是无法得到 TGT 中的具体内容的，我们可以使用前面得到的 session key 继续和 TGS 进行通信。
接下来我们来看一下第二步的协议流程
首先他会传输之前所获得到的 TGT，然后还有前面通过自己的 NTLM hash 解密出来的 session key，来加密 client 的信息和 timestamp，还有 client 和 server 的信息，client 将这三块信息一同发送给 TGS。
等到 TGS 接收到前面所传输的信息后，因为 TGS 本身也属于 KDC 的一部分，它是拥有 krbtgt 用户的 NTLM hash 的，可以对所传输的 TGT 进行解密，为什么要先解密 TGT 呢，因为 TGS 本身是没有 session key 的，不能对 client 中所加密的其他信息进行一个认证，而TGT 中是存在 session key 的，TGS 通过解密 TGT 便可以获得传输中的 session key，最后便通过 session key 来解密 client 所加密的内容，从中获取到时间戳 timestamp，如果时间戳跟当前时间相差太久的话，认证就需要重新再来，重复第一步中的操作，重新去请求 TGT（ 因为 Kerberos 在设计的时候，就假设是处于一个不安全的环境中的，是假设它中间存在中间人攻击的，所以依靠时间戳来限制）。
从中还能获取到 client 的信息，TGS 还会将这个 client 的信息与 TGT 中的 client 信息进行比较，如果两个相等的话，还会继续判断此 client 有没有权限访问 server，如果都没有问题的话，就认证成功，返回 ticket 给 client。
在这次传输的时候，里面是包含有两个信息的
- 首先它会在本地
再生成一个随机字符 server session key，使用之前的 session key 将新生成的 server session key 加密得到第一个字符串，这里的 server session key 主要用于后面在 client 与 server 的认证过程中的。 - 第二个内容就是 ticket 了，KDC 先会通过前面所得到的 server 的信息，在 AD 中找到所对应的 NTLM hash，然后通过这个 NTLM hash 去加密 ticket，最后一并返回到 client。
在给到 client 以后，client 拥有 session key 的，所以可以解密得到 server session key，但是服务端没有 server hash，所以是无法解密得到 ticket 的。
Ticket 中所包含的内容主要有以下几个
我们再在数据包中看一下所有的流程
先有 client 发起 krb-tgs-req 的一个请求
当 TGS 处理完以后，回复了 krb-tgs-rep 数据包
到这里为止，与 KDC 的通信就结束了，接下来是拿着 ticket 与 server 进行通信
Client 向 server 发送一个 krb-ap-req 请求，其中第一块就是 ticket，因为 client 是不能对其进行解密的。然后第二个内容就是解密出来的 server session key，通过解密出来的 server session key 加密 client 信息和时间戳，最后一并发送到 server。
Server 在收到数据包之后，使用 自己的 hash将 ticket 解密，从中获得 server session key，然后将 krb-ap-req 中的 client 信息和时间戳解密出来，然后与 ticket 中的 client 信息进行比对，将这里的时间戳与 ticket 中的 end time 进行比较，如果超过了这个时间，就代表 ticket 已经失效了，需要重新进行认证。
其实在整个 Kerberos 认证流程中，TGT 和 ticket 的结构都是一样的，唯一不同的就是 TGT 中是 session key，ticket 中是 server session key，session key 是由 AS 给 client 的，server session key 是由 TGS 给 client 的。
以下是两个交互的数据包
其实整个 Kerberos 认证的流程就是不断交换密钥，使用对称加密算法，解密验证身份和时间戳，最后达到认证的效果。
最后使用比较通俗的话来给大家解释一下
比如你要去坐飞机，首先你去购买机票，对方（AS）肯定会先验证你的身份（client info），验证通过后，把机票（TGT）给你，然后在登机的时候，检票人员（TGS）会验证你的机票（TGT），然后告诉你飞机位置（ticket），之后你就可以带着 ticket 去相应的位置了。
文章首发公众号：无心的梦呓(wuxinmengyi)
这是一个记录红队学习、信安笔记，个人成长的公众号
扫码关注即可