KAPITEL 9 Konfigurierung und Benutzung von Kerberos

Transkript

1 KAPITEL 9 Konfigurierung und Benutzung von Kerberos Das dritte in diesem Buch beschriebene Protokoll für die Authentifizierung im Netzwerk heißt Kerberos. Benannt ist es nach dem dreiköpfigen Hund, der nach der griechischen Mythologie den Eingang zur Unterwelt bewacht. Wie sein mythologischer Namensgeber ist auch das moderne Kerberos eine Art Torwächter. Kerberos funktioniert allerdings nach anderen Prinzipien und löst auch andere Probleme als NT-Domänen oder LDAP, woraus sich auch Unterschiede in den besten Anwendungsgebieten ergeben. Grob gesagt ist Kerberos am besten geeignet, wenn Anmeldungen an mehreren Systemen mit einer Reihe von verschiedenen Protokollen (z.b. SSH, FTP etc.) realisiert werden sollen. Kerberos bietet hierfür die Möglichkeit der»einmaligen Anmeldung«(das sog. single sign-on), für das es keine vergleichbaren anderen Protokolle gibt. Für seine Aufgaben benötigt Kerberos drei Arten von Software: den Haupt-Kerberos-Server, einen oder mehrere Kerberos Application Server, die als Server für andere Protokolle dienen und Kerberos für die Authentifizierung verwenden, und Clients, die auf die Application Server zugreifen. Die meisten Microsoft Application Server und deren Clients arbeiten aber nicht so gut mit Kerberos-Servern unter Linux zusammen wie mit ihren Entsprechungen von Microsoft. Dieses Kapitel zeigt Kerberos erst aus der Perspektive von Linux und endet mit Windows-spezifischen Informationen. In diesem Kapitel geht es hauptsächlich um die Einrichtung der Kerberos- Umgebung mit ein paar als»kerberisiert«bezeichneten Werkzeugen. Hierbei handelt es sich um gängige Werkzeuge, die Kerberos beiliegen. Diese werden für die Anmeldung und Konfigurierung benutzt und besitzen zusätzliche Kerberos-spezifische Fähigkeiten, wie beispielsweise eine Telnet-Version, die mit Kerberos verschlüsselte Verbindungen erlaubt. Kerberos kann noch für viele andere Protokolle benutzt werden, beispielsweise zur Abholung von über POP mit einmaliger Anmeldung. Sollen andere als die Kerberos bereits beiliegenden Protokolle genutzt werden, muss allerdings zusätzliche Software installiert werden. 211

2 Kerberos-Grundlagen Kerberos ist ein zentrales Anmeldewerkzeug. Allerdings ist diese Aussage trotz ihrer Wahrheit stark vereinfachend. Kerberos wurde entwickelt, um eine Reihe von Problemen bei der Authentifizierung zu lösen, mit denen andere Protokolle nicht besonders gut umgehen können. Wenn Sie diese Probleme kennen und wissen, wie Kerberos sie löst, wird es für Sie einfacher, den Kerberos-Server einzurichten und festzustellen, welche Schritte dafür nötig sind. Außerdem müssen Sie entscheiden, welche Software Sie für den Kerberos-Server, die Kerberos-Application Server und deren Clients einsetzen wollen. Viele dieser Entscheidungen betreffen wahrscheinlich eher den Linux-Bereich; allerdings kann es je nach Ihren Bedürfnissen nötig sein, dass auch Kerberos-spezifische Entscheidungen zu treffen sind, die Auswirkungen auf Windows haben. Das Problem: zentralisierte einmalige Anmeldungen Besonders in großen Netzwerken wird es mehr als einen Server geben. Dies erhöht den Wunsch, zentrale Authentifizierungswerkzeuge wie NT-Domänen oder LDAP zu verwenden. Allerdings ist die zentrale Verwaltung der Anmeldungen über einen Server nur ein Teil der Antwort. Kerberos wurde ursprünglich entwickelt, um drei großen Problembereichen zu begegnen: Zentralisierte Authentifizierung Die wichtigste Ziel bei der Entwicklung von Kerberos bestand in der Zentralisierung der Anmeldevorgänge. Dies ist im Prinzip das gleiche Ziel wie das von NT- Domänen und eine der möglichen Funktionen von LDAP. Kerberos legt darüber hinaus großes Gewicht auf eine bestimmte Form der umgekehrten Authentifizierung: Clients können feststellen, ob die Server, auf die zugegriffen wird, tatsächlich die sind, die sie vorgeben zu sein. Dieser Identitätsnachweis hilft Ihnen, sicherzustellen, dass Sie die Finanzplanung für Ihre Abteilung tatsächlich auf dem Fileserver Ihrer Abteilung abspeichern und nicht auf dem Laptop eines Industriespions, der vorgibt, nur den Fotokopierer reparieren zu wollen. Geschützte Passwörter Viele Netzwerkprotokolle sind anfällig für das Ausspähen von Passwörtern. Zwar hat es in den letzten Jahren eine Reihe guter Entwicklungen in diesem Bereich gegeben, wobei sichere Protokolle wie SSH ihre unsicheren Vorgänger (Telnet) weitgehend abgelöst haben. Trotzdem wurde Kerberos mit besonderem Augenmerk auf die Passwort- Sicherheit entwickelt. Gleichzeitig wurde Kerberos als Werkzeug konzipiert, das von vielen Protokollen verwendet werden kann, wodurch beliebige kerberisierte Clients und Server (Programme mit Unterstützung für die Authentifizierung über Kerberos) von der durch Kerberos erreichten Passwort-Sicherheit profitieren können. Viele kerberisierte Programme bieten zudem auch eine Verschlüsselung von Daten, die keine Passwörter sind, auch wenn dies für einige dieser Werkzeuge nicht einmal nötig wäre. 212 Kapitel 9: Konfigurierung und Benutzung von Kerberos

3 Einmalige Anmeldungen Dies ist zweifellos eines der ungewöhnlichsten Merkmale von Kerberos. Die Idee ist, dass Benutzer sich häufig bei einem Rechner anmelden, um dann von dort aus auf andere Computer im Netzwerk zuzugreifen. Vielleicht holen Sie Ihre s von einem POP-Server ab, benutzen ein Protokoll für entfernte Anmeldungen, um Programme auf einem anderen System zu starten, laden per FTP Dateien auf einen dritten Rechner hoch, verschicken Druckaufträge über ein Druckprotokoll und so weiter. Die Eingabe eines Passworts für jeden dieser Dienste ist mehr als mühsam. Um das Problem zu entschärfen, speichern manche Werkzeuge Ihr Passwort auf der Festplatte, was in der Praxis aber ein potenzielles Sicherheitsrisiko darstellt. Kerberos wurde entwickelt, dieses Problem zu lösen, indem es einmalige Anmeldungen ermöglicht. Sobald Sie sich einmal gegenüber dem Kerberos-Server authentifiziert haben, muss für sämtliche Anwendungen, die den Haupt-Kerberos-Server für die Authentifizierung verwenden, keine neuerliche Anmeldung mehr vorgenommen werden. Die ersten beiden dieser Fähigkeiten werden auch noch recht gut von NT-Domänen und LDAP beherrscht. Allerdings gibt es bei keinem der beiden Protokolle eine Authentifizierung der Server gegenüber den Clients. (Eventuell wird die Identität des NT-Domänen- Controllers und des LDAP-Servers authentifiziert, aber nicht die Identität anderer Server.) Die Möglichkeit von Kerberos, einmalige Anmeldungen durchzuführen, wird dagegen von keinem der beiden anderen Protokolle beherrscht. (Windows führt ein Caching der Passwörter durch, was die Illusion einer einmaligen Anmeldung bei der NT-Domäne vermittelt. Diese Zwischenspeicherung hilft allerdings nur bei bestimmten Protokollen.) Andererseits wurde Kerberos nicht primär für die Verwaltung von Benutzerkonten konzipiert. Insbesondere die Werkzeuge für die Bereitstellung vollständiger Benutzerinformationen für Linux-Clients also die Aufgaben, die hauptsächlich von NSS unter Linux wahrgenommen werden fehlen in Kerberos. Auch wenn Sie Kerberos als Teil des Anmeldeprozesses an einer Workstation benutzen können, müssen Sie in dieser Situation anhand lokaler Datenbanken oder per LDAP oder mit einem anderen Werkzeug lokale Benutzerkonten führen. Das Active-Directory-Konzept von Microsoft verwendet LDAP und Kerberos gemeinsam. Zwar überschneiden sich beide Werkzeuge in Ihrer Funktionalität, gleichzeitig ergänzen sie sich aber auch recht gut. Leider ist Microsofts Kerberos-Implementierung ein wenig seltsam und arbeitet daher mit anderen Versionen nicht besonders gut zusammen. Diese Dinge werden später in den Abschnitten»Windows und Kerberos«und»Kerberos-Werkzeuge für Windows«beschrieben. Ein Überblick über die Arbeitsweise von Kerberos Abhandlungen über Kerberos sind, ähnlich entsprechenden Texten zu LDAP und NT- Domänen, gespickt mit bestimmten Fachbegriffen. Um die Arbeitsweise von Kerberos und dessen Konfigurierung zu begreifen, ist es mehr als hilfreich, diese Begriffe zu kennen. Kerberos-Grundlagen 213

