Zwei typische Formen für Kerberos (v5)-Hauptnamen scheinen zu sein:
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
Ich habe so etwas auch für Dienste gesehen, die auf mehreren Ports vorhanden sein könnten:
service/fully-qualified-domain-name:port@REALM
Ich habe eine interne Anwendung, die gerade kerberisiert wird, und möchte wissen, wie die Dienstprinzipale benannt werden sollten. Der Dienst ist verteilt, wobei mehrere Instanzen auf mehreren Rechnern in mehreren Unterdomänen ausgeführt werden.
Nehmen wir zum Beispiel an, mein Domänenname istzombo.com, und mein Kerberized-Dienst „tenaciousd“ läuft auf den Maschinen „www1“ bis „www5“. Außerdem hat jede Maschine zehn Instanzen auf bekannten Ports, beispielsweise 25001 bis 25010.
Ich verfüge also über fünfzig Instanzen des Servers, die im Grunde alle gleich sind. Dadurch kann ich die Last ausgleichen, neue Versionen schrittweise bereitstellen usw.
Wie soll ich nun die Dienstprinzipale in Kerberos benennen? Sollte es für jeden Host, auf dem der Dienst ausgeführt wird, einen geben, wie es in der gängigsten Form der Fall zu sein scheint?
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
Oder ist es die bessere Vorgehensweise (und warum), einen Dienstprinzipal pro Dienstinstanz zu haben?
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
...
tenaciousd/www5.zombo.com:[email protected]
Und schließlich: Wie wäre es, nur einen Dienstprinzipal zu haben? Das erscheint zwar einfacher, wird aber seltener eingesetzt?
[email protected]
Falls es wichtig ist: Der kerberisierte Dienst (und die Clients) verwenden Cyrus SASL, GNU GSSAPI und MIT Kerberos 5. Die SASL-API verwendet zusätzlich zum Dienstnamen einen Parameter für „vollqualifizierten Domänennamen“, aber ich vermute, das liegt daran, dass sie mehr als nur Kerberos unterstützt und wir wahrscheinlich auch andere Dinge als tatsächliche FQDNs übergeben könnten.
Die meisten Dokumentationen, die ich gefunden habe, gehen davon aus, dass jeder Dienst auf einem einzelnen Host in einem Bereich ausgeführt wird oder dass es den Clients zumindest sehr wichtig ist, mit welcher Dienstinstanz sie sich verbinden. In meinem Fall sind die Dienste aus Sicht des Clients alle ziemlich gleich. Was wäre also hier die beste Vorgehensweise?
Antwort1
Für Dinge, die nicht eindeutig sind (d. h. replizierte Dienste, die genau dieselben Aufgaben ausführen), verwende ich normalerweise einen gemeinsamen Server-Principal. Dies funktioniert gut, wenn externe Entitäten beispielsweise denselben Domänennamen sehen, da dadurch die Illusion aufrechterhalten wird.
Das bedeutet auch, dass ein Benutzer, wenn er von Instanz 1 zu Instanz 49 wechselt, keinen weiteren Kerberos-Handshake durchführen muss, da er bereits über ein gültiges, funktionierendes Ticket verfügt. Er wird dieses Ticket verwenden, um sich bei allen Instanzen zu authentifizieren, ohne für jede Instanz ein neues abrufen zu müssen.
Daher würde ich verwenden:
tenaciousd/[email protected]
als Hauptnamen für diesen Dienst, wobei davon ausgegangen wird, dass dieser Dienst von Clients über www.example.com angesprochen wird.