| | Start » Informationen » Themen » Kerberos 5

Kerberos 5

DFN-CERT, März 2003

1 Einleitung

Einführung in Kerberos 5 und seine häufigsten Anwendungsgebiete auf Unix-ähnlichen Systemen. Es wird ein grundlegendes Verständnis der Funktionsweise und der Mechanismen vermittelt. Der Leser sollte danach in der Lage sein, eine einfache Kerberos 5-Installation einzurichten. Kenntnisse und Erfahrungen in der Administration von Unix-ähnlichen Systemen werden vorausgesetzt.

Die Vorgängerversion Kerberos 4 wird nicht im Einzelnen behandelt, es werden lediglich Unterschiede zwischen den beiden Versionen aufgezeigt, wo dies nützlich erscheint.

Der vorliegende Text soll bei der Entscheidung helfen, ob ein Kerberos 5-System eingesetzt wird. Es wird nicht empfohlen, allein aufgrund dieser Arbeit Kerberos 5 zur Verwendung auf einem Produktionssystem zu installieren. Hinweise zum weiterführenden Studium werden im Text gegeben.

1.1 Glossar

Authentifizierung (auch Authentisierung):

In der Datenverarbeitung: Feststellen, dass ein Principal für die Zwecke der EDV derjenige ist, der er vorgibt zu sein. Dies passiert meist mit Hilfe eines geheimen Schlüssels.

Authentikator

Ein zusätzliche Legitimation, die bei Kerberos zusammen mit einem Ticket präsentiert wird, um sich zu authentisieren. Authentikatoren können nur einmal verwendet werden. Da mit dem Authentikator auch das Ticket präsentiert wird, redet dieser Text der Einfachheit halber nur von Tickets.

Autorisierung:

Die Vergabe von Rechten (z.B. Dateizugriff) an einen Principal.

KDC:

"Key Distribution Center", der Kerberos-Server, welcher die Kerberos-Tickets verteilt.

Kerberos:

Zum einen das Netzwerkprotokoll, mit dem Ticketanfragen an den Kerberos-Dienst gestellt und beantwortet werden, zum anderen besagter Kerberos-Dienst, der auf einem dedizierten Hostrechner läuft¹. Der Kerberos-Dienst ist ein Server, der die Identität von Principals überprüft und Tickets vergibt.

PAM

"Pluggable Authentication Modules", modulares System von dynamischen Programmbibliotheken zur Authentifizierung. Wird auf den meisten modernen Unix-ähnlichen Systemen verwendet.

Principal:

Ein Benutzer, ein Host oder ein Netzwerkdienst. "Principals" werden in der Kerberos Datenbank verwaltet.

Der volle Name eines Principals hat folgende Struktur:

 

    primary/instance@REALM
  

Zum vollen Namen eines Principals gehört der so genannte primary (dt. "primär"), der in der Regeln dem Benutzernamen oder Diensttyp entspricht, die instance (dt. "Instanz"), die etwa der Rolle entspricht, die ein Benutzer einnimmt, aber auch z.B. einen Dienst- oder Hostnamen enthalten oder leer sein kann² und schließlich das Kerberos 5-Realm.

Ein denkbarer Name für einen Principal wäre also z.B. testuser/admin@KERBEROS.TEST, der sich aufschlüsselt zu primary: testuser, instance: admin, Realm: KERBEROS.TEST.

Es ist denkbar, dass der Benutzer testuser mit diesem Principal Aufgaben der Benutzeradministration (der Kerberos 5 Datenbank) wahrnimmt.

Realm

Mehrere Hosts, die unter gemeinsamer Administration stehen und auf denen die gleichen Principals verfügbar sind, gehören zu einem "Kerberos 5-Realm". Es wird empfohlen, dass der Domainname aller Hosts im Realm und der Name des "Realm" ein gemeinsames Suffix haben sollen. Zur Domain "kerberos.test" würde dann z.B. das Kerberos-Realm KERBEROS.TEST gehören. Realm heisst im Deutschen etwa Bereich oder Gebiet.

Schlüssel, geheimer:

Ein geheimer Schlüssel ist mindestens zwei Instanzen bekannt. Im Falle von Kerberos ist die Passphrase eines Principals in der Kerberos 5-Datenbank abgespeichert und dem Benutzer bekannt.

Schlüssel, privater:

Ein Schlüssel, der nur einer Instanz (z.B. einer Person) bekannt ist. Wird bei "Public-Key"-Verfahren mit einem dazugehörigen öffentlichen Schlüssel verwendet.

TGT

"Ticket Granting Ticket", das erste Ticket, welches vom Kerberos-Server angefordert und benötigt wird, um weitere Authentisierung zu erhalten.

Ticket

Hier: Eine elektronische Form der Legitimation, die dazu dient, die Identität eines Klienten gegenüber einem bestimmten Netzwerkdienst zu verifizieren.

1.2 Typografische Konventionen

In diesem Informationsbulletin werden folgende Schriftarten verwendet.

2 Was ist Kerberos?

Kerberos bietet sichere und einheitliche Authentisierung in einem ungesicherten TCP/IP Netzwerk aus sicheren Hostrechnern. Die Authentisierung übernimmt eine "vertrauenswürdige dritte Partei". Diese dritte Partei ist ein besonders geschützter Kerberos 5-Netzwerkdienst.

Durch Kerberos werden insbesondere Angriffe durch passives "Sniffing" unterbunden, aber auch "Spoofing", "Dictionary Attacks", "Replay" und andere Angriffe werden erschwert.

2.1 Funktionsweise

In der Regel gibt es eine physikalisch geschützte Maschine, auf der ein Kerberos-Dienst (und nichts anderes³) läuft, auf den Klienten und Server zur Authentifizierung zurückgreifen.

In einem ersten Schritt fragt ein "Principal" (z.B. der Benutzer an einer Workstation) den Kerberos-Dienst nach einem Ticket für einen so genannten "Ticket Granting Service" (TGS). Dieses Ticket wird mit dem geheimen Schlüssel des Principals verschlüsselt. Da der geheime Schlüssel nicht auf der Workstation des Principals gespeichert ist, muss er den geheimen Schlüssel eingeben, um das Ticket zu verwenden. Dies kann per Tastatureingabe, oder z.B. mit einer Smartcard geschehen.

Zu keiner Zeit wird dabei ein Passwort im Klartext über das Netz gesandt.

Wenn der Benutzer nun die Autorisierung erhalten möchte, einen Netzwerkdienst (z.B. "telnet") zu verwenden, bittet der Telnet-Klient unter Vorlage des ersten Tickets beim Kerberos-Server um ein Ticket für den Telnet-Dienst. Dieses Ticket wird dann zusammen mit einem Authentikator dem Server vorgelegt⁴.

Mit diesem Ticket darf sich der Benutzer dann am entfernten Hostrechner anmelden.

Kerberos Tickets haben eine begrenzte Lebensdauer, nach deren Ablauf sie nicht mehr gültig sind, außerdem sind sie an die IP-Adresse eines bestimmten Rechners gebunden.

Dies dient dem Zweck, dass Tickets, die von einer unbefugten Instanz abgehört wurden, nicht mehr nach Ablauf ihrer Lebensdauer und auch nicht auf einem anderen Host missbräuchlich verwendet werden können.

