14.9    Replikation des Kerberos-Servers

Der Kerberos-Server ist ja jetzt eine zentrale Authentifizierungsquelle in Ihrem Netzwerk. Wenn Sie nur einen Kerberos-Server haben, können Ihre Anwender die Dienste nicht mehr nutzen, wenn der Kerberos-Server einmal ausfallen sollte. Aus diesem Grund sollten Sie immer mindestens zwei Kerberos-Server in Ihrem Netzwerk haben.

Es gibt verschiedene Wege, um die Replikation zwischen dem KDC-Master und den KDC-Slaves durchzuführen. Der wohl beste Weg 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.

14.9.1    Bekanntmachung aller KDCs im Netz

In diesem Abschnitt geht es darum, den schon laufenden KDC auf einen zweiten Server zu replizieren, der als KDC-Slave läuft. Für die Replikation müssen alle KDC-Slaves wissen, wo ihr KDC-Master ist. Dafür gibt es zwei Möglichkeiten. 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. 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. Dabei müssen Sie natürlich Zugriff auf die Zonendateien Ihres DNS-Servers haben. Beide Varianten sollen hier vorgestellt werden.

Bekanntmachung aller KDCs über die Datei »krb5.conf«

Um alle Server bekannt zu machen, müssen Sie lediglich den Bereich [realms] so wie in Listing 14.24 anpassen:

[realms]
        EXAMPLE.NET = {
                kdc = k1.example.net
                kdc = k2.example.net
                admin_server = k1.example.net
        }

Listing 14.24    Anpassung der Datei »krb5.conf«

Der Rechner mit dem FQDN k2.example.net soll hier als KDC-Slave eingerichtet werden. 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. Die geänderte krb5.conf müssen Sie jetzt auf allen Clients ablegen und natürlich auch auf allen Ihren KDC-Slaves. Damit ist die einfache Art der Bekanntgabe aller KDCs auch schon abgeschlossen.

Bekanntmachung aller KDCs über SRV-Einträge im DNS

Etwas aufwendiger, aber dafür nur einmalig durchzuführen ist die es, die KDCs in Ihrem Netzwerk über SRV-Einträge im DNS bekannt zu machen. 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.

In der Forward-Zonendatei Ihrer DNS-Zone tragen Sie zusätzlich die in Listing 14.25 aufgeführten Einträge ein:

; 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 k1.example.net.
_kerberos._tcp IN SRV 01 00 88 k1.example.net.

; Der KDC-Master
_kerberos-master._udp IN SRV 01 00 88 k1.example.net.
_kerberos-master._tcp IN SRV 01 00 88 k1.example.net.

; Port 749, für den kadmin aber nur TCP
_kerberos-adm._tcp IN SRV 01 00 749 k1.example.net.

; Port 464 für die Verwendung von kpasswd, nur UDP
_kpasswd._udp IN SRV 01 00 464 k1.example.net.

; Port 88, für alle KDC-Slaves
_kerberos._udp IN SRV 01 00 88 k2.example.net.
_kerberos._tcp IN SRV 01 00 88 k2.example.net.

Listing 14.25    SRV- und TXT-Einträge im DNS

Die Einträge haben folgende Bedeutungen:

Nachdem Sie alle Einträge in der Zonendatei erstellt und den DNS-Server neu gestartet haben, können Sie die SRV-Einträge jetzt so wie in Listing 14.26 prüfen:

root@k1:~# host -t SRV _kerberos-master._tcp.example.net
_kerberos-master._tcp.example.net has SRV record 1 0 88 k1.example.net.

root@k1:~# host -t SRV _kerberos-adm._tcp.example.net
_kerberos-adm._tcp.example.net has SRV record 1 0 749 k1.example.net.

root@k1:~# host -t SRV _kpasswd._udp.example.net
_kpasswd._udp.example.net has SRV record 1 0 464 k1.example.net.

root@k1:~# host -t SRV _kerberos._tcp.example.net
_kerberos._tcp.example.net has SRV record 1 0 88 k1.example.net.
_kerberos._tcp.example.net has SRV record 1 0 88 k2.example.net.

Listing 14.26    Testen der SRV-Einträge

Wenn alle SRV-Einträge aufgelöst werden, können Sie jetzt die Datei krb5.conf so anpassen, wie es in Listing 14.27 dargestellt ist:

[libdefaults]
        default_realm = EXAMPLE.NET

