推荐视频：Youtube

TryHackMe | Cyber Security Training

介绍

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为 客户机 / 服务器 应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一 种可信任的第三方认证服务，是通过传统的密码技术(如:共享密钥)执行认证服务的

参与角色

1. 客户端
2. 服务端
3. KDC （Key Distribution Center）= DC
   1. 作用： 管理票据、认证票据、分发票据
   2. 组成：
      1. Authentication Service (身份验证服务器): 为客户端生成 TGT 的服务
      2. Ticket Granting Service (票证授予服务器): 为客户端生成某个服务的票证
4. 基础概念：
   1. 票据： 是网络对象互相访问的凭证
   2. TGT （Ticket Granting Ticket） ： 入场券，通过TGT 来获取凭据，是一种临时凭证的存在
5. Account Database : 存储所有的客户端的白名单，只有存在于白名单的客户端才能申请到 TGT

域认证

1. 粗略流程

1. 用户将他们的用户名和使用从他们的密码派生的密钥加密的时间戳发送到密钥分发中心 (KDC)，该服务通常安装在负责在网络上创建 Kerberos 票证的域控制器上。
   KDC 将创建并发回票证授予票证 ( TGT )，这将允许用户请求额外的票证以访问特定服务。需要一张票才能获得更多的票可能听起来有点奇怪，但它允许用户在每次想要连接到服务时无需传递其凭据即可请求服务票。与TGT一起，一个会话密钥被提供给用户，他们将需要它来生成以下请求。
   请注意，TGT是使用krbtgt帐户的密码哈希加密的，因此用户无法访问其内容。必须知道加密的TGT包括会话密钥的副本作为其内容的一部分，并且 KDC 无需存储会话密钥，因为它可以在需要时通过解密 TGT 来恢复副本。
   
2. 当用户想要连接到网络上的服务（如共享、网站或数据库）时，他们将使用他们的TGT向 KDC 请求票证授予服务 (TGS) 。TGS 是只允许连接到为其创建的特定服务的票证。要请求 TGS，用户将发送他们的用户名和使用会话密钥加密的时间戳，以及TGT和服务主体名称 (SPN)，后者指示我们打算访问的服务和服务器名称。
   因此，KDC 将向我们发送一个 TGS 以及一个Service Session Key，我们需要用它来验证我们想要访问的服务。TGS 使用从服务所有者哈希派生的密钥进行加密 。服务所有者是运行服务的用户或机器帐户。TGS 在其加密内容上包含服务会话密钥的副本，以便服务所有者可以通过解密 TGS 来访问它。
   
3. 然后可以将 TGS 发送到所需的服务以进行身份验证并建立连接。该服务将使用其配置的帐户密码哈希来解密 TGS 并验证服务会话密钥。
   

2. 详细流程

1. Client & AS

1. Client 向 AS 发出请求
   1. User Name/ID
   2. Service Name/ID
   3. IP address
   4. 当前时间戳
2. KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性
   1. 不存在用户名，认证失败，服务结束
   2. 存在用户名，AS 认证中心认为用户存在，便返回响应给客户端
      1. 第一部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和TGS间通信的 TGS_Session_key(CT_SK)、客户端即将访问的TGS的 Name 、TGT的有效时间、一个当前时间戳 。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。
      2. 第二部分内容称为TGT，他叫做票据授予票据，客户端需要使用TGT去KDC中的TGS（票据授予中心）获取访问网络服务所需的 Ticket（服务授予票据），TGT中包含的内容有User Name/ID、TGS Name/ID、IP、当前时间戳、TGT 的有效时间、一把用于客户端和TGS间进行通信的 TGS_Session_key(CT_SK)。整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况

2. Client & TGS

客户端收到来最 AS 的响应后，客户端使用自己的密钥来对第一部分内容解密。解密后根据响应中的时间戳与自己请求时的时间之间差值比较如果大于五分钟认为该 AS 是伪造的，认证失败。如果时间戳合理，客户端便准备向 TGS 发起请求，这次请求的目的是为： **获取能够访问目标网络服务的服务授予票据Ticket**

1. Client ：
   1. Client 使用 TGS_Session_key(CT_SK) 将自己的客户端消息加密，发送给客户端，加密的内容： User Name/ID、Timestamp
   2. 服务主体名称 (SPN) : 指示我们要访问的服务和服务器名称
   3. 将第一次通信中收到的 TGT 原封不动的发送
2. TGS：
   1. TGS 首先根据客户端传输的 Server 服务查看当前 Kerberos 系统是否存在被用户访问的该服务，如果不存在认证失败
   2. TGS 使用自己的密钥对 TGT 中内容进行解密，根据解密消息判断：
      1. 时间戳： 根据时间戳判断此次消息是否可靠有效
   3. 使用 TGT 中解密出来的 TGS_session_Key 对客户端发送的加密内容进行解密，取出的用户信息与 TGT 中用户信息进行比对，如果全部相同则认为客户端身份正确
   4. TGS 将当前用户信息存储的 TGS Cash 中
   5. 此时 TGS 将返回响应给客户端：
      1. 第一部分 : 使用 TGS Serssion Key 加密的内容，其中包括 Service Name/ID、时间戳、ST 有效时间。
      2. 第二部分: 用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket), 其中包括 User Name/ID、Service name/ID、时间戳、IP 地址、ST 有效时间、用于客户端和服务端之间通信的 CS_SK（Session Key）

3. 第三次通信

客户端收到来自 TGS 的消息后，使用缓存的 Service_Session_key 对收到的第一部分内容解密，检查时间戳

1. 客户端：
   1. 使用解密的内容中的 Service_Session_key 加密信息，信息包括： User Name/ID 、时间戳
   2. 将收到的 Servre Ticket 原封不动的发送给 Service
2. 服务端：
   1. 时间自己的密钥解密 Servre Ticket ，核对时间戳后将消息中的 Service_Session_key 取出，并解密客户端发送的消息，获取经过 TGS 认证后的客户端消息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端
   2. 将客户信息保存在 Service Cash 中
   3. 返回一段使用 Service_Session_key 加密的响应给客户端，客户端收到请求后，使用缓存在本地的 Service_Session_key 解密确认服务daunt的身份
3. 客户端收到响应后：
   1. 将 Servre Ticket 保存到 User Cash 中

扩展

TGT 内容

Kerberos 流量分析

kerberos.zip

Kerberos 是 Microsoft Windows 域的默认身份验证服务。它负责验证不可信网络上两台或多台计算机之间的服务请求。最终目的是安全地证明身份