1.2. Cross-Realm Operation (Realm-übergreifender Betrieb)
1.2. Cross-Realm Operation (Realm-übergreifender Betrieb)
Das Kerberos-Protokoll ist so konzipiert, dass es über organisatorische Grenzen hinweg funktioniert. Ein Client in einer Organisation kann bei einem Server in einer anderen authentifiziert werden. Jede Organisation, die einen Kerberos-Server betreiben möchte, richtet ihr eigenes "Realm" (Reich) ein. Der Name des Realms, in dem ein Client registriert ist, ist Teil des Namens des Clients und kann vom End-Service verwendet werden, um zu entscheiden, ob eine Anfrage erfüllt werden soll.
Durch die Einrichtung von "Inter-Realm"-Schlüsseln können die Administratoren zweier Realms einem Client, der im lokalen Realm authentifiziert ist, erlauben, seine Identität gegenüber Servern in anderen Realms zu beweisen. Der Austausch von Inter-Realm-Schlüsseln (für jede Richtung kann ein separater Schlüssel verwendet werden) registriert den Ticket-Granting Service jedes Realms als Principal im anderen Realm. Ein Client ist dann in der Lage, ein TGT für den Ticket-Granting Service des entfernten Realms von seinem lokalen Realm zu erhalten. Wenn dieses TGT verwendet wird, verwendet der entfernte Ticket-Granting Service den Inter-Realm-Schlüssel (der sich normalerweise von seinem eigenen normalen TGS-Schlüssel unterscheidet), um das TGT zu entschlüsseln; somit ist sicher, dass das Ticket vom eigenen TGS des Clients ausgestellt wurde. Tickets, die vom entfernten Ticket-Granting Service ausgestellt wurden, werden dem End-Service anzeigen, dass der Client aus einem anderen Realm authentifiziert wurde.
Ohne Realm-übergreifenden Betrieb und mit entsprechender Berechtigung kann der Client die Registrierung eines separat benannten Principals in einem entfernten Realm arrangieren und normale Austauschvorgänge mit den Services dieses Realms durchführen. Jedoch wird dies selbst für kleine Zahlen von Clients umständlich, und automatischere Methoden, wie hier beschrieben, sind notwendig.
Man sagt, ein Realm kommuniziert mit einem anderen Realm, wenn die beiden Realms einen Inter-Realm-Schlüssel teilen, oder wenn das lokale Realm einen Inter-Realm-Schlüssel mit einem Zwischenrealm teilt, das mit dem entfernten Realm kommuniziert. Ein Authentication Path (Authentifizierungspfad) ist die Sequenz von Zwischenrealms, die bei der Kommunikation von einem Realm zu einem anderen durchlaufen werden.
Realms können hierarchisch organisiert sein. Jedes Realm teilt einen Schlüssel mit seinem Parent (Elternteil) und einen anderen Schlüssel mit jedem Child (Kind). Wenn ein Inter-Realm-Schlüssel nicht direkt von zwei Realms geteilt wird, ermöglicht die hierarchische Organisation, dass ein Authentifizierungspfad leicht konstruiert werden kann.
Wenn keine hierarchische Organisation verwendet wird, kann es notwendig sein, eine Datenbank zu konsultieren, um einen Authentifizierungspfad zwischen Realms zu konstruieren.
Obwohl Realms typischerweise hierarchisch sind, können Zwischenrealms umgangen werden, um Realm-übergreifende Authentifizierung durch alternative Authentifizierungspfade zu erreichen. (Diese könnten eingerichtet werden, um die Kommunikation zwischen zwei Realms effizienter zu gestalten.) Es ist wichtig für den End-Service zu wissen, welche Realms durchlaufen wurden, wenn entschieden wird, wie viel Vertrauen in den Authentifizierungsprozess gesetzt werden soll. Um diese Entscheidung zu erleichtern, enthält ein Feld in jedem Ticket die Namen der Realms, die an der Authentifizierung des Clients beteiligt waren.
Der Anwendungsserver ist letztlich verantwortlich für das Akzeptieren oder Ablehnen der Authentifizierung und SOLLTE das Transited-Feld überprüfen. Der Anwendungsserver kann sich darauf verlassen, dass der Key Distribution Center (KDC) für das Realm des Anwendungsservers das Transited-Feld überprüft. Der KDC des Anwendungsservers wird in diesem Fall das Flag TRANSITED-POLICY-CHECKED setzen. Die KDCs für Zwischenrealms können auch das Transited-Feld überprüfen, wenn sie TGTs für andere Realms ausstellen, aber sie werden ermutigt, dies nicht zu tun. Ein Client kann anfordern, dass die KDCs das Transited-Feld nicht überprüfen, indem er das Flag DISABLE-TRANSITED-CHECK setzt. KDCs SOLLTEN dieses Flag respektieren.