Kerberos（v5）主要名称的两种典型forms似乎是：
username[/instance]@REALM service/fully-qualified-domain-name@REALM 我也看到了这样的可能存在于多个端口上的服务：
service/fully-qualified-domain-name:port@REALM
我有一个现在正在Kerberized的内部应用程序，并希望了解如何命名服务主体。 该服务是分布式的，几个子域中的每个子域中的几台机器上运行着多个实例。
例如，假设我的域名是zombo.com ，并且我的Kerberized服务“tenaciousd”在机器“www1”到“www5”上运行。 此外，每台机器在知名端口上有10个实例，比如25001至25010。
所以我有五十个服务器实例，基本上都是一样的，这让我平衡负载，逐渐部署新版本，等等。
现在，我应该如何在Kerberos中命名服务主体？ 运行该服务的每个主机是否应该有一个，这似乎是最常见的forms？
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以外的东西。
我发现的大部分文档都假定每个服务都在一个域中的单个主机上运行，或者至less客户端关心的是他们连接的服务实例。 就我而言，从客户的angular度来看，服务几乎是一样的，那么这里最好的做法是什么呢？
对于不是唯一的事情（即复制服务，履行完全相同的职责），我通常共享一个共同的服务器主体。 如果外部实体看到相同的域名，例如它可以维持这种错觉，这就很好。
这也意味着，如果用户从实例1切换到实例49，则他们将不必执行另一个Kerberos握手，因为他们已经有了一个有效的工作票证。 他们将使用该票证对任何实例进行身份validation，而无需每个实例都获取一个新实例。
因此，我会使用：
tenaciousd/[email protected]
作为这项服务的主要名称，假设www.example.com是客户如何处理这项服务。