4 KDC Das Herz von Kerberos bildet das so genannte Key Distribution Center (KDC; zentrale Vergabestelle von Schlüsseln). Dieses System verwaltet die Kerberos-Anmeldungen. In manchen Netzwerken gibt es mehrere KDCs. In diesen Fällen wird einer der Server als Master-KDC definiert, während die anderen Kerberos-Server als Slave- KDCs arbeiten. Slave-KDCs werden im Prinzip genauso konfiguriert wie die Master, allerdings benötigen beide möglichen Versionen zusätzliche Komponenten, um die Passwort-Datenbank auf allen KDCs zugänglich zu machen. kerberisiert (Kerberized) Dieses Adjektiv beschreibt Server- oder Client-Programme, die das Kerberos-Protokoll unterstützen. Hierbei verlassen sie sich, wenn auch indirekt, für die Authentifizierung auf das KDC, wie wir in Kürze sehen werden. Als Ausweichlösung können diese Programme Benutzer oft auch weiterhin auf konventionellere Arten als mit Kerberos authentifizieren. Kerberos Application Server Ein Application Server, der kerberisierte Server ausführt. Kerberos-Client Dieser Begriff bezieht sich auf einen beliebigen Computer, der von einem KDC ein»ticket«(wird in Kürze beschrieben) erhalten hat. Normalerweise ist der Kerberos- Client ein vom Benutzer ausgeführtes Client-Programm. Realm Eine Kerberos-Realm bezeichnet die Reichweite der Zuständigkeit eines KDC. Kerberos-Realms werden oft nach DNS-Domains oder Subdomains benannt. Bei Realms wird zwar zwischen Groß- und Kleinschreibung unterschieden, allerdings werden sie per Konvention meistens komplett großgeschrieben. Wenn Sie beispielsweise ein Kerberos-System für die Domain example.com einrichten, so bekommt die Realm den Namen EXAMPLE.COM. Die Realm muss jedoch nicht zwingend der Domain entsprechen. So können zusätzliche Rechner einbezogen oder bestimmte Computer ausgeschlossen werden, ganz wie Sie wollen. Tickets Tickets bilden das Herzstück der Kerberos-Authentifizierung. Ein Ticket ist ein verschlüsseltes Datenpäckchen, das zum Zweck der Authentifizierung zwischen Systemen ausgetauscht wird. Die meisten Tickets werden mit einem Passwort verschlüsselt, was bedeutet, dass die korrekte Verschlüsselung des Tickets gleichzeitig dessen Gültigkeit bestätigt. TGT Ein so genanntes Ticket-granting-Ticket ist ein spezielles Ticket, das in der Lage ist, weitere Tickets anzufordern. Das KDC versendet ein TGT an den Benutzer; und dessen Kerberos-Client-Werkzeuge verwenden das TGT daraufhin, um weitere Tickets für den Zugriff auf andere Server anzufordern. 214 Kapitel 9: Konfigurierung und Benutzung von Kerberos

5 TGS Der Ticket-Granting-Service ist ein Subsystem des KDC, das für die Vergabe von TGTs zuständig ist. Prinzipale Ein Kerberos-Prinzipal bezeichnet die Kennung eines Benutzers oder eines Servers. Prinzipale haben die Form primärer_name wobei als primärer_name ein Name (meistens ein Benutzername) benutzt wird, während der Instanzname eine optionale Erweiterung ist, mit der für einen Benutzer mehrere Prinzipale eingerichtet werden können; REALM bezeichnet den Namen der Realm, für die der Prinzipal gültig sein soll. So ist ein möglicher Prinzipal für den Benutzer fluffy in der Realm EXAMPLE.COM. Für Application Server werden die Prinzipale nach dem betreffenden Server benannt, wie z.b. telnet/mandragora.example. für den Telnet-Server, der unter der Subdomain mandragora.example.com zu erreichen ist. Computer, auf denen Application Server laufen, benötigen spezielle Prinzipale, deren primärer Name host lautet, wie z.b. bei COM. Ein Großteil der Administration von Kerberos besteht in der Verwaltung der Prinzipale. Die Tatsache, dass Kerberos auf der Arbeit mit Tickets basiert, schafft gewisse Unterschiede zu den meisten anderen Werkzeugen zur Netzwerk-Authentifizierung, auch wenn viele Details den Benutzern verborgen bleiben. Grob skizziert funktioniert das System folgendermaßen: Der Benutzer fordert von der KDC ein TGT an; dieses wird daraufhin von der KDC an die Kerberos-Werkzeuge auf dem System des Benutzers übergeben. Stellt der Benutzer im Folgenden eine Verbindung zu einem Application Server her, geben die Kerberos-Programme auf dem Client das TGT und weitere Informationen über den Server, zu dem die Verbindung hergestellt werden soll, an die KDC zurück. Dieser antwortet mit einem neuen Ticket, das mit dem Passwort des Application Servers verschlüsselt wurde. Es enthält den Benutzernamen und weitere wichtige Informationen. Das System des Benutzers reicht dieses Ticket nun an den Application Server weiter, der weiß, dass das Ticket gültig ist, weil es mit seinem eigenen Passwort verschlüsselt wurde (das nur dem Application Server und der KDC bekannt ist). Ab diesem Zeitpunkt ist der Benutzer für die Benutzung des Application Servers authentifiziert und die Sitzung kann genauso weitergehen wie bei einem direkteren Austausch von Benutzernamen und Passwörtern. (Der Application Server kann natürlich seine eigenen lokalen Sicherheitsregeln verwenden, um den Zugriff auf Benutzerebene einzuschränken bis hin zum Ausschluss von Benutzern, die bereits von der KDC authentifiziert wurden). Kerberos-Tickets enthalten Zeitstempel und verfallen nach einer bestimmten Zeit. Die Werte hängen von Ihren Kerberos-Einstellungen und der Art des Tickets ab. Wenn die Uhr eines Computers falsch eingestellt ist, kann es daher passieren, dass eine Authentifizierung in einem Kerberos-Netzwerk nicht möglich ist. Aus diesem Grund sollten Sie ein Werkzeug zur Synchronisierung der Netzwerk-Zeit einsetzen, um alle Systemuhren korrekt zu stellen. In Kapitel 15 wird ein Werkzeug für diesen Zweck beschrieben: das Network Time Protocol. Kerberos-Grundlagen 215

