Kerberos (v5) 主體名稱的兩種典型形式似乎是：
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
我還看到類似的服務可能存在於多個連接埠上：
service/fully-qualified-domain-name:port@REALM
我有一個內部應用程序，現在正在 Kerberized，並且想了解服務主體應如何命名。此服務是分散式的，多個實例在多個子域中的每台機器上執行。
例如，假設我的網域是zombo.com，而我的 Kerberized 服務“tenaciousd”在計算機“www1”到“www5”上運行。此外，每台電腦在眾所周知的連接埠（例如 25001 到 25010）上有 10 個實例。
所以我有五十個伺服器實例，它們基本上相同，這讓我可以平衡負載，逐步部署新版本，等等。
現在，我應該如何在 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。 ，我們可能還可以傳遞除實際FQDN 之外的其他內容。
我發現的大多數文件都假設每個服務都在一個領域中的單一主機上運行，或者至少客戶端非常關心它們連接到哪個服務實例。就我而言，從客戶的角度來看，服務幾乎都是一樣的，那麼這裡的最佳實踐是什麼？
答案1
對於不唯一的事情（即複製的服務，執行完全相同的職責），我通常共用一個公共伺服器主體。例如，如果外部實體看到相同的域名，那麼這種方法就很有效，因為它維持了這種錯覺。
這也意味著，如果使用者從實例 1 切換到實例 49，他們將不必執行另一次 Kerberos 握手，因為他們已經擁有有效的工作票證。他們將使用該票證對任何實例進行身份驗證，而無需為每個實例獲取新的票證。
因此，我會使用：
tenaciousd/[email protected]
作為此服務的主要名稱，假設客戶使用 www.example.com 來尋址此服務。