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.

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.