6 In der Praxis und aus Sicht des Anwenders besteht die Benutzung von Kerberos aus der Authentifizierung über die KDC und dem Zugriff auf bestimmte Server. Werkzeuge für den ersten Schritt und für die Verwaltung von Kerberos-Sitzungen werden im Abschnitt»Kerberisierte Clients verwenden««beschrieben. Manche Werkzeuge können die KDC- Authentifizierung in den Anmeldevorgang eines Desktop-Systems integrieren, wodurch der Anmeldevorgang aus Sicht der Benutzer relativ nahtlos vor sich geht. Dennoch besteht das Hauptaugenmerk bei Kerberos in der Bereitstellung zentralisierter Netzwerk- Zugriffe, wogegen sich LDAP und in geringem Maße auch NT-Domäne auf zentralisierte Authentifizierungen für Desktop-Anmeldungen konzentrieren. Dieser Unterschied kann recht subtil sein, ist aber wichtig für das Verständnis der Verwendung von Kerberos im Gegensatz zu anderen Werkzeugen. Kerberos ist für Umgebungen geeignet, in denen Benutzer häufig auf mehrere passwort-geschützte Server zugreifen müssen, von denen kerberisierte Versionen zur Verfügung stehen. Weniger nützlich ist Kerberos in Umgebungen, in denen sich Benutzer hauptsächlich bei Ihren Desktop-Rechnern anmelden, ohne häufig auf andere passwort-geschützte Computer zugreifen zu müssen. Für die Authentifizierung von Desktop-Anmeldungen sind LDAP und NT-Domänen besser geeignet. (NT-Domänen, insbesondere für Windows-Desktop-Rechner, bieten außerdem die Illusion eines passwortlosen Zugriffs auf Datei- und Druckerfreigaben, aber nur auf die wenigsten anderen Arten von Servern.) Kerberos-Werkzeuge für Linux Eine der Schwierigkeiten bei Kerberos besteht in der Entscheidung, wofür Kerberos eigentlich benutzt werden soll. Allgemein lassen sich Kerberos-Pakete als V4 oder V5 klassifizieren, wobei V5 die aktuellere Version ist. Linux-Implementierungen beider Versionen sind zum Beispiel: MIT Kerberos Kerberos ist ursprünglich eine Entwicklung des MIT. Daher sehen viele Leute das originale MIT-Kerberos als Standard an. Weitere Informationen finden Sie auf der offiziellen Website unter von wo Sie Kerberos auch herunterladen können. Es gibt eine Quellcode-Version sowie Binärpakete für verschiedene Betriebssysteme, darunter Linux, Windows und MacOS (X und frühere Versionen). Die MIT-Binärdateien für Linux stehen allerdings nur als tar-archiv zur Verfügung. Die letzte Version ist eine Implementierung von Kerberos V5. Heimdal Diese Version des Kerberos V5-Protokolls kommt aus Schweden und steht unter der Adresse zum Herunterladen bereit. Auf der Site finden Sie Quellcode-Dateien, darunter Versionen für Linux, Solaris, DEC Unix und Mac OS X. Die aktuelle Version beim Schreiben dieses Buches war ebones Bei diesem Paket, das Sie unter finden, handelt es sich um eine Implementierung von Kerberos V4. Es liegt manchen Linux-Distributionen in einem Paket mit dem Namen krb4 bei. Als Implementierung von Kerberos 216 Kapitel 9: Konfigurierung und Benutzung von Kerberos

7 V4 ist es bereits ein wenig betagt. Kommt bei Ihnen Kerberos V4 zum Einsatz, müssen Sie aber auch diese Möglichkeit in Betracht ziehen. Beim Schreiben dieses Buches war die aktuellste Version Viele Distributionen enthalten eine oder mehrere dieser Implementierungen in Binärform. Typischerweise ist MIT-Kerberos unter Paketnamen wie mit-krb5 oder krb5 zu finden, während Heimdal-Pakete oft den Namen heimdal oder etwas Ähnliches tragen. Manche Distributionen teilen die Kerberos-Pakete in mehrere Teile auf, wobei die Basiswerkzeuge, Server und Clients voneinander getrennt werden. Theoretisch sollte es daher möglich sein, verschiedene Kerberos V5-Implementierungen miteinander zu mischen und aufeinander abzustimmen (z.b. MIT Kerberos-Server und Heimdal-Clients); in der Praxis sollten Sie allerdings möglichst bei einem einzelnen Produkt bleiben. Probleme treten am wahrscheinlichsten bei den Werkzeugen zur Administration auf, oder wenn Sie versuchen, Master- und Slave-KDCs verschiedener Typen zu mischen. Probleme zwischen Clients und KDCs oder Application Servern sind weniger häufig. Auch betriebssystem-übergreifende Anwendungen (z.b. die Verwendung von Linux-Clients für MIT- Kerberos und einer MacOS-basierten KDC) sollten möglich sein, auch wenn es hierbei gelegentlich zu Problemen kommt. Da Kerberos V4 langsam in die Jahre kommt und einige Sicherheitsmängel auf Protokollebene enthält, werden wir uns in diesem Kapitel nur mit Kerberos V5 beschäftigen. Als Referenz für dieses Kapitel wurden die MIT- und Heimdal-Implementierungen von Kerberos V5 verwendet. Die primäre KDC der Referenz- Realm läuft mit Heimdal 0.6 unter SUSE 9.1. Für die meisten Aufgaben beschreiben wir aber die Werkzeuge und Befehle von Heimdal und MIT Kerberos. Die Kerberos-Pakete für Linux enthalten bereits eine große Anzahl von kerberisierten Servern und Clients, inklusive Telnet, rlogin, FTP, rsh und rcp. In den folgenden Abschnitten dieses Kapitels finden Sie detaillierte Beschreibungen dieser Werkzeuge. Kerberos wurde so entwickelt, dass fast jedes Protokoll die benötigten Authentifizierungen über Kerberos durchführen kann. Daher geht die Liste der kerberisierten Protokolle auch über die dem Hauptpaket beliegenden hinaus. Wollen Sie Kerberos mit einem nicht beiliegenden Protokoll benutzen, müssen Sie an anderer Stelle suchen. Auch wenn die Unterstützung für Kerberos lange nicht vollständig ist, wird das Protokoll von vielen Clients und Servern unterstützt. Manchmal besteht diese Unterstützung in einer Kompilierungsoption; es kann also sein, dass Sie die betreffende Software neu kompilieren müssen, damit die Kerberos-Fähigkeiten zur Verfügung stehen. In anderen Fällen müssen Sie vielleicht einen anderen Client oder ein anderes Server-Paket verwenden. Obwohl die Unterstützung für Kerberos sich bei weitem nicht nur auf Clients und Server beschränkt, ist sie längst nicht universell. Es kann also sein, dass eine lange und aufwändige Suche nötig ist, um das kerberisierte Werkzeug für eine bestimmte Aufgabe zu finden. Kerberos-Grundlagen 217

