JavaScript is required to for searching.
Navigationslinks �berspringen
Druckansicht beenden
Systemverwaltungshandbuch: Sicherheitsservices
search filter icon
search icon

Dokument-Informationen

Vorwort

Teil I Übersicht über die Sicherheit

1.  Sicherheitsservices (Überblick)

Teil II System-, Datei- und Gerätesicherheit

2.  Verwalten von Rechnersicherheit (Übersicht)

3.  Steuern des Zugriffs auf Systeme (Aufgaben)

4.  Steuern des Zugriffs auf Geräte (Aufgaben)

5.  Verwenden von Basic Audit Reporting Tool (Aufgaben)

6.  Steuern des Zugriffs auf Dateien (Aufgaben)

7.  Verwenden von Automated Security Enhancement Tool (Aufgaben)

Teil III Rollen, Berechtigungsprofile und Berechtigungen

8.  Verwenden von Rollen und Berechtigungen (Übersicht)

9.  Rollenbasierte Zugriffssteuerung (Aufgaben)

10.  Rollenbasierte Zugriffssteuerung (Übersicht)

11.  Berechtigungen (Aufgaben)

12.  Berechtigungen (Referenz)

Teil IV Kryptografische Services

13.  Oracle Solaris Cryptographic Framework (Übersicht)

14.  Oracle Solaris Cryptographic Framework (Aufgaben)

15.  Oracle Solaris Key Management Framework

Teil V Authentifizierungsservices und sichere Kommunikation

16.  Verwenden von Authentifizierungsservices (Aufgaben)

17.  Verwenden von PAM

18.  Verwenden von SASL

19.  Verwenden von Oracle Solaris Secure Shell (Aufgaben)

20.  Oracle Solaris Secure Shell (Referenz)

Teil VI Kerberos-Service

21.  Einführung zum Kerberos-Service

Allgemeine Informationen zum Kerberos-Service

Funktionsweise des Kerberos-Service

Erstauthentifizierung: das Ticket-gewährende Ticket

Nachfolgende Kerberos-Authentifizierungen

Die Kerberos-Remote-Anwendungen

Kerberos-Hauptelemente

Kerberos-Bereiche

Kerberos-Server

Kerberos-Sicherheitsservices

Die Komponenten verschiedener Kerberos-Versionen

Kerberos-Komponenten

Kerberos-Ergänzungen für die Version Solaris 10 5/08

Kerberos-Ergänzungen für die Version Solaris 10 8/07

Kerberos-Ergänzungen für die Version Solaris 10 6/06

Kerberos-Erweiterungen in der Version Solaris 10 3/05

Kerberos-Komponenten in der Version Solaris 9

SEAM 1.0.2-Komponenten

Kerberos-Komponenten in der Version Solaris 8

SEAM 1.0.1-Komponenten

SEAM 1.0-Komponenten

22.  Planen des Kerberos-Service

23.  Konfigurieren des Kerberos-Service (Aufgaben)

24.  Kerberos-Fehlermeldungen und -Fehlerbehebung

25.  Verwalten von Kerberos-Hauptelementen und Richtlinien (Aufgaben)

26.  Verwenden von Kerberos-Anwendungen (Aufgaben)

27.  Der Kerberos-Service (Referenz)

Teil VII Prüfung bei Oracle Solaris

28.  Prüfung bei Oracle Solaris (Übersicht)

29.  Planen der Oracle Solaris-Prüfung

30.  Verwalten der Oracle Solaris-Prüfung (Aufgaben)

31.  Prüfung bei Oracle Solaris (Referenz)

Glossar

Index

Funktionsweise des Kerberos-Service

Im Folgenden ist eine Übersicht des Kerberos-Authentifizierungssystems aufgeführt. Eine detailliertere Beschreibung finden Sie unter Funktionsweise des Kerberos-Authentifizierungssystems.

Für den Benutzer ist der Kerberos-Service nach dem Starten der Kerberos-Sitzung weitgehend unsichtbar. Bei Befehlen wie rsh oder ftp verhält es sich ähnlich. Das Initialisieren einer Kerberos-Sitzung umfasst häufig nur eine Anmeldung und die Angabe eines Kerberos-Passworts.

