Kerberos (v5) 主体名称的两种典型形式似乎是：
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
对于可能存在于多个端口上的服务，我也看到过类似的情况：
service/fully-qualified-domain-name:port@REALM
我有一个内部应用程序，目前正在进行 Kerberos 化，我想了解如何命名服务主体。该服务是分布式的，在多个子域中的每台机器上运行多个实例。
例如，假设我的域名是zombo.com，我的 Kerberized 服务“tenaciousd”在机器“www1”至“www5”上运行。此外，每台机器在知名端口（例如 25001 至 25010）上有 10 个实例。
所以我有 50 个服务器实例，基本上都是相同的，这使我能够平衡负载、逐步部署新版本等等。
现在，我应该如何在 Kerberos 中命名服务主体？是否应该为运行该服务的每台主机都设置一个，这似乎是最常见的形式？
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
或者每个服务实例有一个服务主体是否更好的做法（以及为什么）？
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
...
tenaciousd/www5.zombo.com:[email protected]
最后，如果只有一个服务主体，这看起来更简单但却不常见，那怎么样？
[email protected]
如果重要的话，Kerberized 服务（和客户端）使用 Cyrus SASL、GNU GSSAPI 和 MIT Kerberos 5。SASL API 除了服务名称之外还采用“完全限定域名”参数，但我怀疑这是因为它支持的不仅仅是 Kerberos，我们可能还会传递除实际 FQDN 之外的内容。
我发现的大多数文档都假设每个服务都在一个域中的单个主机上运行，或者至少客户端非常关心它们连接到哪个服务实例。就我而言，从客户端的角度来看，这些服务几乎都是一样的，那么这里的最佳做法是什么？
答案1
对于不唯一的事物（即执行完全相同职责的复制服务），我通常共享一个通用服务器主体。例如，如果外部实体看到相同的域名，这种方法很有效，因为它保持了这种假象。
这也意味着，如果用户从实例 1 切换到实例 49，他们无需再执行一次 Kerberos 握手，因为他们已经拥有有效且可用的票证。他们将使用该票证对任何实例进行身份验证，而无需为每个实例获取新的票证。
因此，我会使用：
tenaciousd/[email protected]
作为此服务的主要名称，假设 www.example.com 是客户端对此服务的寻址方式。