Da es vergleichsweise einfach möglich ist, eine IP-Adresse in einem IP-Paket zu fälschen und auch IP-Pakete abzufangen⁵ bietet dies jedoch nur eine leichte Erschwernis für einen hypothetischen Angreifer.

Auch die begrenzte Lebensdauer von Tickets ist eine vergleichsweise leicht zu umgehende Einschränkung.

Die eigentlichen Stärken von Kerberos liegen in den kryptografischen Methoden.

2.2 Anwendungsmöglichkeiten

Praktisch jeder Netzwerkdienst lässt sich an Kerberos anpassen. Bei der Kerberos-Distribution selbst werden bereits angepasste Varianten von telnet, den bekannten r-Kommandos und ftp mitgeliefert, die zusätzlich über die Möglichkeit zur Verschlüsselung des Datenstroms verfügen. Angepasste Varianten vieler verbreiteter Netzwerkdienste, wie z.B. "Secure Shell" und cvs sind verfügbar. Außerdem gibt es auch Netzwerkdateisysteme, die Kerberos zur Authentisierung verwenden (z.B. AFS⁶ und DFS).

Wird in einem Netzwerk Kerberos zur Authentisierung verwendet, ist es sinnvoll, Kerberos mit Hilfe von PAM oder einem an Kerberos angepassten login-Programm gleich in die lokale Anmeldung zu integrieren. Zum Einen lässt sich darüber eine Vereinheitlichung der Passwörter und der Benutzerverwaltung für alle Hostrechner erreichen, zum Anderen ist es für den Benutzer bequem, ohne Angabe eines weiteren Passworts auf alle für ihn freigegebenen Netzwerkressourcen zugreifen zu können ("Single Sign-On").

3 Verwendung

Dieses Kapitel beschreibt, wie man sich an einem System anmeldet, das Kerberos zur Authentisierung verwendet, wie man Netzwerkdienste verwendet und mit Tickets umgeht. Es wird davon ausgegangen, dass ein Systemadministrator (oder ein Distributor eines Unix-ähnlichen Systems wie z.B. Linux oder Solaris) beim Übersetzen und Installieren der Software weitestgehend die Vorgaben beibehalten hat, also die als üblich angenommene Entscheidungen bei der Konfiguration getroffen hat.

3.1 Anmeldung am System

Die Anmeldung am System entspricht weitgehend dem unter Unix üblichen Verfahren. Man sieht also einen textbasierten Login-Prompt oder einen grafischen Anmeldebildschirm⁷ vor sich, gibt seinen vom Systemadministrator vergebenen Benutzernamen und dann das richtige Passwort ein.

Nun ist es möglich (und durchaus üblich und empfohlen), dass man nach dem Anmelden bereits ein gültiges TGT und auch Tickets für den einen oder anderen Dienst erhalten hat⁸. Ob dies der Fall ist, kann mit dem Befehl klist getestet werden. Die Ausgabe sollte in etwa wie folgt aussehen:

alice@testhost:~> klist

Die Benutzerin alice hat sich hier (über login oder xdm oder ähnliches) am System testhost.kerberos.test⁹ angemeldet. Das System hat den Domainnamen kerberos.test und das Kerberos 5 "Realm" KERBEROS.TEST. Wie empfohlen, entspricht das Kerberos 5-Realm dem Domainnamen, nur in Großbuchstaben.

Wie bereits erläutert, hat ein Kerberos Ticket eine Geltungsdauer, hier ist sie in der Ausgabe des klist Befehls angegeben. alices Ticket gilt vom 11. November 2002 um 13:10:38 Uhr bis um 23:10:38 Uhr des gleichen Tages.

Um 23:10:38 Uhr läuft das Ticket also ab, wenn alice es nicht in der Zwischenzeit verlängert. Nach dem Ablauf des ersten Tickets können auch die erhaltenen Tickets für weitere Dienste nicht mehr verwendet werden, so dass alice sich ein neues Ticket holen muss, wenn sie weiterhin Kerberos 5-Dienste verwenden will¹⁰.

Hier sieht man auch, dass sowohl ein Benutzer als auch ein Netzwerkdienst in der Kerberos-Terminologie ein "Principal" ist. Die Benutzerin alice verkörpert den voreingestellten Principal alice@KERBEROS.TEST wenn sie sich am System anmeldet und der "Ticket Granting Server", also der Kerberos-Dienst, der die Tickets vergibt, verkörpert den Principal "krbtgt/KERBEROS.TEST@KERBEROS.TEST".

Die Benutzerin alice hat in unserem Beispiel beim Anmelden nur das "Ticket Granting Ticket" (TGT) erhalten. Es ist aber denkbar, dass auf einem System nach dem erfolgreichen Anmelden gleich weitere Autorisierungen vergeben werden, wie z.B. Zugriff auf ein OpenAFS-Dateisystem. Je nach Konfiguration des Systems werden direkt nach dem Einloggen schon weitere Tickets in der Ausgabe von klist aufgelistet.

Wenn kein Ticket vorhanden ist, wird klist etwa das Folgende ausgeben:

alice@testhost:~> klist

3.2 Benutzung von Netzwerkdiensten

Mit ihrem Kerberos 5-Ticket kann alice jetzt Dienste auf einem entfernten Host benutzen. Sie könnte sich z.B. per rsh oder telnet am Host server.kerberos.test anmelden oder per ftp oder rcp Dateien übertragen. Für alle diese Programme sollte mit dem Schalter -x die Verschlüsselung des Datenstroms angeschaltet werden. Die Authentisierung erfolgt dann ohne Angabe eines Passwortes mit Hilfe des Tickets. Ohne Verwendung dieses Schalters werden Passwörter weiterhin im Klartext übertragen. Wenn bei der Anmeldung am entfernten System, die eigentlich mit Kerberos erfolgen sollte, nach einem Passwort gefragt wird, muss man davon ausgehen, dass etwas nicht stimmt. Man sollte dann prüfen, ob der Schalter -x vergessen wurde, oder der verwendete Client oder Server nicht Kerberos-fähig ist. Es handelt sich hier auch nur um eine schwache Verschlüsselung des Datenstroms (in der Regel: DES), so dass einer Anmeldung über eine - idealerweise an Kerberos 5 angepasste - "Secure Shell" der Vorzug zu geben ist.

Auf manchen Systemen sind alle Versionen der genannten Programme durch Kerberos-fähige Alternativen ersetzt, so dass alice also nur "telnet -x server.kerberos.test" eingeben müsste, um sich am entfernten Server verschlüsselt anzumelden.

Auf anderen Systemen sind die Standardkommandos aber noch unter ihren alten Namen vorhanden und die Kerberos-fähigen Versionen dieser Dienste und ihrer Klientenprogramme haben ein vorangestelltes 'k' im Namen. Die Kommandos heissen dann in der Regel ktelnet, kftp, kftp krcp usw.

Im Folgenden wird der Kürze halber davon ausgegangen, dass die k-Varianten der Kommandos installiert sind.

3.2.1 Authentisierung ohne Passworteingabe

