我大部分时间都花在开发上，所以我并不熟悉所有的细节......
我在 Linux 主机上运行一项服务。我想使用 Kerberos 将身份信息传输给该服务。我的一些客户端位于连接到 AD 的 Windows 客户端上，因此它们已经有票证。我了解如何使用 kinit 在我的 *nix 客户端上获取票证，并已验证我可以这样做。我有一个 /etc/krb5.conf 文件，它似乎可以在我的 *nix 客户端上运行
我知道我需要做以下事情...
- 要求 AD 管理员为特定 SPN 生成密钥表。
- 将密钥表放在我的服务器上服务可以找到的地方。
- 客户端使用票证和 SPN 从 Kerberos 基础设施获取令牌。
- 配置服务以接收令牌并使用 keytab 对其进行解码。
这是我的问题...
SPN 通常采用 service_name/FQDN@domain_name 的形式。但是，我的客户端不使用服务的主机名来构造 SPN。相反，SPN 是在配置文件中设置的。如果我可以创建一个 SPN 并在服务器的每个实例上使用它，对我来说会最简单。
因此我会执行以下操作...
- 创建形式为 service_name/some_dummy_name@domain_name 的 SPN。
- 生成密钥表并将其复制到 svr1.mycompany.mydomain、svr2.mycompany.mydomain、...、svrX.mycompany.mydomain。
- 使用单个 SPN 配置我的客户端。
我似乎认为这会起作用，因为当服务器集群时，可以在具有不同主机名的多个服务器上使用相同的 SPN/keytab。
归根结底，SPN 的 FQDN 部分对服务器是否重要，还是只是为了让典型的客户端能够生成正确的 SPN？如果多台服务器具有相同的密钥表，它们是否可以接收和验证相同的令牌，还是需要其他东西？
需要强调的是，该服务是 Linux 上的 Java 应用程序，客户端是 Windows 和 *nix 上的 Java 应用程序。AD 将提供 Kerberos 服务器基础设施。
答案1
在您概述的情况下，它应该可以工作。您可以在多台机器上使用密钥表，只要客户端都有某种方式来确定要为哪个服务主体请求服务密钥。Kerberos 要求连接的两端通过某种带外方式来确定服务主体。通常，这是基于服务器 DNS 名称的约定，但 Kerberos 中没有任何内容要求这样做。
如果服务器数量“较少”并且没有定期轮换密钥表的安全要求，我认为这是一个合理的解决方案。
答案2
FQDN 对于客户当使用默认 Windows API 时，客户端使用它来确定他们想要什么 SPN，即 API 只获取客户端想要连接的服务和 FQDN，而系统只需从 dc 获取票证即可。
如果您在配置中使用硬编码的 SPN，则无需遵循此规定，它也可以像技术视图一样工作，但我知道如果自动 API 参与其中，可能会导致问题，因为您将违背最佳实践。