Kapitel 7 SEAM-Referenz

In diesem Kapitel werden viele Dateien, Befehle und Dämonen aufgeführt, die zum Umfang von SEAM gehören. Zusätzlich werden in diesem Kapitel detailierte Informationen über die Funktionsweise des Kerberos-Authentisierungssystems bereitgestellt.

Es folgt eine Liste der Referenzinformationen in diesem Kapitel.

• "SEAM-Dateien"

• "SEAM-Befehle"

• "SEAM-Dämonen"

• "SEAM-Terminologie"

• "Funktionsweise des Authentisierungssystems"

• "Zugriff auf einen Service mit SEAM erhalten"

SEAM-Dateien

PAM-Konfigurationsdatei

Die mit SEAM ausgelieferte Standarddatei für die PAM-Konfiguration enthält Einträge für die Behandlung der neuen, für Kerberos ausgestatteten Anwendungen. Die neue Datei enthält Einträge für die Module des Authentisierungs-Services, der Konto-, Sitzungs- und Passwortverwaltung.

Für das Authentisierungsmodul gelten die neuen Einträge für rlogin, login, dtlogin, krlogin, ktelnet und krsh. Ein Beispiel für diese Einträge finden Sie weiter unten. Jeder dieser Services verwendet die neue PAM-Bibliothek /usr/lib/security/pam_krb5.so.1, um die Kerberos-Authentisierung bereitzustellen.

Die ersten drei Einträge beschäftigen sich mit der Option try_first_pass, die die Authentisierung mit Hilfe des anfänglichen Benutzerpassworts anfordern. Die Verwendung des anfänglichen Passworts bedeutet für den Benutzer, dass er auch dann nicht zur Eingabe eines weiteren Passworts aufgefordert wird, wenn mehrere Mechanismen aufgeführt sind.

Die nächsten drei Einträge verwenden die Option acceptor, um das PAM-Modul davon abzuhalten, den Prozess für den Empfang des anfänglichen Ticket-granting Tickets durchzuführen. Dieser Austausch wurde für die mit Kerberos ausgestatteten Server-Anwendungen bereits von der Anwendung durchgeführt, daher muss für diesen Schritt PAM nicht verwendet werden. Zusätzlich wird ein other-Eintrag als Standardeintrag für alle Einträge eingefügt, die nicht festgelegt sind und die eine Authentisierung erfordern.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

Für die Kontoverwaltung verfügt dtlogin über einen neuen Eintrag, der die Kerberos-Bibliothek verwendet, wie unten dargestellt. Es ist ein other-Eintrag einbezogen, um eine Standardregel bereitzustellen. Momentan werden von dem other-Eintrag keine Aktionen durchgeführt.

dtlogin account optional /usr/lib/security/pam_krb5.so.1
other account optional /usr/lib/security/pam_krb5.so.1

Die letzten beiden Einträge in der Datei /etc/pam.conf werden unten dargestellt. Der other-Eintrag für die Sitzungsverwaltung vernichtet Berechtigungsnachweise von Benutzern. Der neue other-Eintrag für die Passwortverwaltung wählt die Kerberos-Bibliothek aus.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM-Befehle

Dieser Abschnitt führt einige Befehle auf, die in SEAM enthalten sind.

SEAM-Dämonen

Die mit SEAM verwendeten Dämonen werden in der folgenden Tabelle aufgeführt.

SEAM-Terminologie

Der folgende Abschnitt führt Begriffe und Ihre Definitionen auf, die in der SEAM-Dokumentation verwendet werden. Damit Sie vielen dieser Erläuterungen folgen können, ist die Kenntnis dieser Begriffe erforderlich.

Kerberos-spezifische Terminologie

Die Kenntnis der in diesem Abschnitt aufgeführten Begriffe ist für das Verständnis der Abschnitte über die Verwaltung der KDCs erforderlich.

Das Key Distribution Center oder KDC stellt den Teil von SEAM dar, der für die Ausgabe von Berechtigungsnachweisen zuständig ist. Diese Berechtigungsnachweise werden mit Informationen erstellt, die in der KDC-Datenbank gespeichert werden. Jeder Bereich benötigt mindestens zwei KDCs, eine Master-KDC und mindestens eine Slave-KDC. Alle KDC generieren Berechtigungsnachweise, aber nur das Master-KDC behandelt Änderungen an der KDC-Datenbank.

