Wenn ich bei so manchem Betreiber frage: „Wann habt ihr denn das letzt Mal den Masterkey eures Kerberos-Servers getauscht?“ Ist oft die Antwort „noch nie“ oder noch schlimmer „was für einen Masterkey?“
Der Masterkey auf einem Kerberos-Server sollte aber immer regelmäßig getauscht werden, spätestens dann, wenn der Admin, der den aktuellen Key vergeben hat, fas Unternehmen verlässt. Um das Verfahren mal darzustellen, stelle ich hier mal eine Schritt für Schritt Anleitung bereit:
Alles wird auf dem primary KDC ausgeführt.
Anzeigen des aktuellen Schlüssels
root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Do Jan 01 01:00:00 CET 1970 *
Das Datum „Do Jan 01 01:00:00 CET 1970“ zeigt, dass der Masterkey, seit erstellen der Datenbank noch nie gewechselt wurde. Jetzt wird erst noch einmal sichergestellt, dass der Schlüssel verwendet wird.
root@kerberos01:~# kdb5_util use_mkey 1
Jetzt kann der neuen Schlüssels erstellt werden und in den stash-file geschrieben werden.
root@kerberos01:~# kdb5_util add_mkey -s
Es wird ein neuer Hauptschlüssel für den Hauptschlüssel-Principal »K/M@EXAMPLE.NET« erstellt. Sie werden nach einem neuen Datenbank-Master-Passwort gefragt.
Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Der Schlüssel wird erzeugt und in die Datei geschrieben, aber noch nicht aktiviert
Erneutes Auflisten der Schlüssel
root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, keine Aktivierungszeit gesetzt
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025 *
Noch ist der Schlüssel mit KVNO 1 aktiv (erkennbar an dem Stern am Ende der Zeile)
Wenn mehrere Kerberos-Server vorhanden sind, dann ist jetzt der Zeitpunk gekommen, den stash-file zu verteilen und die Datenbank neu replizieren.
Es macht Sinn auf allen KDCs mit kdb5_util list_mkeys zu prüfen, ob der neue Schlüssel vorhanden ist
Auf dem primary KDC den neuen Schlüssel aktivieren:
root@kerberos01:~# kdb5_util use_mkey 2
Dann sollten Sie sich noch einmal die Schlüssel auflisten lassen
root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025
Jetzt ist der neu Schlüssel aktiv. die (2) ist die KVNO des neuen Schlüssels
Anschließend muss der kdc-Dienst, auf allen KDCs, neu gestartet werden.
Jetzt müssen noch alle Schlüssel der Principals in der Datenbank mit dem neuen Master-key verschlüsselt werden. Das passiert wieder auf dem primary KDC. Dafür gibt es zwei Möglichkeiten:
1. Die schneller Methode, aber dann ist der KDC währen der neuen Verschlüsselung nicht erreichbar. Clients können aber die anderen KDC zur Authentifizierung nutzen.
root@kerberos01:~# kdb5_util update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 6 aktualisiert, 0 bereits aktuell
2. Muss der primary KDC während des Prozesse verfügbar bleiben geht das mit:
root@kerberos01:~# kdb5_util -x unlockiter update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 0 aktualisiert, 6 bereits aktuell
Dauert bei einer großen Anzahl an Principals aber länger.
Jetzt muss wieder dafür gesorgt werden, dass die Datenbank auf alle KDCs repliziert wird!
Nach der Replikation kann der alte Schlüssel entfernt werden mit:
root@kerberos01:~# kdb5_util purge_mkeys
Sind Sie sicher, dass alle nicht verwendeten Hauptschlüssel, die für Principal »K/M@EXAMPLE.NET« gespeichert sind, vollständig entfernt werden sollen?
(Geben Sie als Bestätigung »yes« ein)? yes
Ok, die nicht verwendeten Hauptschlüssel von »K/M@EXAMPLE.NET« werden vollständig entfernt …
Der/Die folgende(n) Hauptschlüssel werden/wird von K/M@EXAMPLE.NET vollständig entfernt:
KVNO: 1
1 Schlüssel vollständig entfernt
Beim Auflisten wird nur noch der neue Schlüssel angezeigt:
root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *
Liegt die Kerberos-Datenbank im LDAP, wird die Replikation automatisch durchgeführt. Nur wenn standalone Kerberos-Server mit einer lokalen Datenbank verwendet werden, muss die Replikation von Hand angestoßen werden.