Das Konzept eines Tickets bildet den Mittelpunkt des Kerberos-Systems. Bei einem Ticket handelt es sich um einen Satz elektronischer Informationen, die einen Benutzer oder einen Service wie z. B. den NFS-Service identifizieren. Ein Ticket identifiziert Sie und Ihre Netzwerkzugriffsberechtigungen. Dies ist vergleichbar mit einem Führerschein, der Sie ebenfalls identifiziert und angibt, welche Fahrzeuge Sie fahren dürfen. Beim Ausführen einer Kerberos-basierten Transaktion (beispielsweise einer Remote-Anmeldung bei einem anderen Rechner) senden Sie transparent eine Anforderung für ein Ticket an ein Key Distribution Center oder KDC. Das KDC greift auf eine Datenbank zu, um Ihre Identität zu authentifizieren, und gibt ein Ticket zurück, das Sie für den Zugriff auf den anderen Rechner berechtigt. "Transparent" bedeutet, dass Sie ein Ticket nicht explizit anfordern müssen. Die Anforderung erfolgt über den Befehl rlogin. Da nur ein authentifizierter Client ein Ticket für einen bestimmten Service erhalten kann, kann kein anderer Benutzer rlogin unter einer angenommenen Identität verwenden.

Tickets sind bestimmte Attribute zugewiesen. Ein Ticket kann beispielsweise weiterleitbar sein, d. h. es kann auf einem anderen Rechner verwendet werden, ohne dass ein neuer Authentifizierungsvorgang erforderlich ist. Ebenfalls kann ein Ticket nachdatiert sein, was bedeutet, dass es erst nach einer bestimmten Zeit gültig ist. Die Art der Verwendung von Tickets (beispielsweise zur Angabe, welche Benutzer welche Arten von Tickets erhalten dürfen) wird von Richtlinien bestimmt. Richtlinien werden bei der Installation oder Verwaltung des Kerberos-Service festgelegt.


Hinweis - Die Begriffe Berechtigungsnachweis und Ticket kommen im Folgenden sehr häufig vor. In Bezug auf Kerberos werden diese Begriffe häufig synonym verwendet. Technisch gesehen entspricht ein Berechtigungsnachweis jedoch einem Ticket und dem Sitzungsschlüssel für die entsprechende Sitzung. Dieser Unterschied wird unter Erhalten von Zugriff auf einen Service mit Kerberos im Detail erläutert.


In den folgenden Abschnitten wird näher auf den Kerberos-Authentifizierungsprozess eingegangen.

Erstauthentifizierung: das Ticket-gewährende Ticket

Die Kerberos-Authentifizierung umfasst zwei Phasen: eine Erstauthentifizierung, die alle nachfolgenden Authentifizierungen ermöglicht, und die nachfolgenden Authentifizierungen selbst.

Die folgende Abbildung zeigt den Vorgang der Erstauthentifizierung.

Abbildung 21-1 Erstauthentifizierung für eine Kerberos-Sitzung

image:Das Ablaufdiagramm stellt einen Client dar, der ein TGT vom KDC anfordert und anschließend das TGT verschlüsselt, das das KDC an den Client zurückgibt.
  1. Ein Client (ein Benutzer oder ein Service wie NFS) beginnt eine Kerberos-Session durch Anfordern eines Ticket-gewährenden Tickets (TGT) vom Key Distribution Center (KDC). Diese Anforderung erfolgt häufig automatisch bei der Anmeldung.

    Ein Ticket-gewährendes Ticket ist erforderlich, um andere Tickets für bestimmte Services zu erhalten. Das Ticket-gewährende Ticket lässt sich mit einem Pass vergleichen. Wie ein Pass identifiziert das Ticket-gewährende Ticket Sie und ermöglicht Ihnen, zahlreiche "Visa" zu erhalten, wobei die "Visa" (Tickets) hier nicht für andere Länder, sondern für Remote-Rechner oder Netzwerkdienste bestimmt sind. Ebenso wie Pässe und Visa sind das Ticket-gewährende Ticket und die anderen Tickets nur für eine begrenzte Zeit gültig. Der Unterschied besteht darin, dass "kerberisierte" Befehle erkennen, dass Sie über einen Pass verfügen, und die Visa für Sie besorgen. Sie müssen die Transaktionen nicht selbst ausführen.

    Weiterhin ist das Ticket-gewährende Ticket mit einem dreitägigen Skipass vergleichbar, der für vier verschiedene Skistationen gültig ist. Sie zeigen den Pass bei einer der Skistationen vor und erhalten für diese Station ein Liftticket, solange der Pass noch nicht abgelaufen ist. Sobald Sie das Liftticket erhalten haben, können Sie diese Station zum Skifahren nutzen. Wenn Sie am nächsten Tag zu einer anderen Skistation gehen und dort erneut Ihren Pass vorzeigen, bekommen Sie ein weiteres Liftticket für jene Station. Der Unterschied liegt darin, dass die Kerberos-basierten Befehle erkennen, dass Sie über einen Wochenend-Skipass verfügen, und das Liftticket für Sie besorgen. Dies bedeutet abermals, dass Sie die Transaktionen nicht selbst ausführen müssen.

  2. Das KDC erstellt ein Ticket-gewährendes Ticket und sendet es in verschlüsselter Form an den Client zurück. Der Client entschlüsselt das Ticket-gewährende Ticket unter Verwendung des Passworts des Clients.

  3. Da der Client jetzt über ein Ticket-gewährendes Ticket verfügt, kann er Tickets für alle Arten von Netzwerkvorgängen wie etwa rlogin oder telnet anfordern, bis das Ticket-gewährende Ticket abläuft. Die Lebensdauer dieses Tickets beträgt normalerweise ein paar Stunden. Jedes Mal, wenn der Client einen eindeutigen Netzwerkvorgang ausführt, fordert er ein Ticket für diesen Vorgang vom KDC an.

Nachfolgende Kerberos-Authentifizierungen

Nachdem der Client die Erstauthentifizierung erhalten hat, läuft jede nachfolgende Authentifizierung nach dem in der folgenden Abbildung dargestellten Muster ab.

Abbildung 21-2 Erhalten von Zugriff auf einen Service mit Kerberos-Authentifizierung

image:Das Ablaufdiagramm zeigt den Client, der mit einem TGT ein Ticket vom KDC anfordert und anschließend mithilfe des zurückgegebenen Tickets auf den Server zugreift.
  1. Der Client fordert vom KDC ein Ticket für einen bestimmten Service an, um z. B. entfernt auf einen anderen Rechner zuzugreifen, indem er sein Ticket-gewährendes Ticket als Identitätsnachweis an das KDC sendet.

  2. Das KDC sendet das Ticket für den bestimmten Service an den Client zurück.

    Beispiel: Der Benutzer joe möchte auf ein freigegebenes NFS-Dateisystem zugreifen, für das krb5-Authentifizierung erforderlich ist. Da er zum Zeitpunkt des Zugriffs auf die Dateien bereits authentifiziert ist (d. h. bereits über ein Ticket-gewährendes Ticket verfügt), ruft das NFS-Clientsystem automatisch und transparent ein Ticket vom KDC für den NFS-Service ab.

    Beispiel: Der Benutzer joe verwendet rlogin auf dem Server boston. Da er bereits authentifiziert ist (d. h. bereits über ein Ticket-gewährendes Ticket verfügt), erhält er über den Befehl rlogin automatisch und transparent ein Ticket. Mit diesem Ticket kann er sich beliebig oft entfernt bei boston anmelden, bis das Ticket abläuft. Wenn joe sich entfernt beim Rechner denver anmelden möchte, erhält er ein anderes Ticket, wie in Schritt 1 beschrieben.

  3. Der Client sendet das Ticket an den Server.

    Wenn der NFS-Service verwendet wird, sendet der NFS-Client das Ticket für den NFS-Service automatisch und transparent an den NFS-Server.

  4. Der Server erteilt dem Client Zugriff.