8 Windows und Kerberos Theoretisch lässt sich Windows genauso leicht in eine Kerberos-Realm einbinden wie Linux. In der Praxis müssen Sie natürlich erst einmal wissen, wie die nötigen Einstellungen auf diesen Systemen vorgenommen werden. Die Speicherorte für Konfigurationsdateien und ähnliche Dinge sind für beide Systeme unterschiedlich. Eventuell stoßen Sie auch auf Probleme mit der Kompatibilität bestimmter Kerberos-Implementierungen. Wir weisen an dieser Stelle besonders darauf hin, dass Windows 2000 und neuere Versionen eine AD-Unterstützung enthalten, die teilweise auf Kerberos basiert. Allerdings gibt es bei der Microsoft-Implementierung im Vergleich mit anderen Anbietern gewisse Unterschiede. Hierzu gehören besonders die folgenden Bereiche: Verschlüsselungsalgorithmen Aus politischen und technischen Gründen hat sich Microsoft entschlossen, andere Verschlüsselungsalgorithmen zu verwenden als in den Kerberos-Versionen von Wenn Sie einen AD-Controller als KDC benutzen, müssen Sie daher entweder bei der KDC die Verschlüsselung per Data Encryption Standard (DES) aktivieren und die Benutzer-Passwörter ändern, oder Sie benutzen auf den Systemen ohne Windows eine aktuelle Kerberos-Version (wie MIT-Kerberos 1.3 oder neuer). Das PAC Das vermutlich größte Problem bei der Kompatibilität zwischen Windows- und Nicht-Windows-Systemen, die Kerberos verwenden sollen, hängt mit dem Privilege Access Certificate (PAC) zusammen. Hierbei handelt es sich um ein zusätzliches Feld, um das Windows-KDCs ihre Tickets erweitern. Die Windows-Clients von Microsoft weigern sich in der Regel, mit KDCs zusammenzuarbeiten, die kein PAC zurückgeben, wodurch es beispielsweise bei der Zusammenarbeit mit Linux-KDCs zu Schwierigkeiten kommt. Das PAC von Microsoft wurde eigentlich proprietär entwickelt, dennoch wurde Ende 2003 Dokumentation verfügbar, die dieses Problem abschwächen konnte. Zum Glück ignorieren Kerberos-Implementierungen, die nicht von Microsoft stammen, das PAC einfach, wodurch Linux-basierte Kerberos-Application Server und -Clients meistens auch mit einem Windows-KDC funktionieren. Zwischengespeicherte Benutzerinformationen (Credentials) Damit Benutzer sich auch anmelden können, wenn es Probleme mit dem KDC oder dem Netzwerk gibt, führen Windows-Systeme eine Zwischenspeicherung der vom Benutzer eingegebenen Anmeldeinformationen durch. Normalerweise gibt es bei diesem Vorgehen keine Probleme. Meldet sich ein Benutzer allerdings mit gespeicherten Anmeldedaten an und wird während der Sitzung ein Microsoft-basiertes KDC verfügbar, so bleibt das KDC für das System sehr wahrscheinlich unsichtbar, wodurch ein Zugriff auf die Netzwerk-Ressourcen unter Umständen verhindert wird. Insgesamt funktioniert die Zusammenarbeit zwischen einer Microsoft-basierten KDC für Ihr Netzwerk und Linux-Application Servern und -Clients recht gut. Bei der Benutzung von älteren Kerberos-Implementierungen sollten Sie allerdings die Aktivierung der DES- 218 Kapitel 9: Konfigurierung und Benutzung von Kerberos

9 Unterstützung nicht vergessen. Danach müssen Sie die Passwörter aktualisieren, damit diese auch mit DES verschlüsselt werden. Dieser Schritt ist bei aktuellen Implementierungen von Kerberos V5 für Linux vermutlich nicht nötig. (Im Zweifelsfall überprüfen Sie, ob Ihre Kerberos-Implementierung den Verschlüsselungsalgorithmus RC4-HMAC unterstützt.) Eine detaillierte Beschreibung der Administrierung eines Windows-basierten KDC würde den Rahmen dieses Buches allerdings sprengen. Die Verwendung von Windows-Clients mit einem nicht Microsoft-basierten KDC ist etwas schwieriger, aber nicht unmöglich. In diesem Fall müssen Sie für Ihre Benutzer auf dem Windows-System lokale Benutzerkonten anlegen und Windows danach mit speziellen Werkzeugen für die Benutzung der Kerberos-Authentifizierung einrichten. Eine detaillierte Beschreibung dieses Vorgehens finden Sie im Abschnitt»Kerberisierte Windows- Clients«weiter hinten in diesem Kapitel. Alternativ dazu können Sie auch ein Kerberos- Paket installieren, das nicht von Microsoft stammt, und auf die Verwendung von Kerberos bei der Authentifizierung von Anmeldungen verzichten. Stattdessen verwenden Sie, ähnlich wie auch bei Linux, reguläre kerberisierte Clients und Server unter Windows. Konfigurierung des Kerberos-Servers unter Linux Die größte Schwierigkeit bei der Einbindung von Kerberos in Ihr Netzwerk besteht in der Konfigurierung des Kerberos-Servers des KDC. Als Erstes muss die Konfigurationsdatei für den Server angepasst werden. Das ist aber noch lange nicht alles. Sie müssen außerdem einen Masterkey erzeugen, mit dem die Kommunikation des KDC verschlüsselt wird. Zur Praxis bei der Arbeit mit Kerberos-Realms gehören außerdem Aufgaben wie das Anlegen von Prinzipalen und die Konfigurierung von Regeln zur Zugriffskontrolle. Schließlich müssen Sie noch die Kerberos-Server zum Laufen bringen (den Haupt-Kerberos-Server und einen separaten Server für die Administration). Konfigurierung der Kerberos-Realm MIT Kerberos verwendet zwei Konfigurationsdateien: krb5.conf und kdc.conf. Heimdal verzichtet dagegen auf die zweite Datei, so dass Sie diese bei der Benutzung von Heimdal auch nicht einzurichten brauchen. Die Datei krb5.conf enthält bestimmte Informationen über Ihre Realm und den Betrieb Ihres Servers, während in kdc.conf Informationen abgelegt werden, die sich speziell auf das KDC beziehen. Ein Großteil der Informationen zu der Realm in krb5.conf wird von Application Servern und Clients benötigt. Daher wird die Datei auch von diesen Systemen benutzt, obwohl möglicherweise einige Bereiche fehlen oder ignoriert werden. Konfigurierung des Kerberos-Servers unter Linux 219

10 krb5.conf anpassen Die Haupt-Konfigurationsdatei für das KDC heißt krb5.conf. Wenn Sie Kerberos aus einem Paket installieren, liegt diese Datei sehr wahrscheinlich im Verzeichnis /etc. In Beispiel 9-1 sehen Sie ein Beispiel für eine krb5.conf-datei. Beispiel 9-1: Beispiel für die Einträge in krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] ticket_lifetime = default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false [realms] EXAMPLE.COM = { kdc = kdc.example.com:88 admin_server = kdc.example.com:749 default_domain = example.com } [domain_realm].example.com = EXAMPLE.COM tropical.pangaea.edu = EXAMPLE.COM Diese Datei wird in mehrere Abschnitte unterteilt. Jeder Abschnitt beginnt mit dessen Namen in eckigen Klammern ([]). Die meisten Optionen erstrecken sich über eine Zeile und bestehen aus dem Namen der Option, gefolgt von einem Gleichheitszeichen (=) und dem Wert der Option. Einige Optionen verwenden auch zusammengesetzte Werte, die sich über mehrere Zeilen erstrecken können und mit geschweiften Klammern ({}) umgeben werden. Ein Beispiel hierfür sehen Sie bei dem Eintrag EXAMPLE.COM im Abschnitt [realms]. Viele der krb5.conf-parameter sind selbsterklärend, andere benötigen allerdings ein paar Erläuterungen: Logging-Optionen Die Optionen im Abschnitt [logging] teilen dem Server mit, wo Daten protokolliert werden sollen, die den Betrieb von Kerberos betreffen. Dieser Abschnitt ist für die Installationen von Application Servern und Clients nicht notwendig, sondern nur für KDCs. Lebensdauer der Tickets Mit der Option ticket_lifetime setzen Sie die Standard-Lebensdauer (in Sekunden) für die meisten vom KDC vergebenen Tickets. Der in Beispiel 9-1 gezeigte Wert entspricht einer Lebensdauer von acht Stunden. Bei zu großen Werten erhöht sich das Risiko von Sicherheitsproblemen durch gestohlene Tickets; ein zu kleiner 220 Kapitel 9: Konfigurierung und Benutzung von Kerberos

