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
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)
Kerberos-spezifische Terminologie
Authentifizierungsspezifische Terminologie
Funktionsweise des Kerberos-Authentifizierungssystems
Interaktion des Kerberos-Service mit DNS und der Datei nsswitch.conf
Erhalten von Zugriff auf einen Service mit Kerberos
Abrufen eines Berechtigungsnachweises für den Ticket-gewährenden Service
Abrufen eines Berechtigungsnachweises für einen Server
Abrufen von Zugriff auf einen bestimmten Service
Wesentliche Unterschiede zwischen Oracle Solaris Kerberos und MIT Kerberos
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)
Verschlüsselungstypen identifizieren, welche kryptografischen Algorithmen bei kryptografischen Vorgängen verwendet werden sollen. Die Verschlüsselungstypen aes , des3-cbc-sha1 und rc4–hmac ermöglichen die Erstellung von Schlüsseln, die für stärkere kryptografische Vorgänge verwendet werden können. Diese stärkeren Vorgänge erhöhen die Gesamtsicherheit des Kerberos-Service.
Hinweis - In Versionen vor &S10Update4 kann der Verschlüsselungstyp aes1-cts-hmac-sha-96 mit dem Kerberos-Service verwendet werden, wenn die ungebündelten Strong Cryptographic-Pakete installiert sind.
Wenn ein Client ein Ticket vom KDC anfordert, muss das KDC Schlüssel verwenden, deren Verschlüsselungstyp sowohl mit dem Client als auch mit dem Server kompatibel ist. Während der Client mithilfe des Kerberos-Protokolls anfordern kann, dass das KDC bestimmte Verschlüsselungstypen für den Teil des Clients verwendet, der sich auf die Ticketantwort bezieht, ermöglicht das Protokoll dem Server nicht, Verschlüsselungstypen für das KDC anzugeben.
Hinweis - Wenn Sie ein Master-KDC installiert haben, das die Version Solaris 10 nicht ausführt, müssen Sie die Slave-KDCs vor der Aktualisierung des Master-KDC auf die Version Solaris 10 aktualisieren. Ein Master-KDC für Solaris 10 verwendet die neuen Verschlüsselungstypen, die von einem älteren Slave nicht verarbeitet werden können.
Nachfolgend werden einige der Probleme aufgeführt, die Sie vor dem Ändern der Verschlüsselungstypen berücksichtigen müssen.
Das KDC geht davon aus, dass der erste dem Server-Hauptelementeintrag in der Hauptelement-Datenbank zugewiesene Schlüssel/Verschlüsselungstyp vom Server unterstützt wird.
Auf dem KDC sollten Sie sicherstellen, dass die für das Hauptelement generierten Schlüssel mit den Systemen kompatibel sind, auf denen das Hauptelement authentifiziert wird. Standardmäßig erstellt der Befehl kadmin Schlüssel für alle unterstützten Verschlüsselungstypen. Wenn die Systeme, auf denen das Hauptelement verwendet wird, diesen Standardsatz von Verschlüsselungstypen nicht unterstützten, sollten Sie die Verschlüsselungstypen beim Erstellen eines Hauptelements einschränken. Sie können die Verschlüsselungstypen unter Verwendung des Flag -e in kadmin addprinc oder durch Festlegen des Parameters supported_enctypes in der Datei kdc.conf auf diese Teilmenge beschränken. Der Parameter supported_enctypes sollte verwendet werden, wenn die meisten Systeme in einem Kerberos-Bereich eine Teilmenge des Standardsatzes von Verschlüsselungstypen unterstützen. Durch Festlegen von supported_enctypes wird der Standardsatz von Verschlüsselungstypen angegeben, den kadmin addprinc bei der Erstellung eines Hauptelements für einen bestimmten Bereich verwendet. In der Regel eignen sich diese beiden Methoden am besten zum Festlegen der von Kerberos verwendeten Verschlüsselungstypen.
Beim Bestimmen der von einem System unterstützten Verschlüsselungstypen müssen Sie sowohl die auf dem System ausgeführte Version von Kerberos als auch die kryptografischen Algorithmen berücksichtigen, die von der Serveranwendung unterstützt werden, für die ein Server-Hauptelement erstellt wird. So sollten Sie z. B. beim Erstellen eines nfs/hostname-Service-Hauptelements die Verschlüsselungstypen auf die von dem NFS-Server auf diesem Host unterstützten Typen beschränken. Beachten Sie, dass in der Version Solaris 10 alle unterstützten Kerberos-Verschlüsselungstypen auch vom NFS-Server unterstützt werden.
Mithilfe des Parameters master_key_enctype in der Datei kdc.conf kann der Verschlüsselungstyp des Master-Schlüssels festgelegt werden, der die Einträge in der Hauptelement-Datenbank verschlüsselt. Verwenden Sie diesen Parameter nicht, wenn die KDC-Hauptelement-Datenbank bereits erstellt wurde. Mit dem Parameter master_key_enctype kann während der Erstellung der Datenbank der standardmäßige Verschlüsselungstyp des Master-Schlüssels des-cbc-crc in einen stärkeren Verschlüsselungstyp geändert werden. Stellen Sie beim Konfigurieren der Slave-KDCs sicher, dass alle Slave-KDCs den ausgewählten Verschlüsselungstyp unterstützen und denselben Eintrag für master_key_enctype in kdc.conf aufweisen. Vergewissern Sie sich außerdem, dass für master_key_enctype einer der Verschlüsselungstypen in supported_enctypes angegeben ist, wenn supported_enctypes in kdc.conf festgelegt ist. Eine falsche Vorgehensweise bezüglich dieser Punkte kann zur Folge haben, dass das Master-KDC nicht mit den Slave-KDCs funktioniert.
Auf dem Client können Sie festlegen, welche Verschlüsselungstypen der Client anfordert, wenn er Tickets vom KDC durch ein Parameterpaar in krb5.conf erhält. Der Parameter default_tkt_enctypes gibt die Verschlüsselungstypen an, die der Client vorzugsweise beim Anfordern eines TGT (Ticket-gewährendes Ticket) vom KDC verwendet. Das TGT wird vom Client verwendet, um weitere Servertickets auf effizientere Weise zu erhalten. Durch Festlegen von default_tkt_enctypes erhält der Client eine gewisse Kontrolle über die zum Schutz der Kommunikation zwischen Client und KDC verwendeten Verschlüsselungstypen, wenn er mit dem TGT ein Serverticket anfordert (in diesem Fall spricht man von einer TGS-Anforderung). Bedenken Sie, dass die in default_tkt_enctypes angegebenen Verschlüsselungstypen mit mindestens einem der Verschlüsselungstypen für Hauptelementschlüssel in der auf dem KDC gespeicherten Hauptelement-Datenbank übereinstimmen müssen. Andernfalls schlägt die TGT-Anforderung fehl. In den meisten Fällen empfiehlt es sich, default_tkt_enctypes nicht festzulegen, da dieser Parameter Interoperabilitätsprobleme nach sich ziehen kann. Standardmäßig fordert der Clientcode alle unterstützten Verschlüsselungstypen an und das KDC wählt die Verschlüsselungstypen basierend auf den Schlüsseln, die es in der Hauptelement-Datenbank auffindet.
Der Parameter default_tgs_enctypes beschränkt die von den Clients in TGS-Anforderungen angeforderten Verschlüsselungstypen, mit denen Servertickets erhalten werden. Dieser Parameter schränkt ebenfalls die Verschlüsselungstypen ein, die das KDC beim Erstellen des Sitzungsschlüssels verwendet, den Client und Server gemeinsam nutzen. Wenn ein Client beispielsweise 3DES-Verschlüsselung nur bei sicherem NFS verwenden möchte, sollten Sie default_tgs_enctypes = des3-cbc-sha1 festlegen. Stellen Sie sicher, dass die Client- und Server-Hauptelemente über einen des-3-cbc-sha1-Schlüssel in der Hauptelement-Datenbank verfügen. Ebenso wie bei default_tkt_enctype empfiehlt es sich meistens, den Parameter nicht festzulegen, da es zu Interoperabilitätsproblemen kommen kann, wenn die Berechtigungsnachweise auf KDC und Server nicht ordnungsgemäß eingerichtet sind.
Auf dem Server können Sie die akzeptierten Verschlüsselungstypen mit permitted_enctypes in kdc.conf festlegen. Außerdem können Sie die bei der Erstellung von keytab-Einträgen verwendeten Verschlüsselungstypen angeben. Auch hier ist es in den meisten Fällen besser, keine der beiden Methoden zum Festlegen der Verschlüsselungstypen zu verwenden, sondern stattdessen die zu verwendeten Verschlüsselungstypen vom KDC bestimmen zu lassen, da das KDC nicht mit der Serveranwendung kommuniziert, um den zu verwendenden Schlüssel oder Verschlüsselungstyp zu bestimmen.