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)
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)
19. Verwenden von Oracle Solaris Secure Shell (Aufgaben)
20. Oracle Solaris Secure Shell (Referenz)
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 Komponenten verschiedener Kerberos-Versionen
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
Kerberos-Komponenten in der Version Solaris 8
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)
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.
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
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.
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.
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.
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
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.
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.
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.
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-basierten bzw. kerberisierte Befehle, die ein Benutzer wie z. B. joe verwenden kann, sind Folgende:
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
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.
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:
joe ist der primäre Name. Der primäre Name kann wie in diesem Fall ein Benutzername oder ein Service wie z. B. nfs sein. Der primäre Name kann auch durch das Wort host dargestellt werden, was bedeutet, dass es sich bei diesem Hauptelement um ein Service-Hauptelement handelt, das verschiedene Netzwerkdienste bereitstellt (ftp, rcp, rlogin und so weiter).
admin ist die Instanz. Bei Benutzer-Hauptelementen ist eine Instanz optional, für Service-Hauptelemente ist sie dagegen erforderlich. Beispiel: Wenn der Benutzer joe gelegentlich als Systemadministrator fungiert, kann er sich mithilfe von joe/admin von seiner üblichen Identität als Benutzer unterscheiden. Ebenso kann joe , wenn er über Konten auf zwei verschiedenen Hosts verfügt, zwei Hauptelementnamen mit unterschiedlichen Instanzen verwenden, z. B. joe/denver.example.com und joe/boston.example.com. Beachten Sie, dass der Kerberos-Service joe und joe/admin wie zwei vollständig verschiedene Hauptelemente behandelt.
Bei Service-Hauptelementen ist die Instanz der voll qualifizierte Hostname. bigmachine.eng.example.com ist ein Beispiel für eine derartige Instanz. Der primäre Name bzw. die Instanz für dieses Beispiel könnte ftp/bigmachine.eng.example.com oder host/bigmachine.eng.example.com sein.
ENG.EXAMPLE.COM ist der Kerberos-Bereich. Informationen zu Bereichen finden Sie unter Kerberos-Bereiche.
Folgende Namen sind gültige Hauptelementnamen:
joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
nfs/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM
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
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