11 Wert ist für Benutzer unbequem, da sie ihre Kerberos-Sitzungen neu initialisieren müssen. Standard-Realm Mit der Option default_realm legen Sie fest, welche Realm das KDC verwalten soll. Der Wert entspricht sehr wahrscheinlich Ihrem DNS-Domainnamen, ohne dass dies allerdings zwingend wäre. Optionen für DNS-Abfragen Die Optionen dns_lookup_realm und dns_lookup_kdc teilen Kerberos mit, dass DNS für das Auffinden von Systemen verwendet werden soll. Realm-Definitionen Im Abschnitt [realms] werden die Kerberos-Realms definiert. In Beispiel 9-1 ist dies die Realm EXAMPLE.COM. Zur Definition gehören Verweise auf ein KDC und einen administrativen Server. (Werden in Ihrer Realm Slave-KDCs eingesetzt, werden diese genau wie der Master mit einer eigenen kdc-zeile definiert.) Der administrative Server ist für Verwaltungsaufgaben wie etwa das Hinzufügen von Prinzipalen zuständig. Normalerweise befindet sich dieser auf dem gleichen Server wie das Master-KDC. Zu den Definitionen gehören die Portnummern 88 für das KDC und 749 für den administrativen Server. Anhand der Option default_domain wird festgelegt, welcher Domain-Name bei Bedarf mit dem Prinzipal assoziiert werden soll. In einer krb5.conf -Datei können mehrere Realms eingerichtet werden. In unserem Beispiel werden die Realms zwar im gleichen [realms]-abschnitt, aber auf eigenen Zeilen definiert. Abbilden von Domains auf Realms Im Abschnitt [domain_realm] wird festgelegt, auf welche Weise Computer auf Realms abgebildet werden sollen. In Beispiel 9-1 gehören alle Computer der Domain example.com zur Realm EXAMPLE.COM sowie der Rechner tropical.pangaea.edu. Subdomains werden mit einem führenden Punkt (.) markiert. Einträge ohne diesen Punkt werden als einzelne Rechner betrachtet. Zusätzlich zu den in Beispiel 9-1 gezeigten Einträgen gibt es bei MIT Kerberos sehr wahrscheinlich noch einen Eintrag, der auf die Datei kdc.conf verweist: [kdc] profile = /var/kerberos/krb5kdc/kdc.conf In manchen Beispiel-Konfigurationsdateien findet sich auch ein Abschnitt mit dem Namen [appdefaults]. Hiermit werden bestimmte Änderungen an den Einstellungen für bestimmte Application Server und Clients festgelegt. So wollen Sie die Lebensdauer für Tickets vielleicht an die wahrscheinliche Länge einer Sitzung für den bestimmten Dienst anpassen. kdc.conf anpassen Die Kerberos-Implementierung von Kerberos legt die Optionen für das KDC typischerweise in einer eigenen Datei mit dem Namen kdc.conf ab, auf die mit einer profile- Option im Abschnitt [kdc] von krb5.conf verwiesen wird. In Beispiel 9-2 sehen Sie ein Konfigurierung des Kerberos-Servers unter Linux 221

12 typisches Beispiel dieser Datei. Die meisten dieser Optionen sollten Sie nicht verändern. Sie können allerdings den Namen der Kerberos-Realm auf der ersten Zeile des Abschnitts [realms] anpassen. Die Optionen master_key_type und supported_enctypes beziehen sich auf die von Kerberos unterstützten Verschlüsselungsmethoden. Beispiel 9-2: Beispiel für die Einträge in kdc.conf [kdcdefaults] acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth [realms] EXAMPLE.COM = { master_key_type = des-cbc-crc supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbccrc:v4 des-cbc-crc:afs3 } Einen Masterkey erzeugen Wegen seines hohen Sicherheitsanspruchs verwendet Kerberos einen so genannten kryptographischen Masterkey. Ohne diesen Schlüssel wird Kerberos nicht starten. Der Schlüssel wird aus einem Passwort erzeugt, das in einer so genannten Stash-Datei gespeichert werden kann. Durch die Benutzung einer Stash-Datei kann Kerberos beim Booten des Computers automatisch gestartet werden; ohne Stash-Datei müssen Sie bei jedem Start des Kerberos-Servers das Passwort eingeben. Bei der Heimdal-Implementierung trägt das Werkzeug zum Erstellen des Masterkeys und der Stash-Datei den Namen kstash. (Heimdal verwendet eine einzelne Datei für beide Zwecke.) Um einen neuen Schlüssel und die Stash-Datei anzulegen, können Sie den folgenden Befehl verwenden: # kstash Master key: Verifying - Master key: kstash: writing key to `/var/heimdal/m-key' Wie die meisten Hilfsprogramme, die nach einem Passwort fragen, stellt auch kstash das Passwort bei der Eingabe nicht dar. Bei MIT Kerberos kommt zum Anlegen des Masterkeys und der Stash-Datei das Hilfsprogramm kdb5_util zum Einsatz: # kdb5_util create -r EXAMPLE.COM -s Loading random data Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: 222 Kapitel 9: Konfigurierung und Benutzung von Kerberos

13 Der Masterkey, die Stash-Datei und das Passwort sind extrem sensibel. Um diese Informationen zu schützen, sollten die Hilfsprogramme Dateien mit angemessenen Rechten anlegen (typischerweise 0600), wobei davon ausgegangen wird, dass zumindest der Kerberos-Server nicht kompromittiert wurde. Sie sollten besonders darauf achten, das Passwort nicht zu vergessen oder es in falsche Hände geraten zu lassen. Suchen Sie sich ein Passwort, das so nah wie möglich an einer zufälligen Reihe von Buchstaben, Zahlen und Interpunktionszeichen ist, ohne aber das Risiko einzugehen, es zu vergessen. Verwenden Sie das Passwort auf keinen Fall für andere Konten oder Server. Administration von Realms Jetzt ist Ihr KDC fast schon für die Benutzung bereit. Allerdings müssen Sie immer noch einen Prinzipal anlegen und Regeln zur Zugriffskontrolle definieren. Beide Aufgaben sind für den normalen Betrieb von Kerberos sehr wichtig. Vermutlich werden Sie diese Aufgaben, besonders das Anlegen von Prinzipalen, in Zukunft einige Male durchführen. Prinzipale Im Prinzip sind Prinzipale die Benutzerkonten von Kerberos. Um korrekt zu funktionieren, braucht Kerberos einige Prinzipale auf jeden Fall. Zusätzlich wollen Sie vermutlich Prinzipale für weitere Benutzer einrichten. In diesem Abschnitt werden beide Aufgaben beschrieben. Application Server benötigen ebenfalls Prinzipale, deren Einrichtung aber im Abschnitt»Die Prinzipale für den Application Server vorbereiten«beschrieben wird. Für die Verwaltung von Prinzipalen liegt Kerberos das Werkzeug kadmin bei. Normalerweise baut das Werkzeug hierfür eine Verbindung zum administrativen Kerberos-Server auf (definiert über die Option admin_server in krb5.conf). Momentan läuft dieser Server aber noch nicht, weil er noch nicht vollständig konfiguriert wurde. Daher müssen Sie die Prinzipale momentan noch ohne den Server anlegen. Bei Heimdal geschieht dies durch den Aufruf von kadmin mit der Option -l. Bei MIT Kerberos benutzen Sie dagegen den verwandten Befehl kadmin.local. Bei Heimdal sieht die Interaktion für die Initialisierung der Realm wie folgt aus: # kadmin -l kadmin> init EXAMPLE.COM Realm max ticket life [unlimited]: Realm max renewable ticket life [unlimited]: kadmin> add admin/admin@example.com Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes [ ]: admin/admin@example.com's Password: Verifying - admin/admin@example.com's Password: Konfigurierung des Kerberos-Servers unter Linux 223