Wenn man es bequem und sicher haben möchte, kann man mit Kerberos also Netzwerkdienste ohne Passworteingabe verwenden. In unserem Beispiel möchte sich alice, die an der Konsole von testhost angemeldet ist, auf dem Server server anmelden. Kerberos 5-Tickets werden vom Host kerberos vergeben.

Damit dies möglich ist, muss der Systemadministrator Host-Principals für die teilnehmenden Hosts angelegt und deren geheime Schlüssel in einer lokalen Datei (einer sogenannten "Keytab") auf den Hosts hinterlegt haben. Auf server liegt also in der Datei /etc/krb5.keytab ein Ticket für den Principal host/server.kerberos.test und auf testhost eines für host/testhost.kerberos.test. Dies wird in der bei Kerberos 5 mitgelieferten Dokumentation näher erläutert (Siehe http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/admin.html#SEC12)

Wenn alice bereits ein gültiges Ticket besitzt, wird das ktelnet-Programm (und alle anderen Kerberos-fähigen Netzwerk-Klienten) dieses dem Kerberos-Dienst vorlegen und sie ist am entfernten System angemeldet.

Falls die Anmeldung nicht funktioniert oder nach einem Passwort gefragt wird, ist entweder der entfernte Dienst nicht Kerberos-fähig, oder es wird ein Kommando verwendet, das Kerberos nicht beherrscht, oder der Administrator hat es versäumt, die Host-Principals richtig anzulegen.

Wichtige Information erhält man aus der Ausgabe des klist Kommandos auf dem lokalen und dem entfernten System.

Auf dem lokalen System testhost:

Hier auf dem lokalen System testhost ist ein Ticket für den Dienst host/server.kerberos.test@KERBEROS.TEST vergeben worden. Dies ist genau der Host-Principal, den (hoffentlich) der Administrator angelegt hat.

Auf dem entfernten System server wird das Ticket für den Host-Principal fehlen, weil dieses auf testhost angefordert wurde, bevor die Anmeldung erfolgte.

3.3 Manuelle Authentifizierung

Es kann sein, dass Kerberos nicht als primäre Authentisierung an einem System konfiguriert ist. Außerdem laufen Kerberos Tickets nach einer Zeit ab und müssen aufgefrischt werden, oder man möchte ein Ticket für einen anderen Principal oder eines mit anderen Eigenschaften erhalten.

In so einem Fall, kann man sich als Benutzer selbst mittels des "kinit" Befehls mit Tickets versorgen. Das Kommando kinit bekommt als Argumente verschiedene Schalter und den "Principal" für den man Tickets erhalten will. Ohne Angabe von Parametern versucht kinit ein TGT für den "Principal" zu erhalten, der den gleichen Namen hat, wie der Benutzer.

Die Unix-Benutzerin alice aus unserem Beispiel gibt also einfach "kinit" und ihr Kerberos Passwort ein, um ein TGT für den Kerberos Principal alice zu erhalten.

Falls sich beim Auflisten der Tickets mit klist herausstellt, dass die Tickets nicht die gewünschten Eigenschaften haben, kann mit Schaltern ein TGT angefordert werden, das bestimmte Bits gesetzt hat. So würde z.B. das Kommando kinit -f mit dem Schalter -f explizit ein Ticket mit gesetztem "forwardable" Bit anfordern¹¹, das auf einem entfernten System weiterverwendet werden kann.

Alles Weitere funktioniert dann so wie in den vorigen Abschnitten beschrieben.
 

3.4 Umgang mit Tickets

3.4.1 Eigenschaften von Tickets

Die Tabelle 2 erklärt die wichtigsten Flags in Kerberos 5 Tickets:

3.4.1.1 Erläuterungen zu ausgewählten Eigenschaften

• Tickets mit dem Flag 'F' können auf einen entfernten Host weitergeleitet werden. Im Abschnitt 3.2.1 wurde erläutert, wie man sich mit einem der "kerberisierten" Netzwerk-Clients an einem entfernten Server anmelden kann. Wie bereits erläutert, sind Kerberos Tickets an die IP-Adresse des Hosts gebunden, auf dem sie ausgestellt wurden, so dass das alte Kerberos Ticket auf dem neuen Host nicht weiterverwendet werden kann. Wenn auf dem entfernten Host nun weiterhin Kerberos benötigt wird (um z.B. auf ein Dateisystem zuzugreifen), kann es sein, dass ein neues Ticket benötigt wird, folglich müsste sich der Benutzer mit dem kinit Kommando ein neues Ticket holen. Dies wird wesentlich vereinfacht, wenn man gleich zu Beginn (z.B. mit dem Kommando "kinit -f") ein Ticket angefordert hat, das weitergeleitet werden kann. In diesem Fall wird der KDC ein neues Ticket ausstellen, das für den entfernten Host gültig ist. Kerberos 5 kann auch vom Systemadministrator so konfiguriert werden, dass grundsätzlich immer Tickets mit bestimten Flags geholt werden, so dass es nicht nötig ist, sich von Hand ein Ticket mit kinit zu holen.
• Tickets mit dem Flag 'R' sind erneuerbar. Diese Eigenschaft ist dann sinnvoll, wenn man länger in einer Sitzung arbeiten will, als von der maximalen Gültigkeitsdauer der Tickets her vorgesehen ist. Bei einem lang laufenden Prozess der Kerberos Tickets benötigt, kann mit "kinit -r <Zeitdauer>" also z.B. "kinit -r 62d" ein Ticket geholt werden, das eine bestimmte Zeitspanne lang erneuert werden kann (hier 62 Tage). Es sollte dann dafür gesorgt werden, dass so lange der Prozess läuft, das Ticket regelmäßig bevor es abläuft mit dem Befehl kinit -R erneuert wird. Der Systemadministrator kann hierfür ein kleines Programm erstellen, welches im Hintergrund abläuft.
• Tickets mit dem Flag 'D' sind dazu gedacht, dass ein Prozess zu einem definierten späteren Zeitpunkt autorisiert werden soll. Beispielsweise könnte dies ein Prozess sein, der von den Daemonen cron oder atd gestartet wird. Das Ticket mit dem 'D'-Schalter wird dazu vorher von dem Benutzer geholt. Der Prozess läßt das Ticket dann zu dem späteren Zeitpunkt mittels kinit -v vom KDC validieren.

Man sollte darauf achten, dass man nur Tickets mit Eigenschaften anfordert, die man auch benötigt. Dadurch wird im allgemeinen das Risiko eines Missbrauchs minimiert. Z.B. ist es denkbar, dass ein Ticket mit der Eigenschaft 'F', das also weitergeleitet werden kann, von einem Angreifer aufgefangen und während seiner Geltungsdauer zum Anmelden auf einem entfernten Host verwendet wird. Dieses Risiko kann einfach dadurch minimiert werden, dass man einfach nur dann ein Ticket zur Weiterleitung anfordert, wenn man auch vorhat, sich auf einem anderen Host anzumelden.

Auch die anderen Flags haben ähnliche Sicherheitsimplikationen, näheres dazu kann im Kapitel 6 nachgelesen werden.

3.4.2 Tickets wegwerfen

Mit dem Kommando kdestroy können die momentan im "Ticket Cache" gespeicherten Tickets weggeworfen werden. Dies ist aber nur dann nötig, wenn die Tickets nicht automatisch beim Abmelden vom System weggeworfen werden. Bei Systemen, bei denen Kerberos in den Login-Prozess integriert wurde, ist dies in der Regel der Fall. Als Test kann man sich anmelden, mit echo $KRB5CCNAME den Ort des Kerberos "Ticket Caches" ausgeben, aufschreiben (oder merken), sich dann wieder abmelden und nach dem erneuten Anmelden kann man nachsehen, ob die Datei noch existiert. Wenn sie nicht existiert, wurde das Ticket automatisch beim Abmelden gelöscht.

3.5 Passwort ändern

Das Passwort ändert man mit dem Kommando kpasswd. Dazu wird Kontakt zu dem "Kerberos Administration Daemon"(kadmind) aufgenommen. Falls das Ändern des Passwortes fehlschlägt, könnte dies daran liegen, dass der kadmind fehlerhaft oder nicht installiert wurde, oder dass man das alte Passwort falsch eingegeben hat.

In größeren Netzwerken, in denen mehrere Kerberos 5 KDCs laufen, kann es sein, dass man sich erst nach einer gewissen Zeit an allen Maschinen mit dem neuen Kerberos 5 Passwort anmelden kann, bzw. Tickets erhält. Dies liegt dann daran, dass Änderungen an der Kerberos Datenbank regelmäßig über das Netzwerk propagiert werden, so dass nicht alle Maschinen sofort das neue Passwort kennen.

Einzelheiten über die Administration von kadmind finden sich im Kapitel 5.

4 Installation

Zunächst sollte man prüfen, ob bei dem verwendeten Betriebssystem schon ein Kerberos 5-Paket dabei ist (eventuell auf einer zusätzlichen CD). Bei den meisten Linux-Distributionen ist beispielsweise eine Variante von Kerberos 5 dabei (entweder die freie, unabhängige Kerberos Implementation "Heimdal" oder die originale Kerberos 5-Implementation vom MIT), auch viele kommerzielle Unix Anbieter unterstützen eine Kerberos Variante. Dies ist nicht notwendigerweise Kerberos 5 und auch nicht immer eine hinreichend aktuelle Version von Kerberos 5, so dass man prüfen sollte, ob die beim Betriebssystem mitgelieferte Kerberos 5-Variante den eigenen Anforderungen genügt. Auf jeden Fall sollte aus Sicherheitserwägungen heraus die jeweils aktuelle Kerberos 5-Version verwendet werden.

Falls die mitgelieferte Kerberos-Implementation nicht ausreicht, kann entweder der MIT-Kerberos-Quellcode vom "Cryptography Publishing Project" unter http://www.crypto-publish.org/mit-kerberos5/index.html bezogen werden (oder, wenn man sich in den USA oder Kanada befindet, auch von der Website des MIT: http://web.mit.edu/kerberos/www/), oder die Quellen der "Heimdal"-Implementation unter http://www.pdc.kth.se/heimdal/.

Im Folgenden wird die Installation und Konfiguration der MIT-Variante beschrieben.

Genauere Anleitung zum Übersetzen und Installieren der MIT Kerberos Distribution gibt http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/install.html.

Die derzeit (Oktober 2002) aktuelle Version von Kerberos 5 des MIT ist Version 1.2.6. Es sollte jeweils immer die aktuellste Version mit den neusten Sicherheitspatches installiert werden, ob es sich nun um Pakete vom Hersteller des Betriebssystems (bzw. der Distribution) oder um selbst übersetzte Quellen handelt. Näheres hierzu findet sich unter http://web.mit.edu/kerberos/www/advisories/index.html.

4.1 Voraussetzungen

1. Alle Hosts, die Kerberos verwenden sollen, sollten über miteinander synchronisierte Uhren verfügen. Hierzu empfiehlt sich die Verwendung von NTP.
2. Ein Compiler und das Kommando make sollten installiert sein.
3. Die Header-Dateien der System-Bibliotheken sollten installiert sein.
4. Außerdem sollten etwa 60 bis 70 Megabyte freier Plattenplatz auf der Partition, in die die Quellen ausgepackt wurden, vorhanden sein. Die fertige Kerberos 5-Installation benötigt etwa 4 bis 5 Megabyte Plattenplatz.
5. Außerdem ist es empfehlenswert, die Header für eine Variante der curses-Bibliotheken installiert zu haben, da einige Kerberos 5 Kommandos diese benötigen.
   

4.2 Übersetzen der Quellen

Nachdem die Datei krb5-1.2.6.tar.gz ausgepackt wurde, kann der Quellcode mit der Sequenz cd krb5-1.2.6/src && ./configure && make mit den vorgegebenen Einstellung übersetzt und mit su root -c ¨make install¨ installiert werden.

Kerberos 5 benötigt keinerlei spezielle Programmbibliotheken, um betrieben oder übersetzt zu werden.

Das voreingestellte Präfix für die Kerberos Installation ist /usr/local, deswegen wird im folgenden davon ausgegangen, dass sich die Konfigurationsdateien in /usr/local/var/krb5kdc und /etc befinden¹².

4.3 Gemeinsame Konfiguration von Klienten und Server

Kerberos-Server und -Klienten erhalten gemeinsame Einstellungen aus der Datei krb5.conf, die in /etc, oder $PREFIX/etc (also in unserem Falle /usr/local/etc) liegen kann.

Listing 1 zeigt ein minimales, lauffähiges Beispiel für eine solche Konfigurationsdatei, für das "Kerberos-Realm"KERBEROS.TEST.

[libdefaults]
default_realm = KERBEROS.TEST
default_tkt_enctypes = des3-hmac-sha1
default_tgs_enctypes = des3-hmac-sha1
dns_lookup_kdc = false
dns_lookup_realm = false
[realms]
KERBEROS.TEST = {
kdc = kerberos.kerberos.test:88
admin_server = kerberos.kerberos.test:749
default_domain = kerberos.test
}
[domain_realm]
.kerberos.test = KERBEROS.TEST
.test = KERBEROS.TEST
[logging]
kdc = FILE:/usr/local/var/log/krb5kdc.log
admin_server = FILE:/usr/local/var/log/kadmin.log
default = FILE:/usr/local/var/log/krb5lib.log

Die Sektion libdefaults enthält allgemeine Voreinstellungen für alle Kerberos-Programme, -Klienten und -Server.

Die Direktive default_realm teilt den Programmen mit, welches "Realm" als Voreinstellung zu benutzen ist. "Principals" können so z.B. ohne Angabe des Namens des Kerberos 5 Realms verwendet werden.

Mit default_tkt_enctypes werden die Verschlüsselungstypen spezifiziert, die die Klienten anfordern sollen, mit default_tgs_enctypes jene, die der KDC zurückgeben soll. Standardmäßig sind des-cbc-crc und des3-hmac-sha1 die einzigen Optionen, allerdings kann Kerberos auch dahingehend erweitert werden, dass andere Typen möglich sind.

Da DES nach heutigen Erkenntnissen eine zu schwache Verschlüsselung bietet, sollte nach Möglichkeit des3-hmac-sha1 bzw. ein gleich guter oder besserer Verschlüsselungstyp verwendet werden. Die Verwendung von DES sollte nur noch in Betracht kommen, um die Kompatibilität zu älteren Klientenprogrammen zu wahren. In diesem Fall empfiehlt sich die Verwendung des krb524d Servers, der aber hier nur am Rande erwähnt werden soll.

Es ist möglich, Informationen darüber, welche Hosts Kerberos-Dienste bereitstellen, im "Domain Name Service" (DNS) zu hinterlegen. Ein SRV-Eintrag im DNS-Server wird dann einen KDC kennzeichnen und ein TXT-Eintrag ermöglicht die Zuordnung von Hosts zu einem Kerberos 5-Realm. Näheres dazu und zur Kerberos-Administration im allgemeinen findet sich in der Datei admin.html im Unterverzeichnis doc der Kerberos-Quellen¹³.

Die Verwendung von DNS bietet sich in einer größeren Installation an, weil bestimmte Veränderungen der Konfiguration schnell propagiert werden können, ohne dass auf mehreren Rechnern die Datei /etc/krb5.conf verändert werden muss. Auch wird die Komplexität und Vielzahl der Einstellungen in /etc/krb5.conf hierdurch minimiert, weil der Abschnitt [domain_realm] und die Einstellungen der KDCs im Abschnitt [realms] ganz wegfallen kann.

In unserem einfachen Beispiel wird aber mit |dns_lookup_kdc = false| und |dns_lookup_realm = false| diese Möglichkeit unterbunden.

Stattdessen wird mit der Einstellung |kdc = kerberos.kerberos.test| der KDC festgelegt, welcher die Tickets vergibt, und mit |admin_server = kerberos.kerberos.test| festgelegt, dass der kadmind auf dem gleichen Host läuft. Diese Direktiven befinden sich in der Sektion realms der Konfigurationsdatei, in den Einstellungen zum Realm "KERBEROS.TEST". Dort ist weiter mit |default_domain = kerberos.test| angegeben, dass Hosts aus der Internet Domain kerberos.test per Voreinstellung diesem Realm zugehörig sind.

In der Sektion domain_realm können weitere Verknüpfungen von Domainnamen und Kerberos-Realms angegeben werden, wobei ein Eintrag der mit einem Punkt ('.') beginnt, immer bedeutet, dass alle Hosts mit diesem Suffix zu dem angegebenen Kerberos-Realm gehören. Die hier gegebenen Einträge sind redundant, da die Angabe von |.test = KERBEROS.TEST| bereits ausreichen würde.

Im Abschnitt logging wird eingestellt, in welche Dateien die Serverprozesse ihre Logeinträge schreiben sollen. Diese Optionen werden nur von Servern beachtet. Da in diesem Beispiel die Logeinträge an die bestehende Datei angehängt werden, wäre es empfehlenswert hier für eine Rotation der Logdateien zu sorgen. Alternativ bietet Kerberos 5 auch die Möglichkeiten, Logeinträge an den syslogd abzusetzen, oder die Dateien jeweils bei einem Neustart der Serverprozesse zu überschreiben (siehe http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/admin.html#SEC22).

4.4 Einrichten des Kerberos 5-KDC

Zunächst wird die Konfigurationsdatei kdc.conf mit allen nötigen Einstellungen versehen, dann das Datenverzeichnis /usr/local/var/krb5kdc mit den richtigen Zugriffsrechten angelegt und vorbereitet, so dass anschließend die Datenbank angelegt, der Server gestartet, eine Default-Policy festgelegt und die Administrationsbenutzer angelegt werden können.
 

4.4.1 Konfigurationsdatei kdc.conf

Der Pfad der kdc.conf ist von der Konfiguration des krb5-Pakets abhängig. Die verwendete Version ist mit dem Präfix /usr/local übersetzt, weswegen die kdc.conf im Pfad /usr/local/var/krb5kdc liegen muss. Das Verzeichnis wird angelegt mit

install -d -o root -g root -m 700 /usr/local/var/krb5kdc

und die Datei dort mit folgendem Inhalt angelegt:

[kdcdefaults]
kdc_ports = 88,750
[realms]
KERBEROS.TEST = {
database_name = /usr/local/var/krb5kdc/principal
admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab
acl_file = /usr/local/var/krb5kdc/kadm5.acl
dict_file = /usr/local/var/krb5kdc/kadm5.dict
key_stash_file = /usr/local/var/krb5kdc/.k5.KERBEROS.TEST
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 3d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal
}

Im Abschnitt kdcdefaults werden hier lediglich die Portnummern festgelegt, an denen der KDC Verbindungen annimmt.

Wie die Datei krb5.conf auch, hat diese Konfigurationsdatei eine Sektion realms. Es ist möglich, dass ein KDC mehrere Realms verwaltet, aber in diesem Fall werden nur Einstellungen für eines vorgenommen. Die Bedeutung der Direktiven im einzelnen ist Tabelle 3 zu entnehmen.

4.4.2 Anlegen der Datenbank und Start der Server vorbereiten

Das Verzeichnis /usr/local/var/krb5kdc wird auf dem Host kerberos, der in unserem Beispiel als KDC fungiert, mit den Befehlen

Dann wird auf dem Host kerberos die Datenbank initialisiert:

Statt Master Passwort ist natürlich ein geeignetes Passwort zu wählen.

Es ist wichtig, dass das KDC-Master Passwort nicht vergessen wird, da es eventuell später noch zur Einrichtung eines sekundären KDCs benötigt wird.

Nun müssen die administrativen Accounts kadmin/admin und kadmin/changepw noch in die in der Datei kdc.conf angegebene "keytab" gelegt werden:

Damit Benutzer mit Administratorenrolle diese wahrnehmen können, muss noch die Datei /usr/local/var/krb5kdc/kadm5.acl angelegt werden:

*/admin@KERBEROS.TEST *

Hierin ist festgelegt, dass alle Principals mit der Instanz admin alle Rechte zur Veränderung der Kerberos 5-Datenbank haben.

Nun können die Server gestartet werden.

4.4.3 Starten der Server

In der Beispielinstallation soll auf dem Host kerberos sowohl den KDC (Prozess krb5kdc) als auch den Administrationsserver (kadmind) laufen. In der Kerberos-Distribution vom MIT ist noch der krb524-Server enthalten, der Kerberos 5-Tickets in das alte Kerberos 4-Format konvertiert. Dieser wird benötigt wenn man Dienste betreibt, die noch das alte Format erwarten, wie z.B. AFS. Das ist hier nicht der Fall, darum wird er weggelassen.

Damit die Dienste beim Hochfahren des Systems geladen werden und auch der Bequemlichkeit halber wird für den Start der Server ein Shellscript verwendet, das bei einem zum "System V" kompatiblen init Prozess in die Konfiguration der "runlevels" integriert werden kann.

Im Folgenden einige Beispiele, wie solche Scripts aussehen könnten:

Der KDC-Prozess krb5kdc kann mit dem Script in Listing 4 gestartet werden, das nach /etc/init.d/krb5kdc gelegt wird.

[keywords,comments,strings]

#! /bin/sh
#
# /etc/init.d/krb5kdc
#
### BEGIN INIT INFO
# Provides:          krb5kdc
# Required-Start:    $network
# Required-Stop:     $afs
# Default-Start:     2 3 5
# Default-Stop:
# Description:       Kerberos 5 kdc
### END INIT INFO
KRB5KDC=krb5kdc
BINPATH=/usr/local/sbin/
case "$1" in
start)
echo -n "Starting service Kerberos 5 KDC"
$BINPATH$KRB5KDC
echo .
;;
stop)
echo -n "Shutting down service Kerberos 5 KDC"
pkill -TERM $KRB5KDC
echo .
;;
restart)
$0 stop
$0 start
;;
reload|force-reload)
echo -n "Reload service Kerberos 5 KDC"
pkill -HUP  $KRB5KDC
echo .
;;
status|check)
echo -n "Checking for service Kerberos 5 KDC"
pgrep $KRB5KDC 
if [ "$?" = 0 ]
then
echo ok.
else
echo failed.
fi
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload}"
exit 1
esac

