Bis zu diesem Punkt haben Sie Ihren LDAP-Server schon soweit konfiguriert, dass Sie alle Zugriffe über TLS abgesichert haben. Wenn Sie Ihren Anwendern eine zentrale Anmeldung über LDAP bereitstellen wollen, damit sie sich in Ihrem Netzwerk an verschiedenen Diensten authentifizieren können, ist es sinnvoll, über ein Single Sign-on mithilfe von Kerberos nachzudenken. Denn alleine mit LDAP ist ein Single Sign-on nicht möglich. Ohne Kerberos müssen sich die Anwender bei jedem authentifizierten Zugriff auf eine Anwendung erneut mit ihrem Benutzernamen und Passwort authentifizieren. Durch den Einsatz von Kerberos melden sich die Anwender nur noch einmal im Netz an, und die Authentifizierung an Diensten wird über Kerberos geregelt. Das setzt voraus, dass Sie auch alle Anwendungen an den Kerberos anbinden. Die Dienste müssen „kerberisiert“ werden. Leider lassen sich nicht alle Dienste kerberisieren. Wenn das bei einem Dienst (vielmehr handelt sich da meist um bestimmte Anwendungen) nicht möglich ist, haben Sie zwei Möglichkeiten: Sie leben damit und lassen diesen Dienst außen vor oder Sie schauen sich nach einer anderen Anwendung um, die sich kerberisieren lässt.
Sind alle Voraussetzung erfüllt, meldet sich ein Anwender einmal an seinem System an und kann anschließend ohne weitere Authentifizierungen alle Anwendungen nutzen. Dazu benötigen die Dienste ebenfalls eine Kerberos-Konfiguration.
Ein weiterer Vorteil hinsichtlich der Sicherheit ist der, dass sich nicht nur die Anwender authentifizieren müssen, sondern auch alle Hosts und Services authentifizieren sich gegen den Kerberos.
Kerberos wurde 1978 am Massachusetts Institute of Technology (MIT) entwickelt und wird für die Authentifizierung von Netzwerkdiensten, Hosts und Services genutzt. Die aktuelle Version von Kerberos ist Version 5.
In den meisten Distributionen wird der Kerberos des Massachusetts Institute of Technology eingesetzt. Diese Version wurde aber aufgrund der verwendeten Verschlüsselungsalgorithmen unter die strengen Exportregeln der USA gestellt. Aus diesem Grund wurden verschiedene andere Implementierungen außerhalb der USA entwickelt. Die am meisten verwendete Kerberos-Implementierung ist die Heimdal -Implementierung aus Schweden. Als im Jahr 2000 die strenge Reglementierung für den MIT-Kerberos aufgehoben wurde, haben einige Distributionen den Heimdal-Kerberos entfernt und verwenden heute nur noch den MIT-Kerberos.Heute wird der Heimdal-Kerberos nur noch von Debian-basierten Distributionen bereitgestellt. Den MIT-Kerberos finden Sie aber auf allen Distributionen, und aus diesem Grund werden wir uns hier im Buch ausschließlich mit der MIT-Implementierung beschäftigen.
Hinweis: Wenn Sie einen Kerberos-Server mit einer der beiden Implementierungen einrichten, können Sie für den LDAP-Client sowohl die Kerberos-Client-Pakete des MIT-Kerberos einsetzen oder die Pakete des Heimdal-Clients. Nur die Syntax der Kommandos ist bei den Paketen unterschiedlich.
Die Verwendung von Kerberos bietet Ihnen eine einheitliche und sichere Authentifizierungsmethode. Bei einer Authentifizierung in einem Netzwerk, das mit Kerberos arbeitet, wird die Authentifizierung von einer vertrauenswürdigen dritten „Partei“ (Trusted Third Party) übernommen. Hierbei handelt es sich dann um den Kerberos-Dienst.
In Bild 15.1 sehen Sie den Vorgang einer Authentifizierung:
Bild 15.1 Authentifizierungsmodell von Kerberos
Der Service und der Host, auf dem der Service läuft, authentifizieren sich mit ihrem Host- und Service-Principal. Für die Authentifizierung verwenden sie ihre Keytab-Datei, in der das verschlüsselte Passwort liegt.
Der Anwender authentifiziert sich beim KDC durch die Eingabe seines Passworts bei der Anmeldung. War die Anmeldung erfolgreich, erhält er ein Ticket (Ticket Granting Ticket, TGT), mit dem er sich jetzt direkt bei einem Service anmelden kann.
Der Anwender greift auf einen Service zu und überträgt sein TGT an den Host, der den Service bereitstellt. Der Service prüft das TGT. Da der Service dem KDC traut und das TGT vom KDC ausgestellt wurde, ist der Anwender vertrauenswürdig. Jetzt bekommt der Anwender Zugriff auf den Dienst, und der Service sendet dem Anwender ein Service-Ticket. Bei jedem weiteren Zugriff auf den Service verwendet der Anwender jetzt automatisch das Service-Ticket. Der gesamte Vorgang ist für den Anwender transparent.
Der Kerberos-Server wird nur für die Authentifizierung sorgen, er kann jedoch nicht zur Autorisierung oder zum Verwalten der Benutzerkonten eingesetzt werden. Für die Aufgaben der Kontenverwaltung kann entweder eine lokale Anmeldung genutzt werden oder Sie richten eine zentrale Benutzerverwaltung mit LDAP ein.
Mithilfe von Kerberos können Sie in Ihrem Netzwerk ein Single Sign-on (sso) realisieren. Jeder Benutzer gibt sein Passwort nur einmal ein und erhält dann ein Ticket. Mit diesem Ticket kann er sich dann automatisch bei allen Diensten im Netzwerk anmelden, die Kerberos unterstützen.
Damit Sie später nicht auf jedem Kerberos-Client die Namen der Kerberos-Server einrichten müssen, ist es sinnvoll, einen DNS-Server im Netzwerk zu betreiben. Der Vorteil ist der, dass Sie dann die Dienste, die der Kerberos-Server bereitstellt, über DNS SRV-Records anbieten können. Ohne die SRV-Records ist es notwendig, dass Sie die Kerberos-Server auf jedem Client konfigurieren. Das würde dazu führen, dass wenn Sie einen neuen Kerberos-Server in Ihr Netzwerk einbinden, eine Anpassung für jeden Client notwendig wäre.
Beim Einsatz von Kerberos werden verschiedene Begriffe verwendet. Deshalb erhalten Sie hier eine Übersicht über die Begriffe und deren Bedeutung:
Realm: Bei Realm handelt es sich um den administrativen Bereich, oft auch Authentifizierungszone genannt, für den Kerberos-Server. Hier wird häufig der Name der DNS-Domäne in Großbuchstaben verwendet.
Hinweis: Achten Sie bei der Verwendung des Realms immer darauf, dass Sie diesen auch groß schreiben. An vielen Stellen kommt es sonst zu Fehlern.
Principal: Der Principal wird von Kerberos für die Authentifizierung benötigt. Der Principal setzt sich aus einer oder mehreren Komponenten und dem Realm zusammen. Ein Principal für einen Benutzer hat nur eine Komponente, die mit dem @-Zeichen an den Realm gebunden wird (zum Beispiel stefan@EXAMPLE.NET). Für die Authentifizierung eines Service- oder Hosttickets werden dagegen zwei Komponenten verwendet, zum Beispiel host/kerberos01.example.net@EXAMPLE.NET für einen Host in Ihrem Netzwerk. Für die Services gibt es die folgenden Komponenten:
ldap für den LDAP-Service
HTTP für Webservices
nfs, wenn Sie NFS-Server einbinden wollen
imap für Ihre IMAP-Server
Einige Services, wie zum Beispiel SSH, nutzen den Host-Principal des Systems.
Ticket: Das Ticket wird für die Anmeldung an einem Host oder für einen Dienst benötigt. Das Ticket kann auch als virtueller Fahrschein betrachtet werden, ohne den der Dienst nicht benutzt werden kann.
Ticket Granting Ticket (TGT): Das TGT erhält der Client vom Ticket Granting Server (TGS). Mit diesem TGT kann der Client, ohne weitere Authentifizierungen durch den KDC durchführen zu müssen, die Tickets für weitere Dienste erhalten. Wenn der Service ebenfalls Kerberos für die Authentifizierung nutzt, kann der Service das TGT des Benutzers bei der Anmeldung selbstständig prüfen, da er dem KDC vertraut und somit auch dem TGT des Benutzers.
Authentication Service (AS): Der AS beantwortet die Anfragen der Clients und erzeugt die zufälligen Sitzungsschlüssel sowie die Kerberos-Tickets.
Ticket Granting Service (TGS): Der TGS vergibt das Ticket Granting Ticket (TGT) an die Clients. Mithilfe dieses Tickets kann dann der Client Tickets für andere Dienste beziehen.
Key Distribution Center (KDC): Hierbei handelt es sich um eine Datenbank, in der alle Principals mit ihrem Passwort abgelegt sind. Der TGS ist ein Teil des KDC.
| 15.1 | Funktionsweise von Kerberos |
Bevor ein Dienst oder ein Host Kerberos für die Authentifizierung von Benutzern über Tickets nutzen kann, muss der entsprechende Dienst kerberized werden. Denn nur dann kann der Dienst das Ticket des Anwenders gegen den Kerberos-Server überprüfen.
Wenn sich ein Anwender am System anmeldet, erhält er vom AS ein TGT. Will nun der Anwender einen Dienst nutzen oder auf einen anderen Host zugreifen, der kerberized ist, holt sich der Client mit dem TGT ein Ticket des entsprechenden Hosts oder Diensts. Der Client schickt dann das Ticket an den Host oder Dienst, dieser kann nun das Ticket gegen den Kerberos-Server prüfen und daraufhin den Zugriff zulassen. Dieser Vorgang findet für den Anwender absolut transparent statt. Greift ein Benutzer erneut auf den Dienst zu, nutzt er das Ticket, das er beim ersten Zugriff vom Service erhalten hat.
| 15.1.1 | Einstufiges Kerberos-Verfahren |
Beim einstufigen Kerberos-Verfahren werden alle Authentifizierungen nur vom AS gegen die KDC-Datenbank durchgeführt. Jeder Zugriff von einem Client auf einen Dienst erfordert immer das Passwort des Benutzers. Ein sso ist mit diesem Verfahren nicht realisierbar, da kein TGT an den Client vergeben wird, mit dem er sich automatisch authentifizieren könnte. Dieses Verfahren wird heute kaum noch verwendet und soll deshalb hier nicht weiter besprochen werden.
| 15.1.2 | Zweistufiges Kerberos-Verfahren |
Beim zweistufigen Kerberos-Verfahren kommt der TGS ins Spiel. Jeder Client, der sich mit seinem in der KDC-Datenbank eingetragenen Principal und dessen Passwort angemeldet hat, erhält ein TGT, das nur eine begrenzte Gültigkeitsdauer aufweist (meist acht bis zehn Stunden). Dieses Ticket wird im Ticket-Cache des Benutzers abgelegt. Sie finden die Datei, in der das Ticket gespeichert wird, im Verzeichnis /tmp. Die Datei hat dort den Namen krb5cc_<user-uid> (bei neueren Versionen des Kerberos kann es auch sein, dass der Name noch um einen zufälligen String erweitert wird). Immer, wenn der Anwender jetzt auf einen neuen Dienst oder Host zugreifen will, wird der Kerberos-Client im Hintergrund mithilfe des TGT ein Ticket für den Zugriff vom TGS anfordern und damit die Authentifizierung für den Anwender transparent durchführen. Damit ist ein echtes sso möglich.
Wichtig: Bevor wir jetzt zur Installation und Konfiguration des Kerberos-Servers kommen, noch ein wichtiger Punkt. Kerberos ist sehr zeitkritisch. Bei der Überprüfung der Tickets wird auch immer die Zeit der Erstellung überprüft. Aus diesem Grund ist es sinnvoll, dass Sie einen Zeitserver in Ihrem Netzwerk haben und alle Hosts in Ihrem Netzwerk sich die Systemzeit von diesem Zeitserver holen. Auch ein funktionsfähiger DNS-Server, der alle Hosts (sowohl die Server als auch die Clients) auflösen kann, muss in Ihrem Netzwerk laufen.
| 15.2 | Installation und Konfiguration des Kerberos-Servers |
Der Kerberos-Server ist nicht abhängig vom LDAP-Server. Ein Kerberos-Server kann auch ohne zentrale Benutzerverwaltung eingerichtet und genutzt werden. Ohne eine zentrale Benutzerverwaltung würden die Passwörter im Kerberos verwaltet, und die Benutzerkonten würden lokal auf den einzelnen Systemen eingerichtet. Um die Funktionsweise von Kerberos besser erklären zu können, werden wir im ersten Schritt einen Kerberos-Server ohne OpenLDAP einrichten und anschließend den OpenLDAP-Server für die zentrale Benutzerverwaltung zum Kerberos hinzufügen. Wir werden dabei die bestehende Kerberos-Datenbank in den OpenLDAP importieren, sodass bestehende Principals in den LDAP übernommen werden können. Das betrifft besonders die Host- und Service-Principals. Bei den Benutzer-Principals gibt es da bestimmte Einschränkungen, auf die wir an der entsprechenden Stelle zu sprechen kommen.
Um den ersten Kerberos-Server einzurichten, installieren Sie als Erstes die benötigten Pakete. Für Debian installieren Sie die Pakete wie gewohnt mit apt-get, wie in Listing 15.1 zu sehen:
Listing 15.1 Installation der benötigten Debian-Pakete
root@kerberos01:~# apt-get install krb5-admin-server krb5-kdc \ krb5-user krb5-kdc-ldap Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Statusinformationen werden eingelesen... Fertig Die folgenden zusätzlichen Pakete werden installiert: krb5-config Vorgeschlagene Pakete: openbsd-inetd inet-superserver Die folgenden NEUEN Pakete werden installiert: krb5-admin-server krb5-config krb5-kdc krb5-user krb5-kdc-ldap
Das Paket krb5-kdc-ldap wird hier schon mit installiert, um später die Kerberos-Datenbank in den LDAP verschieben zu können und den Kerberos-Server für die Verwendung von LDAP zu konfigurieren. Mehr dazu, wie Sie Kerberos in den LDAP integrieren können, finden Sie in Abschnitt 15.8, «Kerberos im LDAP einbinden». Während der Installation werden eventuell (abhängig von der Distribution) die folgenden Parameter abgefragt, über die Sie sich im Vorfeld Gedanken machen sollten:
Der Realm: Mit dem Realm legen Sie den Administrationsbereich für den Kerberos fest. Hier tragen Sie den FQDN des Servers ein, der für den Realm verantwortlich ist. Meist wird hier der DNS-Name der Domäne verwendet. Hier im Buch arbeiten wir mit dem Realm EXAMPLE.NET. Wenn Sie für den Realm den DNS-Namen Ihrer Domäne verwenden, hat das den Vorteil, dass Sie alle Namen der Principals für Ihre Hosts den FQDN der Hosts zuordnen können. Besonders, wenn Sie für mehr als eine Domäne verantwortlich sind. Der Realm wird grundsätzlich groß geschrieben.
Der Administrationsserver: Auf dem Administrationsserver werden die Principals verwaltet. Diesen Server darf es für jeden Realm nur einmal geben. Auch hier geben Sie den FQDN des Servers an.
Der KDC-Server: Das ist der Server, auf dem sich die Datenbank mit den Principals befindet. Der Server mit der Datenbank kann ein anderer Server sein als der Server, von dem aus die Datenbank verwaltet wird. Aus diesem Grund wird während der Einrichtung nach dem Admin-Server und dem KDC-Server gefragt. Hier im Buch sollen beide Dienste auf derselben Maschine eingerichtet werden. Das ist in den meisten Fällen auch die einfachste und beste Vorgehensweise. Die Trennung findet deshalb statt, da Sie später noch zusätzliche KDCs einrichten können, die dann nur die Funktion des KDCs übernehmen.
Bei Redhat installieren Sie die Pakete aus Listing 15.2:
Listing 15.2 Installation der benötigten CentOS-Pakete
[root@kerberos01 ~]# yum install krb5-libs krb5-server \ krb5-workstation krb5-server-ldap ...
Hier werden Sie während der Installation der Pakete nicht nach Parametern für die Datei /etc/krb5.conf gefragt.
| 15.2.1 | Konfiguration des ersten Kerberos-Servers |
Nachdem Sie die Pakete installiert haben, können Sie jetzt mit der Konfiguration beginnen. Für die Konfiguration des Kerberos-Servers werden die Datei kdc.conf und die Datei /etc/ krb5.conf verwendet. Die Datei kdc.conf finden Sie bei Debian im Verzeichnis /etc/krb5kdc, bei Redhat im Verzeichnis /var/lib/kerberos/krb5kdc.
Konfiguration der Datei /etc/krb5.conf
In dieser Datei finden Sie die Informationen für den Kerberos-Realm. An dieser Stelle legen Sie auch fest, auf welchen Systemen der KDC läuft und auf welchem System sich der Admin-Server für die Verwaltung der Datenbank befindet. Für einen Kerberos-Realm kann es mehrere KDCs geben, aber immer nur einen Admin-Server. Immer wenn Sie einen neuen KDC für einen Realm installieren, ist es (im Moment) noch notwendig, dass Sie auf allen KDCs und Client die krb5.conf anpassen.
Damit es nicht notwendig wird, dass Sie auf allen Clients bei jeder Änderung der KDCs die krb5.conf an alle Clients anpassen, werden wir Ihnen im Verlauf dieses Kapitel zeigen, wie Sie die benötigten Informationen über einen DNS-Server bei den Clients bekannt machen können.
Während der Installation der Pakete wird bereits eine Datei krb5.conf angelegt, in dieser befinden sich aber sehr viele nicht benötigte Einträge. Aus diesem Grund macht es Sinn, dass Sie die Datei immer auf Ihre Umgebung anpassen und alle nicht benötigten Einträge aus der Datei entfernen. In Listing 15.3 sehen Sie den Aufbau der Datei für die Beispielumgebung hier im Buch:
Listing 15.3 Alle benötigten Einträge in der krb5.conf
[libdefaults] default_realm = EXAMPLE.NET [realms] EXAMPLE.NET = { kdc = kerberos01.example.net admin_server = kerberos01.example.net } [domain_realm] .example.net = EXAMPLE.NET [logging] kdc = FILE:/var/log/kdc.log admin_server = FILE:/var/log/kadmind.log default = SYSLOG:NOTICE:DAEMON
Die einzelnen Abschnitte und Parameter haben dabei folgende Bedeutungen:
[libdefaults]
In diesem Abschnitt befinden sich die Standardeinstellungen für die Kerberos-Libraries. An dieser Stelle können Sie einige Einstellungen vornehmen, die das Verhalten des Kerberos-Servers verändern. Eine vollständige Übersicht über die möglichen Parameter finden Sie unter https://web.mit.edu/kerberos/krb5-1.19/doc/admin/conf_files/krb5_conf.html#libdefaults.
default_realm = EXAMPLE.NET
Dieser Parameter gibt den Standard-Realm für die Client-Server-Kommunikation an. Achten Sie darauf, dass Sie den Realm hier unbedingt in Großbuchstaben schreiben.
[realms]
In diesem Abschnitt werden alle Realms verwaltet, die ein Client kennt, und es wird definiert, auf welchen Hosts sich die entsprechenden Server befinden.
kdc = kerberos01.example.net
Das ist der FQDN des KDC. An dieser Stelle können später auch noch weitere KDCs eingetragen werden.
admin_server = kerberos01.example.net
Da der Admin-Server und der KDC auf verschiedenen Maschinen laufen können, ist es wichtig, dass hier der FQDN des Admin-Servers angegeben wird. In den meisten Fällen werden Sie den KDC und den Admin-Server auf derselben Maschine installieren. Wir werden hier im Buch auch beide Dienste auf demselben Host installieren und konfigurieren.
[domain_realm]
Hier wird die Verbindung des Kerberos-Realms und des Domainnamens hergestellt. Dieser Eintrag wird von Programmen benötigt, die feststellen müssen, zu welchem Realm ein Host gehört. Hier wird der FQDN der DNS-Domain verwendet.
.example.com = EXAMPLE.NET
Da die Domain hier im Buch genauso heißt wie der Realm, steht auf beiden Seiten der Zuweisung derselbe Name. Wichtig ist, dass der Realm auch an dieser Stelle komplett großgeschrieben wird.
[logging]
In diesem Abschnitt wird das Logging für den KDC und den Admin-Server festgelegt.
kdc = FILE:/var/log/kdc.log
Dieses ist die Log-Datei für den KDC. Sie können auch im Verzeichnis /var/log ein Unterverzeichnis anlegen und die Log-Dateien in dieses Unterverzeichnis legen. Wenn Sie mit einem Unterverzeichnis arbeiten, denken Sie daran, die Rechte des Verzeichnisses so anzupassen, dass der Benutzer, unter dem der KDC und der Admin-Server laufen, schreibenden Zugriff auf das Verzeichnis hat.
admin_server = FILE:/var/log/kadmind.log
Dieses ist die Log-Datei für den Admin-Server.
default = SYSLOG:NOTICE:DAEMON
An dieser Stelle können Sie das Verhalten des Syslogd bestimmen wie beispielsweise hier das Log-Level NOTICE.
Wichtig: Achten Sie darauf, dass die Namen des KDC und des Admin-Servers über DNS auflösbar sind.
Wichtig: Um die Log Files schreiben zu können, ist es notwendig, dass Sie in den Startskripten des systemd das Verzeichnis /var/log zum Schreiben freigeben. Passen Sie in der Datei krb5-kdc.service und krb5-admin-server.service den Parameter ReadWriteDirectories entsprechend an. Der Ort, an dem Sie die Datei finden, ist distributionsabhängig, bei Debian ist es das Verzeichnis /usr/lib/systemd/system/. Führen Sie anschließend das Kommando systemctl daemon-reload aus, um die Änderung wirksam werden zu lassen.
Konfiguration der Datei kdc.conf
Die Datei kdc.conf dient zur Konfiguration des KDCs und liegt bei Debian im Verzeichnis /etc/krb5kdc/. Bei Redhat finden Sie die Datei im Verzeichnis /var/lib/kerberos. Bei Debian wurde der Realm bereits während der Installation der Pakete abgefragt. Haben Sie dort schon den korrekten Realm angegeben, brauchen Sie an der Datei kaum Änderungen vorzunehmen. In der Datei kdc.conf finden Sie bereits Einträge für den von Ihnen angegebenen Realm. Haben Sie bei der Installation der Pakete keinen oder nicht den endgültigen Realm angegeben, können Sie jetzt die Datei anpassen. Auf einem Debian-System sieht die Datei so aus wie in Listing 15.4:
Listing 15.4 Die Datei kdc.conf auf einem Debian-System
[kdcdefaults] kdc_ports = 749,88 spake_preauth_kdc_challenge = edwards25519 [realms] EXAMPLE.NET = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 749,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = aes256-cts-hmac-sha1-96 supported_enctypes = aes256-cts-hmac-sha1-96:normal \ aes128-cts-hmac-sha1-96:normal default_principal_flags = +preauth }
Aus Gründen der Sicherheit haben wir die Standardeinstellungen für die Verschlüsselung geändert. Die Werte der Standardeinstellung haben wir entfernt, da die Standardverschlüsselungen heute als unsicher gelten.
Der Parameter spake_preauth_kdc_challenge sorgt für besseren Schutz gegen Wörterbuchangriffe. Mehr dazu finden Sie unter https://web.mit.edu/kerberos/krb5-devel/doc/admin/spake.html.
Bei Redhat hat die Datei den Inhalt wie in Listing 15.5 und muss von Ihnen auf jeden Fall angepasst werden:
Listing 15.5 Die kdc.conf auf einen CentOS-System
kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88 spake_preauth_kdc_challenge = edwards25519 [realms] EXAMPLE.NET = { master_key_type = aes256-cts-hmac-sha384-192 acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab supported_enctypes = aes256-cts-hmac-sha384-192:normal \ aes128-cts-hmac-sha256-128:normal \ camellia256-cts:normal \ camellia128-cts:normal }
Wichtig: Die Pfade bei Redhat und Debian sind unterschiedlich. Setzen Sie auf jeden Fall die richtigen Pfade für Ihre Distribution!
Um Ihnen eine eventuelle Anpassung der Parameter einfach zu machen, finden Sie in folgender Aufzählung eine Erklärung der einzelnen Parameter:
[kdcdefaults]
In diesem Abschnitt werden alle Parameter verwaltet, die unabhängig von allen verwalteten Realms auf dem Server vom KDC nötig sind.
kdc_ports = 750,88
Dieser Parameter legt die Ports fest, auf denen der KDC Anfragen entgegennimmt. Bei den hier angegebenen Ports handelt es sich um die Standard-Ports. Sie sollten nicht unnötig verändert werden, da eine Änderung dazu führen kann, dass einige Anwendungen sich mit dem KDC verbinden können, wenn in der Anwendung der Port für die Kommunikation mit dem KDC fest eingebunden ist. Hierbei handelt es sich um UDP-Ports. Wenn der KDC läuft, können Sie mit dem Kommando ss -uln testen, ob die Ports erreichbar sind. In der daraus resultierenden Auflistung sehen Sie dann die beiden UDP-Ports 749 und 88, die vom KDC verwendet werden.
[realms]
In diesem Bereich werden die Parameter für alle Realms verwaltet, für die der KDC verantwortlich ist. Zu jedem Realm, den Sie auf diesem KDC einrichten wollen, gibt es anschließend einen eigenen Konfigurationsbereich.
EXAMPLE.NET =
Das ist der Realm, für den dieser KDC verantwortlich ist. In den geschweiften Klammern werden die für diesen Realm relevanten Parameter eingetragen.
database_name = /var/lib/krb5kdc/principal
Das sind die Namen und der Pfad zur Kerberos-Datenbank. In dem Beispiel sehen Sie die Pfade auf einem Debian-System. Bei CentOS lautet der Pfad /var/lib/kerberos/principal.
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
Hierbei handelt es sich um die Datei, die der Admin der Datenbank benutzt, um sich am Kerberos zu authentifizieren. Auch hier sehen Sie im Listing wieder den Pfad für ein Debian-System.
acl_file = /etc/krb5kdc/kadm5.acl
Das ist die Datei, in der die Zugriffsregeln auf die Datenbank festgelegt werden. Diese Datei ist im Moment noch nicht vorhanden und muss von Ihnen später noch erstellt werden, um festzulegen, wer welche Rechte in der Datenbank hat.
key _stash_file = /etc/krb5kdc/stash
In dieser Datei befindet sich das Master-Passwort, das Sie während der Initialisierung der Datenbank festlegen werden.
kdc_ports = 749,88
Das sind die Ports, über die der KDC dieses Realms erreicht werden kann. Port 749 wird von Kerberos V5 genutzt. Kerberos V4 verwendet den Port 750.
max_life = 10h 0m0s
Hier geben Sie an, wie lange ein Ticket gültig ist. Zehn Stunden ist der Standardwert.
max_renewable_life = 7d 0h 0m 0s
Bei diesem Wert geben Sie an, wie lange ein Ticket maximal verlängert werden kann, bevor es neu angefordert werden muss. Sieben Tage ist der Standardwert.
master_key_type= aes256-cts-hmac-sha384-192
Dieser Parameter legt den Typ der Verschlüsselung für das Master-Passwort fest. Dieser Parameter ist bei Redhat nicht gesetzt. Wollen Sie eine spezielle Verschlüsselung für den Master-Key, können Sie den Parameter nachtragen.
supported_enctypes = aes256-cts-hmac-sha384-192:normal aes128-cts-hmac-sha256-128:normal
Hier können Sie festlegen, welche Verschlüsselungen der Kerberos-Server unterstützen soll. Eine Übersicht über mögliche Schlüssel und deren Sicherheit finden Sie unter https://web.mit.edu/kerberos/krb5-1.19/doc/admin/conf_files/kdc_conf.html#encryptiontypes.
default_principal_flags = +preauth
Dieser zusätzliche Parameter, der beim Starten des Kerberos-Servers übergeben wird, sorgt dafür, dass eine Pre-Authentication stattfinden muss. Das erhöht die Sicherheit gegen Offline-Passwortangriffe. Wenn Sie noch Kerberos-V4-Clients im Netz haben, dürfen Sie diesen Parameter nicht setzen, da diese Funktion erst ab der Kerberos-Version 5 unterstützt wird. Diese Funktion schützt davor, dass ein Angreifer versuchen kann, die Passwörter von Principals durch Offline-Versuche zu erraten. Der KDC sendet eine Anfrage an den Client, die diesen auffordert, einen Timestamp, der mit seinem Schlüssel verschlüsselt wurde, zu entschlüsseln. Gelingt das nicht, ist die Authentifizierung fehlgeschlagen und wird abgebrochen.
| 15.2.2 | Initialisierung und Testen des Kerberos-Servers |
Nachdem Sie die beiden Konfigurationsdateien erstellt haben, können Sie im nächsten Schritt die Datenbank für den Kerberos-Server initialisieren. Bei der Initialisierung der Datenbank wird auch das Master-Passwort festgelegt. Dieses Passwort dürfen Sie auf gar keinen Fall verlieren, denn ohne das Passwort können Sie die Datenbank später nicht mehr exportieren, um Sie eventuell auf eine manderen Kerberos-Server wieder einzuspielen. Auch wenn Sie später auf eine andere Verschlüsselung umstellen wollen, benötigen Sie das Passwort, um die Datenbank zu entschlüsseln und die neue Art der Verschlüsselung durchführen zu können. Solange der Server läuft und Sie keine Änderungen der Struktur oder der Verschlüsselung vornehmen wollen, benötigen Sie das Passwort nicht, denn auch bei einem Neustart des Systems wird das Öffnen der Datenbank über den stash-File, in dem sich das verschlüsselte Passwort befindet, durchgeführt.
Wichtig: Mit dem Master-Passwort kann die gesamte Kerberos-Datenbank entschlüsselt werden. Sie sollten an dieser Stelle ein sehr sicheres Passwort wählen und das Passwort nicht weitergeben. Das Passwort kann nicht für die Authentifizierung genutzt werden, sondern nur, um die Datenbank zu entschlüsseln. Verlieren Sie das Passwort, dann ist es nicht mehr möglich, die Datenbank komplett zu entschlüsseln. Eine spätere Migration auf einen anderen Server ist ohne das Master-Passwort auch nicht mehr möglich. Legen Sie deshalb das Passwort unbedingt an einer sicheren Stelle ab. Kopieren Sie auch die stash-Datei an einen sicheren Ort.
Jetzt können Sie die Datenbank mit dem Kommando kdb5_util -s create erzeugen. Bei der Initialisierung werden Sie auch nach dem Master-Passwort gefragt. Den Vorgang der Initialisierung sehen Sie in Listing 15.6:
Listing 15.6 Initialisierung der Datenbank
root@kerberos01:~# kdb5_util create -s Zufällige Daten werden geladen. Datenbank /var/lib/krb5kdc/principal für Realm EXAMPLE.NET \ wird initialisiert, Hauptschlüsselname K/M@EXAMPLE.NET Sie werden nach dem Master-Passwort der Datenbank gefragt. Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN. Enter KDC database master key: Re-enter KDC database master key to verify:
Nach der Initialisierung finden Sie im Konfigurationsverzeichnis des KDC eine Datei mit dem Namen stash. Darin wurde das Passwort verschlüsselt abgelegt.
Im Anschluss an die Initialisierung der Datenbank ist es noch notwendig, dass Sie die Zugriffsberechtigungen vergeben. Ohne die Einrichtung der ACLs für die Datenbank können Benutzer kein Passwort ändern, und die Mitglieder der Kerberos-Admin-Gruppe können keine Principals anlegen. Damit die Zugriffe auf die Datenbank gesteuert werden können, passen Sie vor dem ersten Test die Datei kadm5.acl an.
Hinweis: Bei Debian existiert die Datei nicht und muss von Ihnen erstellt werden. Über die ACLs wird nicht nur der Zugriff für Benutzer gesteuert, sondern auch die Berechtigungen für Dienste. Achten Sie bei der Datei auf die unterschiedlichen Pfade der einzelnen Distributionen. Die Pfade für die Datei finden Sie in der Konfigurationsdatei kdc.conf der jeweiligen Distribution.
In jeder Zeile der Datei steht eine ACL, um den Zugriff auf die Datenbank zu steuern. Die ACLs werden der Reihe nach abgearbeitet. Sobald eine Regel auf eine Anfrage passt, wird die Abarbeitung der ACLs abgebrochen. Deshalb ist die Reihenfolge der ACLs besonders wichtig. In Listing 15.7 sehen Sie eine einfache kadm5.acl-Datei:
Listing 15.7 Die Kerberos-ACLs
*/admin@EXAMPLE.NET * *@EXAMPLE.NET il */*@EXAMPLE.NET i
Nach jeder Änderung an der Datei kadm5.acl dürfen Sie nicht vergessen, den KDC und den Admin-Server neu zu starten, damit die Änderungen wirksam werden. Die einzelnen Einträge haben dabei folgende Bedeutungen:
*/admin@EXAMPLE.NET *
Die Admins des KDC haben Vollzugriff auf die Datenbank. Diesen Eintrag dürfen Sie nicht vergessen, sonst können Sie keine Principals anlegen. Der Eintrag sollte auch immer der erste in der Liste sein, um zu verhindern, dass der Zugriff eines Administrators durch eine andere ACL verhindert wird.
*@EXAMPLE.NET il
Mit diesem Recht (i=info) ist es möglich, die Datenbank abzufragen. Das Recht (l=list) ermöglicht das Auslesen aller Informationen eines Principals. Der Eintrag ist nur für Principals mit nur einer Komponente gültig. Bei diesen Principals handelt es sich um Benutzer-Principals.
*/*@EXAMPLE.NET i
Dieser Eintrag ist für alle Principals mit zwei Komponenten wie Hosts und Services gültig. Diese Principals erhalten lediglich das Recht, die Datenbank abzufragen.
Hinweis: Für die Änderung des eigenen Passworts wird kein Eintrag in der Datei benötigt, denn jeder Benutzer kann immer das Passwort seines eigenen Principals ändern. Dazu bedarf es keiner zusätzlichen Rechte.
Um Ihnen eine Übersicht über die möglichen Rechte zu geben, finden Sie in der Tabelle 15.1 eine entsprechende Übersicht über alle möglichen Rechte, die Sie über ACLs geben oder nehmen können. Dabei bedeuten ein kleiner Buchstabe, dass das Recht einem Principal gegeben wird, und ein großer Buchstabe, dass dem Principal die Rechte genommen werden.
Tabelle 15.1 Kerberos-Rechte in der Übersicht
ACL-Flag |
Rechte |
a/A |
erlaubt oder verbietet das Hinzufügen eines Principals |
d/D |
erlaubt oder verbietet das Löschen eines Principals |
m/M |
erlaubt oder verbietet das Verändern eines Principals |
c/C |
erlaubt oder verbietet das Ändern von Passwörtern |
i/I |
erlaubt oder verbietet das Suchen in der Datenbank |
l/L |
erlaubt oder verbietet das Auflisten der Datenbank |
Wichtig: Gehen Sie sehr sparsam mit dem Recht c um. Ein Principal, der dieses Recht hat, kann alle Passwörter aller Principals ändern.
Bei Redhat ist lediglich eine Zeile für den Admin des Kerberos eingetragen. Der Realm des Admins ist aber auch dort nur ein Standardwert, auch dort ist eine Anpassung nötig.
| 15.2.3 | Verwalten der Principals |
Jetzt können Sie sich mit dem Admin-Server verbinden. Für die Verbindung zum Admin-Server gibt es zwei Programme: zum einen das Programm kadmin.local und zum anderen das Programm kadmin. Das Programm kadmin.local greift dabei direkt auf die Kerberos-Datenbank zu und benötigt selbst keine Authentifizierung. Das Programm kann nur von root verwendet werden.
Hinweis: Da im Moment noch kein Principal vorhanden ist, stellen Sie den ersten Kontakt zur Datenbank immer über kadmin.local her, denn darüber können Sie die Principals auch als root verwalten. Erst wenn Sie einen Administrator angelegt haben, können Sie das Programm kadmin verwenden, denn für die Nutzung des Programms ist eine Authentifizierung notwendig. Im Gegensatz zu kadmin können Sie sich mit dem Programm kadmin.local nur lokal an der Datenbank anmelden, eine Authentifizierung über das Netzwerk ist damit nicht möglich.
Nach dem Aufruf von kadmin.local befinden Sie sich in einem eigenen Prompt des Admin-Servers. Hier haben Sie jetzt die Möglichkeit, neue Principals anzulegen, bestehende zu ändern oder sich alle Principals auflisten zu lassen. In Listing 15.8 sehen Sie eine Liste aller bereits vorhandenen Principals:
Listing 15.8 Auflisten der Standard-Principals
root@kerberos-01:~# kadmin.local Authenticating as principal root/admin@EXAMPLE.NET with password. kadmin.local: listprincs K/M@EXAMPLE.NET kadmin/admin@EXAMPLE.NET kadmin/changepw@EXAMPLE.NET kadmin/kerberos01.example.net@EXAMPLE.NET kiprop/kerberos01.example.net@EXAMPLE.NET krbtgt/EXAMPLE.NET@EXAMPLE.NET
Wichtig: Diese Principals, die Sie dort aufgelistet bekommen, werden zwingend so vom Kerberos-Server benötigt. Ändern oder löschen Sie diese Principals nicht, denn das kann dazu führen, dass der Kerberos-Server nicht mehr funktioniert.
Im nächsten Schritt können Sie die ersten Principals anlegen. Wichtig ist, dass Sie beim Erstellen der Principals auf Groß- und Kleinschreibung achten. Denken Sie daran, der Realm wird immer groß geschrieben.
Als Erstes legen Sie jetzt den admin für den Kerberos an. Direkt im Anschluss können Sie weitere Benutzer anlegen. Sie dürfen das Programm kadmin.local nach dem Anlegen des Admins noch nicht verlassen; ohne einen Host-Principal ist eine Anmeldung am Programm kadmin nicht möglich. Für die Verwaltung der Kerberos-Datenbank ist immer eine Authentifizierung des Hosts, von dem aus zugegriffen wird, und des zugreifenden Benutzers nötig.
In Listing 15.9 sehen Sie, wie die neuen Principals mit dem Kommando addprinc erzeugt werden:
Listing 15.9 Anlegen der ersten Principals
kadmin.local: addprinc root/admin Für root/admin@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die \ Vorgabe keine Richtlinie verwandt. Geben Sie das Passwort für Principal root/admin@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal root/admin@EXAMPLE.NET erneut ein.: Principal "root/admin@EXAMPLE.NET" created. kadmin.local: addprinc andreas Für andreas@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die \ Vorgabe keine Richtlinie verwandt. Geben Sie das Passwort für Principal andreas@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal andreas@EXAMPLE.NET erneut ein.: Principal "andreas@EXAMPLE.NET" created.
Der erste Principal root/admin ist jetzt der Administrator des Kerberos-Servers, hier können Sie auch einen anderen Benutzer als den root verwenden. Wenn Sie die Systemadministration des Linux-Hosts und die Administration des Kerberos-Servers von verschiedenen Personen durchführen lassen wollen, hätten Sie hier die Chance, einen oder mehrere Benutzer als Administrator festzulegen. Der zweite Principal andreas ist nur ein ganz normaler Benutzer.
Wenn Sie im Anschluss noch einmal das Kommando listprincs verwenden, sehen Sie wie in Listing 15.10 Ihre neu angelegten Principals:
Listing 15.10 Auflisten der neuen Principals
kadmin.local: listprincs K/M@EXAMPLE.NET andreas@EXAMPLE.NET kadmin/admin@EXAMPLE.NET kadmin/changepw@EXAMPLE.NET kadmin/kerberos01.example.net@EXAMPLE.NET kiprop/kerberos01.example.net@EXAMPLE.NET krbtgt/EXAMPLE.NET@EXAMPLE.NET root/admin@EXAMPLE.NET
Hinweis: An dieser Stelle nochmal der Hinweis, dass Sie das Programm kadmin.local noch nicht verlassen dürfen. Denn es reicht nicht aus, die Benutzer in der Datenbank anzulegen. Es muss auch noch mindestens ein Client angelegt werden, von dem aus Sie auf den Kerberos-Server zugreifen wollen. Der Grund ist der, dass Kerberos sowohl eine Client- als auch eine Benutzerauthentifizierung bei der Anmeldung mit kadmin durchführt.
Für jeden Host, von dem aus Sie sich in Zukunft am Admin-Server anmelden wollen, benötigen Sie noch einen Eintrag in der Kerberos-Datenbank. Der Client wird dabei mit seinem FQDN in die Kerberos-Datenbank eingetragen. Aus diesem Grund ist es immer sinnvoll, eine funktionierende DNS-Infrastruktur im Netz zu haben, wenn Kerberos eingesetzt werden soll.
Als Erstes kann der Server, auf dem der Admin-Server läuft, in die Datenbank eingetragen werden. Später können Sie dann weitere Systeme wie Ihren Arbeitsplatzrechner in die Datenbank eintragen. Das Eintragen in die Datenbank führen Sie wieder mit dem Kommando addprinc im Programm kadmin.local aus. Beim Anlegen des Host-Principals verwenden Sie zusätzlich den Parameter -randkey. Über den Parameter -randkey wird ein Schlüssel erzeugt, der für die Authentifizierung am Kerberos-Server vom Client verwendet wird. Ohne diesen Parameter würde wieder nach einem Passwort gefragt. Das wäre dann das Passwort, das der Client für die Authentifizierung angeben müsste. Da der Client (ein Computer) aber selber kein Passwort eingeben kann, wird hier ein zufälliger Schlüssel generiert, der in einem weiteren Schritt in einer Datei gespeichert wird. Diese Datei mit dem verschlüsselten Key verwendet der Client dann für die Authentifizierung.
Nicht nur der Client, sondern auch der LDAP-Dienst soll sich authentifizieren können. Aus diesem Grund benötigen Sie noch einen Service-Key, der dann dem Dienst zugewiesen wird. In einer Produktivumgebung werden Sie den Kerberos-Server und den LDAP-Server auf getrennten Systemen verwalten; dann benötigen Sie für beide Systeme einen Host-Principal und zusätzlich noch einen Service-Principal für den LDAP-Dienst. Im Moment reicht es, wenn Sie einen Host-Principal für den Kerberos-Server anlegen, die Keys für den LDAP-Server werden erst zu einem späteren Zeitpunkt benötigt. Das Anlegen des Service-Principals dient hier nur zur Veranschaulichung.
In Listing 15.11 sehen Sie, wie der Host-Principal und der Service-Principal erzeugt werden:
Listing 15.11 Anlegen des ersten Host- und Service-Principals
kadmin.local: addprinc -randkey host/kerberos01.example.net Für host/kerberos01.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben\ , es wird die Vorgabe keine Richtlinie verwandt. Principal "host/kerberos01.example.net@EXAMPLE.NET" created. kadmin.local: addprinc -randkey ldap/kerberos01.example.net Für ldap/kerberos01.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben\ , es wird die Vorgabe keine Richtlinie verwandt. Principal "ldap/kerberos01.example.net@EXAMPLE.NET" created.
Jetzt können Sie das Programm kadmin.local mit exit verlassen. Denn jetzt ist es so weit: Sie können sich mit dem Principal root/admin am Kerberos authentifizieren und das Programm kadmin verwenden!
Für die Authentifizierung am Programm kadmin benötigen Sie nun einen Kerberos-Principal. Da Sie bereits für den root einen admin-Principal angelegt haben, können Sie sich als root/admin am Programm kadmin anmelden. Der root/admin gehört zur Kerberos-Gruppe admin und kann daher die Einträge in der Datenbank verwalten. Das Recht hat diese Gruppe über die vorher eingerichteten ACLs erhalten.
Jeder Benutzer, der jetzt einen Principal in der Kerberos-Datenbank besitzt, kann sich mit dem Programm kadmin am Admin-Server anmelden. Aufgrund der vorher konfigurierten ACLs hat er nur die Rechte, die Sie ihm eingeräumt haben. In Listing 15.12 sehen Sie, was passiert, wenn ein normaler Benutzer versucht, einen neuen Principal zu erstellen:
Listing 15.12 kadmin als unprivilegierter Benutzer
root@kerberos01:~# kadmin -p andreas@EXAMPLE.NET Authentifizierung als Principal andreas@EXAMPLE.NET mit Passwort Passwort für andreas@EXAMPLE.NET: kadmin: listprincs K/M@EXAMPLE.NET andreas@EXAMPLE.NET host/kerberos01.example.net@EXAMPLE.NET kadmin/admin@EXAMPLE.NET kadmin/changepw@EXAMPLE.NET kadmin/kerberos01.example.net@EXAMPLE.NET kiprop/kerberos01.example.net@EXAMPLE.NET krbtgt/EXAMPLE.NET@EXAMPLE.NET ldap/kerberos01.example.net@EXAMPLE.NET root/admin@EXAMPLE.NET kadmin: addprinc stefan Für stefan@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird \ die Vorgabe keine Richtlinie verwandt. Geben Sie das Passwort für Principal stefan@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal stefan@EXAMPLE.NET erneut ein.: add_principal: Aktion erfordert add-Recht while creating \ "stefan@EXAMPLE.NET". kadmin: change_password andreas Geben Sie das Passwort für Principal andreas@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal andreas@EXAMPLE.NET erneut ein.: Passwort von andreas@EXAMPLE.NET geändert
Sie sehen, dass der Benutzer zwar das Kommando zum Anlegen eines neuen Principals aufrufen und ein neues Passwort angeben kann, aber beim eigentlichen Anlegen des neuen Principals kommt es zu einer Fehlermeldung. Das Einzige, was der Benutzer hier machen kann, ist, sein Passwort zu ändern. Für alle weiteren Möglichkeiten müssten Sie die ACLs erweitern.
Tipp: Wenn Sie keinen Principal beim Start von kadmin angeben, wird immer der gerade angemeldete Benutzer mit der Gruppe admin verknüpft und versucht, eine Authentifizierung durchzuführen. Wenn Sie sich nicht als root anmelden wollen, können Sie über den Parameter -p <principal> den root/admin oder einen anderen Benutzer aus der Admin-Gruppe angeben, um das Programm kadmin zu starten.
| 15.3 | Kerberos und PAM |
Zu diesem Zeitpunkt haben Sie einen Kerberos-Server, auf dem Sie Principals verwalten können, aber die Benutzer können Kerberos noch nicht für eine Anmeldung nutzen. Jetzt wird es Zeit, dass Sie dafür sorgen, dass die Benutzer sich über Kerberos authentifizieren. Im ersten Schritt wird an dieser Stelle erst einmal die lokale Anmeldung realisiert, später soll dann Kerberos in den LDAP integriert werden, um eine zentrale Benutzerverwaltung zu ermöglichen.
Die meisten Linux-Distributionen ermöglichen heute eine Authentifizierung über PAM, deshalb soll an dieser Stelle jetzt auch PAM für Kerberos konfiguriert werden. Hier im Buch wird PAM zwar konfiguriert, aber die Funktion und die Möglichkeiten von PAM sind so weitreichend, dass eine ausführliche Erklärung den Rahmen des Buchs sprengt.
Bevor Sie jetzt mit der Konfiguration von PAM beginnen, hier noch ein wichtiger Hinweis:
Wichtig: Wenn Sie die Konfigurationsdateien von PAM editieren, achten Sie darauf, dass Sie immer eine root-Konsole geöffnet haben, denn wenn Sie einen Fehler in einer der Konfigurationsdateien haben, kann sich möglicherweise kein Benutzer mehr anmelden, das gilt auch für root. Bei einer Änderung der Konfigurationsdateien muss nach der Änderung kein Dienst neu gestartet werden, beim Speichern der Änderung sind die Änderungen sofort wirksam.
PAM-Konfiguration unter Debian
Damit Sie PAM verwenden können, installieren Sie als Erstes das Paket libpam-krb5 für Debian. Bei Debian sind keine Änderungen an den Dateien in /etc/pam.d notwendig. Das PAM-Modul wird automatisch in alle common-*-Dateien eingetragen.
Als Beispiel sehen Sie in Listing 15.13 die Einträge in der Datei common-auth:
Listing 15.13 Einträge in der PAM-Konfiguration
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so
Die erste Zeile ergänzt die Authentifizierung um die Möglichkeit, die Passwörter aus dem Kerberos zu nutzen.
Achten Sie darauf, dass hier als erste UID die 1000 eingetragen ist. Bei allen auf Debian basierenden Distributionen wird die UID 1000 immer für den ersten Benutzer verwendet, der während der Installation angelegt wird. Wollen Sie verhindern, dass der Benutzer auch Kerberos für die Anmeldung nutzt, setzen Sie den Wert mindestens auf 1001. Damit würde der erste Benutzer eines Systems sich grundsätzlich mit dem Passwort aus der Datei /etc/shadow authentifizieren. Es macht Sinn, den ersten Benutzer als lokale Anmeldung zu belassen, denn sollte der Kerberos-Dienst einmal nicht erreichbar sein, wäre immer noch eine lokale Anmeldung möglich. Zwar sorgt die zweite Zeile dafür, dass im Falle einer fehlerhaften oder unmöglichen Authentifizierung gegen Kerberos die lokale Passwortdatei /etc/shadow verwendet wird, aber es kann bei der Anmeldung eine Zeit lang dauern, bis die lokale Anmeldung angeboten wird.
Wenn die Authentifizierung gegen Kerberos erfolgreich war, dann werden die nächsten beiden Zeilen in der Konfiguration übersprungen success=2.
Wird der Benutzer nicht im Kerberos gefunden, wird die zweite Zeile abgearbeitet. Die dritte Zeile sorgt dafür, dass für den Fall, dass beide Authentifizierungen fehlschlagen, die Authentifizierung abgebrochen wird. Wird die Authentifizierung über Kerberos ordnungsgemäß durchgeführt, sorgt der Parameter try_first_pass der zweiten Zeile dafür, dass die Authentifizierung über die Datei /etc/shadow nicht mehr abgearbeitet wird.
Tipp: Sollten Sie bei der Anmeldung der Benutzer auf Probleme stoßen, können Sie in der Datei common-auth hinter den Modulen pam_unix2 und pam_krb5 die Option debug setzen. Dann können Sie in der Datei /var/log/syslog und var/log/auth.log sehr leicht einen Fehler in der PAM-Konfiguration aufspüren.
| 15.3.0.1 | PAM-Konfiguration unter Redhat |
Bei Redhat hat sich die Verwaltung der lokalen Authentifizierung komplett geändert, bis einschließlich Redhat 7 konnte die Konfiguration von PAM mit dem Kommando authconfig durchgeführt werden. Alle neueren Versionen stellen Ihnen diese Art der Konfiguration nicht mehr zur Verfügung. Hier wird die PAM-Konfiguration mittels des neuen Kommandos authselect durchgeführt. Dabei werden alle Änderungen jetzt am sssd durchgeführt und nicht mehr direkt im PAM. Da die Einführung in authselect etwas aufwendiger ist,
können wir hier im Buch nicht darauf eingehen. Eine ausführliche Beschreibung finden Sie unter https://docs.pagure.org/sssd.sssd/users/pam_krb5_migration.html. Für eine erfolgreiche Authentifizierung der Benutzer reicht die Installation der entsprechenden Pakete. Alle Einstellungen, die für die Authentifizierung benötigt werden, werden automatisch durchgeführt.
| 15.3.1 | Testen der Anmeldung |
Jetzt ist es soweit: Ein Benutzer, der in der lokalen Datenbank des Kerberos-Servers angelegt wurde, kann sich das erste Mal mit seinen Kerberos-Credentials anmelden. Sollten Sie noch keinen lokalen Benutzer angelegt haben, legen Sie jetzt einen neuen Benutzer an, vergeben Sie für den Benutzer aber kein Passwort, denn diese Information bekommt er aus dem Kerberos. Erzeugen Sie für den Benutzer einen Kerberos-Principal, in dem dann das Passwort abgelegt wird. Durch die Verknüpfung von PAM und dem Anmeldeprozess wird jetzt der Benutzername aus der Datei /etc/passwd zusammen mit dem namensgleichen Principal aus dem Kerberos für die Anmeldung verwendet.
In Listing 15.14 sehen Sie noch einmal alle Schritte für das Anlegen eines neuen Benutzers, zusammen mit dem Kerberos-Principal:
Listing 15.14 Anlegen eines neuen lokalen Benutzers
root@kerberos01:~# useradd -s /bin/bash skania root@kerberos01:~# kadmin Authentifizierung als Principal root/admin@EXAMPLE.NET mit Passwort Passwort für root/admin@EXAMPLE.NET: kadmin: addprinc skania Für skania@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die Vorgabe \ keine Richtlinie verwandt. Geben Sie das Passwort für Principal skania@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal skania@EXAMPLE.NET erneut ein.: Principal "skania@EXAMPLE.NET" created. root@kerberos01:~# grep skania /etc/shadow skania:!:19409:0:99999:7:::
In dem Auszug aus der Datei /etc/shadow sehen Sie, dass für den lokalen Benutzer kein Passwort vergeben wurde.
Melden Sie sich jetzt mit einem der von Ihnen angelegten lokalen Benutzer an Ihrem Kerberos-Server an. Verwenden Sie bei der Anmeldung das Passwort des Kerberos-Principals. Nach der Anmeldung prüfen Sie mit dem Kommando kinit, ob der Benutzer ein Ticket erhalten hat. In Listing 15.15 sehen Sie den Anmeldevorgang:
Listing 15.15 Testen der Anmeldung
user@host:~$ ssh skania@192.168.56.81 skania@192.168.56.81’s password: ... skania@kerberos01:~$ klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_1001_N0waF0 Standard-Principal: skania@EXAMPLE.NET Valid starting Expires Service principal 21.02.2023 12:33:22 21.02.2023 22:33:22 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 22.02.2023 12:33:22
Was passiert aber jetzt, wenn der angemeldete Benutzer sein Passwort ändern will, denn das Passwort muss ja im Kerberos geändert werden? Da Sie die Authentifizierung über PAM steuern, erkennt das Kommando passwd die Verwendung von Kerberos und leitet die Passwortänderung an Kerberos weiter. In Listing 15.16 sehen Sie den Vorgang:
Listing 15.16 Ändern des Passworts
skania@kerberos01:~$ passwd Current Kerberos password: Enter new Kerberos password: Retype new Kerberos password: passwd: Passwort erfolgreich geändert
Sie sehen, hier wird jetzt nur noch das Kerberos-Passwort geändert. Für den Benutzer ändert sich an dem Vorgang nichts, nur die Anzeige ist eine andere.
| 15.4 | Hosts und Dienste |
Im letzten Abschnitt haben wir uns um die Benutzer gekümmert, die sich über Kerberos anmelden sollen. Da Kerberos aber auch eine Authentifizierung der Hosts und der Services ermöglicht, sehen Sie in diesem Abschnitt, wie Sie die Authentifizierung für Hosts und Services einrichten.
Ein Host oder Service ist nicht in der Lage, sein Passwort einzugeben, also muss das Passwort für den Host oder Service anders abgeglichen werden. Dieser Vorgang läuft über eine keytab-Datei, die Sie für den entsprechenden Host oder Service anlegen.
Sie können alle Host- und Service-Keys immer in der Standard-keytab-Datei für das System /etc/krb5.keytab ablegen. Besser und sicherer ist es aber, für jeden Dienst eine eigene keytab-Datei zu verwalten und nur den Host-Key in die Standard-Keytab zu legen. Da die keytab-Datei für einen Service immer auf dem System liegen muss, das auch den Dienst bereitstellt, ist es aus Sicherheitsgründen besser, die Dateien separat zu verwalten und auf dem System nur mit den benötigten Rechten auszustatten.
Beim Erstellen der Principals in Abschnitt 15.2.3, «Verwalten der Principals», haben Sie schon einen Principal für einen Host und einen Service erstellt. Für diese beiden Principals soll jetzt eine eigene keytab-Datei erzeugt werden. Der Host-Key wird dabei in der Datei /etc/krb5.keytab eingetragen und der Service-Key für den LDAP-Dienst in eine eigene Datei. Dazu verwenden Sie wieder das Programm kadmin.
Nachdem Sie sich an kadmin angemeldet haben, können Sie den neuen Eintrag in der keytab-Datei erstellen, wie in Listing 15.17 gezeigt:
Listing 15.17 Erstellen der Keytab-Dateien
kadmin: ktadd host/kerberos01.example.net Der Eintrag für Principal host/kerberos01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ FILE:/etc/krb5.keytab hinzugefügt. Der Eintrag für Principal host/kerberos01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ FILE:/etc/krb5.keytab hinzugefügt. kadmin: ktadd ldap/kerberos01.example.net Der Eintrag für Principal ldap/kerberos01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ FILE:/etc/krb5.keytab hinzugefügt. Der Eintrag für Principal ldap/kerberos01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ FILE:/etc/krb5.keytab hinzugefügt. kadmin: ktadd -k /etc/ldap.keytab ldap/kerberos01.example.net Der Eintrag für Principal ldap/kerberos01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/etc/ldap.keytab hinzugefügt. Der Eintrag für Principal ldap/kerberos01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/etc/ldap.keytab hinzugefügt.
Beim ersten Kommando wird die Host-Keytab für den Host angelegt; da hier keine Datei angegeben wurde, wird der Key in die Standard-Keytab /etc/krb5.keytab geschrieben. Beim zweiten Kommando haben wir absichtlich vergessen, eine neue Keytab-Datei anzugeben; der Key wird deshalb auch in der Standard-Keytab abgelegt. Beim dritten Kommando wird über die Option -k /etc/ldap.keytab ein Dateiname angegeben, in dieser Datei wird der Key abgelegt.
Achten Sie darauf, dass Sie die Reihenfolge der Parameter einhalten. Bei allen Kommandos innerhalb von kadmin muss der Principal immer als letztes Argument angegeben werden.
Wichtig: Bei der Key Version Number (KVNO) handelt es sich um die aktuelle Seriennummer eines Eintrags in einer keytab-Datei. Bei der Authentifizierung eines Dienstes oder eines Hosts wird die KVNO immer mit der Version in der Datenbank verglichen. Nur wenn die Versionsnummer identisch ist, ist eine Authentifizierung möglich. Wenn eine Authentifizierung fehlschlägt, prüfen Sie immer auch die KVNO. Bei jeder Generierung eines Keys wird die KVNO hochgezählt.
Wenn Sie später aus irgendeinem Grund einen Key ungültig machen wollen, brauchen Sie lediglich eine neue Keytab-Datei zu generieren. Dadurch wird der alte Key ungültig und kann nicht mehr für eine Authentifizierung genutzt werden.
Das Programm ktutil
Wollen Sie zu einem späteren Zeitpunkt die Informationen aus einer Keytab auslesen, verwenden Sie dafür das Programm ktutil. Wenn Sie das Programm aufrufen, erhalten Sie einen eigenen Prompt.
Nach dem Start lesen Sie als Erstes die Keytab ein, aus der Sie die Keys auslesen wollen. Welche Kommandos Ihnen im Programm ktutil zur Verfügung stehen, können Sie durch Eingabe eines Fragezeichens feststellen. In Listing 15.18 sehen Sie, wie Sie sich den Inhalt einer Keytab ansehen können:
Listing 15.18 Anzeigen des Inhalts einer Keytab
ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- ------------------------------------------- 1 2 host/kerberos01.example.net@EXAMPLE.NET 2 2 host/kerberos01.example.net@EXAMPLE.NET 3 2 ldap/kerberos01.example.net@EXAMPLE.NET 4 2 ldap/kerberos01.example.net@EXAMPLE.NET
Wie Sie in der Liste sehen, ist hier beim Anlegen des LDAP-Keys ein Fehler passiert, und der Schlüssel wurde beim ersten Mal direkt in die Datei /etc/krb5.keytab geschrieben. Erst beim zweiten Mal wurde der Key in die Datei /etc/ldap.keytab geschrieben. Aus diesem Grund soll jetzt der Key aus der Datei entfernt werden, anschließend wird die Datei ohne den LDAP-Key gespeichert. Diesen Vorgang sehen Sie in Listing 15.19:
Listing 15.19 Löschen eines Keys
ktutil: delent 4 ktutil: l slot KVNO Principal ---- ---- ----------------------------------------- 1 2 host/kerberos01.example.net@EXAMPLE.NET 2 2 host/kerberos01.example.net@EXAMPLE.NET 3 2 ldap/kerberos01.example.net@EXAMPLE.NET ktutil: delent 3 ktutil: l slot KVNO Principal ---- ---- ----------------------------------------- 1 2 host/kerberos01.example.net@EXAMPLE.NET 2 2 host/kerberos01.example.net@EXAMPLE.NET ktutil: wkt /etc/krb5.keytab.neu
Wichtig: Geben Sie beim Schreiben der Keytab-Datei auf jeden Fall einen neuen Dateinamen an. Wenn Sie den Namen der bestehenden Datei angeben, wird die Datei nicht überschrieben, sondern es werden die Einträge der Liste zur alten Liste in der Datei hinzugefügt. Damit hätten Sie die Schlüssel alle doppelt in der Datei. Nachdem Sie das Programm ktutil verlassen haben, können Sie dann die alte Datei löschen und die neue umbenennen.
Jetzt haben Sie in der Datei /etc/krb5.conf den Key für den Host-Principal mit der KVNO=2 und in der Datei /etc/ldap.keytab den Service-Principal für den LDAP mit der KVNO=3.
Hinweis: Wenn Sie andere KVNOs für Ihre Keys haben, kann das daran liegen, dass Sie schon Keys erzeugt und wieder gelöscht haben. Wichtig ist nur, dass die KVNO des Keys in der Datenbank mit dem Key in der Keytab-Datei übereinstimmt.
Sie wollen wissen, welche KVNO eines Principals die aktuelle ist? Nutzen Sie das Programm kadmin. In Listing 15.20 sehen Sie die Prüfung des Keys:
Listing 15.20 Überprüfen des Keys
kadmin: getprinc ldap/kerberos01.example.net Principal: ldap/kerberos01.example.net@EXAMPLE.NET Ablaufdatum: [niemals] Letzte Passwortänderung: Di Feb 21 16:45:34 CET 2023 Passwortablaufdatum: [niemals] maximale Ticketlebensdauer: 0 days 10:00:00 maximale verlängerbare Lebensdauer: 7 days 00:00:00 zuletzt geändert: Di Feb 21 16:45:34 CET 2023 (root/admin@EXAMPLE.NET) letzte erfolgreiche Authentifizierung: [niemals] Last failed authentication: [never] Fehlgeschlagene Anmeldeversuche: 0 Anzahl der Schlüssel: 2 Key: vno 3, aes256-cts-hmac-sha384-192 Key: vno 3, aes128-cts-hmac-sha256-128 MKey: vno 1 Attribute: REQUIRES_PRE_AUTH Richtlinie: [keins]
Das Programm kvno
Eine andere Möglichkeit, die KVNO zu prüfen, ist die Verwendung des Kommandos kvno. Doch bevor Sie mit dem Kommando kvno die Keys prüfen können, benötigen Sie ein Kerberos TGT. Um das Ticket zu erhalten, authentifizieren Sie sich mit dem Kommando kinit. Prüfen Sie mit klist, dass außer dem TGT kein weiteres Ticket in Ihrem Cache vorhanden ist. Sollten schon weitere Service-Tickets in Ihrem Cache vorhanden sein, löschen Sie alle Tickets mit kdestroy und melden sich anschließend erneut mit kinit an.
Bei der Verwendung von kvno geben Sie die Keytab-Datei und den Principal an, den Sie prüfen wollen. Bei der Ausführung des Programms wird versucht, mit dem Key aus der Keytab-Datei ein Ticket vom Kerberos-Server zu beziehen. Stimmt der Key in der Datei mit dem Key in der Datenbank überein, funktioniert die Authentifizierung, wie Sie es in Listing 15.21 sehen. Auch sehen Sie anschließend mit klist die entsprechenden Tickets:
Listing 15.21 Prüfen der eingerichteten Keys
root@kerberos01:~# klist klist: No credentials cache found (filename: /tmp/krb5cc_0) root@kerberos01:~# kinit root/admin Passwort für root/admin@EXAMPLE.NET: root@kerberos01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: root/admin@EXAMPLE.NET Valid starting Expires Service principal 21.02.2023 16:58:29 22.02.2023 02:58:29 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 22.02.2023 16:58:27 root@kerberos01:~# kvno -k /etc/ldap.keytab ldap/kerberos01.example.net ldap/kerberos01.example.net@EXAMPLE.NET: KVNO = 3, \ Schlüsseltabelleneintrag gültig root@kerberos01:~# kvno -k /etc/krb5.keytab host/kerberos01.example.net host/kerberos01.example.net@EXAMPLE.NET: KVNO = 2, \ Schlüsseltabelleneintrag gültig root@kerberos01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: root/admin@EXAMPLE.NET Valid starting Expires Service principal 21.02.2023 16:58:29 22.02.2023 02:58:29 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 22.02.2023 16:58:27 21.02.2023 16:59:03 22.02.2023 02:58:29 ldap/kerberos01.example.net@\ EXAMPLE.NET erneuern bis 22.02.2023 16:58:27 21.02.2023 16:59:38 22.02.2023 02:58:29 host/kerberos01.example.net@\ EXAMPLE.NET erneuern bis 22.02.2023 16:58:27
Beide KVNO in den Dateien sind mit denen in der Datenbank identisch und somit als gültig gekennzeichnet. Sollte der Key in der Keytab-Datei nicht mit dem Key in der Datenbank übereinstimmen, schlägt der Versuch fehl, mit kvno ein Ticket zu beziehen. Prüfen Sie dann in der Datenbank die KVNO und generieren Sie die entsprechende Keytab-Datei neu.
Jetzt können Sie sich auch mithilfe des Host-Keys aus der Datei /etc/krb5.conf authentifizieren, wenn Sie das Programm kadmin starten. In Listing 15.22 sehen Sie ein Beispiel dafür:
Listing 15.22 Authentifizierung mit der Keytab-Datei
root@kerberos01:~# kadmin -k Authentifizierung als Principal host/kerberos01.example.net@EXAMPLE.NET mit \ Standardschlüsseltabelle kadmin: addprinc ptau Für ptau@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die \ Vorgabe keine Richtlinie verwandt. Geben Sie das Passwort für Principal ptau@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal ptau@EXAMPLE.NET erneut ein.: add_principal: Aktion erfordert add-Recht while creating \ "ptau@EXAMPLE.NET".
Wie Sie in dem Beispiel sehen, können Sie so aber keine neuen Principals erzeugen, da der Host keine Rechte dazu besitzt. Wollen Sie über diese Art der Authentifizierung auch neue Principals erzeugen, passen Sie die ACLs an. Denken Sie jedoch dabei daran, dass dann jeder Benutzer, der auf diesem System angemeldet ist, auch Principals verwalten kann. Besser ist es daher, sich immer am kadmin mit einem Passwort zu authentifizieren.
Dieses Beispiel dient nur dazu, um Ihnen zu zeigen, wie Sie eine Authentifizierung auch mit einer Keytab-Datei durchführen können. Sie können selbstverständlich für Ihren Administrator auch eine Keytab-Datei anlegen und dann diese Keytab-Datei beim Start von kadmin als Parameter übergeben. Aber auch hier bleibt das Problem bestehen, dass jeder Benutzer, der direkten Zugriff auf das System hat, diese Art der Authentifizierung am Programm kadmin nutzen kann.
| 15.4.1 | Entfernen von Einträgen |
Irgendwann wollen Sie mit Sicherheit auch einmal einen Benutzer, einen Host oder einen Service aus der Kerberos-Datenbank entfernen. Um nun einen Benutzer aus dem System komplett zu entfernen, gehen Sie so vor wie in Listing 15.23:
Listing 15.23 Entfernen eines Benutzer-Principals
kadmin: delprinc ktom Sind Sie sicher, dass Sie den Principal ktom@EXAMPLE.NET löschen \ möchten? (yes/no): yes Principal ktom@EXAMPLE.NET gelöscht Stellen Sie sicher, dass Sie diesen Principal aus allen ACLs entfernt \ haben, bevor Sie ihn erneut benutzen.
Jetzt können Sie den Benutzer mit userdel aus dem System entfernen.
Wenn Sie einen Host oder einen Service entfernen möchten, ist es wichtig, dass Sie neben dem Principal auch immer noch den Eintrag aus der keytab-Datei entfernen, wenn Sie den Service in der Standard-Keytab-Datei eingetragen haben. Wenn Sie jeden Service in einer eigenen Datei bereitstellen, können Sie einfach die Datei löschen. In Listing 15.24 sehen Sie, wie Sie einen Service entfernen können. Genauso gehen Sie auch für einen Host vor.
Listing 15.24 Löschen von keytab-Einträgen
kadmin: delprinc ldap/kerberos01.example.net Sind Sie sicher, dass Sie den Principal ldap/kerberos01.example.net@\ EXAMPLE.NET löschen möchten? (yes/no): yes Principal ldap/kerberos01.example.net@EXAMPLE.NET gelöscht Stellen Sie sicher, dass Sie diesen Principal aus allen ACLs entfernt \ haben, bevor Sie ihn erneut benutzen.
Jetzt sind Sie in der Lage, die Kerberos-Datenbank zu verwalten.
| 15.5 | Konfiguration des Kerberos-Clients |
Nachdem der Kerberos-Server läuft, soll in diesem Abschnitt nun der Kerberos-Client konfiguriert werden. Jeder Host in Ihrem Netzwerk, der eine Authentifizierung über Kerberos durchführen soll, benötigt einen Principal und eine Keytab-Datei.
Hinweis: Denken Sie daran, dass die Authentifizierung über Kerberos sehr zeitkritisch ist. Die Zeitabweichung zwischen einem Kerberos-Server und einem Kerberos-Client darf maximal 5 Minuten betragen. An dieser Stelle macht es Sinn, dass Sie in Ihrem Netzwerk einen Zeitserver eingerichtet haben.
Ein weiterer Punkt ist die Namensauflösung. In Ihrem Netzwerk sollte auch ein DNS-Server aktiv sein, der sowohl den Kerberos-Server als auch alle Kerberos-Clients ordnungsgemäß auflösen kann.
Als Erstes installieren Sie auf dem Client die Pakete, die für die Verwaltung des Clients notwendig sind. Bei Debian sind das die Pakete krb5-config, krb5-user und libpam-krb5.
Für Redhat installieren Sie das Paket krb5-client. Während der Installation der Pakete werden Sie nach dem Admin-Server und dem Kerberos-Server gefragt. Geben Sie dort den FQDN Ihres Kerberos-Servers an. Die Eingaben werden direkt in die Datei /etc/krb5.confübernommen.
Da wir aber im letzten Abschnitt den Kerberos-Server bereits installiert haben, der ja auch schon die Client-Konfiguration in der Datei /etc/krb5.conf erhalten hat, sollten Sie an dieser Stelle die Datei einfach vom Server auf den Client kopieren. Die Datei /etc/krb5.conf kann auf allen Clients identisch sein.
Legen Sie für jeden Client einen Principal in Ihrer Kerberos-Datenbank an, denn ohne einen Eintrag in der Datenbank kann der Client keine Authentifizierung eines Benutzers durchführen. Achten Sie beim Anlegen des Clients darauf, dass Sie die Option -randkey verwenden, um den Principal mit einem Schlüssel zu versehen und nicht mit einem Passwort. Denn ein Passwort müsste der Client bei jedem Neustart eingeben.
Erzeugen Sie im Anschluss daran eine Keytab-Datei für den Client und kopieren die Datei auf dem Client. Auf dem Client kopieren Sie die Datei in das Verzeichnis /etc und nennen Sie die Datei dort krb5.keytab, denn es handelt sich bei der Datei um die Standard-Keytab für den Client. In Listing 15.25 sehen Sie noch einmal alle Schritte als Zusammenfassung:
Listing 15.25 Client in Kerberos eintragen
kadmin: addprinc -randkey host/client01.example.net Für host/client01.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben\ , es wird die Vorgabe keine Richtlinie verwandt. Principal "host/client01.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/client01.keytab host/client01.example.net Der Eintrag für Principal host/client01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der \ Schlüsseltabelle WRFILE:/root/client01.keytab hinzugefügt. Der Eintrag für Principal host/client01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der \ Schlüsseltabelle WRFILE:/root/client01.keytab hinzugefügt. root@kerberos01:~# scp /root/client01.keytab client01:/etc/krb5.keytab root@kerberos01:~# scp /etc/krb5.conf client01:/etc/
Damit ist die Konfiguration des Clients abgeschlossen. Jetzt können Sie die Konfiguration des Clients testen, indem Sie mit kinit ein TGT für einen Benutzer beziehen. In Listing 15.26 sehen Sie, wie das TGT vom Kerberos-Server für einen lokalen Benutzer auf dem Client bezogen wird:
Listing 15.26 Beziehen eines Kerberos-Tickets
root@client01:~# kinit skania Passwort für skania@EXAMPLE.NET: root@client01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: skania@EXAMPLE.NET Valid starting Expires Service principal 21.02.2023 17:43:13 22.02.2023 03:43:13 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 22.02.2023 17:43:10
| 15.5.1 | PAM und Kerberos auf dem Client |
Damit sich die Benutzer nun auch direkt über Kerberos authentifizieren können, konfigurieren Sie jetzt noch PAM auf dem Client. Dazu gehen Sie genauso vor wie zuvor schon auf dem Kerberos-Server. Installieren Sie als Erstes die entsprechenden PAM-Pakete für Ihre Distribution auf allen Clients. Erstellen Sie anschließend ein lokales Benutzerkonto auf dem Client, für das es auf dem Kerberos-Server einen Principal im Kerberos-Server gibt. Achten Sie darauf, dass der Benutzer dieselbe UID hat wie der Benutzer auf dem Server, da es sonst zu Problemen kommt, wenn Sie zusätzliche Dienste wie zum Beispiel NFS konfigurieren wollen. Ein Passwort müssen Sie für den neuen Benutzer nicht vergeben, denn die Authentifizierung findet jetzt über Kerberos statt. Dieser lokale Benutzer dient nur zum Testen der Anmeldung, später wird LDAP für die zentrale Benutzerverwaltung eingerichtet.
Wenn Sie die Anmeldung getestet haben, werden Sie feststellen, dass der Benutzer, der sich anmeldet, auch sofort ein TGT erhalten hat. Jeder Benutzer kann auf der Konsole seine Tickets mit dem Kommando kdestroy löschen und sich mit kinit ein neues Ticket vom KDC holen. Wollen Sie verhindern, dass ein Benutzer seine Tickets verwalten kann, dann verzichten Sie auf die Installation des Pakets krb5-user, denn in diesem Paket befinden sich alle Kommandos zur Verwaltung der Tickets. Sein Passwort kann der Benutzer einfach mit dem Kommando passwd ändern.
| 15.6 | Replikation des Kerberos-Servers |
Der Kerberos-Server ist jetzt die zentrale Authentifizierungsquelle in Ihrem Netzwerk, und jede Anmeldung eines Benutzers, jeder Zugriff auf einen Dienst wird über den Kerberos-Server authentifiziert. Wenn Sie nur einen Kerberos-Server haben, können Ihre Anwender die Dienste nicht mehr nutzen, sollte der Kerberos-Server ausfallen. Aus diesem Grund ist es immer wichtig, dass Sie mindestens zwei Kerberos-Server in Ihrem Netzwerk betreiben, nur so können Sie die Verfügbarkeit des Kerberos verbessern.
Es gibt verschiedene Wege, die Replikation zwischen dem KDC-Master und den KDC-Slaves durchzuführen. Der wohl beste ist die Verwendung des Programms kprop zur Replikation der Datenbank von einem Server auf einen anderen. Dieser Vorgang wird Propagation genannt. Genau diese Art der Replikation wird hier im Buch beschrieben.
| 15.6.1 | Bekanntmachung aller KDCs im Netz |
In diesem Abschnitt geht es darum, den schon laufenden KDC auf einen zweiten Server, der als KDC-Slave läuft, zu replizieren. Für die Replikation müssen alle KDC-Slaves wissen, wo ihr KDC-Master ist. Es gibt zwei Möglichkeiten, wie Ihre KDC-Slaves den KC-Master in Ihrem Netz finden. Die erste ist die einfachere, die immer dann ausreicht, wenn nur ein zusätzlicher KDC-Slave eingerichtet werden soll und auch in Zukunft nicht unbedingt weitere KDC-Slaves benötigt werden und wenn die Anzahl der Clients gering ist. Für diese Art der Replikation werden einfach alle KDCs über die Datei krb5.conf bekannt gemacht.
Die zweite Möglichkeit ist die Bekanntmachung der KDCs über SRV-Einträge im DNS-Server. Das ist immer dann die richtige Wahl, wenn Sie mehrere KDC-Slaves einrichten wollen oder sehr viele Clients im Netz betreiben. Dazu benötigen Sie den Zugriff auf die Zonendateien Ihres DNS-Servers. Beide Varianten sollen hier vorgestellt werden.
Nicht nur die Anzahl der KDCs sollte ein Kriterium dafür sein, welche Art der Bekanntmachung Sie wählen, sondern auch die Anzahl der Clients, die den Kerberos-Dienst nutzen wollen. Denn jeder Client muss alle KDCs kennen, um beim Ausfall eines KDCs einen anderen KDC für die Authentifizierung zu finden.
| 15.6.1.1 | Bekanntmachung aller KDCs über die Datei krb5.conf |
Um alle Server bekannt zu machen, müssen Sie lediglich den Bereich [realms] wie in Listing 15.27 anpassen:
Listing 15.27 Anpassung der krb5.conf
[realms] EXAMPLE.NET = { kdc = kerberos01.example.net kdc = kerberos02.example.net admin_server = kerberos01.example.net }
Der Rechner mit dem FQDN kerberos02.example.net wird hier als KDC-Slave eingerichtet. Wie Sie sehen, gibt es in der Konfiguration nur einen admin_server. Das ist auch richtig so, denn alle Änderungen werden immer am KDC-Master durchgeführt. Die KDC-Slaves dienen nur zur Authentifizierung. Der Admin-Server darf in jedem Realm nur einmal eingerichtet sein. Alle Änderungen nehmen Sie immer auf dem Admin-Server vor. Die Änderungen werden dann auf alle anderen Slaves repliziert.
Die geänderte krb5.conf verteilen Sie jetzt auf alle Clients und natürlich auch auf alle Ihre KDC-Slaves. Damit ist die einfache Art der Bekanntgabe aller KDCs auch schon abgeschlossen. Sie merken schon: Wenn Sie sehr viele Clients in Ihrem Netzwerk haben, ist diese Art der Bekanntgabe nicht realisierbar oder nur mit viel Aufwand durchzuführen.
| 15.6.1.2 | Bekanntmachung aller KDCs über SRV-Einträge im DNS |
Etwas aufwendiger, aber dafür nur einmalig durchzuführen ist die Bekanntmachung der KDCs in Ihrem Netzwerk über SRV-Einträge im DNS. Sollten Sie dann später weitere KDCs in Ihrem Netz benötigen, reicht es, diese einfach auf Ihrem DNS-Server in der entsprechenden Zone einzutragen. Auch der Austausch eines KDCs lässt sich so sehr einfach realisieren.
In Ihrem DNS-Server (wir verwenden hier im Buch den Bind9) tragen Sie in der Forward-Zonendatei Ihrer DNS-Zone die zusätzlich in Listing 15.28 aufgeführten Einträge ein:
Listing 15.28 DNS-Einträge für die SRV-Records
; srv- und txt-Einträge für die Kerberos-Server ; REALM Registrierung _kerberos IN TXT EXAMPLE.NET ; Port 88 für den KDC, UDP und TCP für Kerberos5 _kerberos._udp IN SRV 01 00 88 kerberos01.example.net. _kerberos._tcp IN SRV 01 00 88 kerberos01.example.net. ; Der KDC-Master _kerberos-master._udp IN SRV 01 00 88 kerberos01.example.net. _kerberos-master._tcp IN SRV 01 00 88 kerberos01.example.net. ; Port 749, für den kadmin aber nur TCP _kerberos-adm._tcp IN SRV 01 00 749 kerberos01.example.net. ; Port 464 für die Verwendung von kpasswd, nur UDP _kpasswd._udp IN SRV 01 00 464 kerberos01.example.net. ; Port 88, für alle KDC-Slaves _kerberos._udp IN SRV 01 00 88 kerberos02.example.net. _kerberos._tcp IN SRV 01 00 88 kerberos02.example.net.
Die Einträge haben folgende Bedeutungen:
_kerberos IN TXT EXAMPLE.NET
Durch diesen TXT-Record wird der Kerberos-Realm der DNS-Zone zugeordnet.
_kerberos._udp IN SRV 01 00 88 kerberos01.example.net.
Der TCP- und UPD-Port 88 wird für den KDC-Master bekannt gemacht.
_kerberos-master._udp IN SRV 01 00 88 kerberos01.example.net.
Dieser Eintrag zeigt immer auf den Master-KDC, der für die Verwaltung der Passwörter verantwortlich ist. Wenn ein Benutzer bei der Anmeldung anscheinend ein falsches Passwort angibt, wird der Anmeldeprozess an den Master weitergeleitet, und dort wird die Anmeldung erneut geprüft. Erst wenn auch bei dem Master die Anmeldung fehlschlägt, erhält der Benutzer eine Fehlermeldung.
Sollte also ein Benutzer sein Passwort ändern, sich sofort wieder anmelden und wird die Anmeldung an einem KDC-Slave geprüft, der noch nicht synchronisiert ist, wird die Anmeldung trotzdem mit dem neuen Passwort durchgeführt. Der Slave leitet die Anmeldung mit dem unbekannten Passwort an den Master weiter, der das geänderte Passwort kennt, da Passwörter immer auf dem Master geändert werden. Somit ist die Anmeldung mit dem neuen Passwort an jedem beliebigen KDC möglich.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos01.example.net.
Hier wird der TCP-Port 749 bekannt gegeben, über den der Admin-Server für den Kerberos erreichbar ist. Dieser Eintrag darf nur auf den KDC-Master zeigen, da auf ihm alle Einträge verwaltet werden. Wenn Sie mit dem Kommando ss -tlpn die Ports abfragen, werden Sie sehen, dass der Port auch nur auf dem Master erreichbar ist.
_kpasswd._udp IN SRV 01 00 464 kerberos01.example.net.
Der UDP-Port 464 wird immer dann benötigt, wenn ein Benutzer sein Passwort ändert. Der Eintrag darf auch nur auf den KDC-Master zeigen.
_kerberos._udp IN SRV 01 00 88 kerberos02.example.net.
Jetzt folgen die Einträge für alle KDC-Slaves. Da die Slaves nur für die Authentifizierung verantwortlich sind, muss hier auch nur der TCP- und UDP-Port 88 bekannt gemacht werden.
Nachdem Sie alle Einträge in der Zonendatei erstellt und den DNS-Server neu gestartet haben, können Sie die SRV-Einträge jetzt wie in Listing 15.29 prüfen:
Listing 15.29 Prüfen der SRV-Records
root@client01:~# host -t srv _kerberos-master._tcp.example.net _kerberos-master._tcp.example.net has SRV record 1 0 88 \ kerberos01.example.net. root@client01:~# host -t srv _kerberos-adm._tcp.example.net _kerberos-adm._tcp.example.net has SRV record 1 0 749 \ kerberos01.example.net. root@client01:~# host -t srv _kerberos._tcp.example.net _kerberos._tcp.example.net has SRV record 1 0 88 kerberos02.example.net. _kerberos._tcp.example.net has SRV record 1 0 88 kerberos01.example.net. root@client01:~# host -t srv _kerberos._tcp.example.net _kerberos._tcp.example.net has SRV record 1 0 88 kerberos02.example.net. _kerberos._tcp.example.net has SRV record 1 0 88 kerberos01.example.net.
Bei den ersten beiden Tests wird nur der Name des Kerberos-Masters angezeigt, denn alle Slaves müssen den Master- und den Admin-Server kennen. Hier darf immer nur ein Host als Antwort angezeigt werden. Bei den beiden anderen Tests wird in der Abfrage nach den Kerberos-Servern gefragt, die in der Lage sind, eine Authentifizierung durchzuführen. Sie sehen hier, dass die Reihenfolge der beiden Server in der Antwort wechselt. Das ist ein Verhalten des Bind9, der für mehrere Einträge zu einer IP- oder einem SRV-Record ein round robin durchführt. Das heißt, bei einer Anfrage eines Clients wird der Client immer die erste Adresse nutzen, und somit werden dadurch die Anfragen der Clients auf alle Kerberos-Server verteilt.
Wenn alle SRV-Einträge aufgelöst werden, können Sie jetzt die Datei krb5.conf so anpassen, wie es in Listing 15.30 dargestellt ist:
Listing 15.30 Anpassung der krb5.conf
[libdefaults] default_realm = EXAMPLE.NET [realms] EXAMPLE.NET = { admin_server = kerberos-01.example.net } [domain_realm] .example.net = EXAMPLE.NET [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON
Wie Sie sehen, sind in der Datei keine Einträge mehr für KDCs vorhanden. Lediglich der Eintrag admin_server bleibt erhalten. Denn da über den SRV-Eintrag nicht alle Funktionen abgedeckt werden können, muss der Eintrag auch bestehen bleiben. Jetzt können Sie beliebig viele KDC-Slaves einrichten, und nur noch der DNS-Server benötigt eine Anpassung. Alle krb5.conf-Dateien auf Ihren Clients bleiben unverändert. Kopieren Sie die so angepasste Datei auf alle Clients und Server, die sich über Kerberos authentifizieren sollen.
| 15.6.2 | Konfiguration des KDC-Masters |
Bevor Sie mit der Konfiguration des Slave-KDCs beginnen, sorgen Sie dafür, dass der FQDN des neuen Servers über DNS aufgelöst werden kann, denn alle Serviceanfragen der Clients und die Anfragen der Slave-Server werden über DNS bereitgestellt. Achten Sie auch bei den Slave-KDCs auf eine einheitliche Zeit.
Als Erstes benötigen Sie für den KDC-Slave auf dem KDC-Master einen Principal und eine Keytab-Datei. Der Principal wird mit dem Programm kadmin wie in Listing 15.31 erzeugt. Nachdem Sie den Principal angelegt haben, können Sie sofort die Keytab-Datei für den Slave erzeugen:
Listing 15.31 Anlegen des zweiten Kerberos-Servers
kadmin: addprinc -randkey host/kerberos02.example.net Für host/kerberos02.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben\ , es wird die Vorgabe keine Richtlinie verwandt. Principal "host/kerberos02.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/kerberos02.keytab host/kerberos02.example.net Der Eintrag für Principal host/kerberos02.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/kerberos02.keytab hinzugefügt. Der Eintrag für Principal host/kerberos02.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/kerberos02.keytab hinzugefügt. root@kerberos01:~# scp /etc/krb5.conf kerberos02:/etc/ root@kerberos01:~# scp /root/kerberos02.keytab kerberos02:/etc/krb5.keytab
| 15.6.3 | Konfiguration des KDC-Slaves |
Bevor Sie die eigentliche Replikation starten können, wird zunächst der KDC-Slave konfiguriert. Installieren Sie dazu auf dem KDC-Slave für Debian die Pakete krb5-config, krb5-kdc, krb5-user und libpam-krb5. Auf keinen Fall dürfen Sie das Paket krb5-admin-server installieren, da dieses Paket nur auf dem KDC-Master installiert werden darf. Dafür benötigen Sie noch das Paket krb5-kpropd, das für die Replikation der Datenbank erforderlich ist.
Wichtig: Starten Sie den KDC-Dienst zu diesem Zeitpunkt noch nicht auf dem KDC-Slave, denn erst müssen noch ein paar Dateien vom KDC-Master auf den KDC-Slave kopiert werden.
Die folgenden Dateien des KDC-Masters werden auf dem KDC-Slave benötigt:
die Datei /etc/krb5.conf für die Client-Konfiguration
die Datei kdc.conf für die Server-Konfiguration
die Datei kadm5.acl, um die Zugriffsrechte gleichzusetzen
die Datei stash bei Debian oder bei CentOS .k5.EXAMPLE.NET mit dem Master-Passwort
Die Pfade für die letzten drei Dateien sind wieder abhängig von der Distribution, mit der Sie arbeiten. Bei Debian finden Sie diese im Verzeichnis /etc/krb5kdc und bei CentOS im Verzeichnis /var/lib/kerberos/krb5kdc.
| 15.6.4 | Replikation des KDC-Masters auf den KDC-Slave |
Hinweis: In vielen Anleitungen, die im Internet kursieren, wird nun die Datenbank auf dem Slave erst erstellt und dann überschrieben. Das ist aber nicht notwendig und funktioniert in den meisten Fällen auch nicht. Durch das Kopieren der Dateien vom KDC-Master auf den KDC-Slave ist die Vorbereitung des KDC-Slaves abgeschlossen. Es muss keine Datenbankdatei mit den Principals vorhanden sein, um eine erfolgreiche Replikation durchführen zu können.
Wenn der KDC-Slave jetzt einfach alle Daten von irgendeinem Master annehmen würde, dann wäre das eine Sicherheitslücke. Damit der KDC-Slave auch nur die Principals vom eigenen KDC-Master annimmt, benötigen Sie jetzt noch eine Datei kpropd.acl. Diese Datei legen Sie bei Debian im Verzeichnis /etc/krb5kdc und bei CentOS im Verzeichnis /var/lib/kerberos/krb5dc des Slave an. Den Inhalt der Datei sehen Sie in Listing 15.32:
Listing 15.32 ACL für kprop
host/kerberos01.example.net@EXAMPLE.NET
Achten Sie beim Erstellen der Datei auf die richtige Schreibweise, der Realm muss in Großbuchstaben geschrieben werden.
Leider ist das noch nicht alles. Der Slave benötigt noch einen Dienst, der installiert und konfiguriert werden muss: der Dienst, der die Replikationen des KDC-Masters annimmt und in die Datenbank des KDC-Slaves schreibt. Bei diesem Dienst handelt es sich um den kpropd. Der Dienst kann entweder über den Systemd gestartet werden oder über den xinetd. Der einfachere Weg ist der Start über den Systemd; dafür aktivieren Sie den Service krb5-kpropd, so wie Sie es in Listing 15.33 sehen:
Listing 15.33 kpropd über systemd
root@kerberos02:~# systemctl enable krb5-kpropd Synchronizing state of krb5-kpropd.service with SysV service script with \ /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable krb5-kpropd root@kerberos02:~# systemctl start krb5-kpropd
Wenn Sie nicht den Systemd verwenden wollen, installieren Sie den xinetd und schreiben die Konfigurationsdatei für den xinetd, um den kpropd starten zu können. Erzeugen Sie im Verzeichnis /etc/xinetd.d die Datei kpropd mit dem Inhalt aus Listing 15.34:
Listing 15.34 Einträge für die xinetd-Konfiguration
service kprop { socket_type = stream wait = no user = root server = /usr/sbin/kpropd only_from = 192.168.56.81 log_on_success = PID HOST EXIT DURATION log_on_failure = PID HOST disable = no }
Starten Sie anschließend den xinetd neu, um den kpropd zu starten. Die IP-Adresse, die Sie in der Datei eingetragen haben, ist die IP-Adresse des KDC-Masters, denn nur von dieser IP-Adresse sollen Daten angenommen werden. Der kpropd nutzt den TCP-Port 754. Testen Sie, ob der Port bereitgestellt wird. In Listing 15.35 sehen Sie den Test:
Listing 15.35 Prüfen des Ports von kpropd
root@kerberos02:~# ss -tlpn | grep 754 LISTEN 0 5 *:754 *:* users:(("kpropd",pid=1435,fd=3))
Im nächsten Schritt schreiben Sie auf dem KDC-Master die aktuelle Datenbank in eine Dump-Datei. Die Datei wird gleich auf dem Slave repliziert. Diesen Vorgang führen Sie mit dem Kommando kdb5_util dump /root/slave-repl durch. Dabei wird die Kerberos-Datenbank in die Datei /root/slave-repl geschrieben. Die Daten werden im ASCII-Format gespeichert, alle Passwörter werden aber verschlüsselt eingetragen.
Jetzt kommt der spannende Moment, in dem die Datenbank vom KDC-Master das erste Mal auf den KDC-Slave propagiert wird. In Listing 15.36 sehen Sie diesen Vorgang:
Listing 15.36 Replikation der Datenbank
root@kerberos01:~# kdb5_util dump /root/slave-repl root@kerberos01:/etc/krb5kdc# kprop -d -f /root/slave-repl \ kerberos02.example.net 5281 bytes sent. Datenbankverbreitung auf kerberos02.example.net: ERFOLGREICH
Die Option -d schaltet den Debug-Modus für das Kommando kprop ein, dadurch erhalten Sie die Meldungen der Replikation.
Jetzt haben Sie auf dem Slave-KDC die identische Datenbank wie auf dem Master-KDC. Prüfen Sie mit mit dem Kommando kdb5_util dump den Inhalt der Datenbank auf dem KDC-Slave. Damit ist die Replikation abgeschlossen, erst jetzt können Sie den Kerberos auf dem KDC-Server starten.
Hinweis: Vergessen Sie nicht, dem KDC-Prozess das Schreibrecht im Verzeichnis /var/log zu geben. Editieren Sie dafür wie schon zuvor auf dem Master das systemd-Skript des Dienstes.
Um zu sehen, ob der Dienst läuft, verwenden Sie das Kommando ss -tlpn und prüfen Sie, ob die Kerberos-Ports bereitgestellt werden.
Ein weiterer Test, den Sie durchführen können, ist der, dass Sie den Master-KDC stoppen und eine Anmeldung von einem Client durchführen. Die Anmeldung wird dann vom Slave-KDC durchgeführt.
Leider wird die Datenbank nicht automatisch vom KDC-Master auf den KDC-Slave propagiert; diesen Vorgang können Sie aber über ein Shell-Skript in Zusammenarbeit mit einem Cronjob realisieren. Zusätzlich können Sie bei Bedarf das Skript auch noch von Hand ausführen und somit eine sofortige Replikation anstoßen. Die Replikation ist besonders für neue Principals notwendig, da sonst eventuell keine Authentifizierung stattfinden kann. Achten Sie darauf, dass Sie immer alle Slave-KDCs replizieren. Sonst kann es durch das Bereitstellen der KDCs über DNS-round robin dazu kommen, dass sich ein Benutzer manchmal anmelden kann und manchmal nicht – immer abhängig davon, welchen KDC er gerade vom DNS an erster Stelle angeboten bekommt.
Geänderte Passwörter sind nicht das Problem. Dafür haben Sie ja im DNS den entsprechenden SRV-Eintrag erstellt, der bewirkt, dass bei einer fehlerhaften Authentifizierung immer der KDC-Master mit dem aktuellen Passwort gefunden wird. In Listing 15.37 sehen Sie ein Beispiel für ein Shell-Skript zur Replikation:
Listing 15.37 Shell-Skript für die Replikation
#!/bin/bash /usr/sbin/kdb5_util dump /root/slave-repl /usr/sbin/kprop -f /root/slave-repl k2.example.net > /dev/null
Hinweis: Wie Sie in dem Skript sehen, wird die Option -d hier nicht mehr verwendet, da ein Debugging an dieser Stelle nicht mehr notwendig und auch nicht sinnvoll ist.
Jetzt brauchen Sie nur noch einen Cronjob einzurichten, und die Replikation wird automatisch durchgeführt. Wenn später alle Kerberos-Server ihre Daten im LDAP suchen, brauchen Sie die Replikation gar nicht mehr, denn dann greifen alle KDCs auf denselben Datenbestand zu: den des LDAP-Servers. Einen Admin-Server wird es aber auch dann noch geben.