14 Der Befehl init initialisiert die Kerberos-Datenbank. Dies sollte bei der ersten Benutzung des Programms der erste Befehl sein, den Sie eingeben. Mit dem Befehl add wird danach ein Prinzipal für den administrativen Benutzer angelegt. (Sie können bei Bedarf auch andere primäre Namen und Instanznamen verwenden, wobei der Prinzipal aber aus Ihrer Domain stammen muss.) Bei MIT Kerberos ist die Eingabe von init nicht nötig, und der Befehl add heißt hier addprinc. Dafür benötigen Sie bei der MIT-Variante den Befehl ktadd, um einen so genannten keytab anzulegen. Hierbei handelt es sich um einen speziellen Schlüssel, den Kerberos für die Verwaltung administrativer Prinzipale verwendet: kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw Das System sollte nun mit einem recht ausführlichen Bericht über das Anlegen der keytab-dateien antworten. Egal ob Sie Heimdal oder MIT Kerberos verwenden, wollen Sie zu diesem Zeitpunkt vermutlich ein oder zwei Testkonten anlegen. Für diese lassen wir der Einfachheit halber die Instanznamen weg. Wenn Sie einen Prinzipal für die Standard-Realm anlegen, brauchen Sie nicht einmal den Namen der Realm anzugeben: kadmin> add fluffy Heimdal ist bei den zu diesem Zeitpunkt gestellten Fragen etwas ausführlicher, wobei als Antwort meistens der Standardwert ausreicht. Unabhängig davon, welchen Server Sie verwenden, müssen Sie ein Passwort eingeben. Nachdem das KDC und der kadmind-server laufen, können Sie den Server mit kadmin auch von einem anderen Rechner aus administrieren. Allerdings ist das kadmin-programm für MIT-Kerberos nicht für die Administrierung eines Heimdal-Servers geeignet oder umgekehrt. Die administrativen Protokolle sind nicht miteinander kompatibel. ACL-Definitionen Kerberos verwendet ACLs (Listen zur Zugriffskontrolle), um zu ermitteln, wer auf welche Weise auf den Server zugreifen darf (hiermit ist kadmind gemeint nicht das KDC als Ganzes). Die ACLs für Kerberos ähneln vom Konzept her den Dateisystem-ACLs, sind aber nicht identisch und basieren auch nicht auf den ACLs für Dateisysteme. Die ACLs für Kerberos werden in einer speziellen Datei definiert. Bei Heimdal ist dies in der Regel /var/heimdal/kadmind.acl; bei MIT Kerberos ist es die Datei, auf die im Eintrag acl_file in kdc.conf verwiesen wird. (Bei Heimdal können Sie diesen Parameter in einem [kdc]- Abschnitt in dessen krb5.conf-datei definieren, falls Sie hier eine andere Datei verwenden wollen.) Die ACL-Datei besteht aus mehreren Zeilen, die jeweils zwei bis drei Einträge enthalten: Kerberos-Prinzipal Rechte [Ziel-Prinzipal] Der erste Eintrag, Kerberos-Prinzipal, ist der Prinzipal, für den die ACL gilt, sprich: der Benutzer, dessen Rechte hier definiert werden. Bei den Rechten handelt es sich um eine Zeichenkette aus einem oder mehreren Buchstaben (bei MIT Kerberos) oder eine durch 224 Kapitel 9: Konfigurierung und Benutzung von Kerberos

15 Kommata getrennte Liste von Codes (bei Heimdal), die sämtliche Operationen definieren, die ein Benutzer ausführen kann; eine Zusammenfassung finden Sie in Tabelle 9-1. Ist keine dritte Option vorhanden, werden diese Rechte auch auf alle anderen Prinzipale angewandt. Gibt es dagegen einen dritten Eintrag, so bezeichnet dieser die Prinzipale, die der erste angegebene Prinzipal auf die angegebene Weise modifizieren darf. Auf diese Weise können Sie bestimmten Benutzern erlauben, bestimmte Klassen von Prinzipalen zu verändern, andere aber nicht. Tabelle 9-1: Kerberos-Codes für ACL-Rechte Code für MIT Kerberos Code für Heimdal Bedeutung a add Prinzipale oder Regeln können hinzugefügt werden. A Prinzipale oder Regeln können nicht hinzugefügt werden. d delete Prinzipale oder Regeln können gelöscht werden. D Prinzipale oder Regeln können nicht gelöscht werden. m modify Prinzipale oder Regeln können verändert werden. M Prinzipale oder Regeln können nicht verändert werden. c cpw or change-password Passwörter können verändert werden. C Passwörter können nicht verändert werden. i get Datenbank-Anfragen dürfen durchgeführt werden. I Datenbank-Anfragen dürfen nicht durchgeführt werden. l list Eine Liste von Prinzipalen oder Regeln darf angezeigt werden. L Eine Liste von Prinzipalen oder Regeln darf nicht angezeigt werden. x oder * all Wildcard-Zeichen für»darf alles«(admcil). Bei beiden Prinzipal-Angaben kann ein Sternchen (*) als Wildcard-Zeichen benutzt werden. So können Sie beispielsweise bei MIT Kerberos sämtlichen Benutzern der Instanz admin alles erlauben, indem Sie schreiben: */admin@example.com * Bei MIT Kerberos gibt es bereits Einträge wie diesen. Allerdings sollten Sie diese für Ihre Realm anpassen. Vermutlich wollen Sie auch die ACLs noch etwas feiner auf Ihre Bedürfnisse abstimmen, z.b. indem Sie verschiedene Administratorengruppen einrichten, die unterschiedliche Zugriffsrechte auf die administrativen Funktionen des Servers bekommen. Heimdal liegt standardmäßig keine ACL-Datei bei, daher wollen Sie hier vermutlich erst einmal eine anlegen. Wird diese Datei nicht angelegt, ist eine Administration von anderen Systemen aus nicht möglich. Zu den hierfür nötigen Aufgaben gehört auch das Anlegen von Prinzipalen oder die Extraktion von Keytabs. Diese sind für das Hinzufügen von Application Servern zur Kerberos-Domain notwendig. (Selbstverständlich können Sie diese Aufgaben auch weiterhin am KDC selbst ausführen; allerdings müssen Sie sensible Keytab-Dateien dann irgendwie auf den Application Server übertragen, z.b. mit einer Diskette oder einer Dateiübertragung über das Netzwerk.) Konfigurierung des Kerberos-Servers unter Linux 225