Auf Systemen, wo die Befehle pkill und pgrep nicht vorhanden sind, kann die Ausgabe des Kommandos ps -e (System V) bzw. ps ax (BSD) mit den Befehlen grep krb5kdc|grep -v grep|awk '{print $1}' weiterverarbeitet werden, um die Prozess-ID der Serverprozesse zu erhalten.

Das Init-Script zum Starten des Administrationsdienstes ist beinahe identisch mit dem vorherigen:

#! /bin/sh
#
# /etc/init.d/kadmind
#
### BEGIN INIT INFO
# Provides:          kadmind
# Required-Start:    $network $krb5kdc
# Required-Stop:     $afs
# Default-Start:     2 3 5
# Default-Stop:
# Description:       Kerberos 5 admin daemon
### END INIT INFO
KADMIND=kadmind
BINPATH=/usr/local/sbin/
case "$1" in
start)
echo -n "Starting service kadmind"
$KADMIND
echo .
;;
stop)
echo -n "Shutting down service kadmind"
pkill -TERM $KADMIND
echo .
;;
restart)
$0 stop
$0 start
;;
reload|force-reload)
echo -n "Reload service kadmind"
pkill -HUP  $KADMIND
echo .
;;
status|check)
echo -n "Checking for service kadmind"
pgrep $KADMIND
if [ "$?" = 0 ]
then
echo ok.
else
echo failed.
fi
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload}"
exit 1
esac

