| SUSE LINUX – Administrationshandbuch Kapitel 19. Sicherheit im Netzwerk / 19.4. Installation und Administration von Kerberos | ||||
|---|---|---|---|---|
 | 19.3. Netzwerkauthentifizierung — Kerberos | 19.5. Sicherheit ist Vertrauenssache |  | |
| SUSE LINUX – Administrationshandbuch Kapitel 19. Sicherheit im Netzwerk / 19.4. Installation und Administration von Kerberos | ||||
|---|---|---|---|---|
| 19.3. Netzwerkauthentifizierung — Kerberos | 19.5. Sicherheit ist Vertrauenssache | | |
Dieser Abschnitt erläutert die Installation des Heimdal Kerberos sowie einige Aspekte der Administration. Es wird vorausgesetzt, dass Sie mit den Grundlagen von Kerberos vertraut sind (siehe auch Abschnitt 19.3. “Netzwerkauthentifizierung — Kerberos”).
Die „Domain“ einer Kerberos-Installation wird als Realm bezeichnet und hat einen Namen wie FOOBAR.COM oder einfach nur ACCOUNTING. Da Kerberos Groß-/Kleinbuchstaben unterscheidet, ist foobar.com ein anderer Realm als FOOBAR.COM. Die Wahl von Groß-/Kleinbuchstaben ist Ihnen überlassen. Es ist jedoch üblich, für Realm-Namen Großbuchstaben zu benutzen.
Es ist empfehlenswert, Ihren DNS-Domainnamen (oder eine Subdomain wie ACCOUNTING.FOOBAR.COM) zu benutzen. Wie Sie später sehen werden, haben Sie es als Administrator viel leichter, wenn Sie Ihre Kerberos-Clients so konfigurieren, dass das KDC und andere Kerberos-Dienste via DNS ansprechbar sind. Um dies zu ermöglichen, ist es sinnvoll, wenn der Realm-Name eine Subdomain Ihres DNS-Domainnamens ist.
Im Gegensatz zum DNS-Namensraum ist Kerberos nicht hierarchisch gegliedert. Sie können nicht einen Realm namens FOOBAR.COM aufsetzen, darunter zwei „Subrealms“ namens DEVELOPMENT und ACCOUNTING erstellen und erwarten, dass die beiden untergeordneten Realms irgendwie Principals von FOOBAR.COM übernehmen. Stattdessen hätten Sie drei getrennte Realms, für die Sie „Crossrealm“-Authentifizierung konfigurieren müssten, um Benutzern eines Realms zu ermöglichen, mit Servern oder Benutzern eines anderen Realms zu interagieren. Die Einrichtung der Crossrealm-Authentifizierung wird beispielsweise in [tung:99] beschrieben.
Der Einfachheit halber nehmen wir an, dass Sie für Ihre gesamte Organisation nur einen Realm anlegen. Im restlichen Teil dieses Abschnittes wird der Realm-Name SAMPLE.COM für alle Beispiele benutzt.
Wenn Sie Kerberos benutzen möchten, brauchen Sie zunächst einen Rechner, der als Key Distribution Center (KDC) eingesetzt wird. Auf diesem Rechner befindet sich die gesamte Kerberos-Benutzerdatenbank mit den Passwörtern und allen Informationen.
Das KDC ist der wichtigste Teil Ihrer Sicherheitsinfrastruktur — wenn jemand hier eindringt, sind alle Benutzerkonten und die gesamte Infrastruktur, die durch Kerberos geschützt wird, offengelegt. Ein Angreifer, der Zugang zur Kerberos-Datenbank hat, kann ein beliebiges Principal in der Datenbank verkörpern! Sorgen Sie dafür, dass die Sicherheitsvorkehrungen für diesen Rechner so strikt wie möglich sind:
Stellen Sie den Server an einem physikalisch sicheren Standort auf, zum Beispiel in einem abgeschlossenen Serverraum, zu dem nur ein begrenzter Personenkreis Zugang hat.
Lassen Sie außer dem KDC keine anderen Netzwerkanwendungen auf dem Rechner laufen. Dies gilt sowohl für Server- als auch für Clientanwendungen. Das KDC sollte beispielsweise keine Dateisysteme über NFS importieren oder DHCP benutzen, um seine Netzwerkkonfiguration abzurufen.
Ein guter Ansatz wäre, zunächst nur ein Minimalsystem zu installieren und dann die Liste aller installierten Pakete zu überprüfen und eventuelle unnötige Pakete zu löschen. Dies schließt Server wie inetd, portmap und cups sowie alles ein, was mit X11 zu tun hat. Selbst die Installation eines SSH-Servers stellt ein potentielles Sicherheitsrisiko dar.
Auf diesem Rechner gibt es kein grafisches Login, da auch ein X-Server ein potentielles Sicherheitsrisiko darstellt. Kerberos hat jedoch ein eigenes Administrationsinterface.
Konfigurieren Sie /etc/nsswitch.conf so, dass nur in lokalen Dateien nach Benutzern und Gruppen gesucht wird. Ändern Sie die Zeilen für passwd und group wie folgt:
passwd: files group: files
Editieren Sie die Dateien passwd, group, shadow und in /etc und entfernen Sie die Zeilen, die mit einem Pluszeichen anfangen (diese werden für NIS-Anfragen benutzt).
Sie sollten sich auch überlegen, DNS-Anfragen zu deaktivieren, da dies einen Risikofaktor darstellt. Falls in der DNS Resolver Library eine Sicherheitslücke ist, könnte ein Angreifer das KDC überlisten, eine DNS-Anfrage durchzuführen, die diese Lücke ausnutzt. Um DNS-Anfragen zu deaktivieren, löschen Sie einfach /etc/resolv.conf.
Deaktivieren Sie alle Benutzerkonten außer dem von Root, indem Sie /etc/shadow editieren und die gehashten Passwörter durch Sternchen oder Ausrufezeichen ersetzen.
Um Kerberos erfolgreich einsetzen zu können, müssen alle Systemuhren in Ihrer Organisation in einem bestimmten Bereich synchronisiert werden. Der Grund hierfür ist, dass Kerberos versuchen wird, Sie vor erneut versendeten Credentials (Replay) zu schützen. Es könnte einem Angreifer gelingen, Kerberos-Credentials im Netzwerk zu beobachten und diese zu benutzen, um den Server anzugreifen. Kerberos setzt verschiedene Verteidigungsmechanismen ein, um dies zu verhindern. Einer dieser Mechanismen sieht vor, dass die Tickets mit Zeitstempeln versehen werden. Ein Server, der ein Ticket mit einem nicht aktuellen Zeitstempel erhält, wird das Ticket zurückweisen.
Natürlich erlaubt Kerberos beim Vergleichen von Zeitstempeln einen gewissen Spielraum. Computeruhren können jedoch äußerst ungenau sein — es ist nicht ungewöhnlich, das PC-Uhren im Laufe einer Woche eine halbe Stunde vor- oder zurückgehen. Sie sollten daher alle Hosts im Netzwerk so konfigurieren, dass ihre Uhren mit einer zentralen Zeitquelle synchronisiert werden.
Sie können dies sehr einfach bewerkstelligen, indem Sie auf einem Rechner einen NTP-Zeitserver installieren und alle Clients ihre Uhren mit diesem Server synchronisieren lassen. Dies kann erreicht werden, indem Sie einen NTP-Daemon im Client-Modus auf allen Rechnern laufen lassen oder ntpdate einmal am Tag von allen Clients ausführen lassen (diese Lösung funktioniert wahrscheinlich nur bei einer kleineren Anzahl von Clients).
Das KDC selber muss auch mit der gemeinsamen Zeitquelle synchronisiert werden. Da ein NTP-Daemon auf diesem Rechner ein Sicherheitsrisiko darstellen würde, ist es wahrscheinlich das Beste, ntpdate via einen Croneintrag auszuführen.
Eine Beschreibung der Konfiguration von NTP finden Sie im Abschnitt 14.11. “Zeitsynchronisation mit xntp”. Weiterführende Information ist in der NTP-Dokumentation auf Ihrem installierten System unter /usr/share/doc/packages/xntp-doc erhältlich.
Selbstverständlich können Sie die maximale Abweichung, die Kerberos bei der Überprüfung von time stamps toleriert, nach eigenen Vorstellungen anpassen. Dieser Wert (clock skew) wird in der Konfigurationsdatei krb5.conf verändert, wie unter Abschnitt 19.4.6.3. “Anpassung der Uhrabweichung” beschrieben.
Standardmäßig protokollieren die auf dem KDC-Host laufenden Kerberos-Daemons ihre Information zum syslog-Daemon. Falls Sie die Aktivitäten Ihres KDC beobachten möchten, ist es vielleicht nützlich, diese Protokolldateien regelmäßig zu verarbeiten und auf ungewöhnliche Ereignisse oder potentielle Probleme zu untersuchen.
Um dies zu erreichen, kann man auf dem KDC-Host ein Protokollscannerskript laufen lassen oder diese Protokolldaten via rsync vom KDC auf einen anderen Host kopieren und die Protokollanalyse dort durchführen. Es wird davon abgeraten, die gesamte Protokollausgabe über die Weiterleitungsfunktion von syslogd weiterzuleiten, da die Information in unverschlüsselter Form im Netzwerk übertragen wird.
Dieser Abschnitt erläutert die Erstinstallation des KDC, einschließlich der Einrichtung eines administrativen Principals.
Bevor Sie anfangen können, müssen Sie die Kerberos-Software installieren. Installieren Sie die RPMs heimdal, heimdal-lib und heimdal-tools auf dem KDC:
rpm -ivh heimdal-*.rpm heimdal-lib-*.rpm heimdal-tools*.rpm
Der nächste Schirtt ist die Initialisierung der Datenbank, in der Kerberos sämtliche Informationen über die Principals speichert. Zuerst muss der Master Key der Datenbank gesetzt werden, der benötigt wird, um die Datenbank vor unbeabsichtigter Offenlegung zu schützen, besonders wenn diese auf ein Band gesichert wird.
Der Master Key wird aus einer Passphrase generiert und in einer Datei gespeichert, die als Stash File bezeichnet wird. Daher brauchen Sie nicht jedes Mal, wenn das KDC neu gestartet wird, das Passwort einzugeben. Wählen Sie eine gute Passphrase, beispielsweise einen Satz aus einem Buch, das Sie an einer zufälligen Stelle aufschlagen.
Wenn Sie die Kerberos-Datenbank auf Band sichern (/var/heimdal/heimdal.db), sichern Sie bitte nicht die stash Datei (in /var/heimdal/m-key). Ansonsten könnte jeder, der das Band lesen kann, die Datenbank entschlüsseln. Aus diesem Grunde ist es empfehlenswert, eine Kopie der Passphrase in einem Safe oder an einem anderen sicheren Ort aufzubewahren, da Sie diese benötigen, wenn Sie nach einem Absturz Ihre Datenbank von Band wiederherstellen.
Um den Master Key zu setzen, starten Sie die Utility kstash ohne zusätzliche Argumente und geben die Passphrase zweimal ein:
kstash Master key:<enter pass phrase> Verifying password - Master key:<enter pass phrase again>
Zuletzt müssen die Einträge für Ihren Realm in der Kerberos-Datenbank erstellt werden. Starten Sie die Utility kadmin mit der Option -l. Diese Option veranlasst kadmin, auf die lokale Datenbank zuzugreifen. Standardmäßig versucht kadmin, den Kerberos-Administrationsdienst über das Netzwerk zu erreichen. In diesem Stadium würde dies nicht funktionieren, da dieser Dienst noch nicht läuft.
Nun weisen Sie kadmin an, Ihren Realm zu initialisieren. kadmin wird eine Reihe von Fragen stellen. Zunächst ist es das Beste, die von kadmin angebotenen Standardeinstellungen anzunehmen:
kadmin -l kadmin> init SAMPLE.COM Realm max ticket life [unlimited]: <press return> Realm max renewable ticket life [unlimited]: <press return>
Um zu prüfen, ob etwas geschehen ist, benutzen Sie den Befehl list:
kadmin> list * default@SAMPLE.COM kadmin/admin@SAMPLE.COM kadmin/hprop@SAMPLE.COM kadmin/changepw@SAMPLE.COM krbtgt/SAMPLE.COM@SAMPLE.COM changepw/kerberos@SAMPLE.COM
Dies zeigt, dass es jetzt in der Datenbank eine Reihe von Principals gibt, die alle für den internen Gebrauch durch Kerberos bestimmt sind.
Nun schaffen Sie zwei Kerberos-Principals für sich selbst — ein „normales“ Principal für Ihre tägliche Arbeit und eines für administrative Aufgaben im Zusammenhang mit Kerberos. Verfahren Sie wie folgt, um den Login-Namen newbie einzurichten:
kadmin -l kadmin> add newbie Max ticket life [1 day]: <press return> Max renewable life [1 week]: <press return> Principal expiration time [never]: <press return> Password expiration time [never]: <press return> Attributes []: <press return> newbie@SAMPLE.COM's Password: <type password here> Verifying password: <re-type password here>
Sie können die Standardwerte mit Enter bestätigen. Wählen Sie ein geeignetes Passwort.
Danach erstellen Sie ein anderes Principal namens newbie/admin durch Eingabe von add newbie/admin am kadmin-Prompt. Der Suffix admin hinter dem Benutzernamen bezeichnet die „Rolle“ role. Später werden Sie diese administrative Rolle benutzen, um die Kerberos-Datenbank zu administrieren.
Ein Benutzer kann mehrere „Rollen“ haben, die unterschiedlichen Zwecken dienen. Ihre Handhabung hat dennoch nichts mit Magie zu tun — sehen Sie sie einfach als völlig unterschiedliche Accounts mit ähnlichen Namen an.
Starten Sie die KDC-Daemons. Dies schließt den eigentlichen kdc (der Daemon, der für die Benutzerauthentifizierung und Ticketanfragen zuständig ist), kadmind (der Server für die Fernadministration) sowie kpasswd (zuständig für Passwortänderungsanfragen von Benutzern) ein. Um den Daemon manuell zu starten, geben Sie Folgendes ein:
rckdc start Starting kdc done
Sorgen Sie dafür, dass das KDC standardmäßig gestartet wird, wenn der Server neu gestartet wird. Dies wird mit Hilfe des Befehls insserv kdc bewerkstelligt.
Die Konfiguration von Kerberos kann grundsätzlich auf zweierlei Weise erfolgen — über eine statische Konfiguration mit der Datei /etc/krb5.conf oder über eine dynamische Konfiguration via DNS. Bei der DNS-Konfiguration versuchen Kerberos-Anwendungen, die KDC-Dienste durch DNS-Einträge zu finden. Bei der statischen Konfiguration müssen Sie die Hostnamen Ihres KDC-Servers in der Datei krb5.conf eintragen (und die Datei aktualisieren, wenn das KDC „umzieht“ oder Sie Ihren Realm in irgendeiner anderen Weise neu konfigurieren).
Die DNS-basierte Konfiguration ist gewöhnlich viel flexibler und der Konfigurationsaufwand pro Rechner viel geringer. Dieser Ansatz erfordert jedoch, dass Ihr Realm-Name mit Ihrer DNS-Domain identisch ist oder eine Subdomain hiervon ist.
Außerdem verursacht die Konfiguration von Kerberos via DNS ein kleines Sicherheitsproblem, denn ein Angreifer kann Ihre Infrastruktur durch Ihren DNS erheblich stören (durch Abschuss des Nameservers, Verfälschung von DNS-Einträgen [Spoofing] usw.). Im schlimmsten Fall führt dies jedoch zu einem DoS. Ein ähnliches Szenario kann auch bei der statischen Konfiguration auftreten, es sei denn, Sie geben in krb5.conf IP-Adressen anstelle von Hostnamen ein.
Eine Art der Kerberos-Konfiguration ist der Änderung der Konfigurationsdatei /etc/krb5.conf. Die Datei, die standardmäßig im installierten System vorhanden ist, enthält einige Beispieleinträge. Entfernen Sie diese, bevor Sie mit Ihrer eigenen Konfiguration beginnen.
krb5.conf besteht aus mehreren Abschnitten. Jeder dieser Abschnitte beginnt mit dem Namen des Abschnitts in eckigen Klammern ([Beispielname]).
Für die statische Konfiguration fügen Sie bitte den folgenden Abschnitt in krb5.conf ein (wobei kdc.sample.com der Hostname des KDCs ist):
[libdefaults]
default_realm = SAMPLE.COM
[realms]
SAMPLE.COM = {
kdc = kdc.sample.com
kpasswd_server = kdc.sample.com
admin_server = kdc.sample.com
}
Über die Zeile default_realm wird die standardmäßige Realm für Kerberos-Applikationen festgelegt.
Falls Sie mehrere Realms haben, fügen Sie einfach dem Abschnitt [realms] einen weiteren Ausdruck hinzu.
Fügen Sie dieser Datei auch einen Ausdruck hinzu, der besagt, wie Anwendungen Hostnamen zu Realms zuordnen müssen. Wenn man beispielsweise eine Verbindung zu einem entfernten Host aufbaut, muss die Kerberos-Library wissen, in welchem Realm sich dieser Host befindet. Dies muss im Abschnitt [domain_realms] konfiguriert werden:
[domain_realm]
.sample.com = SAMPLE.COM
www.foobar.com = SAMPLE.COM
Dieser Eintrag teilt der Library mit, dass sich alle Hosts in den sample.com DNS-Domains in dem Kerberos-Realm SAMPLE.COM befinden. Außerdem sollte auch ein externer Host namens www.foobar.com als Angehöriger des Realms SAMPLE.COM betrachtet werden.
Die DNS-basierte Kerberos-Konfiguration macht intensiven Gebrauch von SRV-Einträgen (Siehe (RFC2052) A DNS RR for specifying the location of services unter http://www.ietf.org). Diese Einträge wurden in früheren Implementierungen des BIND-Nameservers noch nicht unterstützt. Deshalb ist BIND Version 8 (oder spätere Versionen) erforderlich.
Was Kerberos betrifft, ist der Name eines SRV-Eintrags immer wie folgt aufgebaut: _service._proto.realm, wobei realm der Kerberos-Realm ist. Beachten Sie, dass DNS bei Domainnamen keine Groß-/Kleinbuchstaben unterscheidet, so dass Kerberos-Realms, die Groß-/Kleinschreibung unterscheiden, bei dieser Konfigurationsmethode nicht mehr funktionieren würden. _service ist der Name eines Dienstes (verschiedene Namen werden benutzt, wenn beispielsweise eine Verbindung zum KDC oder zum Passwortdienst aufgebaut wird). _proto kann entweder _udp oder _tcp sein, aber nicht alle Dienste unterstützen beide Protokolle.
Der Datenteil der SRV Resource Records besteht aus einem Prioritätswert, einer Gewichtung, einer Portnummer und einem Hostnamen. Die Priorität definiert die Reihenfolge, in welcher Hosts versucht werden sollen (kleinere Werte stellen eine höhere Priorität dar). Die Gewichtung wird benutzt, um ein gewisses Load-Balancing zwischen Servern gleicher Priorität zu unterstützen. Diese Funktion wird kaum gebraucht, so dass Sie diese auf Null setzen können. Bei der Suche nach Diensten sucht Heimdal Kerberos zur Zeit nach den folgenden Namen:
Definiert die Lokalisierung des KDC-Daemons (der Authentifizierungs- und Ticket-Granting-Server). Typischerweise sehen die Einträge wie folgt aus:
_kerberos._udp.SAMPLE.COM. IN SRV 0 0 88 kdc.sample.com. _kerberos._tcp.SAMPLE.COM. IN SRV 0 0 88 kdc.sample.com.
Beschreibt die Lokalisierung des Servers für Passwortänderungen. Typischerweise sehen die Einträge wie folgt aus:
_kpasswd._udp.SAMPLE.COM. IN SRV 0 0 464 kdc.sample.com.
Dakpasswdd TCP nicht unterstützt, sollte es keinen _tcp Eintrag geben.
Beschreibt die Lokalisierung des Fernadministrationsservers. Typischerweise sehen die Einträge wie folgt aus:
_kerberos-adm._tcp.SAMPLE.COM. IN SRV 0 0 749 kdc.sample.com.
Da kadmind UDP nicht unterstützt, sollte es keinen _udp Eintrag geben.
Wie bei der statischen Konfigurationsdatei gibt es einen Mechanismus, der Clients darüber informiert, dass ein bestimmter Host sich in dem Realm SAMPLE.COM befindet, selbst wenn er kein Teil der DNS-Domain sample.com ist. Dies kann erreicht werden, indem man _kerberos.hostname einen TXT-Eintrag hinzufügt:
_kerberos.www.foobar.com. IN TXT "SAMPLE.COM"
Über die Variable clock skew setzen Sie die Toleranzgrenzen fest, innerhalb derer Tickets akzeptiert werden, deren Zeitstempel nicht exakt mit der Systemuhr des Hostssystems übereinstimmen.
Im Normalfall ist diese Größe mit 300 Sekunden (5 Minuten) angegeben. Ein Ticket kann also einen Zeitstempel tragen, der fünf Minuten in Vergangenheit oder Zukunft von der Systemzeit des Servers abweicht, um noch akzeptiert zu werden.
Verwenden Sie NTP zur Zeitsynchronisation auf allen Hosts, kann dieser Wert auf eine Minute reduziert werden.
Die clock skew Variable passen Sie in /etc/krb5.conf wie folgt an:
[libdefaults]
clockskew = 120
Um der Kerberos-Datenbank Principals hinzufügen bzw. löschen zu können, ohne direkten Zugang zur Konsole des KDC zu haben, teilen Sie dem Kerberos-Adminserver mit, welche Principals hierzu berechtigt sind.
Sie können dies erreichen, indem Sie die Datei /var/heimdal/kadmind.acl editieren (ACL ist die Abkürzung von Access Control List). Die ACL-Datei ermöglicht eine Spezifizierung der Vorrechte und die Feineinstellung des Kontrollgrads. Nähere Informationen sind auf der Manpage (man 8 kadmind) erhältlich.
Erlauben Sie sich nun, mit der Datenbank alles zu tun, was Sie möchten, indem Sie der Datei die folgende Zeile hinzufügen:
newbie/admin all
Ersetzen Sie den Benutzernamen newbie mit Ihrem eigenen Benutzernamen. Starten Sie nun den KDC neu, um Ihre Änderungen aktiv werden zu lassen.
Die Fernadministration von Kerberos sollte nun mit Hilfe des Tools kadmin möglich sein. Zunächst brauchen Sie ein Ticket für Ihr Admin-Principal. Dieses Ticket wird gebraucht, wenn Sie ein Verbindung zum kadmin-Server herstellen:
kinit newbie/admin newbie/admin@SAMPLE.COM's Password: <enter password> /usr/sbin/kadmin kadmin> privs change-password, list, delete, modify, add, get
Mit dem Befehl privs können Sie überprüfen, welche Vorrechte Sie haben. Die obige Liste führt sämtliche Vorrechte auf.
Zum Beispiel können Sie das Principal newbie modifizieren:
kadmin> mod newbie Max ticket life [1 day]:2 days Max renewable life [1 week]: Principal expiration time [never]:2005-01-01 Password expiration time [never]: Attributes []:
Dies ändert die maximale Lebensdauer des Tickets auf zwei Tage und setzt das Auslaufdatum auf den 01.01.2005.
Hier folgt eine kurze Liste der wichtigsten kadmin Kommandos; bitte konsultieren Sie die Manualpage von kadmin für weitergehende Informationen.
Fügt ein neues Principal hinzu.
Editieren verschiedener Attribute eines Principals, wie z. B. der maximalen Lebensdauer der Tickets und das Auslaufdatum des Kontos/Accounts.
Entfernt ein Principal aus der Datenbank.
benennt ein Principal in neuername um.
Listet alle Principals auf, die dem angegebenen Pattern (Muster) entsprechen. Patterns funktionieren ähnlich wie die Shell Globbing Patterns: list newbie* würde in unserem Beispiel newbie und newbie/admin auflisten.
Zeigt Detailinformation über das Principal an.
Ändert das Passwort eines Principals.
Hilfe ist zu jeder Zeit durch Eingabe von ? und Enter erhältlich, auch an Prompts, die von Befehlen wie modify und add ausgegeben werden.
Der Befehl init, der benutzt wird, wenn der Realm erstmals erstellt wird (sowie bei einigen anderen), ist im Remote-Modus nicht verfügbar. Um einen neuen Realm zu erstellen, gehen Sie an die Konsole des KDCs und benutzen kadmin im lokalen Modus (mit der Befehlszeilenoption -l).
Jede Maschine innerhalb Ihres Netzwerks muss einem Kerberos Realm zugeordnet sein und ein KDC kontaktieren können. Außerdem müssen Sie für sie auch ein so genanntes „Host Principal“ anlegen.
Bis jetzt wurden nur Benutzer Credentials behandelt. „Kerberisierte“ Dienste müssen sich im Normalfall aber auch gegenüber dem Client-Benutzer authentifizieren. Hierzu werden so genannte „Host Principals“ für alle Hosts innerhalb eines Realms in der Kerberos Datenbank vorliegen.
Die entsprechende Namenskonvention lautet: host/<hostname>@<REALM>, hostname ist hier der vollständige gültige Name des betreffenden Hosts.
Host Principals ähneln in vielerlei Hinsicht normalen Benutzer Principals. Allerdings gibt einige kleine Unterschiede. Der Hauptunterschied zwischen Benutzer Principal und Host Principal liegt darin, dass der Schlüssel des ersteren passwortgeschützt ist. Erhält ein Benutzer ein Ticket-Granting Ticket vom KDC, muss er sein Passwort eingeben, damit Kerberos das Ticket entschlüsseln kann. Für einen Systemadministrator wäre es folglich sehr unbequem, müsste er für den SSH Daemon alle acht Stunden neue Tickets anfordern.
Im Fall der Host Principals wird dieses Problem folgendermaßen gelöst: Der zur Entschlüsselung des ursprünglichen Tickets für den Host Principal erforderliche Schlüssel wird einmal vom Administrator vom KDC angefordert. Anschließend wird dieser Schlüssel in einer lokalen Datei namens keytab gespeichert. Dienste wie der SSH Daemon lesen diesen Schlüssel aus und verwenden ihn, um bei Bedarf automatisch neue Schlüssel zu erhalten. Die Standard keytab Datei liegt unter /etc/krb5.keytab.
Um einen Host Principal für machine.sample.com anzulegen, geben Sie während Ihrer kadmin Sitzung Folgendes ein:
kinit newbie/admin newbie/admin@SAMPLE.COM's Password: <type password> kadmin add -r host/machine.sample.com Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []:
Statt ein Passwort für das neue Principal zu setzen, weist die Option -r kadmin an, einen zufälligen Schlüssel zu generieren. Dies ist hier möglich, da wir für diesen Principal keine Benutzeraktivität wünschen. Es ist ein reiner Serveraccount für diese Maschine.
Abschließend extrahieren Sie den Schlüssel und speichern ihn in der lokalen Keytab-Datei /etc/krb5.keytab. Diese Datei gehört dem Superuser, weshalb Sie Root sein müssen, um den folgenden Befehl ausführen zu können:
ktutil get host/machine.sample.com
Danach sorgen Sie bitte dafür, dass Sie das Admin-Ticket mit kdestroy vernichten, das Sie via kinit erhalten haben, wie oben beschrieben.
SUSE LINUX wird mit einem PAM-Modul namens pam_krb5 ausgeliefert, welches die Anmeldung via Kerberos und die Passwortaktualisierung unterstützt. Dieses Modul kann von Anwendungen wie dem Konsole-Login, su und grafischen Anwendungen wie KDM gebraucht werden, in denen der Benutzer ein Passwort eingibt und den Authentifizierungsmechanismus benutzen möchte, um ein erstes Kerberos-Ticket zu erhalten.
Ab dieser Version von SUSE LINUX unterstützt das pam_unix-Modul Kerberos-Authentifizierung und Passwortänderungen. Um die Kerberos-Unterstützung in pam_unix zu aktivieren, ändern Sie die Datei /etc/security/pam_unix2.conf wie folgt:
auth: use_krb5 nullok account: use_krb5 password: use_krb5 nullok session: none
Wenn diese Datei ausgewertet wird, verwenden alle Dienste Kerberos zur Benutzerauthentifizierung. Falls ein Benutzer keinen Kerberos-Principal besitzt, wird pam_unix auf den normalen Password-Authentifizierungsmechanismus zurückgreifen. Das Kerberos-Passwort sollte nun auch transparent mit dem passwd Kommando aktualisierbar sein.
Feineinstellungen von pam_krb5 nehmen Sie über Änderungen der Datei /etc/krb5.conf vor und indem Sie Standardapplikationen für pam hinzufügen. Details zur Vorgehensweise entnehmen Sie bitte der Manualpage (man 5 pam_krb5).
Das Modul pam_krb5 war ursprünglich nicht für Netzwerkdienste bestimmt, die Kerberos-Tickets als Teil der Benutzerauthentifizierung annehmen — dies ist eine ganz andere Geschichte und wird in den folgenden Abschnitten behandelt.
OpenSSH unterstützt Kerberos-Authentifizierung sowohl in der Protokollversion 1 und 2. Version 1 verwendet eine bestimmte Art von Protokollmeldungen zur Übermittlung von Kerberos Tickets. Version 2 verwendet Kerberos nicht mehr direkt, sondern greift auf „GSSAPI“, die so genannte General Security Services API, zurück. Diese Programmierschnittstelle ist nicht Kerberos spezifisch. Sie wurde entwickelt, um die Eigenheiten des zugrunde liegenden Authentifizierungssystems vor der Anwendung zu verbergen, egal ob dies Kerberos, SPKM oder ein anderes derartiges System ist. Allerdings unterstützt die aktuelle GSSAPI Bibliothek von SUSE LINUX zur Zeit nur Kerberos.
Um sshd mit der Kerberos-Authentifizierung zu benutzen, editieren Sie /etc/ssh/sshd_config und setzen die folgenden Optionen:
# These are for protocol version 1 KerberosAuthentication yes KerberosTgtPassing yes # These are for version 2 GSSAPIAuthentication yes GSSAPIKeyExchange yes
Im Anschluss daran benutzen Sie den Befehl rcsshd restart, um Ihren SSH-Daemon neu zu starten.
Wollen Sie Kerberos Authentifizierung mit der Protokollversion 2 nutzen, müssen Sie auch auf der Clientseite die Unterstützung hierfür aktivieren. Entweder Sie erledigen dies systemweit über die Konfigurationsdatei /etc/ssh/ssh_config oder auf Benutzerbasis über ~/.ssh/config. In beiden Fällen müssen Sie der Konfigurationsdatei die Option GSSAPIAuthentication yes hinzufügen.
Nun sollten Sie in der Lage sein, eine Verbindung mit Kerberos-Authentifizierung aufzubauen. Verwenden Sie klist, um zu überprüfen, ob Sie ein gültiges Ticket für die Verbindungsaufnahme mit dem SSH-Server besitzen. Um die Verwendung des SSH-Protokolls Version 1 zu erzwingen, übergeben Sie die Option -1 auf der Kommandozeile.
ssh earth.sample.com Last login: Fri Aug 9 14:12:50 2002 from zamboni.sample.com Have a lot of fun...
Bei Benutzung von Kerberos bietet sich mit LDAP ein Weg zur Verteilung von Benutzerinformationen (Benutzer-ID, Gruppen, Homeverzeichnisse etc.) im lokalen Netz. Natürlich erfordert dies die Verwendung eines starken Verschlüsselungsmechanismus, um Package-Spoofing etc. zu vermeiden.
Für die LDAP-Kommunikation lässt sich natürlich auch Kerberos verwenden.
OpenLDAP implementiert die meisten der verschiedenen Authentifizierungstypen über SASL, das Simple Authentication Session Layer. SASL ist im Grunde ein Netzwerkprotokoll zur Authentifizierung. SUSE LINUX verwendet die cyrus-sasl Implementierung und unterstützt mehrere Authentifizierungstypen. Kerberos Authentifizierung wird über GSSAPI (General Security Services API) umgesetzt.
Standardmäßig ist das SASL-Plugin für GSSAPI nicht installiert. Installieren Sie es von Hand nach:
rpm -ivh cyrus-sasl-gssapi-*.rpm
Um Kerberos Binding zum OpenLDAP-Server zu ermöglichen, legen Sie einen Principal ldap/earth.sample.com an und fügen Sie ihn der keytab hinzu:
kadmin add -r ldap/earth.sample.com ktutil get ldap/earth.sample.com
An dieser Stelle sollten Sie sich über folgenden Stolperstein klar werden: Der LDAP-Server (slapd) läuft standardmäßig unter Benutzer und Gruppe ldap, während keytab nur vom Benutzer root gelesen werden kann. Also müssen Sie entweder die LDAP-Konfiguration dahingehend abändern, dass der Server als Benutzer root gestartet wird oder die keytab für die Gruppe ldap lesbar machen.
Um slapd als root zu betreiben, editieren Sie die Datei /etc/sysconfig/openldap und deaktivieren die beiden Variablen OPENLDAP_USER and OPENLDAP_GROUP durch Einfügen eines Kommentarzeichens am Beginn der Zeile.
Um eine keytab Datei für die Gruppe ldap lesbar zu machen, gehen Sie folgendermaßen vor:
chgrp ldap /etc/krb5.keytab chmod 640 /etc/krb5.keytab
Keine dieser beiden Lösungen ist perfekt. Allerdings ist es momentan nicht möglich, OpenLDAP so zu konfigurieren, dass es eine eigene keytab verwendet.
Abschließend starten Sie den LDAP Server mit dem Befehl rcldap restart neu.
Nun sollten Sie in der Lage sein, Anwendungen wie ldapsearch automatisch mit Kerberos Authentifizierung auszuführen.
ldapsearch -b ou=People,dc=suse,dc=de '(uid=newbie)' SASL/GSSAPI authentication started SASL SSF: 56 SASL installing layers [...] # newbie, People, suse.de dn:uid=newbie,ou=People,dc=suse,dc=de uid: newbie cn: Olaf Kirch [...]
Wie Sie hier sehen, gibt ldapsearch eine Meldung aus, dass es GSSAPI Authentifizierung gestartet hat. Die folgende Meldung ist zugegebenermaßen etwas kryptisch — sie gibt den „Security Strenth Factor“ (SSF) mit 56 an. (Der Wert 56 an dieser Stelle ist etwas willkürlich. Sehr wahrscheinlich wurde er gewählt, da er die Anzahl der Bits in einem DES Enkryption-Key angibt.) Was Ihnen diese Zeilen im Grunde sagen ist, dass die GSSAPI Authentifizierung erfolgreich war und dass die LDAP-Verbindung per Verschlüsselung geschützt wird.
Vergessen Sie nicht, dass Kerberos Authentifizierung immer ein wechselseitiger Prozess ist. Das bedeutet, nicht nur Sie haben sich gegenüber dem LDAP-Server authentifiziert — er hat sich im Gegenzug auch bei Ihnen authentifiziert. Sie können sich also sicher sein, dass Sie mit dem LDAP-Server kommunizieren, den Sie vorgesehen hatten und nicht mit irgendeinem vorgetäuschten Service, den ein Angreifer aufgesetzt hat.
Für den Fall, dass mehrere verschiedene SASL Mechanismen verwendet werden können, können Sie ldapsearch durch die Kommandozeilenoption -Y GSSAPI zur Verwendung von GSSAPI zwingen.
Im vorigen Abschnitt haben wir uns erfolgreich am LDAP-Server authentifiziert. Im nächsten Schritt solle es jedem Benutzer ermöglicht werden, das Login-Shell Attribut in seinen LDAP Benutzerdaten zu ändern.
Angenommen, Sie verwenden ein Schema, nach dem der LDAP-Eintrag des Benutzers joe unter uid=joe,ou=people,dc=suse,dc=de liegt, können Sie die folgenden Zugangsregeln in der Datei /etc/openldap/slapd.conf aufstellen:
# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=suse,dc=de" attrs=loginShell
by self write
# Every user can read everything
access to *
by users read
Über die zweite Anweisung erlaubt authentifizierten Benutzern schreibenden Zugriff auf das loginShell Attribut ihres LDAP Eintrags. Die dritte Anweisung gibt allen authentifizierten Benutzern Lesezugriff auf das gesamte LDAP-Verzeichnis.
Wie findet nun der LDAP-Server heraus, dass joe@SAMPLE.COM von Kerberos das Äquivalent zum LDAP DN distinguished name uid=joe,ou=people,dc=suse,dc=de ist? Diese Zuordnung wir manuell über die saslExpr Direktive vorgenommen. Im Beispiel fügen Sie der slapd.conf folgende Zeilen hinzu:
saslRegexp
uid=(.*),cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com
Um diesen Mechanismus zu verstehen, sollten Sie wissen, dass OpenLDAP einen DN bildet, wenn SASL einen Benutzer authentifiziert. Dieser DN setzt sich aus dem von SASL übergebenen Namen (wie zum Beispiel joe) und dem Typ der SASL Authentifizierung (GSSAPI) zusammen. In diesem Fall wäre uid=joe,cn=GSSAPI,cn=auth das Ergebnis.
Ist ein saslRegexp konfiguriert, wird der LDAP-Server den DN aus der SASL-Information mit dem ersten Argument als regulärem Ausdruck überprüfen. Trifft dieser reguläre Ausdruck zu, wird der Name durch das zweite Argument der saslRegexp Anweisung ersetzt. Die Platzhalter ($1) werden durch den Teilausdruck ersetzt, der über den (.*) Ausdruck ermittelt wurde.
Selbstverständlich sind auch kompliziertere Suchmuster möglich. Sollten Sie eine kompliziertere Verzeichnisstruktur verwenden oder der Benutzername in dem von Ihnen verwendeten Schema nicht Teil des DN sein, können Sie sogar Suchausdrücke verwenden, die den SASL DN dem Benutzer-DN zuordnen.