Diese Schritte erwecken den Anschein, dass der Server zu keiner Zeit mit dem KDC kommuniziert. Dies tut er jedoch, indem er sich wie der erste Client beim KDC registriert. Der Einfachheit halber wurde dieser Teil ausgelassen.

Die Kerberos-Remote-Anwendungen

Die Kerberos-basierten bzw. kerberisierte Befehle, die ein Benutzer wie z. B. joe verwenden kann, sind Folgende:

Diese Anwendungen sind dieselben wie die gleichnamigen Solaris-Anwendungen. Sie wurden jedoch dahingehend erweitert, dass sie Kerberos-Hauptelemente zur Authentifizierung von Transaktionen verwenden und dadurch Kerberos-basierte Sicherheit bieten. Informationen zu Hauptelementen finden Sie unter Kerberos-Hauptelemente.

Weitere Informationen zu diesen Befehlen erhalten Sie unter Kerberos-Benutzerbefehle.

Kerberos-Hauptelemente

Ein Client im Kerberos-Service wird durch sein Hauptelement identifiziert. Ein Hauptelement stellt eine eindeutige Identität dar, der das KDC Tickets zuweisen kann. Bei einem Hauptelement kann es sich um einen Benutzer, wie beispielsweise joe, oder einen Service wie nfs oder telnet handeln.

Üblicherweise wird ein Hauptelementname in drei Komponenten aufgeteilt: den primären Namen, die Instanz und den Bereich. Ein typisches Kerberos-Hauptelement ist beispielsweise joe/admin@ENG.EXAMPLE.COM. In diesem Beispiel gilt Folgendes:

Folgende Namen sind gültige Hauptelementnamen:

Kerberos-Bereiche

Ein Bereich ist ein logisches Netzwerk (ähnlich einer Domain), das eine Gruppe von Systemen unter dem Namen Master-KDC definiert. Abbildung 21-3 zeigt die möglichen Beziehungen zwischen Bereichen. Einige Bereiche sind hierarchisch, wobei ein Bereich eine Obergruppe des anderen Bereichs darstellt. Andernfalls sind die Bereiche nicht hierarchisch (oder auch "direkt") und die Zuordnung zwischen den beiden Bereichen muss definiert werden. Eine Funktion des Kerberos-Service besteht in der bereichsübergreifenden Erteilung von Authentifizierung. Jeder Bereich erfordert lediglich einen Hauptelementeintrag für den anderen Bereich im dazugehörigen KDC. Diese Kerberos-Funktion nennt sich bereichsübergreifende Authentifizierung.

Abbildung 21-3 Kerberos-Bereiche

image:Das Diagramm zeigt den Bereich ENG.EXAMPLE.COM in einer nicht hierarchischen Beziehung mit SEAMCO.COM und in einer hierarchischen Beziehung mit EXAMPLE.COM.

Kerberos-Server

Jeder Bereich muss einen Server zur Verwaltung der Masterkopie der Hauptelement-Datenbank umfassen. Dieser Server wird als der Master-KDC-Server bezeichnet. Außerdem sollte in jedem Bereich mindestens ein Slave-KDC-Server vorhanden sein, der doppelte Kopien der Hauptelement-Datenbank enthält. Sowohl der Master- als auch der Slave-KDC-Server erstellen Tickets zum Einrichten einer Authentifizierung.

Der Bereich kann auch einen Kerberos-Anwendungsserver umfassen. Dieser Server bietet Zugriff auf kerberisierte Services (wie z. B. ftp, telnet, rsh und NFS). Wenn Sie SEAM 1.0 oder 1.0.1 installiert haben, kann der Bereich einen Kerberos-Netzwerkanwendungsserver umfassen. Diese Software wurde jedoch nicht mit diesen Versionen mitgeliefert.

Die folgende Abbildung zeigt, was ein hypothetischer Bereich umfassen kann.

Abbildung 21-4 Ein typischer Kerberos-Bereich

image:Das Diagramm zeigt einen typischen Kerberos-Bereich, EXAMPLE.COM, der ein Master-KDC, drei Clients, zwei Slave-KDCs und zwei Anwendungsserver umfasst.