Eine stash-Datei enthält eine verschlüsselte Kopie des Master-Schlüssels für das KDC. Dieser Schlüssel wird beim Neustart eines Servers verwendet, um das KDC automatisch vor der Ausführung von kadmind und krb5kdc zu authentisieren. Da diese Datei den Master-Schlüssel enthält, sollte die Datei sowie sämtliche Kopien gesichert aufbewahrt werden. Wenn die Verschlüsselung beeinträchtigt ist, kann der Schlüssel dazu verwendet werden, um auf die KDC-Datenbank zuzugreifen oder sie zu verändern.

Authentisierungsspezifische Terminologie

Die im folgenden erläuterten Begriffe sind für das Verständnis des Authentisierungsprozesses erforderlich. Programmierern und Systemverwaltern sollten diese Begriffe bekannt sein.

Ein Client bezeichnet die Software, die auf der Workstation eines Benutzers ausgeführt wird. Die auf dem Client ausgeführte SEAM-Software führt viele Anfragen während dieses Prozesses durch und es ist wichtig, die Aktionen dieser Software vom Benutzer zu unterscheiden.

Die Begriffe Server und Service werden häufig gleichbedeutend verwendet. Der Begriff Server wird verwendet, um das physische System zu definieren, auf dem die SEAM-Software ausgeführt wird. Der Begriff Service entspricht einer bestimmten Funktion, die auf einem Server unterstützt wird (z. B. ftp oder nfs). Die Dokumentation beschreibt Server häufig als Teil eines Services. Dies entspricht aber nicht der eigentlichen Bedeutung der Begriffe. Server beziehen sich auf das physische System, während sich ein Service auf die Software bezieht.

SEAM umfasst drei Arten von Schlüsseln. Einer davon ist der private Schlüssel. Dieser Schlüssel wird jedem Benutzer-Hauptbenutzer übergeben und ist nur dem Benutzer des Hauptbenutzers sowie dem KDC bekannt. Bei Benutzer-Hauptbenutzern basiert der Schlüssel auf dem Passwort des Benutzers. Für Server und Services ist dieser Schlüssel als Service-Schlüssel bekannt. Dieser Schlüssel dient demselben Zweck wie der private Schlüssel, wird aber von Servern und Services verwendet. Die dritte Schlüsselart stellt der Sitzungsschlüssel dar. Dieser Schlüssel wird vom Authentisierungs-Service oder Ticket-granting-Service generiert. Ein Sitzungsschlüssel wird generiert, um sichere Transaktionen zwischen einem Client und einem Service bereitzustellen.

Ein Ticket stellt ein Informationspaket für die sichere Weitergabe der Identität eines Benutzers an einen Server oder einen Service dar. Ein Ticket ist nur für einen einzelnen Client und einen bestimmten Service auf einem bestimmten Server gültig. Es enthält den Hauptbenutzernamen des Services, den Hauptbenutzernamen des Benutzers und die IP-Adresse vom Host des Benutzers sowie einen Zeitstempel und einen Wert, um die Lebensdauer des Tickets zu definieren. Ein Ticket wird mit einem Zufallssitzungsschlüssel erstellt, der vom Client und vom Service verwendet wird. Nach der Erstellung eines Tickets kann dieses wiederverwendet werden, bis es abläuft.

Ein Berechtigungsnachweis stellt ein Informationspaket dar, das ein Ticket und einen passenden Sitzungsschlüssel einbezieht. Berechtigungsnachweise werden häufig mit einem privaten Schlüssel oder einem Service-Schlüssel verschlüsselt. Dies ist davon abhängig, womit der Berechtigungsnachweis entschlüsselt wird.

Der Authentisierer stellt eine weitere Informationsart dar. Ein Authentisierer kann zusammen mit einem Ticket zur Authentisierung eines Benutzer-Hauptbenutzers verwendet werden. Ein Authentisierer umfasst den Hauptbenutzernamen des Benutzers, die IP-Adresse vom Host des Benutzers und einen Zeitstempel. Im Gegensatz zum Ticket kann ein Authentisierer nur einmal verwendet werden, was normalerweise bei der Anforderung des Zugriffs auf einen Service erfolgt. Ein Authentisierer wird mit dem Sitzungsschlüssel für diesen Client und diesen Server verschlüsselt.

Arten von Tickets

Tickets besitzen Eigenschaften, die deren Verwendung regeln. Diese Eigenschaften werden dem Ticket bei der Erstellung zugeordnet, obwohl Sie die Eigenschaften eines Tickets auch später noch ändern können. (Für ein Ticket kann beispielsweise das Attribut forwardable (weiterreichbar) in forwarded (weitergereicht) geändert werden). Mit dem Befehl klist können die Eigenschaften von Tickets angezeigt werden (siehe "Anzeigen von Tickets").

Tickets können durch einen oder mehrere der folgenden Begriffe beschrieben werden:

weiterreichbar/weitergereicht

Ein weiterreichbares Ticket kann von einem Host an einen anderen gesendet werden, ohne dass sich ein Client selbst erneut authentisieren muss. Wenn z. B. der Benutzer david ein weiterreichbares Ticket erhält, während er sich auf dem System von jennifer befindet, kann er sich auf seinem eigenen System anmelden, ohne ein neues Ticket abrufen zu müssen (und sich somit erneut selbst authentisieren zu müssen). (Siehe "Beispiel -- Erstellen eines Tickets", um ein Beispiel eines weiterreichbaren Tickets zu erhalten.) Vergleichen Sie unten ein weiterreichbares Ticket mit einem Vollmachten -Ticket.

Initial

Ein Initial-Ticket ist ein Ticket, das direkt vergeben wird. Es basiert nicht auf einem Ticket-granting Ticket. Einige Services, wie z. B. Passwort ändernde Anwendungen, können als Initialticket markierte Tickets erfordern, um sicherzustellen, dass der Client den Geheimschlüssel kennt. Ein Ticket mit dem Parameter initial zeigt nämlich an, dass der Client sich selbst kürzlich authentisiert hat (anstatt sich auf ein Ticket-granting Ticket zu verlassen, das sich möglicherweise schon einige Zeit im Umlauf befindet).

Ungültiges

Ein Ticket mit dem Parameter invalid (ungültig) ist ein nachdatiertes Ticket, das noch nicht gültig ist. (Siehe unten, erneuerbar.) Es wird von einem Anwendungs-Server zurückgewiesen, bis es gültig ist. Das Ticket muss dem KDC von einem Client in einer TGS-Anforderung mit gesetzter Option VALIDATE vorgelegt werden, nachdem seine Startzeit erreicht wurde, um gültig zu werden.

nachdatierbar/nachdatiert

Ein nachdatiertes Ticket ist ein Ticket, das erst zu einem angegebenen Zeitpunkt nach seiner Erstellung gültig wird. Diese Tickets sind beispielsweise für Stapelaufträge nützlich, die in der Nacht ausgeführt werden, da das Ticket nicht vor der Ausführung des Stapelauftrags verwendet werden kann, falls es gestohlen wird. Wenn ein nachdatiertes Ticket freigegeben wird, erfolgt die Ausgabe als invalid (ungültig). Es verbleibt so, bis: seine Startzeit erreicht wurde, und der Client die Überprüfung beim KDC anfordert. (Siehe dazu invalid (ungültig) weiter oben.) Ein nachdatiertes Ticket ist normalweise gültig, bis das Ticket-granting Ticket abgelaufen ist; wenn es jedoch als erneuerbar markiert ist, wird für seine Lebensdauer normalerweise dieselbe Zeit festgelegt, wie für die gesamte Lebensdauer des Ticket-granting Tickets. Siehe unten, erneuerbar.

Vollmachten-Ticket

Manchmal kann es für einen Hauptbenutzer notwendig sein, einem Service die Durchführung einer Operation in seinem Namen zu erlauben. (Beispielsweise, wenn ein Hauptbenutzer einen Service auffordert, einen Druckauftrag auf einem dritten Host auszuführen.) Der Service muss in der Lage sein, die Identität des Clients anzunehmen, jedoch nur für diese eine Operation. In diesem Fall handelt der Server als Bevollmächtigter (Proxy) des Clients. Der Hauptbenutzername des Bevollmächtigten muss bei der Erstellung des Tickets angegeben werden.