[realms]
        EXAMPLE.NET = {
                admin_server = k1.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

Listing 14.27    Angepasste »krb5.conf«

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 müssen nur noch den DNS-Server anpassen und nicht mehr alle krb5.conf-Dateien. Kopieren Sie einfach diese Datei auf alle Clients und Server, die sich über Kerberos authentifizieren sollen.

14.9.2    Konfiguration des KDC-Masters

Als Erstes müssen Sie den KDC-Master konfigurieren. Dazu müssen Sie für jeden KDC-Slave einen Principal erstellen und die krb5.keytab-Dateien für den KDC-Master und die KDC-Slaves erzeugen. Der Principal wird mit dem Programm kadmin so wie in Listing 14.28 erzeugt:

root@k1:~# kadmin
Authenticating as principal root/admin@EXAMPLE.NET with password.
Password for root/admin@EXAMPLE.NET:

kadmin:  addprinc -randkey host/k2.example.net
WARNING: no policy specified for host/k2.example.net@EXAMPLE.NET; defaulting to no \
         policy
Principal "host/k2.example.net@EXAMPLE.NET" created.

Listing 14.28    Erzeugen des Principals für den KDC-Slave

Im nächsten Schritt müssen Sie die entsprechende krb5.keytab-Datei erzeugen. Diese Datei müssen Sie dann auf allen KDCs im Verzeichnis /etc speichern. Die Datei wird immer auf dem KDC-Master erzeugt und dann auf die KDC-Slaves kopiert. Die Datei erzeugen Sie mit dem Befehl ktadd innerhalb des Programms kadmin. Wenn Sie bei dem Befehl keine Datei mit der Option -k angeben, werden die Schlüssel immer in die Datei /etc/krb5.keytab geschrieben.

In Listing 14.29 sehen Sie, wie die Datei mit dem KDC-Master-Key und dem KDC-Slave-Key erzeugt wird:

root@k1:~# kadmin
Authenticating as principal root/admin@EXAMPLE.NET with password.
Password for root/admin@EXAMPLE.NET:

kadmin:  listprincs
K/M@EXAMPLE.NET
host/k1.example.net@EXAMPLE.NET
kadmin/admin@EXAMPLE.NET
kadmin/changepw@EXAMPLE.NET
kadmin/k1.example.net@EXAMPLE.NET
krbtgt/EXAMPLE.NET@EXAMPLE.NET
root/admin@EXAMPLE.NET
stefan@EXAMPLE.NET
stka@EXAMPLE.NET

kadmin:  addprinc -randkey host/k2.example.net
WARNING: no policy specified for host/k2.example.net@EXAMPLE.NET; defaulting to no \
         policy
Principal "host/k2.example.net@EXAMPLE.NET" created.

kadmin:  ktadd host/k2.example.net
Entry for principal host/k2.example.net with kvno 2, encryption type \
          aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/k2.example.net with kvno 2, encryption type \
          arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/k2.example.net with kvno 2, encryption type \
          des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/k2.example.net with kvno 2, encryption type \
          des-cbc-crc added to keytab FILE:/etc/krb5.keytab.

kadmin:  listprincs
K/M@EXAMPLE.NET
host/k1.example.net@EXAMPLE.NET
host/k2.example.net@EXAMPLE.NET
kadmin/admin@EXAMPLE.NET
kadmin/changepw@EXAMPLE.NET
kadmin/k1.example.net@EXAMPLE.NET
krbtgt/EXAMPLE.NET@EXAMPLE.NET
ktom@EXAMPLE.NET
root/admin@EXAMPLE.NET
stefan@EXAMPLE.NET
kadmin:  q

Listing 14.29    Erzeugung der »keytab«-Dateien

Bevor die Datei jetzt auf den zweiten Kerberos-Server kopiert wird, lassen Sie sich den Inhalt der Datei noch einmal auflisten. Denken Sie daran: Bei der Datei handelt es sich um eine Datei mit den verschlüsselten Passwörtern. Sie können diese Datei daher nicht mit einem Editor öffnen und sollten das auch nicht unbedingt versuchen. Listing 14.30 zeigt Ihnen, wie Sie sich den Inhalt der Datei ansehen können:

root@k1:~# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2          host/k1.example.net@EXAMPLE.NET
   2    2          host/k1.example.net@EXAMPLE.NET
   3    2          host/k1.example.net@EXAMPLE.NET
   4    2          host/k1.example.net@EXAMPLE.NET
   5    2          host/k2.example.net@EXAMPLE.NET
   6    2          host/k2.example.net@EXAMPLE.NET
   7    2          host/k2.example.net@EXAMPLE.NET
   8    2          host/k2.example.net@EXAMPLE.NET

Listing 14.30    Inhalt der »keytab«-Datei

Jetzt können Sie die Datei /etc/krb5.keytab auf den KDC-Slave ins Verzeichnis /etc kopieren.

14.9.3    Konfiguration des KDC-Slaves

Bevor Sie die eigentliche Replikation starten können, müssen Sie zunächst den KDC-Slave konfigurieren. Dazu müssen Sie auf dem KDC-Slave für Debian und Ubuntu die Pakete krb5-config, krb5-kdc, krb5-user und libpam-krb5 installieren. Auf keinen Fall dürfen Sie das Paket krb5-admin-server installieren, da dieses Paket nur auf dem KDC-Master installiert werden darf.

Installieren Sie die benötigten Pakete für den Kerberos-Slave. Bis auf das Paket kadmin-server können Sie die Liste der benötigten Pakete vom Master übernehmen. Der kadmin-server darf nur auf dem Master installiert und eingerichtet sein.

[ ! ]  Den KDC zu diesem Zeitpunkt noch nicht starten

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.

Bei openSUSE müssen Sie, wie schon beim KDC-Master, die Pakete krb5-server und krb5-client über die Softwareverwaltung des YaST installieren.

[+]  Auf dem KDC-Slave dürfen Sie nur den Dienst krb5kdc im Runlevel-Editor des YaST aktivieren. Der Dienst kadmind darf auch hier nur auf dem KDC-Master laufen.

Kopieren Sie im Anschluss die folgenden Dateien des KDC-Masters auf den KDC-Slave:

Die Pfade für die letzten drei Dateien sind wieder abhängig von der Distribution, mit der Sie arbeiten. Bei Debian und Ubuntu finden Sie diese im Verzeichnis /etc/krb5kdc und bei openSUSE im Verzeichnis /var/lib/kerberos/krb5kdc.

14.9.4    Replikation des KDC-Masters auf den KDC-Slave

[+]  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.

Damit der KDC-Slave auch die Principals vom KDC-Master annimmt, müssen Sie jetzt noch eine Datei kpropd.acl erzeugen. Diese Datei müssen Sie bei Debian und Ubuntu in das Verzeichnis /etc/krb5kdc und bei openSUSE und CentOS in das Verzeichnis /var/lib/kerberos/krb5dc ablegen. Den Inhalt der Datei sehen Sie in Listing 14.31:

host/k1.example.net@EXAMPLE.NET

Listing 14.31    Inhalt der Datei »kpropd.acl«

Leider ist das noch nicht alles. Auf dem Slave muss noch ein Dienst installiert und konfiguriert werden, 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 kpropd läuft nicht als eigenständiger Daemon, sondern wird über den xinetd gestartet. Nachdem Sie den xinetd installiert haben, müssen Sie jetzt noch eine Konfigurationsdatei für den kpropd im Verzeichnis /etc/xinetd.d erzeugen. In Listing 14.32 sehen Sie den Inhalt dieser Datei:

service kprop
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/kpropd
only_from = 192.168.56.41
log_on_success = PID HOST EXIT DURATION
log_on_failure = PID HOST
disable = no
}