Nachdem der Start der Server beim Reboot der Maschine durch Anlegen der angemessenen symbolischen Links für ein System V-kompatiblen Init-Prozess oder durch Eintrag in die inittab bei BSD-Systemen gewährleistet wurde, können nun die Server ein erstes Mal von Hand gestartet werden.

Nun können sich Benutzer an allen Maschinen im definierten Realm Tickets holen. Um Kerberos verwenden zu können müssen noch administrative Accounts (falls nötig) und Principals für die Benutzer angelegt werden. Dies wird im einzelnen im Kapitel 5 dargelegt.

Zunächst soll aber die Installation von Kerberos zum Abschluss gebracht werden, indem es in die Systemanmeldung integriert wird.

4.5 Konfiguration von "Pluggable Authentication Modules"

PAM ("Pluggable Authentication Modules") ist mittlerweile ein weit verbreitetes System zur modularen Authentifizierung, dass in vielen Unix-ähnlichen Systemen integriert ist. PAM erlaubt es dem Administrator die Authentifizierungsmechanismen einzelner Anwendungen zu konfigurieren, ohne dass die Anwendung neu übersetzt werden muss. Viele Anwendungen, die Authentisierung in irgendeiner Form benötigen unterstützen bereits PAM. Nähere Informationen über PAM können dem DFN-CERT Informationsbulletin über dieses Thema entnommen werden.

