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.

Tabelle 7-4 Beispiele für Hauptbenutzernamen

Hauptbenutzername	Beschreibung Beschreibung
root/boston.acme.com@ACME.COM	Ein mit dem Konto root auf dem NFS-Client verbundener Hauptbenutzer. Dieser wird als Root-Hauptbenutzer bezeichnet und ist für das erfolgreich authentisierte NFS-Einhängen erforderlich.
host/boston.acme.com@ACME.COM	Ein Hauptbenutzer, der von den mit Kerberos ausgestatteten Anwendungen (z. B. klist und kprop) und Services (wie ftp und telnet) verwendet wird. Dieser wird als Host- oder Service-Hauptbenutzer bezeichnet.
Benutzername@ACME.COM	Ein Hauptbenutzer für einen Benutzer
Benutzername/admin@ACME.COM	Ein Admin-Hauptbenutzer, der für die Verwaltung der KDC-Datenbank verwendet werden kann
ftp/boston.acme.com@ACME.COM	Ein vom Service ftp verwendeter Hauptbenutzer. Dieser kann statt eines Host-Hauptbenutzers verwendet werden.
K/M@ACME.COM	Der Hauptbenutzer für den Master-Schlüsselnamen. Einer dieser Schlüssel ist mit jeder Master-KDC verbunden.
kadmin/history@ACME.COM	Ein Hauptbenutzer, der einen Schlüssel einbezieht, der für die Speicherung der Passwort-Historien anderer Hauptbenutzer verwendet wird. Einer dieser Hauptbenutzer ist für jede Master-KDC vorhanden.
kadmin/kdc1.acme.com@ACME.COM	Ein Hauptbenutzer für den Master-KDC-Server, der den Zugriff auf das KDC mit Hilfe von kadmind ermöglicht
changepw/kdc1.acme.com@ACME.COM	Ein Hauptbenutzer für den Master-KDC-Server, der beim Ändern von Passwörtern den Zugriff auf das KDC ermöglicht
krbtgt/ACME.COM@ACME.COM	Dieser Hauptbenutzer wird bei der Generierung eines Ticket-granting Tickets verwendet.