Listing 14.32    Konfigurationsdatei für den »kpropd«

Die IP-Adresse, die in der Datei angegeben ist, ist die IP-Adresse des KDC-Masters, denn nur von dieser IP-Adresse sollen Daten angenommen werden. Der kpropd hört auf den TCP-Port 754, für diesen gibt es aber in der Datei /etc/services keinen Eintrag. Den Eintrag müssen Sie, so wie in Listing 14.33 zu sehen ist, in die Datei eintragen:

kprop           754/tcp                         # Kerberos propagation

Listing 14.33    Eintrag für den »kpropd« in der Datei »/etc/services«

Anschließend können Sie den xinetd neu starten. Mit dem Kommando netstat -tln sollten Sie jetzt den TCP-Port 754 als aktiv angezeigt bekommen.

Im nächsten Schritt müssen Sie auf dem KDC-Master die aktuelle Datenbank in eine Dump-Datei schreiben. Diesen Vorgang führen Sie mit dem Kommando kdb5_util dump /root/slave-repl durch.

Jetzt kommt der spannende Moment, in dem die Datenbank vom KDC-Master zum ersten Mal auf den KDC-Slave propagiert wird. In Listing 14.34 sehen Sie diesen Vorgang:

root@k1:~# kdb5_util dump /root/slave-repl

root@k1:~# kprop -d -f /root/slave-repl k2.example.net
7511 bytes sent.
Database propagation to k2.example.net: SUCCEEDED

Listing 14.34    Propagierung der Datenbank

Die Option -d schaltet den Debug-Modus für das Kommando kprop ein. Anschließend können Sie mit kdb5_util dump den Inhalt auf dem KDC-Slave überprüfen. Damit ist die Replikation abgeschlossen, und jetzt können Sie den Kerberos auf dem KDC-Server starten.

[✓]  Während der Einrichtung von Kerberos hatten wir die eine oder andere Fehlermeldung. Eine gute Hilfe, um diese Fehler zu lösen, haben wir immer wieder auf dieser Webseite gefunden:
http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml.

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. 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 14.35 sehen Sie ein Beispiel für ein Shell-Skript zur Replikation:

#!/bin/bash
/usr/sbin/kdb5_util dump /root/slave-repl
/usr/sbin/kprop -f /root/slave-repl k2.example.net > /dev/null

Listing 14.35    Skript für die Replikation

[+]  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.