Kerberos 认证
这是一个老生常谈的话题，我们总能在各种各样的平台上看见关于Kerberos认证流程的解析。因此这里就不再对这个概念进行过度深入的解读，在本篇文章中我将只列出关键的认证步骤，帮助理解之后的概念。
Kerberos认证流程可以简化为以下几个关键步骤：
1. 客户端请求TGT（Ticket Granting Ticket）
- 步骤：客户端向Kerberos认证服务器（AS）发送请求，包含用户身份信息
- 目的：获取TGT，用于后续请求服务票据
2. 获取TGT和Session Key
- 步骤：AS将加密的TGT和会话密钥（Session Key）返回给客户端
- 目的：客户端获得TGT和会话密钥，用于与TGS通信
3. 客户端请求服务票据（Service Ticket）
- 步骤：客户端向TGS发送请求，包含TGT和要访问的服务信息
- 目的：获取访问特定服务的票据
4. 获取服务票据
- 步骤：TGS将加密的服务票据和新的会话密钥返回给客户端
- 目的：客户端获得服务票据和会话密钥，用于与目标服务通信
5. 客户端访问目标服务
- 步骤：客户端将之前从TGS获取的服务票据发送给目标服务
- 目的：向目标服务证明自己的身份和权限
6. 目标服务验证票据
- 步骤：目标服务验证票据的有效性
- 目的：确认客户端有权访问服务，并建立安全通信
如上步骤可以用一张图简单直观的表示：
Kerberos Rely
Kerberos Relay（Kerberos中继）的概念并不复杂。其核心思路是将客户端向某个服务发起的 AP_REQ 消息转发到另一个服务上。
这种攻击方式有一个至关重要的前提条件：目标服务以及客户端不能启用强制加密或签名机制，比如 LDAPS or LDAP Signing。
原因在于我们无法获取执行这些操作所需的会话密钥。这一点与 NTLM 中继非常相似，因为在 NTLM 中继中，攻击者同样无法直接处理加密或签名的数据。
还有一个需要注意的点：AP_REQ 消息不能中继到在与客户端最初请求的身份不同的身份下运行的不同服务。因此，为了使攻击成功，我们需要强制客户端为目标服务生成一个 AP_REQ 并将其发送给我们。
“ Kerberos 中继曾经被认为是不可能的，但后来多位研究人员证明了事实并非如此。”