☰

为什么通过 klist 可以看到多个 Kerberos TGT？

tag-icon • tag-icon kerberos delegation
为什么通过 klist 可以看到多个 Kerberos TGT？

我刚开始尝试了解 Kerberos，并偶然发现了我的系统上的两个 TGT - 然后我发现了这篇文章生成了多个 LDAP 和 krbtgt 票证。

我研究了 Kerberos 委派，但不幸的是，出现的问题比答案还多。

  1. 为什么在请求同一领域中另一项服务“背后”的服务时，我们需要不同的 TGT？单个 TGT（始终可以转发）似乎可以很好地为不同的服务器请求多个 ST（如果客户端直接联系）。在 Web 服务器背后的 SQL-Server 等服务上使用原始 TGT 有什么缺点？
  2. 根据https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/understanding-kerberos-double-hop/ba-p/395463客户端本身从不向 DC 请求第二个 TGT 来进行委派（服务器 1 会请求）。为什么我在缓存中看到一个？
  3. 根据https://attl4s.github.io/assets/pdf/You_do_(not)_Understand_Kerberos_Delegation.pdf第 55 页，客户端在请求原始 TGT 后直接请求委托 TGT（这与 2）相矛盾）。当 web01 甚至尚未联系时，客户端如何知道当时需要委托？
C:\Windows\system32>klist

Aktuelle Anmelde-ID ist 0:0x166da1

Zwischengespeicherte Tickets: (10)

#0>     Client: xxx.xxx @ BAG.INT
        Server: krbtgt/BAG.INT @ BAG.INT
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
        Startzeit: 11/8/2023 7:31:02 (lokal)
        Endzeit:   11/8/2023 17:30:59 (lokal)
        Erneuerungszeit: 11/15/2023 7:30:59 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0x2 -> DELEGATION
        KDC aufgerufen: DC2.BAG.INT

#1>     Client: xxx.xxx@ BAG.INT
        Server: krbtgt/BAG.INT @ BAG.INT
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Startzeit: 11/8/2023 7:30:59 (lokal)
        Endzeit:   11/8/2023 17:30:59 (lokal)
        Erneuerungszeit: 11/15/2023 7:30:59 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0x1 -> PRIMARY
        KDC aufgerufen: DC2

答案1

当你在你的机器上运行 klist 命令时看到列出多个 TGT（票证授予票证）时，这意味着你已获得用于不同服务或目的的多个 Kerberos 票证。

答案2

为什么当我们请求同一领域中另一项服务“背后”的服务时需要不同的 TGT？

“委托” TGT 在一个或两个方面有所不同：

  1. 除了常见的“可转发”等标志外，它还设置了“已转发”标志。（您可以在 klist 输出中看到这一点。）

  2. 如果原始 TGT 有一个非空的“地址”列表，则需要发出新的 TGT 来更新列表。

关于第 2 点的更多信息：在过去（Kerberos IV 和早期的 Kerberos 5），Kerberos 票证曾经是 IP 限制的 - TGT 是用您的 IP 地址颁发的（以减轻可能从 /tmp/krb5cc 窃取票证的风险），因此为了使委派起作用，客户端需要获取一个新的 TGT，而该 TGT 则具有 Server1 的 IP 地址。

现在，Active Directory 从未使用过 IP 限制票证（非 AD Kerberos 也不再使用它们），因此 Windows 只需要为所有内容缓存一个“转发”TGT，但协议仍然保持不变：原始 TGT 未被委派，而是从中创建一个新的 TGT（并且“转发”标志仍像以前一样设置）。

$ kinit -a
Password for [email protected]: *****

$ klist -fan
Valid starting       Expires              Service principal
2023-11-09 11:30:30  2023-11-10 11:30:28  krbtgt/[email protected]
    Flags: FIA (Forwardable Initial pre-Authenticated)
    Addresses: 10.35.14.3, 10.147.36.8, 2001:db8::36c4:e19f:3c1:8a8

$ ssh -K exampleHost klist -fan
Valid starting       Expires              Service principal
11/09/2023 09:30:54  11/10/2023 09:30:28  krbtgt/[email protected]
    Flags: FfAT (Forwardable forwarded pre-Authenticated Transit-policy-checked)
    Addresses: 10.147.1.3

（为了演示目的，标志名称被手动添加到“Flags：”行。）

根据https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/understanding-kerberos-double-hop/ba-p/395463客户端本身从不向 DC 请求第二个 TGT 来进行委派（服务器 1 会请求）。为什么我在缓存中看到一个？

确实如此。本文省略了这部分，因为从功能上讲，除了第二个 TGT 具有“Forwarded”标志（除了“Forwardable”之外），TGT 是相同的，因此在大多数情况下，这实际上不值得讨论。

根据https://attl4s.github.io/assets/pdf/You_do_(not)_Understand_Kerberos_Delegation.pdf第 55 页，客户端在请求原始 TGT 后直接请求委托 TGT（这与 2）相矛盾）。当 web01 甚至尚未联系时，客户端如何知道当时需要委托？

web01 服务器有已联系，只是没有显示。捕获不完整；部分内容已被故意删减以用于演示目的。（请注意，SMB“协商协议版本”数据包也丢失了，即使它们是通过同一连接发送的。）

我怀疑它是使用 Wireshark 显示过滤器制作的kerberos，该过滤器仅包含 Wireshark 识别为包含 AS/TGS/AP REQ/REP 消息的数据包 - 但不包括初始未经身份验证的 GET 及其“需要 401 身份验证”响应。

但是，在不知道服务是否为 web01 的情况下获取委托 TGT 也是可行的——如前所述，委托 TGT 在任何方面都不特定于目标服务（无约束委托不会将委托票据标记为其预期接收者——唯一的区别是 IP 地址列表），这意味着 TGT 不一定需要对于 web01特别是——它可能已经被其他东西获取。因此，假设 TGT 被缓存，因为委托已经完成其他服务提前片刻，或者预先缓存“以防万一”（我不认为 Windows 会进行这样的预先缓存）。

相关内容