我是否正确？这就是我的问题的原因？

是的，特别是对于没有 Kerberos 主体的服务器（SSH 目标）。

不过，这不仅仅是一个数据库条目 – 重要的是“域加入”在服务器和 KDC (/etc/krb5.keytab) 之间设置了一个共享密钥，该密钥与服务器的主机主体相关联。如果没有它，Kerberos 就无法运行，因为它是服务验证票证真实性的唯一方法。

为了进行票证转发，需要将一个或两个主机添加到域中，以便能够生成主机票证

这不是“一个或两个”的问题；有三个不同的程序可以生成 TGS-REQ，每个程序只需要一个特定的主体：

• 在您首次本地登录系统（即通过 PAM 基于密码登录）时，Windows 或 pam_krb5 会为其本地系统的主机主体发出 TGS-REQ，作为“KDC 欺骗”缓解措施的一部分，即确保 PAM 不会被诱骗接受假密码。（如果您在未加入的系统上设置了 pam_krb5，则它很容易受到 KDC 欺骗。）

  请注意，这实际上不是 TGT 获取的一部分，因此 – 您可以完美地获取票证并使用 Kerberos，而无需本地主机拥有自己的主体（尽管最好使用kinit而不是 PAM 集成）。

• 在对远程服务（例如 SSH）进行身份验证时，客户端会为服务器系统的主机主体（或其他服务主体）发出 TGS-REQ 。例如，如果您运行ssh mailsrv它将为host/mailsrv服务发出 TGS-REQ。

  请注意，这并不称为“票证转发”——该术语具体指不受约束的委派（将票证与其会话密钥一起转发），而身份验证仅以与 TLS 服务器呈现其证书相同的方式呈现票证，即从不发送私钥。

• 身份验证后，如果客户端和服务器都启用了该选项，Kerberos 可以将您的整个 TGT 复制到服务器进行“第二跳”身份验证。这就是 Unix Kerberos 所称的“票证转发”（与 SSH 代理转发相比），在 Active Directory 中也称为“无约束委派”。由于历史原因，转发不会直接复制您的 TGT，而是发出 TGS-REQ 以krbtgt获取重复的 TGT。

简而言之，如果您有一个 TGT 并且正在寻找对其他系统的简单 Kerberos 身份验证，那么它就是必须加入 Kerberos 领域的服务器- 客户端的主体永远不会发挥作用，所以不能描述为“一个或两个”。

但是，您通过 SSH 连接到的服务器必须加入 Kerberos 领域 – 这是一个硬性要求，因为它是 Kerberos 作为协议的基本基础：它依赖于服务和 KDC 拥有共享加密密钥（密钥表或机器帐户密码），服务将使用该密钥来验证收到的票证。

（服务器不一定需要“完整”的 AD 加入配置，包括 PAM、Samba、Winbindd 和所有内容；但它需要在 AD 中有一个计算机帐户。）

如果不允许您为 Linux 系统创建计算机帐户，则您无法设置 Kerberos SSO 来通过 SSH 进入这些帐户。

（尽管：您可能能够通过在 AD 中创建用户帐户并host/...为其分配 SPN，然后生成密钥表来执行此操作。它的工作原理与计算机帐户相同。）

如果我设置自己的本地 KDC/AD/IDM 会怎么样？有没有办法将其指向主 AD？

可以设置自己的 KDC，但这会与您不拥有两组凭据的目标相矛盾，因为新的 KDC 将拥有一组单独的帐户。您不能拥有“代理”KDC。

虽然从技术上来说，可以让两个 Kerberos 领域相互信任（例如，领域 A 中的用户可以获取领域 A 和 B 中的服务票证，而无需来自领域 B 的单独凭据），但这需要比加入各个机器更多的权限 – 它需要 AD 范围的“领域信任”。

（可能是 AD 管理员接受从 AD 到您的领域创建仅出站信任，因为它实际上没有任何安全风险 – 它只允许 AD 用户访问您领域的服务器，而不是相反 – 但是如果他们拒绝将非 Windows 主机加入 Ad 这样的基本操作，很可能他们甚至不愿意触及信任部分。）

因此，如果没有权限，您只能设置手动密码重新同步系统，其中某人可以使用其 AD 详细信息登录，系统会自动向他们颁发 Linux Kerberos 帐户。（我实际上已经看到多所大学记录了这种设置，例如，当他们为 CS 部门设置历史性的 MIT Kerberos 领域时，为其他所有人设置了一个全新的 Windows AD 领域。）

可以同时拥有多个 TGT，因此您可以为 Linux 机器运行自己的 KDC，同时仍获取 AD 机器的 AD 票证，但这有时会有点麻烦。我在工作笔记本电脑上执行此操作，使用完全独立的 TGT，这些 TGT 来自我自己的 Kerberos 领域和工作 AD 领域。

最后，最简单的方法可能是使用 SSH 公钥身份验证（或者甚至基于 SSH 主机的身份验证，其中您的主机组隐式信任彼此以进行 SSH 登录）。

对于用户身份验证，我设置了 kerberos 和 pam 以指向 AD 服务器。将用户添加到系统后，我可以使用我的 AD 用户名和密码登录。登录后，我有一张票

请记住，如果系统没有主机密钥表而只执行 AS-REQ，那么就容易受到 KDC 欺骗 – 如果攻击者首先控制了网络，那么他们可以将所有 Kerberos 流量重定向到他们自己的 KDC，并让它以“成功”的 AS-REP 和“krbtgt”来回答攻击者想要的任何用户名和密码。

标准缓解措施是让客户端系统立即使用收到的 TGT 来向自身请求服务票证，以便它可以根据之前建立的自己的密钥（即在域加入期间 – Windows 上的机器帐户密码或 Linux 上的密钥表）验证该票证，并且只有合法的 KDC 才知道。

（您提到的帖子说：“S1 尝试使用从您的密码生成的密钥解密 TGT。如果解密成功，则密码被视为正确。”这是易受攻击的部分，而这正是 S1 会为其自己的“主机/S1”主体额外执行 TGS-REQ 的地方。）