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 Authentisierunssystems"

• "Zugriff auf einen Service mit SEAM erhalten"

• "Verwenden der Tabelle für gsscred"

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 Paßwortverwaltung.

Für das Authentisierungsmodul sind die neuen Einträge für rlogin, login, dtlogin, krlogin, ktelnet und krsh. Ein Beispiel für diese Einträge finden Sie unten. Jeder dieser Services verwendet die neue PAM-Bibliothe, /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 Benutzerpaßworts anfordern. Die Verwendung des anfänglichen Paßworts bedeutet für den Benutzer, daß er auch dann nicht zur Eingabe eines weiteren Paßworts 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 Prozeß 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 muß 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 Paßwortverwaltung 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.

Änderungen für den Befehl share

Zusätzlich zu den neuen SEAM-Befehlen umfaßt das Produkt SEAM auch Änderungen für den Befehl share, der sowohl für die Versionen Solaris 2.6 und Solaris 7 bereitgestellt wurde. Mit dem Befehl share können drei Sicherheitsmodi verwendet werden:

krb5

Kerberos-Authentisierung auswählen

krb5i

Kerberos-Authentisierung mit Integrität auswählen

krb5p

Kerberos-Authentisierung mit Integrität und Vertraulichkeit auswählen

Wenn mehrere Modi in den Befehl share einbezogen sind, wird standardmäßig der zuerst aufgeführte Modus verwendet, wenn der Client keinen Sicherheitsmodus festlegt. Andernfalls wird der vom Client ausgewählte Modus verwendet.

Wenn eine mount-Aufforderung fehlschlägt, die einen Kerberos-Modus verwendet, dann wird die mount-Aufforderung mit dem Sicherheitsmodus none (kein) abgeschlossen. Dies kommt häufig vor, wenn der root-Hauptbenutzer oder der NFS-Client nicht authentisiert wurde. Die mount-Aufforderung kann auch erfolgreich sein, aber der Benutzer ist dann nicht in der Lage, auf die Dateien zuzugreifen, bevor sie nicht von Kerberos authentisiert wurden. Alle Transaktionen zwischen dem Client und dem Server erfordern die Kerberos-Authentisierung, auch wenn das Dateisystem nicht mit einem Kerberos-Sicherheitsmodus eingehängt wurde.

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 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.

Funktionsweise des Authentisierunssystems

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 Prozeß 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 Prozeß 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 Authentisierungsprozeß 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 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 Paßwort gefragt. Wenn das eingegebene Paßwort mit dem zum Generieren des in der KDC-Datenbank gespeicherten privaten Schlüssels verwendeten Paßworts ü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, muß 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 muß 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

Verwenden der Tabelle für gsscred

Die Tabelle für gsscred wird von einem NFS-Server verwendet, wenn der Server versucht, einen SEAM-Benutzer zu identifizieren. Der NFS-Service verwendet UNIX IDs, um Benutzer zu identifizieren. Diese IDs sind nicht Teil eines Benutzer-Hauptbenutzers oder eines Berechtigungsnachweises. Die Tabelle für gsscred stellt eine Zuordnung der UNIX UIDs (aus der Paßwort-Datei) zu Hauptbenutzernamen bereit. Die Tabelle muß nach dem Füllen der KDC-Datenbank erstellt und verwaltet werden.

Wenn die Anfrage eines Clients eintrifft, versucht der NFS-Service den Hauptbenutzernamen einer UNIX ID zuzuordnen. Wenn die Zuordnung nicht erfolgreich war, wird die Tabelle für gsscred herangezogen. Mit dem Mechanismus kerberos_v5 wird ein root/hostname-Hauptbenutzer automatisch der UID 0 zugeordnet und die Tabelle für gsscred nicht einbezogen. Das bedeutet, daß keine Möglichkeit besteht, spezielle erneute Zuordnungen von root über die Tabelle für gsscred durchzuführen.

Auswählen der Mechanismen für die gsscred-Tabelle

Die Auswahl des richtigen Mechanismusses für die gsscred-Tabelle hängt von verschiedenen Faktoren ab.

• Möchten Sie den Zeitaufwand für die Suche verringern?

• Möchten Sie Sicherheit für den Datenzugriff erhöhen?

• Müssen Sie die Datei schnell erstellen?

Dies ist eine Liste aller Back-End-Mechanismen sowie eine Beschreibung der Vorteile dieser Mechanismen, die ausgewählt werden können.

Dateien

Die Tabelle für gsscred wird in einem Dateisystem gespeichert. Ein lokales, nicht freigegebenes Dateisystem bietet den sichersten Back-End, da die Tabelle nach Erstellung nicht über das Netz übertragen wird. Diese Version der Datei kann am schnellsten erstellt werden.

xfn_files

Die Tabelle für gsscred wird im Dateisystem /var/fn gespeichert. Dieses Dateisystem kann freigegeben werden. Dies muß aber nicht der Fall sein. Alle xfn-Dateien benötigen viel Zeit für ihre Erstellung.

xfn_nis

Die Tabelle für gsscred wird im NIS-Namensbereich gespeichert. Die Suche in diesem Dateisystem ist nicht gesichert. Alle xfn-Dateien benötigen viel Zeit für ihre Erstellung.

xfn_nisplus

Die Tabelle für gsscred wird im NIS+-Namensbereich gespeichert. Die Suche in diesem Dateisystem ist nicht gesichert. Alle xfn-Dateien benötigen viel Zeit für ihre Erstellung.

xfn

Die Tabelle für gsscred wird im Standardsystem für xfn gespeichert. Alle xfn-Dateien benötigen viel Zeit für ihre Erstellung.

Für den Back-End-Mechanismus files (Dateien) kann sich die anfängliche Suche als langsam erweisen. Bei den anderen Mechanismen kann die anfängliche Suche durch Verwendung eines Namen-Service schneller verlaufen. Die Abrufzeit sollte für alle Mechanismen ungefähr gleich sein, nachdem die Daten im Cache gespeichert wurden.