Nachdem im vorangegangenen Teil der Serie auf die grundlegenden Aspekte zur Konfigurationsdatei krb5.conf eingegangen wurde, liegt der Schwerpunkt in diesem Teil auf den beiden Befehlszeilen-Werkzeugen für die Konfiguration. Der iManager wird nur am Rande behandelt. Das liegt daran, dass es in der getesteten Konstellation von OES, iManager und den Plug-Ins für den Kerberos KDC (Key Distribution Center) einige Probleme gab.
Die Plug-Ins waren zwar lauffähig, allerdings war die Anzeige doch in wichtigen Teilen unvollständig. Daher sollte man den Schwerpunkt bei der Nutzung zunächst auf die beiden „klassischen“ Werkzeuge legen, die sich in dieser oder ähnlicher Form auch bei den meisten anderen Kerberos-Implementierungen finden.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
Das Management von Realms
Realms sind die einzelnen Bereiche, die bei Kerberos nutzt, sie lassen sich mit den Domänen im Active Directory vergleichen. Der erste Konfigurationsschritt bei der Einrichtung eines KDC ist die Erstellung eines solchen Realms. Bei Verwendung von kbd5_util wird dazu die Anweisung create verwendet. Diese ist relativ komplex, in der Dokumentation des Novell Kerberos KDC aber umfassend beschrieben.
Wichtige Parameter für die Erstellung eines Realms sind:
-
sscope: Der Bereich, in dem Principals – also die Benutzer – unterhalb des angegebenen Teilbaums gesucht werden. Es gibt die möglichen Werte 1 und 2, wobei mit 2 alle Zweige des Teilbaums durchsucht werden, mit 1 dagegen nur eine Ebene.
-
kdcdn: Liste der „distinguished names“, also der eindeutigen beschreibenden Namen der Systeme, die den KDC-Dienst für diesen Realm bereitstellen.
-
enctypes: Die Verschlüsselungstypen, die von diesem KDC unterstützt werden.
-
defenctype: Der Standardtyp für die Verschlüsselung.
-
salttypes: Die unterstützten Typen des „Salts“, also der zusätzlich für die Verschlüsselung von Informationen verwendeten Werte, die im Klartext ausgetauscht werden.
-
policy: Verweis auf den Distinguished Name eines Richtlinien-Objekts, das verwendet werden soll.
Alternative iManager
Die Alternative dazu ist die Verwendung des Novell iManager (Bild 1). Dort findet sich der Befehl CreateRealm, der eigentlich als New Realm angezeigt werden sollte. Er ist wie alle diese Befehle unterhalb von Kerberos Management angesiedelt. Das Bild 1 macht allerdings deutlich, dass durch die Einschränkungen in der Oberfläche eine Nutzung nur schwer möglich ist.
Weitere Funktionen für das Management der Realms sind die Optionen
-
modify für die Veränderung bestehender Realms
-
view für die Anzeige von Detailinformationen zu einem spezifischen Realm
-
destroy für das Löschen eines Realms
-
list für die Aufzählung von Realms
Auch hier gilt, wie schon bei create, dass die meisten der Anweisungen eine sehr umfassende und komplexe Syntax aufweisen, die in der Dokumentation aber umfassend erläutert ist.
Das Management von Diensten
Der zweite wichtige Aufgabenbereich bei der Verwaltung ist das Management der Diente. Hier werden insgesamt drei Dienste unterschieden:
-
Der KDC selbst;
-
Der Administrationsdienst, über den Konfigurationsänderungen vorgenommen werden;
-
Der Password-Dienst für die Durchführung von Kennwortänderungen.
Diese Dienste sind also nicht zu verwechseln mit den Diensten, für die eine Kerberos-Authentifizierung über Session Tickets erfolgen kann. Vielmehr handelt es sich um die Kerndienste der Kerberos-Infrastruktur. Sie werden ebenso wie Realms mit dem Werkzeug kdb5_util verwaltet.
Es gibt auch hier wieder verschiedene Optionen. Mit create_service lassen sich zusätzliche Instanzen von Diensten erstellen. So kann beispielsweise ein neuer KDC erzeugt werden, um die Last der Authentifizierung auf mehrere Server zu verteilen. Auch von den anderen Diensten lassen sich für die Lastverteilung und Fehlertoleranz zusätzliche Instanzen erzeugen. Da die von den Diensten verwendeten Daten zum überwiegenden Teil im eDirectory abgelegt sind, ist der Aufbau entsprechend skalierbarer und verfügbarer Infrastrukturen relativ leicht machbar – immerhin sind alle Komponenten weitgehend redundant verfügbar.
Weitere Parameter sind modify_service für das Ändern von Diensteinstellungen, view_service zum Anzeigen der Einstellungen für einen spezifizierten Dienst, list_service für eine Liste der Dienste und destroy_service zum Löschen.
Außerdem gibt es noch die Anweisung setsrvpw, mit der sich das Kennwort für jeden einzelnen Dienst konfigurieren lässt. Dieses schützt die Dienste zusätzlich zur Authentifizierung auf Systemebene. Da die Kerberos KDCs ein zentrales Element der Sicherheitsinfrastruktur von Netzwerken sind, ist dieser Schutz unverzichtbar.
Das Management von Principals
Die nächste Aufgabe ist die Verwaltung von Principals. Diese erfolgt mit kadmin. Dabei geht es weniger um die Benutzer als vielmehr um die Dienste. Bei Benutzern geht es nur darum, die Verbindung zwischen einem bereits vorhandenen eDirectory-Benutzerobjekt und der Kerberos-Infrastruktur herzustellen. Das Mapping erfolgt mit der Option add_principal. Gerade hier bietet es sich an, mit der Befehlszeile zu arbeiten, um die Erstellung von Kerberos-Principals für vorhandene Benutzer in einer Batch-Datei durchzuführen.
Die zweite Herausforderung ist die Erstellung von Service-Principals. Jeder Dienst, an dem eine Kerberos-Authentifizierung durchgeführt werden soll, benötigt einen solchen Service-Principal, der explizit erstellt sein muss.
Bei der Erstellung von Principals oder zu einem späteren Zeitpunkt können diesen auch Ticket-Richtlinien zugeordnet werden. Auf diese wird später im Artikel noch eingegangen.
Weitere Befehle für das Management von Principals sind:
-
modify_principal für Änderungen an den Einstellungen zu einem Principal;
-
delete_principal zum Löschen. Benutzer im eDirectory werden dadurch nicht gelöscht;
-
list_principals zur Anzeige einer Liste der Principals;
-
change_password für die Durchführung von Kennwortänderungen bei Principals. Damit kann das Kennwort auch erstmalig gesetzt werden.
Wichtig ist außerdem für einige Funktionen das Auslesen von Principal-Informationen in eine so genannte Keytab-Datei. Dazu wird die Option ktadd verwendet. Diese Dateien werden beispielsweise für den Aufbau von Vertrauensstellungen zwischen Realms – auch im heterogenen Umfeld – benötigt.
Das Management von Ticket-Richtlinien
Eine weitere wichtige Funktion sind die Ticket-Richtlinien. Diese können, wie oben angedeutet, einzelnen Principals zugeordnet werden. In der Regel wird man sie aber Realms oder Containern zuweisen, um keine Einzelzuweisungen vornehmen zu müssen.
Die Konfiguration erfolgt mit dem Utility kbd5_util. Die wichtigsten Einstellungen innerhalb der Richtlinie beziehen sich auf die Lebensdauer von Tickets. Standardwerte dafür sind zehn Stunden für Tickets und sieben Tage für die Erneuerung von Tickets. In der Regel ist es nicht erforderlich, mehr als eine Standardrichtlinie zu erstellen.
Das Management von Kennwort-Richtlinien
Schließlich gibt es noch Kennwortrichtlinien. Diese werden über kadmin verwaltet. Es handelt sich dabei um eine im Vergleich mit der MIT-Implementierung angepasste Funktionalität, weil diese nun mit einem LDAP-Verzeichnis zusammen funktionieren muss.
In der Regel sind solche Richtlinien allerdings nicht erforderlich, weil sie nur wirksam sind, falls sich die Kerberos-Passwörter von den eDirectory-Kennwörtern unterscheiden. Einzig für Service-Kennwörter kann eine Anpassung daher Sinn machen. Falls erforderlich, lassen sich in Richtlinien Einstellungen wie die Lebensdauer von Kennwörtern und ihre Länge modifizieren.
Fazit
Die Verwaltung des Kerberos KDC ist mit den verschiedenen Befehlen zwar nicht einfach, mit etwas Vorbereitung aber relativ gut zu bewerkstelligen. Dennoch muss man sich überlegen, ob man einen Kerberos KDC in einer Infrastruktur überhaupt benötigt.
Das ist nur erforderlich, falls man Kerberos als Authentifizierungsmechanismus einsetzen muss, um eine einheitliche Authentifizierung über Plattformgrenzen hinweg zu erreichen. In vielen Fällen kann man aber auch andere, einfacher einsetzbare und ausgereiftere Dienste von Novell verwenden, um ein vergleichbares Ergebnis zu erzielen. (mja)
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |