Kerberos原理
1. 什么是 Kerberos
kerberos 是 Active Directory 网络中域帐户的首选身份验证协议（它不能在工作组中使用），它由 kerberos SSP 实现。Kerberos 的细节在 RFC 4120 中进行了描述，在 Active Directory 中使用的扩展记录在 MS-KILE文档中。Kerberos 侧重于使用称为“票据”的令牌，它允许根据主体对用户进行身份验证。
Kerberos 也是一种基于票据的无状态认证协议。它有效分离了用户凭证与对可用资源的请求，确保密码不会在网络上传输。该协议本质上采用对称密钥认证机制，并支持可选的非对称特性（如 PKINIT）。Kerberos 密钥分发中心（KDC）负责维护用户密钥信息、票据有效期等数据，但不会记录过往交易历史。相反，Kerberos 的 TGS 依赖于有效的 TGT。其设计基于一个前提：若用户持有有效的票据授予票据（TGT），则表明其身份已通过验证。
1.1. 为什么要用Kerberos
简单高效：它使用 centralize authentication ，能避免所有服务都必须知道每个用户的凭证。这在用户经常更新的情况下（无论是由于密码更改、新用户的添加，还是用户的停用或删除）极为实用。如果所有服务都必须了解所有用户的状态，这会变得十分复杂。相反，他只需要 KDC拥有现有用户的最新列表即可。
防止中间人攻击：此协议允许用户在不发送密码的情况下向服务进行身份验证。这种方式有效防止中间人攻击
2. Kerberos 相关
2.1. 传输层：
Kerberos 使用 UDP 或 TCP 作为传输协议，以明文形式发送数据；因此，Kerberos 负责提供加密
- Kerberos 使用的端口是UDP/88和TCP/88，
- Kerberos 密钥分发中心 (KDC) 在该端口上侦听票证请求。
2.2. 代理
几个代理一起在Kerberos中提供身份验证：
- 希望访问服务的客户端或用户
- AP（Application Server）它提供用户所需的服务
- KDC （Key Distribution Center），是Kerberos的主要服务，负责发行票据，安装在DC（域控制器）上；它由颁发 TGT 的 AS（身份验证服务）支持（Key Distribution Center），是Kerberos的主要服务
在 Kerberos 环境中，当用户想要访问一项服务时，存在三个实体： user 、 service 以及认证服务器，也称为 Key Distribution Center 或 KDC。
KDC是掌握所用账号凭证的实体
3. Kerberos 认证过程中的票据
3.1. TGT（Ticket Granting Ticket）
用途：TGT 是用户在登录时首先从 Kerberos 认证服务器（KDC）获取的票据。它是用户的认证凭证，允许用户向 TGS（票据授予服务）请求服务票据（ST）。
加密方式：TGT 使用 KDC 的密钥加密，KDC（即 Kerberos 认证服务器）是受信任的，并持有加密 TGT 的密钥。
生命周期：TGT 通常有一定的有效期（例如 10 小时），在此期间，用户不需要重新输入密码即可请求服务票据。
3.2. TGS（Ticket Granting Service）
用途：TGS 是 Kerberos 的一个服务，它根据用户的 TGT 向用户提供具体的服务票据（ST）。如果用户想要访问某个特定的服务（例如文件共享、Web 服务等），他会使用 TGT 向 TGS 请求 ST。
加密方式：TGS 使用特定服务的密钥加密服务票据（ST），确保只有该服务才能解密并使用这个票据进行身份验证。
Ticket Granting Service (TGS)是密钥分发中心（KDC）的组成部分，专门负责发放服务票据。
3.3. ST（Service Ticket）：
用途：ST 是用户请求访问特定服务时，TGS 返回给用户的票据。用户通过将 ST 发送给目标服务来证明其身份，服务可以解密 ST 以验证用户的身份。
加密方式：ST 使用目标服务的密钥加密。服务可以使用自己的密钥来解密 ST 并验证用户的身份。
3.4. 票据保护
每个用户都有一个密码或者密钥，他用于充当加密/解密密钥。 KDC知道所有用户的密钥，为了保护票据，会使用如下的方式来保护票据
- KDC 发送给用户的
TGT是使用the secret key of the KDC加密的，只有 KDC 知道。因此，用户无法读取或修改关于他们自己的信息。KDC 本身会保护它。 - KDC 发送给用户的
TGS ticket是使用the service's secret key加密的。同样，由于用户不知道服务密钥，他们无法修改TGS ticket中的信息。另一方面，当他们将此TGS ticket发送给服务时，服务可以解密票据内容并读取用户信息。
4. Kerveros认证流程
4.1. 总体流程
5. 认证阶段
- KRB_AS_REQ：用于向 KDC 请求 TGT
- KRB_AS_REP：用于通过 KDC 交付 TGT
- KRB_TGS_REQ：用于使用 TGT 向 KDC 请求 TGS
- KRB_TGS_REP：用于通过 KDC 交付 TGS
- KRB_AP_REQ：用于使用 TGS 针对服务对用户进行身份验证
- KRB_AP_REP：（可选）服务用于向用户标识自己
- KRB_ERROR：用于传达错误情况的消息
此外，即使它不是 Kerberos 的一部分，而是 NRPC的一部分，AP 也可以选择使用 KERB_VERIFY_PAC_REQUEST 消息向 KDC 发送 PAC 的签名，并验证它是否正确
5.1. KRB_AS_REQ：
首先，用户会发起一个 TGT（或身份卡）请求。该请求被称为 AS-REQ 。但是，为了获取 TGT，他们必须能够证明自己的身份。这个请求是发送给 KDC（在 Active Directory 环境中，它就是域控制器）的。KDC 保存着所有用户的密钥。
为证明其身份，用户还会发送一个 authenticator。这是用户将用自己的密钥加密的当前时间戳。用户名也会以明文形式发送，以便 KDC 知道它正在与谁打交道，
然后收到请求后，KDC将会检索用户名目录关联目录中的密钥，尝试解密此验证器，如果在数据库中发现了相同的密钥则认证成功，反之则失败
这一步，称为 pre-authentication ，并非强制性的，但所有账户都必须执行 by default ，如果管理员未开启预认证，那么客户端便不再需要发送验证器。无论发生什么，KDC 都会发送 TGT。 这种情况下很容易搜到AS-REPRoasting攻击
5.2. AS-REP
当KDC 收到了客户端请求 TGT 的请求。如果 KDC 成功解密了验证器（或者关闭了pre-authentication），它会向用户发送一个名为 AS-REP 的响应
为了保护其余的交换过程，KDC 会在回复用户之前生成一个 temporary session key 。客户端将使用此密钥进行后续交换。避免使用用户密钥对所有信息进行加密。我们之前提到过，Kerberos 是一个无状态的协议，因此 KDC 不会将此会话密钥存储在任何地方
在AS-REP中包含两个元素：
- 用户的TGT：包含用户信息、并使用KDC的密钥进行加密保护，所以用户无法篡改，还包含
generated session key - 还有
session key，但这次是由用户的密钥进行保护的
所以这里的有两个版本的会话密钥， 一个是用户密钥加密，一个是KDC密钥加密的
5.3. TGS-REQ
客户端现在从服务器获得了对其 TGT 请求的响应。此响应包含由 KDC 密钥保护 TGT，以及由客户端/用户密钥保护的会话密钥。然后，它可以解密此信息以提取此临时会话密钥。
然后使用 TGS-REQ 消息向KDC请求一个服务票据 ST 或 TGS ticket：
这里需要传3个东西：
- 希望访问的服务名称（采用SPN形式）
- 之前收到的TGT，其中包含他们的信息和一个会话密码的副本
- 一个认证器，使用此会话密钥进行加密
5.4. TGS-REP
KDC收到请求后会先验证认证器是否用了正确的会话密钥进行加密，以此来判断TGS请求是否有效。
成功后，KDC会获取请求的服务，然后向用户发送一个TGS-REP的消息，这里用户与服务之间的交换会生成一个新的会话密钥（和AS过程一样）。这个会话密钥会出现在KDC发送给用户响应的两个位置：
TGS 票据保护以下内容：
- 请求服务器的SPN
- TGT中存在的用户信息的副本，服务用此来判断是否有权使用它
- 会话密码的副本
所有信息都使用用户/KDC 会话密钥进行加密。在加密响应过程中，用户信息和用户/服务会话密钥的副本也会使用服务密钥进行加密
5.5. AP-REQ
然后用户可以解密此响应以提取用户/服务会话密钥和 TGS 票据
TGS 票据受服务密钥保护。用户无法修改此 TGS 票据，因此他们无法修改其权限，就像 TGT 一样
用户将此 TGS 票据发给给服务，并且与 TGS 请求一样，会向其添加一个用用户/服务会话密码加密的身份验证器
5.6. AP-REP
服务最终会收到 TGS 票据以及一个由 KDC 生成的、使用用户/服务会话密钥加密的验证器。这个 TGS 票据受到服务密钥的保护，因此服务可以解密它。
用户/服务会话密钥的副本嵌入在 TGS 票据中，服务也可以提取它，并使用此会话密钥检查验证器的有效性。
最终，服务可以读取有关用户的信息，包括他们所属的组，并根据其访问规则，授予或拒绝他们访问服务的权限。如果认证成功，服务会通过使用提取的会话密钥加密时间戳，向客户端返回一个 AP-REP 消息。然后，客户端可以验证该消息确实来自服务，并开始发出服务请求
6. 什么是PAC
在 Windows 环境下，Kerberos 身份验证不仅仅验证用户的身份，还涉及用户的授权信息。PAC 就是存储用户权限信息的容器，它包含了用户所属的组、访问权限等数据。
6.1. PAC 结构
PAC 作为 Kerberos 服务票据（TGS）的一部分，由 KDC（Key Distribution Center） 生成并附加到服务票据（ST）中。PAC 主要包括以下内容
- 用户的组成员信息（Group Membership）
- 用户的权限信息（User Permissions）
- 用户的 SID（Security Identifier）
- 用户账户的其它信息
6.2. PAC 的生成与传递
- 当用户首次请求访问服务时，Kerberos 认证服务器会为用户生成一个 TGT，并在后续的请求中附加 PAC
- 用户在凭借有效的 TGT 请求 TGS 时，TGS 会将 PAC 附加到 ST（服务票据）中返回给用户。
- 用户凭借 ST 向目标服务发起请求时，目标服务会从 ST 中提取 PAC，并解析其中的权限信息，来验证用户是否具备访问目标资源的权限。
6.3. PAC 的安全性
- 签名：PAC 被 KDC 用其密钥进行签名，以确保其未被篡改。目标服务使用 KDC 公钥进行验证，确保 PAC 中的内容是可信的。
- 完整性：为了防止 PAC 在传输过程中被篡改，通常会使用加密保护 PAC 的完整性
几个用于验证 PAC 和票证数据完整性的签名
服务器签名：使用用于加密票证的相同密钥创建的 PAC 内容签名
KDC 签名：使用 KDC 密钥创建的服务器签名的签名，可用于检查 PAC 是否由 KDC 创建并防止票据击
票据签名：使用 KDC 密钥创建的票据内容的签名，最近引入了此签名以防止青铜位攻击（CVE-2020-17049）