16 Das KDC starten Um einen Nutzen zu haben, muss das KDC auch laufen. Auf den meisten Linux-Systemen können Sie das KDC über ein SysV-Startup-Skript starten: # /etc/init.d/kdc start Die Details unterscheiden sich von einer Distribution zur anderen; vielleicht heißt das Skript kdc, krb5kdc, mit-krb5kdc oder auch ganz anders. Eventuell müssen Sie die Paketverwaltung Ihrer Distribution verwenden oder einfach die SysV-Startup-Skripten durchsuchen, um das Richtige zu finden. Manche Startup-Skripten starten den administrativen und den KDC-Server gemeinsam. Andere Systeme enthalten ein separates Skript für den Start des administrativen Servers. Dieses trägt oft Namen wie mit-krb5kadmind, kadmin o.ä. Auch in diesem Fall müssen Sie eventuell die Ihrem System beiliegenden Startup-Skripten durchsuchen, um das gewünschte Skript zu finden. Normalerweise wollen Sie den administrativen Server auf dem Master-KDC laufen lassen. Ansonsten ist die Möglichkeit, die Realm von außerhalb des KDCs zu verwalten, stark eingeschränkt. Zu Testzwecken ist es in Ordnung, KDC und den administrativen Server manuell zu starten. Für den richtigen Betrieb wollen Sie Ihr System aber vermutlich so einrichten, dass die Server regelmäßig neu gestartet werden. Bei vielen Distributionen kann hierfür der Befehl chkconfig verwendet werden: # chkconfig --add kdc Bei anderen Distributionen kommen möglicherweise andere Werkzeuge für diese Aufgabe zum Einsatz. Hilfe zu dieser Aufgabe finden Sie in der Dokumentation zu Ihrer Distribution. Konfigurierung von Kerberos-Application Servern Die Einrichtung eines Master-KDC ist der umfangreichste Teil bei der Konfigurierung einer Kerberos-Realm. Für sich allein ist das KDC jedoch nur wenig sinnvoll. Der nächste Schritt besteht daher in der Konfigurierung eines oder mehrerer Application Server. Jeder Rechner, auf dem ein Application Server laufen soll, benötigt bestimmte Kerberos-Grundeinstellungen, die teilweise den Einstellungen für das KDC ähnlich sind. Auch für die Application Server müssen Prinzipale und die nötigen Keytabs angelegt werden. Danach können Sie die Serverprogramme starten, um sie Ihren Benutzern zugänglich zu machen. Kerberos einrichten Jedes Linux-System, auf dem ein Kerberos-Application Server laufen soll, benötigt gewisse Grundeinstellungen, die teilweise denen für das KDC gleichen. So müssen Sie auch hier besonders die Datei /etc/krb5.conf nach den Beschreibungen im Abschnitt»krb5.conf anpassen««einrichten. Allerdings können Sie beim Einsatz als Application Server die Abschnitte [logging] und [kdc] weglassen. 226 Kapitel 9: Konfigurierung und Benutzung von Kerberos

17 Die Prinzipale für den Application Server vorbereiten Bevor Sie den Application Server laufen lassen können, müssen Sie die für den Server nötigen Prinzipale anlegen (sowohl für den Server-Computer als auch für die einzelnen Server-Programme). Darüber hinaus müssen Sie auf dem Application Server-Rechner die Keytabs für diese Prinzipale installieren. Als Erstes müssen die Prinzipale angelegt werden. Das funktioniert in weiten Teilen wie das Anlegen von Prinzipalen für normale Benutzer mit den Befehlen kadmin oder kadmin.local. Sie können die Prozedur vereinfachen, indem Sie den Befehl mit der Option -r (in Heimdal) bzw. -randkey (in MIT Kerberos) aufrufen. Hierdurch wird dem Prinzipal ein zufällig erzeugtes Passwort zugewiesen. Da dieses Passwort nur der Software auf dem Server-Rechner bekannt sein muss, sollte dieses Vorgehen hier recht gut funktionieren. Allgemein werden für die Prinzipale als Instanzname der DNS-Rechnername des Server- Computers und als primärer Name host (für den Rechner als Ganzes) bzw. die einzelnen Server verwendet. Einige Server benötigen allerdings keine eigenen Prinzipale. Um beispielsweise gingko.example.com als kerberisierten Telnet-Server zu verwenden, geben Sie Folgendes ein (hier in kadmin der Heimdal-Variante): kadmin> add -r host/gingko.example.com Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes [ ]: kadmin> add -r telnet/gingko.example.com Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes [ ]: Der kerberisierte Telnet-Server benötigt keinen eigenen Prinzipal. Sie können die zweite add-anweisung im obigen Beispiel also auch weglassen. Wenn die Prinzipale angelegt sind, müssen diese in eine Keytab-Datei extrahiert werden. Hierfür verwenden Sie innerhalb von kadmin entweder den Befehl ext_keytab (Heimdal) oder ktadd (MIT Kerberos): kadmin> ext_keytab -k gingko.keytab host/gingko.example.com telnet/gingko.example.com Über die Option -k teilen Sie dem Programm mit, in welcher Datei die Keytab gespeichert werden soll. Wenn Sie diesen Schritt am Application Server selbst durchführen, können Sie den Dateinamen /etc/krb5.keytab direkt eingeben. Erledigen Sie diese Aufgabe dagegen von einem anderen Rechner aus, z.b. dem KDC, können Sie die Keytab unter einem beliebigen Namen ablegen. Danach müssen Sie die Datei aber irgendwie auf den Application Server übertragen und dort als /etc/krb5.keytab speichern. Wollen Sie dem Application Server zusätzliche kerberisierte Server hinzufügen, müssen Sie weitere Konfigurierung von Kerberos-Application Servern 227

18 Prinzipale anlegen und diesen Schritt wiederholen, indem Sie erneut die Prinzipale für sämtliche Server-Programme angeben. Alternativ dazu können Sie nur die neuen Prinzipale anlegen und in einer separaten Datei abspeichern. Danach können Sie die Dateien mit cat oder ähnlichen Werkzeugen zusammenfügen. Keytab-Dateien dienen als Identitätsnachweis für den Server. Aus diesem Grund sind diese Dateien extrem empfindlich und sollten unter keinen Umständen über unverschlüsselte Netzwerkprotokolle wie z.b. nicht-kerberisiertes FTP oder NFS übertragen werden. Für Übertragungen in einem Netzwerk ist das Werkzeug scp (Teil des SSH- Pakets) eine gute Wahl. Alternativ können Sie auch eine Diskette oder ein anderes Wechselmedium verwenden. Allerdings sollten Sie die Diskette nach getaner Arbeit auf unterster Ebene formatieren oder die Keytab-Datei auf andere Weise dauerhaft von dem Medium entfernen (z.b. mit wipe). Ein Löschen der Datei per rm reicht nicht aus! Wenn Sie die Keytab-Datei auf dem KDC-Rechner erzeugen, sollten Sie nicht vergessen, sie auch hier mit wipe oder einem ähnlichen Werkzeug, das die Daten vollständig zerstört, wieder zu löschen. Das KDC speichert eine Kopie der Keytab-Datei in seiner Prinzipal- Datenbank, die ohne angemessenen Schutz leicht in die falschen Hände geraten kann. Die Server ausführen Sobald die Keytab-Datei für den Application Server an ihrem Platz ist, könen Sie die Server-Programme starten. Das funktioniert in weiten Teilen wie bei nicht-kerberisierten Servern auch. Die Kerberos standardmäßig beiliegenden Server werden typischerweise von einem Superserver (inetd oder xinetd) gestartet. In Beispiel 9-3 sehen Sie eine Datei aus dem Verzeichnis /etc/xinetd.d, die bei Bedarf einen kerberisierten Telnet-Server (ktelnetd) startet, der MIT Kerberos beiliegt. Beispiel 9-3: Beispiel für eine xinetd-konfigurationsdatei für den kerberisierten Telnet-Server service telnet { disable socket_type protocol wait user group server server_args } = no = stream = tcp = no = root = root = /usr/sbin/ktelnetd = -a valid Die Standard-Kerberos-Server unterstützen eine Reihe zusätzlicher Optionen, die Sie aktivieren müssen, damit die Authentifizierung über Kerberos funktioniert: klogind Dieses Programm arbeitet mit dem Befehl rlogin zusammen. In der Regel benutzen Sie hierfür die Optionen -k (Kerberos-Authentifizierung aktivieren), -e (Verschlüsselung aktivieren) und -c (zur Erhöhung der Sicherheit eine kryptographische Prüfsumme vom Client anfordern). 228 Kapitel 9: Konfigurierung und Benutzung von Kerberos

