SEAM-Terminologie

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

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 umfaßt 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 Paßwort 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 umfaßt 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 "Wie Tickets angezeigt werden").

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

forwardable/forwarded (weiterreichbar/weitergereicht)

Ein weiterreichbares Ticket kann von einem Host an einen anderen gesendet werden, ohne daß sich ein Client selbst erneut authentisieren muß. 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. Paßwort ändernde Anwendungen, können als initial markierte Tickets erfordern, um sicherzustellen, daß der Client den Geheimschlüssel kennt -- da ein Ticket mit dem Parameter initial anzeigt, daß 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, nachdatiert ) Es wird von einem Anwendungs-Server zurückgewiesen, bis es gültig ist. Das Ticket muß 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.

Postdatable/postdated (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) und es verbleibt so, bis seine Startzeit erreicht wurde, und der Client die Überprüfung beim KDC anfordert. (Siehe oben, invalid (ungültig)) Ein nachdatiertes ist normalweise gültig, bis das Ticket-granting Tickets 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.

proxiable/proxy (Vollmachten/Proxy)

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 muß 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 des Clients. Der Hauptbenutzername des Bevollmächtigten muß 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.

erneuerbar

Da Tickets mit sehr langer Lebensdauer ein Risiko darstellen, können Tickets auch als erneuerbar angegeben 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, muß er es in dieser Stunde erneuern. Mit Erreichen der maximalen Ticket-Lebensdauer (19 Stunden) läuft das Ticket automatisch ab und kann nicht mehr erneuert werden.

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

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. (Für kinit lautet der Service-Hauptbenutzer 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, daß kinit keinen Wert für die Lebensdauer bereitstellt, und daß 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 durch einen Hauptbenutzernamen gekennzeichnet Der Hauptbenutzername kann einen Benutzer oder einen Service kennzeichnen. Hier folgen Beispiele verschiedener Hauptbenutzernamen.

Tabelle 7-4 Beispiele für Hauptbenutzernamen

Hauptbenutzername	Beschreibung
root/hamburg.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/hamburg.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/hamburg.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 Paßwort-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 Paßwörtern den Zugriff auf das KDC ermöglicht
krbtgt/ACME.COM@ACME.COM	Dieser Hauptbenutzer wird bei der Generierung eines Ticket-granting Tickets verwendet.