Ein Vollmachten-Ticket ist mit einem weiterreichbaren Ticket vergleichbar. Das Vollmachten-Ticket ist jedoch nur für einen einzelnen Service gültig, während ein weiterreichbares Ticket dem Service die vollständige Verwendung der Identität des Clients ermöglicht. Ein weiterreichbares Ticket kann daher als eine Art Generalbevollmächtigter betrachtet werden.

erneuerbares

Tickets mit einer langen Lebensdauer bilden ein Sicherheitsrisiko. Deshalb können Tickets als erneuerbar gekennzeichnet werden. Ein erneuerbares Ticket besitzt zwei Ablaufzeiten: Die Zeit, zu der das aktuelle Exemplar des Tickets abläuft und die maximale Lebensdauer für alle Tickets. Wenn ein Client ein Ticket weiterverwenden möchte, erneuert er es vor Verstreichen der ersten Ablauffrist. Ein Ticket kann z. B. für eine Stunde gültig sein, während alle Tickets eine maximale Lebensdauer von zehn Stunden besitzen. Wenn der Client sein Ticket länger als eine Stunde verwenden möchte, muss er es in dieser Stunde erneuern. Wenn ein Ticket die maximal zulässige Lebensdauer für Tickets erreicht hat (10 Stunden), läuft es automatisch ab und kann nicht erneuert werden.

Informationen über die Anzeige von Tickets zum Betrachten ihrer Attribute finden Sie unter "Anzeigen von Tickets".

Lebensdauer für Tickets

Mit jedem Eingang eines Tickets für den Hauptbenutzer, einschließlich des Ticket-granting Tickets, wird die Lebensdauer des Tickets als kleinster der folgenden Werte für die Lebensdauer festgelegt:

• Der durch die Option -l des Befehls kinit festgelegte Wert für die Lebensdauer wird verwendet, wenn kinit zum Abrufen des Tickets ausgeführt wurde

• Der Wert für die maximale Lebensdauer (max_life) wird in der Datei kdc.conf festgelegt

• Der Wert für die maximale Lebensdauer, der in der Kerberos-Datenbank für den Service-Hauptbenutzer festgelegt ist, der das Ticket bereitstellt. (Im Falle von kinit ist der Service-Hauptbenutzer der krbtgt/Bereich)

• Der Wert für die maximale Lebensdauer, der in der Kerberos-Datenbank für den Benutzer-Hauptbenutzer festgelegt ist, der das Ticket anfordert.

Abbildung 7-1 erläutert, wie die Lebensdauer eines Ticket-granting Tickets bestimmt wird, und veranschaulicht die Herkunft der vier Werte für die Lebensdauer. Obwohl Abbildung 7-1 zeigt, wie die Lebensdauer eines Ticket-granting Tickets bestimmt wird, erfolgt derselbe Vorgang im Grunde auch, wenn ein beliebiger Hauptbenutzer ein Ticket erhält. Der einzige Unterschied besteht darin, dass kinit keinen Wert für die Lebensdauer bereitstellt, und dass der Service-Hauptbenutzer, der das Ticket bereitstellt, einen maximalen Wert für die Lebensdauer bestimmt (und nicht der Hauptbenutzer krbtgt/Bereich).

Abbildung 7-1 Bestimmen der Lebensdauer eines Ticket-granting Tickets

Die Lebensdauer für ein erneuerbares Ticket wird ebenfalls aus mindestens vier Werten bestimmt, jedoch werden hier erneuerbare Werte für die Lebensdauer verwendet:

• Der durch die Option -r des Befehls kinit festgelegte erneuerbare Wert für die Lebensdauer wird verwendet, wenn kinit zum Abrufen oder Erneuern des Tickets ausgeführt wurde

• Der Wert für die maximale, erneuerbare Lebensdauer (max_renewable_life) wird in der Datei kdc.conf festgelegt

• Der Wert für die maximale erneuerbare Lebensdauer, der in der Kerberos-Datenbank für den Service-Hauptbenutzer festgelegt ist, der das Ticket bereitstellt (für kinit lautet der Service-Hauptbenutzer krbtgt/Bereich)

• Der Wert für die maximale erneuerbare Lebensdauer, der in der Kerberos-Datenbank für den Benutzer-Hauptbenutzer festgelegt ist, der das Ticket anfordert.

Hauptbenutzernamen