19 kshd Dieser Server für entfernte Shell-Zugriffe wird zusammen mit rsh verwendet, um die Ausführung von Programmen zu ermöglichen. Auch werden Sie vermutlich die gleichen Parameter -k, -e und -c benutzen, die bereits für klogind beschrieben wurden. kftp Bei diesem Programm handelt es sich um einen kerberisierten FTP-Server. Bei einigen Versionen dieses Programms werden Sie vermutlich die Option -a valid benutzen, mit der die Authentifizierung über Kerberos aktiviert wird. Andere Versionen benötigen diese Option dagegen nicht. Um herauszufinden, ob die Option bei Ihrer Programmversion nötig ist, sollten Sie in der Dokumentation zu Ihrem Kerberos- Paket nachschlagen. ktelnetd Dieser Server ermöglicht den kerberisierten Telnet-Zugriff auf einen Computer. Wie bei kftpd kann es sein, dass eine -a valid-option nötig ist, um die Authentifizierung per Kerberos zu aktivieren. Diese Server unterstützen die Verschlüsselung nur, wenn sie auch zusammen mit den passenden Clients wie jenen, die Kerberos beiliegen, verwendet werden. Kommen nicht-kerberisierte Clients zum Einsatz, bieten die Server keinerlei Vorteile gegenüber ihren nicht-kerberisierten Gegenstücken. Die Server unterstützen noch eine Reihe weiterer Optionen, die sich nicht auf den Betrieb von Kerberos beziehen. Abhängig von den Einstellungen werden Kerberos-Anmeldungen akzeptiert oder abgelehnt. Für weitere Details sollten Sie in den jeweiligen Manpages oder anderen Dokumentationen nachschlagen. (Manchen Paketen liegen keine Manpages für die Server bei.) Bei manchen Kerberos-Paketen (insbesondere Heimdal) wird das k am Anfang der Dateinamen für die Server weggelassen. Außerdem kann sich der Speicherort für die Serverdateien zwischen den einzelnen Paketen unterscheiden. Am einfachsten finden Sie die Details heraus, indem Sie einen Blick auf den Inhalt Ihres Pakets werfen. Zusätzlich zu den hier vorgestellten Programmen gibt es noch weitere kerberisierte Server. Bei manchen ist die Unterstützung für Kerberos in den Haupt-Server integriert, muss aber möglicherweise bei der Kompilierung aktiviert werden. Dies ist beispielsweise bei Samba der Fall, allerdings nur, wenn Sie auch die entsprechenden Optionen bei der Kompilierung angeben. (Die Details der Kerberos-Fähigkeiten von Samba sind allerdings zu komplex, um sie angemessen in diesem Buch wiedergeben zu können.) Für einige Protokolle steht Kerberos zur Verfügung, für andere nicht. Benötigen Sie Kerberos-Unterstützung, sollten Sie daher die Dokumentation Ihrer bevorzugten Server konsultieren. Wird Kerberos nicht unterstützt, finden Sie vielleicht einen Ersatz über eine Web-Suche. Bei der Aktivierung von Kerberos für die einzelnen Server gibt es große Unterschiede; Sie werden daher um das Lesen der Dokumentationen für die Server wohl nicht herum kommen. Konfigurierung von Kerberos-Application Servern 229

20 Konfigurierung von Kerberos-Clients unter Linux Kerberisierte Clients sind leichter zu konfigurieren als KDCs oder Application Server. Trotzdem müssen auch hier ein paar Grundeinstellungen vorgenommen werden. Eventuell müssen Sie sich erst spezielle kerberisierte Versionen der Clients für bestimmte Protokolle besorgen, wenn Sie Werkzeuge benutzen wollen, die Kerberos nicht beiliegen. Wenn alles eingerichtet ist, sollten Sie zumindest ein Basiswissen über die grundlegenden Werkzeuge für die Kerberos-Benutzerverwaltung haben, weil diese die Benutzerzugriffe auf die Realm kontrollieren. Kerberos-Clients vorbereiten Die wichtigste Voraussetzung für die Konfigurierung von Kerberos-Clients ist die Einrichtung einer Kerberos-Konfigurationsdatei, krb5.conf, wie weiter oben beschrieben. Bei der Konfigurierung für den Client-Einsatz werden die Abschnitte a [logging] und [kdc] und damit auch die Datei kdc.conf nicht gebraucht selbst wenn Sie MIT Kerberos verwenden. Sie können ein MIT Kerberos-KDC zusammen mit Heimdal-Clients und ein Heimdal-KDC gemeinsam mit MIT Kerberos-Clients benutzen. Daneben können, wie im Abschnitt»Kerberos-Werkzeuge für Windows«beschrieben, auch andere Kerberos-Implementierungen mit diesen häufig verwendeten Kerberos-Werkzeugen kombiniert werden. Da die Kerberos-Clients keine eigenen Kerberos-Datenbanken unterhalten, ist die Verwendung von kadmin oder kadmin.local für deren Einrichtung nicht nötig. Allerdings müssen Sie für Ihre Benutzer die nötigen Prinzipale anlegen, wie weiter vorne in diesem Kapitel beschrieben wurde. Kerberisierte Clients installieren Kerberisierte Clients können in zwei Gruppen eingeteilt werden: in solche, die dem Kerberos-Hauptpaket bereits beiliegen, und in solche, die aus anderen Quellen stammen. Hierbei sind die»offiziellen«kerberisierten Clients auf die»offiziellen«kerberisierten Server abgestimmt, wie im Abschnitt»Die Server ausführen«beschrieben wurde. Wenn Sie Kerberos aus dem Quellcode selbst kompilieren und installieren, werden die Clients zusammen mit dem Kerberos-Hauptpaket installiert. Daher ist dieses Vorgehen die einfachste Möglichkeit, die Clients zu installieren. Bei manchen Linux-Distributionen liegen die Clients dagegen in einem eigenen Paket vor, wie etwa bei Fedora im Paket krb5-workstation. (Eventuell hängen diese Werkzeuge von zusätzlichen Paketen ab, wie z.b. krb5-libs unter Fedora.) Bei anderen Distributionen liegen dagegen alle Bestandteile in einem großen Paket vor. Wenn Sie zusätzliche Protokolle wie POP oder IMAP verwenden wollen, müssen Sie auch die nötigen Clients auffinden. Im Fall von POP oder IMAP brauchen Sie ein kerberisiertes Programm zum Lesen von s wie beispielsweise Pine ( 230 Kapitel 9: Konfigurierung und Benutzung von Kerberos