Für die Verwendung von PAM mit Kerberos ist eine PAM-fähige Anwendung, die installierte und korrekt konfigurierte dynamische Programmbibliothek für PAM mit den Standardmodulen sowie ein spezielles Kerberos Modul nötig (in den meisten Fällen ebenfalls in Form einer Programmbibliothek), wobei letzteres die eigentliche Authentifizierung mit Kerberos 5 übernimmt.

Leider werden in der Kerberos 5-Distribution des MIT keine PAM-Module mitgeliefert, so dass auf PAM-Module von Drittherstellern zurückgegriffen werden muss.

Auch gibt es zur Zeit (Januar 2003) bedauerlicherweise kein PAM-Modul für Kerberos 5, das sowohl portabel ist, als auch alle Modul-Typen ¹⁵ unterstützt.

Bei einigen Linux Distributionen (z.B. debian und Redhat) sowie anderen freien oder kommerziellen Unix-Systemen (z.B. Solaris ab Version 8) sind unter Umständen schon PAM-Module für den Gebrauch mit Kerberos mitgeliefert. Sollte dies nicht der Fall sein, besteht die Möglichkeit, auf das PAM-Modul für Kerberos 5 von Frank Cusack zurückzugreifen (http://www.fcusack.com/), oder auf die für die "FreeBSD Ports Collection" modifizierte Version dieses Moduls (http://www.freebsd.org/cgi/pds.cgi?ports/security/pam_krb5), auf der auch unter anderem das bei der Debian Linux-Distribution mitgelieferte Kerberos 5 PAM-Modul basiert.

Mit wenigen Änderungen im Makefile lässt es sich auf einigen Unix-ähnlichen Systemen übersetzen und installieren. Nach der Installation sollte sich eine dynamische Programmbibliothek, z.B. die Datei pam_krb5.so in einem Verzeichnis befinden, in dem es von der PAM-Bibliothek gefunden wird (in vielen Fällen wird dies das Verzeichnis /lib/security sein).

Listing 6 ist ein Beispiel für eine PAM-Konfiguration der Anwendung "login", bei dem bevorzugt auf Kerberos 5 zurückgegriffen wird, aber falls die Kerberos 5-Authentifizierung scheitert, versucht wird eine Unix Authentifizierung (über /etc/passwd und /etc/shadow) mit gleichem Passwort vorzunehmen.

Natürlich kann mit Hilfe von PAM Kerberos voll in die Systemanmeldung integriert werden, so dass alle lokalen Anmeldungen über Kerberos 5 erfolgen. Wie dies im einzelnen zu erfolgen hat, kann mit Hilfe dieses Beispiels leicht auf andere Anwendungen (z.B. xdm o.ä.) übertragen werden. 

#%PAM-1.0
auth     required       pam_securetty.so
auth     required       pam_nologin.so
auth     required       pam_env.so
auth     required       pam_mail.so
auth     sufficient     pam_krb5.so
auth     required       pam_unix.so             md5 use_first_pass
account  sufficient     pam_krb5.so
account  sufficient     pam_unix.so
password required       pam_pwcheck.so
password sufficient     pam_krb5.so             use_first_pass use_authtok
password required       pam_unix.so             use_first_pass use_authtok
session  required       pam_limits.so
session  required       pam_unix.so             none # debug or trace
session  optional       pam_krb5.so

4.5.1 Sicherheitsrisiken in Verbindung mit PAM

PAM sollte in Verbindung mit Kerberos 5 unbedingt nur für die lokale Anmeldung benutzt werden. Hiermit ist gemeint, dass der Anwender, der das Kerberos-Passwort eingibt, sich an der Maschine anmeldet, die er physikalisch nutzt. Als Anwendungen kommen hier ein login an der Konsole oder über xdm und seine Varianten (dtlogin, kdm, gdm usw.) in Frage, wobei im Falle von xdm unbedingt in der Konfiguration gewährleistet sein muss, dass keine entfernten Logins (über das xdmcp Protokoll) etwa von X-Terminals oder entfernt laufenden xdm-Prozessen entgegengenommen werden.

Alle Netzwerkanmeldungen (z.B. telnet, rlogin aber auch xdm im Netzwerkbetrieb) scheiden aus Sicherheitsgründen aus.

Der Grund dafür liegt darin, dass die Benutzerinteraktion bei PAM von der Klienten-Anwendung selbst übernommen wird. Informationen über den Erfolg oder Misserfolg der Authentifizierung werden von der Anwendung angezeigt und Benutzereingaben (wie auch Benutzername und vor allem das Passwort) werden von der Anwendung entgegengenommen. Das heißt aber auch, dass im Falle von rlogin und telnet, wenn sie mit einem Kerberos 5-PAM-Modul verwendet werden, das Kerberos 5-Passwort im Klartext über das Netz gesendet wird.

Damit ist ein wesentlicher Sicherheitsgewinn bei der Verwendung von Kerberos 5 wieder zunichte gemacht.

Bei Netzwerkanwendungen (wie rlogin, telnet und auch ssh empfiehlt es sich auf Varianten dieser Dienste zurückzugreifen, die für die Verwendung mit Kerberos 5 angepasst wurden. Im Falle von telnet und rlogin sind solche Varianten in der Kerberos-Distribution enthalten, die auch den Vorteil bieten, dass die Nutzerdaten verschlüsselt übertragen werden können.

Die Secure Shell bildet hierbei eine Ausnahme, da hier die Anwendung dafür sorgt, dass Passwörter und andere Daten nur verschlüsselt übertragen werden. Allerdings ist auch hier die Verwendung einer angepassten Variante komfortabler.

5 Administration

Administrative Aufgaben an der Kerberos 5-Datenbank haben vornehmlich mit der Verwaltung von Principals zu tun. Im Folgenden wird der Zweck und die Funktionsweise des Administrationsservers (kadmind) erklärt und einiges über die Verwaltung von Principals gesagt.

Zu den fortgeschrittenen Aufgaben bei der Kerberos 5-Administration gehören die Einrichtung eines sekundären KDC, die Propagation der Kerberos-Datenbank und anderes. Diese forgeschrittenen Arbeiten werden nicht in diesem Text vermittelt. Hierzu sei nochmals auf die Kerberos-Dokumentation auf den Webseiten des MIT verwiesen:

• http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/admin.html
• http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/install.html
• http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/user-guide.html
  

5.1 Der Administrationsserver kadmind

Der kadmind Prozess nimmt Veränderungen an der Kerberos-Datenbank vor. Da es nur eine Master-Kopie der Kerberos-Datenbank für ein Realm gibt, sollte auch nur genau eine Instanz des kadmind in einem Kerberos-Realm laufen, und zwar auf dem Host, auf dem auch die Master-Kopie der Datenbank läuft (dem so genannten Master-KDC. Das ist in unserer Beispielkonfiguration der Host kerberos).

Administrative Arbeiten an der Datenbank werden mit dem Befehl kadmin ausgeführt, der sich als Klient mit dem Administrationsserver verbindet. Es gibt auch eine Variante dieses Kommandos kadmin.local, die vom Benutzer root auf dem KDC lokal ausgeführt werden kann und die ohne einen laufenden kadmind auskommt. Dieser Befehl wurde schon bei der Einrichtung des Kerberos Servers verwendet (siehe Abschnitt 4.4.2). Es wäre also prinzipiell möglich, auf den kadmind zu verzichten und einfach die Administration der Kerberos Datenbank als root auf dem KDC zu erledigen.

Die Änderung des Kerberos-Passworts eines Principals ist aber auch schon eine Veränderung an der Kerberos-Datenbank, daher muss auf jeden Fall ein kadmind Daemon laufen, wenn die Benutzer ihr Passwort mit dem Befehl kpasswd ändern können sollen.

Die Veränderung seines Kerberos-Passworts ist per Voreinstellung jedem Benutzer möglich. Sollen weitere Arbeiten erledigt werden, müssen dafür Berechtigungen vergeben werden. Der kadmind-Daemon greift dazu auf eine Konfigurationsdatei zurück, in der diese Berechtigungen notiert sind. Es ist die Datei kadm5.acl, die bereits in Abschnitt 4.4.2 angelegt wurde. Dort wurden für alle Principals mit der Instanz /admin alle Veränderungen an der Datenbank erlaubt.

Aus Sicherheitsgründen empfiehlt sich, keine weitergehenden Rechte für Principals mit einer Null-Instanz (Beispiel: benutzer@KERBEROS.TEST) zu vergeben, sondern jedem Benutzer, der weitergehende Rechte erhalten soll, einen weiteren Principal zuzuteilen, der den gleichen primary und eine besondere Instanz hat. Z.B. wäre dies der Principal benutzer/admin@KERBEROS.TEST, der durch die Einstellungen in der Datei kadm5.acl alle Rechte zur Datenbankadministration erhalten würde.

Sollen feinkörnigere Unterschiede in den Berechtigungen gemacht werden, ist die Einrichtung von weiteren Gruppen von Principals mit der gleichen Instanz möglich.

5.2 Verwalten von "Principals"

Wie bereits erwähnt, werden die Principals im wesentlichen mit dem Kommando kadmin administriert.

Dies bietet eine Anzahl von Unterkommandos, die im einzelnen in der "Manpage" zum kadmin Kommando beschrieben werden. Dies sind:

add_principal

Hinzufügen eines Principals. Dabei wird auch das Passwort gesetzt. Hierbei können eine Menge Optionen gesetzt werden, wie Beispielsweise die Lebensdauer des Principals selbst, seines Passworts und seiner Tickets, welche Arten von Tickets erlaubt sind, wie sie verschlüsselt werden, u.v.m.

delete_principal

Löschen eines Principals.

modify_principal

Vornehmen von Veränderungen an einem Principal. Es können alle Optionen verändert werden, die beim Anlegen eines Principals gesetzt werden können.

change_password

Das Passwort eines Principals kann verändert werden, falls z.B. ein Benutzer sein Passwort vergessen hat, oder es abgelaufen ist.

get_principal

Gibt die Charakteristika eines Principals aus.

list_principals

Listet alle Principals auf.

add_policy

Fügt eine "Policy" für Passwörter hinzu. Eine Policy regelt Eigenschaften von Passwörtern wie Ihre Lebensdauer, wie viele verschiedene Zeichenklassen¹⁶ mindestens enthalten sein müssen und wie viele vorige Passwörter in der so genannten "history" aufbewahrt werden, um zu verhindern, dass Benutzer ein vergangenes Passwort erneut verwenden oder zu einfache Passwörter wählen.

delete_policy

Löscht eine Policy.

modify_policy

Verändert die Eigenschaften einer Policy.

get_policy

Zeigt eine Policy an.

list_policies

Listet alle Policies auf.

ktadd

Fügt einen Principal zu einer keytab hinzu.

ktremove

Löscht einen Principal aus einer keytab.

Das Kommando kadmin versucht, wenn es von einem Benutzer aufgerufen wird, sich als Principal mit dem gleichen primary und der Instanz admin an der Kerberos-Datenbank anzumelden.

Wenn also unsere Beispielbenutzerin alice das kadmin-Kommando aufruft, wird sie nach dem Passwort für den Principal alice/admin@KERBEROS.TEST gefragt. Hat sie dieses erfolgreich eingegeben, kann sie mit den obigen Kommandos die Kerberos-Datenbank verändern.

6 Sicherheit

Bruce Schneier weist in seinem Werk "Applied Cryptography"¹⁷ auf folgende potenzielle Sicherheitsprobleme von Kerberos 5 hin:

• Nach Möglichkeit sollte nicht DES sondern DES3 oder besser zur Verschlüsselung verwendet werden.
• Prinzipiell kann man ein altes Ticket während seiner Lebensdauer (in unserem Beispiel 10 Stunden) wiederverwenden. Dies kann ein Problem darstellen, sofern Tickets abgefangen werden können.

  Im Unterabschnitt 3.4.1 wurde bereits darauf hingewiesen, dass nur Tickets mit Eigenschaften angefordert werden sollten, die man auch wirklich benötigt. Dadurch wird die missbräuchliche Wiederverwendbarkeit von Tickets zumindest eingeschränkt. Man sollte bei der Konfiguration von der sicheren Voreinstellung ausgehen, alle besonderen Schalter zunächst einmal explizit in der Datei /etc/krb5.conf zu deaktivieren und dann nur die wirklich benötigten Eigenschaften anschalten.

• Kerberos verlässt sich darauf, dass die Uhren der beteiligten Systeme nicht manipuliert wurden. Damit verlässt es sich implizit auf die Sicherheit von Methoden zur Zeitsynchronisierung, wie z.B. NTP. Wenn es gelingt, diese zu manipulieren, können auch alte Authentikatoren problemlos wiederverwendet werden.

  Es ist darum notwendig, auch die Zeitsynchronisierung im Netzwerk soweit möglich abzusichern. Bei der Verwendung von NTP sollte über die Verwendung der kryptographischen Authentisierungsmechanismen, die dieses Protokoll bietet, nachgedacht werden.

• Kerberos ist nicht immun gegen Angriffe durch das Erraten von Passwörtern. Ein Angreifer könnte Tickets sammeln und zu dechiffrieren versuchen. ("Dictionary Attack")
• Wie die meisten Systeme ist auch Kerberos nicht gegen Trojaner gefeit. Wird ein Klienten-System in einem Kerberos-Realm von einem Angreifer kompromittiert, so dass dieser Administratorenrechte erhält, könnte dieser Angreifer beispielsweise die Klientenprogramme kinit und kpasswd gegen Varianten austauschen, die nicht nur Kerberos Authentisierung durchführen, sondern auch Passwörter aufzeichnen.

Fußnoten

... läuft¹

Wie in der Originaldokumentation der Hersteller wird in diesem Text gelegentlich das Wort "Kerberos" sowohl für das Protokoll als auch den Netzwerkdienst verwendet. Aus dem Zusammenhang sollte aber in jedem Falle klar werden, was von beiden jeweils gemeint ist.

... kann²

Ist die Instanz leer, wird von einer Null-Instanz gesprochen. Der Name des Principals enthält dann keinen Schrägstrich. Principals für Benutzer haben in der Regel (neben anderen Rollen) mindestens die leere Instanz.

... anderes³

Dies ist aus Sicherheitsgründen sehr wichtig!

... vorgelegt⁴

nach Bruce Schneier "Applied Cryptography", Addison Wesley, 1996, ISBN 0-471-11709-9, deutsche Ausgabe: Bruce Schneier, "Angewandte Kryptographie", Addison Wesley, ISBN 3-89319-854-7

... abzufangen⁵

mittels IP-Spoofing, Sniffing und/oder ARP-Poisoning

... AFS⁶

siehe DFN-CERT Informationsbulletin zu "OpenAFS"

... Anmeldebildschirm⁷

z.B. xdm, kdm oder gdm

... hat⁸

Dies wäre z.B. auf einem System der Fall, auf dem das login Programm durch eine Kerberos-fähige Variante ersetzt wurde, oder welches "Pluggable Authentication Modules" (PAM) verwendet, die für die Verwendung von Kerberos konfiguriert sind. Die Verwendung von PAM mit Kerberos 5 wird im Kapitel 4.5 erläutert.

...testhost.kerberos.test⁹

Die "Top-Level-Domain" test gab es nicht, als dieses Dokument erstellt wurde und wird es hoffentlich auch nie geben. Die Benutzernamen, Hostnamen, Domainnamen, Dateinamen in diesem und anderen Beispielen dienen nur der Erläuterung.

... will¹⁰

Jeder Dienst kann dies allerdings auf seine eigene Weise handhaben. So ist es z.B. denkbar, dass ein an einem entfernten System arbeitender Benutzer nicht sofort zwangsweise abgemeldet wird. Bei einem Netzwerkdateisystem wie z.B. AFS wird allerdings sofort der Zugriff auf geschützte Verzeichnisse unmöglich.

... anfordern¹¹

Weitere Informationen zur Verwendung von kinit enthält die "Manpage" zum kinit-Kommando.

... befinden¹²

Unter Solaris findet man die Konfigurationsdateien in /etc/krb5 und die veränderlichen Daten in /var/lib/krb5. Dies betrifft das bei Solaris 8 und 9 mitgelieferte Kerberos. Bei Solaris wurden unterschiedliche Versionen von Kerberos mitgeliefert, ab Solaris 9 auch mit Server-Unterstützung. Die Kerberos-Pakete bei Solaris 9 beruhen auf einer älteren Kerberos 5-Version vom MIT, die bekannte Sicherheitslücken aufweist. Ist ein Compiler vorhanden (z.B. der SunWorkshop Compiler), kann aber problemlos die aktuelle Kerberos -Version übersetzt werden. Wurde Kerberos 5 unter Solaris oder anderen Unix Varianten wie hier beschrieben übersetzt, wird die krb5.conf-Datei in /etc gesucht und die Konfiguration des KDC in /usr/local/var/krb5kdc. Deswegen gehen wird im Weiteren der Einfachheit halber davon ausgegangen, dass die Dateien dort liegen.

... Quellen¹³

Oder im Web unter http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/admin.html

... angelegt¹⁴

kürzer ist das Kommando "install -d -o root -g root -m 700 /usr/local/var/krb5kdc", sofern auf dem System vorhanden

... Modul-Typen¹⁵

auth, account, session und password

... Zeichenklassen¹⁶

Zeichenklassen in diesem Zusammenhang sind Kleinbuchstaben, Großbuchstaben, Nummern und Sonderzeichen. Wenn mindestens zwei verschiedene Zeichenklassen gefordert werden, muss ein Passwort schon neben Kleinbuchstaben mindestens auch einen Großbuchstaben, eine Zahl oder ein Sonderzeichen enthalten, um akzeptiert zu werden.

... ¹⁷

Addison Wesley, 1996, ISBN 0-471-11709-9, deutsche Ausgabe: Bruce Schneier, "Angewandte Kryptographie", Addison Wesley, ISBN 3-89319-854-7