Jedes Ticket wird duch einen Hauptbenutzernamen identifiziert. Über den Hauptbenutzernamen kann ein Benutzer oder ein Service angegeben werden. Hier folgen Beispiele verschiedener Hauptbenutzernamen.

Funktionsweise des Authentisierungssystems

Anwendungen ermöglichen Ihnen das Anmelden auf einem entfernten System, wenn Sie ein Ticket, das Ihre Identität nachweist, sowie einen Sitzungsschlüssel vorweisen können. Der Sitzungsschlüssel enthält Informationen, die für den Benutzer und den Service spezifisch sind, auf den zugegriffen werden soll. Für alle Benutzer wird vom KDC bei der ersten Anmeldung ein Ticket und ein Sitzungsschlüssel erstellt. Das Ticket und der passende Sitzungsschlüssel bilden einen Berechtigungsnachweis. Bei der Verwendung mehrerer Netzwerkdienste kann der Benutzer viele Berechtigungsnachweise ansammeln. Der Benutzer benötigt für jeden auf einem bestimmten Server ausgeführten Service einen Berechtigungsnachweis. Der Zugriff auf den Service ftp auf einem Server namens hamburg erfordert z. B. einen Berechtigungsnachweis, und der Zugriff auf den Service ftp auf einem anderen Server erfordert wiederum einen eigenen Berechtigungsnachweis.

Der Prozess der Erstellung und Speicherung der Berechtigungsnachweise erfolgt transparent. Berechtigungsnachweise werden vom KDC erstellt, das den Berechtigungsnachweis an den Anfordernden sendet. Nach dem Empfang wird der Berechtigungsnachweis in einem Berechtigungsnachweis-Cache gespeichert.

Zugriff auf einen Service mit SEAM erhalten

Damit ein Benutzer Zugriff auf einen bestimmten Service auf einem bestimmten Server erhält, benötigt er zwei Dinge. Als erstes benötigt er einen Berechtigungsnachweis für den Ticket-granting-Service (auch als TGS bezeichnet). Nachdem der Ticket-granting-Service diesen Berechtigungnachweis entschlüsselt hat, erstellt er einen zweiten Berechtigungsnachweis für den Server, auf den der Benutzer zugreifen möchte. Der zweite Berechtigungsnachweis kann dann dazu verwendet werden, den Zugriff auf den Service des Servers anzufordern. Nachdem der Server den zweiten Berechtigungsnachweis erfolgreich entschlüsselt hat, wird dem Benutzer der Zugriff gewährt. Dieser Prozess wird unten eingehender beschrieben.

Erhalten eines Berechtigungsnachweises für den Ticket-granting-Service

1. Der Client sendet eine Anfrage für einen bestimmten Benutzer-Hauptbenutzer an den Authentisierungs-Server, um den Authentisierungsprozess zu starten. Diese Anfrage wird unverschlüsselt gesendet. Da keine sicherheitsrelevanten Informationen in der Anfrage enthalten sind, ist eine Verschlüsselung nicht notwendig.

2. Wenn die Anfrage beim Authentisierungs-Service eingegangen ist, wird der Hauptbenutzername des Benutzers in der KDC-Datenbank überprüft. Wenn ein Hauptbenutzer übereinstimmt, erhält der Authentisierungs-Service den privaten Schlüssel für diesen Hauptbenutzer. Dann generiert der Authentisierungs-Service einen Sitzungsschlüssel (z. B. Sitzungsschlüssel 1, der vom Client und dem Ticket-granting-Service verwendet wird sowie ein Ticket für den Ticket-granting-Service (Ticket 1). Dieses Ticket wird auch als Ticket-granting Ticket (TGT) bezeichnet. Sowohl der Sitzungsschlüssel als auch das Ticket werden mit dem privaten Schlüssel des Benutzers verschlüsselt, und die Informationen werden anschließend an den Client zurück gesendet.

3. Der Client verwendet diese Informationen, um Sitzungschlüssel 1 und Ticket 1 zu entschlüsseln, wobei der private Schlüssel für den Benutzer-Hauptbenutzer verwendet wird. Da der private Schlüssel nur dem Benutzer und der KDC-Datenbank bekannt sein sollte, müssten die Informationen in dem Paket sicher sein. Der Client speichert die Informationen im Berechtigungsnachweis-Cache.

Normalerweise wird ein Benutzer während dieses Vorgangs nach seinem Passwort gefragt. Wenn das eingegebene Passwort mit dem zum Generieren des in der KDC-Datenbank gespeicherten privaten Schlüssels verwendeten Passworts übereinstimmt, dann kann der Client die vom Authentisierungs-Service gesendeten Informationen erfolgreich entschlüsseln. Nun verfügt der Client über einen Berechtigungsnachweis, der mit dem Ticket-granting Service verwendet werden kann. Der Client ist nun dazu bereit, einen Berechtigungsnachweis für einen Server anzufordern.

Abbildung 7-2 Erhalten eines Berechtigungsnachweises für den Ticket-granting-Service

Erhalten eines Berechtigungsnachweises für einen Server

1. Damit ein Client den Zugriff auf einen bestimmten Server anfordern kann, muss er zuerst einen Berechtigungsnachweis für diesen Server vom Authentisierungs-Service erhalten haben (siehe "Erhalten eines Berechtigungsnachweises für den Ticket-granting-Service"). Der Client sendet dann eine Anfrage an den Ticket-granting-Service, die den Service-Hauptbenutzernamen (Ticket 1) sowie einen mit dem Sitzungsschlüssel 1 verschlüsselten Authentisierer einbezieht. Ticket 1 wurde ursprünglich vom Authentisierungs-Service mit dem Sitzungsschlüssel des Ticket-granting-Services verschlüsselt.

2. Da der Sitzungsschlüssel des Ticket-granting-Services dem Ticket-granting-Service bekannt ist, kann Ticket 1 entschlüsselt werden. Die in Ticket 1 enthaltenen Informationen umfassen auch Sitzungsschlüssel 1, damit der Ticket-granting-Service den Authentisierer entschlüsseln kann. Zu diesem Zeitpunkt wird der Benutzer-Hauptbenutzer mit dem Ticket-granting-Service authentisiert.

3. Nachdem die Authentisierung erfolgreich durchgeführt wurde, generiert der Ticket-granting-Service einen Sitzungschlüssel für den Benutzer-Hauptbenutzer und den Server (Sitzungsschlüssel 2) sowie ein Ticket für den Server (Ticket 2). Sitzungsschlüssel 2 und Ticket 2 werden dann mit Sitzungsschlüssel 1 verschlüsselt. Da Sitzungsschlüssel 1 nur dem Client und dem Ticket-granting-Service bekannt sind, ist diese Information sicher und kann problemlos über das Netzwerk gesendet werden.

4. Wenn der Client dieses Informationspaket empfängt, wird es von ihm mit Sitzungsschlüssel 1 entschlüsselt, der im Berechtigungsnachweis-Cache gespeichert wurde. Der Client hat somit einen Berechtigungsnachweis erhalten, der für den Server eingesetzt werden kann. Nun kann der Client den Zugriff auf einen bestimmten Service auf diesem Server anfordern.

Abbildung 7-3 Erhalten eines Berechtigungsnachweises für einen Server

Zugriff erhalten auf einen bestimmten Service

1. Der Client muss zuerst einen Berechtigungsnachweis für den Ticket-granting-Service vom Authentisieruns-Server sowie einen Server-Berechtigungsnachweis vom Ticket-granting-Service erhalten, um Zugriff auf einen bestimmten Service anfordern zu können (siehe "Erhalten eines Berechtigungsnachweises für den Ticket-granting-Service" und "Erhalten eines Berechtigungsnachweises für einen Server"). Der Cient kann eine Anfrage an den Server senden, die Ticket 2 und einen weiteren Authentisierer einbezieht. Der Authentisierer wird mit Sitzungsschlüssel 2 verschlüsselt.

2. Ticket 2 wurde vom Ticket-granting-Service mit dem Service-Schlüssel für diesen Service verschlüsselt. Da der Service-Schlüssel dem Service-Hauptbenutzer bekannt ist, kann der Service Ticket 2 entschlüsseln und Sitzungsschlüssel 2 abrufen. Sitzungsschlüssel 2 kann anschließend dazu verwendet werden, den Authentisierer zu entschlüsseln. Wenn der Authentisierer erfolgreich entschlüsselt wurde, wird dem Client der Zugriff auf den Service gewährt.

Abbildung 7-4 Zugriff erhalten auf einen bestimmten Service