Das krbtgt-Kennwort in Active Directory sicher rotieren

Die Schlüssel des Kontos krbtgt verschlüsseln und signieren jedes TGT der Domäne. Wer sie besitzt, kann ein Golden Ticket für jede Identität mit beliebigen Gruppenmitgliedschaften fälschen – so lange, wie der Schlüssel gültig bleibt. In vielen Domänen hat sich dieser Schlüssel seit der Erstellung der Domäne nicht geändert. Das bedeutet: Jede frühere Kompromittierung, jedes alte Backup und jedes DCSync eines längst ausgeschiedenen Dienstleisters erzeugt noch funktionierende Tickets. Regelmäßige krbtgt-Rotation ist die einzige Maßnahme, die diese Exposition auslaufen lässt.

Das Verfahren selbst besteht aus zwei Kennwortrücksetzungen. Sicher wird es durch alles drumherum: das Verständnis des Schlüsselverlaufs, die Bestätigung der Replikation, den Umgang mit RODC-Konten und die Wahl zwischen Routine- und Incident-Modus. Dieser Leitfaden vertieft den Abschnitt zur doppelten Rücksetzung aus Kerberos-Härtung.

Warum zwei Rücksetzungen und warum der Abstand zählt

Wird krbtgt zurückgesetzt, behält der DC den vorherigen Schlüssel neben dem neuen. Ein TGT, das mit einem der beiden Schlüssel verschlüsselt ist, wird akzeptiert. Genau das verhindert einen Ausfall: Tickets, die eine Minute vor der Rücksetzung ausgestellt wurden, bleiben gültig.

• Nach Rücksetzung 1: aktueller Schlüssel = K1, vorheriger Schlüssel = K0. Mit K0 gefälschte Golden Tickets funktionieren weiterhin.
• Nach Rücksetzung 2: aktueller Schlüssel = K2, vorheriger Schlüssel = K1. K0 ist verschwunden, mit dem ursprünglichen Schlüssel gefälschte Tickets werden abgelehnt.

Erfolgt Rücksetzung 2 zu früh, werden auch legitime TGTs abgelehnt, die kurz vor Rücksetzung 1 mit K0 ausgestellt wurden. Benutzer sehen Authentifizierungsfehler, bis sie sperren und entsperren oder sich neu anmelden, und Dienste mit lang laufenden Sitzungen können ausfallen. Der sichere Abstand ist die maximale TGT-Lebensdauer plus Zeitabweichung, nachdem die Replikation konvergiert ist.

# Kerberos-Richtlinie aus der Default Domain Policy auslesen
$gpo = Get-GPO -Name 'Default Domain Policy'
$report = [xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)
$report.GPO.Computer.ExtensionData.Extension.Account |
    Where-Object { $_.Type -eq 'Kerberos' } |
    Select-Object Name, SettingNumber

Liefert die Abfrage nichts, ist die Richtlinie nicht explizit definiert, und es gelten die Standards. MaxTicketAge (Stunden, Standard 10) ist die TGT-Lebensdauer, MaxRenewAge (Tage, Standard 7) das Erneuerungsfenster und MaxClockSkew (Minuten, Standard 5) die Toleranz. Erneuerungsanfragen werden gegen den aktuellen oder vorherigen Schlüssel geprüft, ein unter K0 ausgestelltes TGT kann nach Rücksetzung 2 also ohnehin nicht erneuert werden.

Messen: aktueller Zustand

# krbtgt-Konten in jeder Domäne der Gesamtstruktur, einschließlich der RODC-Konten krbtgt_
(Get-ADForest).Domains | ForEach-Object {
    Get-ADUser -Server $_ -Filter 'SamAccountName -like "krbtgt*"' `
        -Properties PasswordLastSet, msDS-KeyVersionNumber |
        Select-Object @{n='Domain';e={$_.DistinguishedName -replace '^.*?,DC=','DC='}},
                      SamAccountName, PasswordLastSet, msDS-KeyVersionNumber
}

Ein in Jahren gemessenes PasswordLastSet ist beim ersten Durchlauf die Regel. Jede Domäne hat ihr eigenes krbtgt; eine Gesamtstruktur mit mehreren Domänen braucht eine Rotation in jeder Domäne. Jeder RODC hat ein Konto krbtgt_NNNNN, das vom RODC-Computerobjekt über msDS-KrbTgtLink verknüpft ist:

Get-ADComputer -Filter 'PrimaryGroupID -eq 521' -Properties msDS-KrbTgtLink |
    Select-Object Name, msDS-KrbTgtLink

Prüfen: zuerst die Replikationsintegrität

Eine Rücksetzung, die nicht jeden beschreibbaren DC erreicht hat, ist gefährlich. Ein DC, der Rücksetzung 1 verpasst hat, stellt weiter TGTs mit K0 aus, und repliziert Rücksetzung 2, bevor Rücksetzung 1 konvergiert ist, haben die DCs unterschiedliche Schlüsselverläufe und lehnen gegenseitig ihre Tickets ab. Beginnen Sie nie eine Rotation, während die Replikation fehlschlägt.

# Gesamtstrukturweite Replikationsübersicht: Jede "fails"-Spalte muss 0 sein
repadmin /replsummary

# Fehler pro DC
Get-ADReplicationFailure -Target (Get-ADDomain).DNSRoot -Scope Domain |
    Select-Object Server, Partner, FailureCount, LastError

Beheben Sie alle Fehler, bestätigen Sie, dass alle DCs erreichbar sind, und stellen Sie vor der ersten Rücksetzung sicher, dass Sie ein aktuelles, getestetes Systemstatus-Backup von mindestens einem DC pro Domäne haben.

Die Änderung planen

Die erste Rotation in einer Domäne, deren krbtgt sich seit Jahren nicht geändert hat, verdient einen ordentlichen Change-Eintrag, auch wenn der Befehl selbst nur Sekunden dauert.

Erfassen, was von langlebigen Tickets abhängt. Fragen Sie Anwendungsverantwortliche nach Diensten, die sich einmal authentifizieren und eine Kerberos-Sitzung tagelang halten: Linux-Hosts mit Keytabs und erneuerbaren Tickets, Anwendungsserver mit eigenen Kerberos-Clients und lang laufende Batchjobs. Das sind die Systeme, die Rücksetzung 2 bemerken.

Das Zeitfenster wählen. Rücksetzung 1 ist für Benutzer unsichtbar, wenn die Replikation gesund ist. Rücksetzung 2 kann Probleme sichtbar machen – planen Sie sie daher zu Beginn eines Arbeitstags, wenn Supportpersonal anwesend ist, nicht über Nacht, wenn niemand eine gebrochene Integration vor dem Morgen bemerkt.

Reihenfolge in einer Gesamtstruktur mit mehreren Domänen. Rotationen in verschiedenen Domänen sind unabhängig, weil das krbtgt jeder Domäne nur TGTs für diese Domäne signiert; bereichsübergreifende Tickets über Vertrauensstellungen verwenden stattdessen die Schlüssel der Vertrauenskonten. Beginnen Sie zur Probe mit einer kleinen untergeordneten Domäne, dann die Stammdomäne der Gesamtstruktur, dann die übrigen Domänen. Führen Sie nicht alle im selben Zeitfenster durch.

RODCs. Rotieren Sie im Routinemodus die RODC-Konten krbtgt_NNNNN nach dem Domänenkonto, einen RODC nach dem anderen, und bestätigen Sie jeweils, dass der RODC und seine beschreibbaren Replikationspartner sich über die neue Schlüsselversion einig sind, bevor Sie weitermachen. In Zweigstellen hinter langsamen Leitungen retten Sie Konvergenzprüfungen.

Nachweise. Dokumentieren Sie für jedes Konto msDS-KeyVersionNumber und PasswordLastSet vorher und nachher. Auditoren und Incident Responder werden fragen, wann sich der Schlüssel zuletzt geändert hat, und die Antwort sollte ein Dokument sein, keine Vermutung.

Durchsetzen: Routinerotation mit New-KrbtgtKeys.ps1

Verwenden Sie New-KrbtgtKeys.ps1, ursprünglich von Microsoft veröffentlicht und heute von der Community auf GitHub gepflegt, statt Ad-hoc-Aufrufen von Set-ADAccountPassword. Das Skript bietet einen Informationsmodus, einen Simulationsmodus, der das Verfahren gegen selbst erstellte Test-krbtgt-Konten durchspielt, und einen echten Rücksetzungsmodus. Im echten Modus setzt es das gewählte Konto auf dem PDC-Emulator zurück (bei RODC-Konten auf dem Quell-DC des RODC), erzwingt die Einzelobjektreplikation des Kontos auf jeden DC und prüft, ob jeder DC die neue Schlüsselversion meldet. Lesen Sie das Menü sorgfältig und führen Sie in jeder Domäne zuerst den Informations- und den Simulationsmodus aus.

Eine Routinerotation sieht so aus:

1. Führen Sie das Skript im Informationsmodus aus und lesen Sie den Bericht: gefundene DCs, Erreichbarkeit, Schlüsselversion auf jedem DC.
2. Führen Sie den Simulationsmodus gegen die Testkonten aus; bestätigen Sie, dass die Replikation auf jeden DC gelingt.
3. Rücksetzung 1 des Domänen-krbtgt im echten Modus. Bestätigen Sie, dass msDS-KeyVersionNumber auf jedem DC hochgezählt wurde.
4. Warten Sie mindestens MaxTicketAge + MaxClockSkew (24 Stunden sind ein komfortabler Standard).
5. Rücksetzung 2 im echten Modus mit denselben Prüfungen.
6. Wiederholen Sie das für die RODC-Konten krbtgt_NNNNN und für jede andere Domäne der Gesamtstruktur.

Unabhängig vom übergebenen Kennwort erzeugt der DC für krbtgt einen eigenen Zufallswert – es gibt also nichts, was in einem Tresor gespeichert werden müsste.

Planen Sie die Routinerotation mindestens alle 180 Tage und zusätzlich, nachdem ein Tier-0-Admin ausgeschieden ist, nach einer AD-Wiederherstellung von Backupmedien, die Ihre Kontrolle verlassen hatten, und nach jedem Verdacht auf DCSync oder eine Exposition von NTDS.dit.

Incident-Modus

Wenn Sie Hinweise auf eine Kompromittierung von krbtgt haben (ein DCSync von einer unerwarteten Quelle, Golden-Ticket-Indikatoren, ein gestohlenes DC-Backup), soll der alte Schlüssel jetzt verschwinden, nicht morgen.

1. Nehmen Sie dem Angreifer zuerst die Möglichkeit, den neuen Schlüssel zu lesen: Setzen Sie kompromittierte Tier-0-Konten zurück oder deaktivieren Sie sie, entfernen Sie unberechtigte DCSync-Rechte (siehe DCSync-Rechte finden) und isolieren Sie kompromittierte Hosts.
2. Führen Sie Rücksetzung 1 durch, warten Sie nur, bis die Replikation über alle DCs konvergiert ist (Minuten, nicht Stunden), und führen Sie dann Rücksetzung 2 durch.
3. Nehmen Sie die Auswirkungen in Kauf: Jedes TGT der Domäne wird ungültig. Benutzer authentifizieren sich beim nächsten Ressourcenzugriff oder bei der nächsten Anmeldung neu; lang laufende Dienste müssen eventuell neu gestartet werden.
4. Wiederholen Sie die doppelte Rücksetzung am Ende der Wiederherstellung, sobald Sie sicher sind, dass keine Persistenz mehr besteht.

Das Erzwingen der Replikation zwischen den Rücksetzungen ist im Incident-Modus noch wichtiger, weil Ihnen der Zeitpuffer fehlt, um eine langsame Leitung abzufedern:

# Das krbtgt-Objekt vom PDC-Emulator auf alle DCs übertragen
$pdc = (Get-ADDomain).PDCEmulator
$krbtgt = (Get-ADUser krbtgt).DistinguishedName
Get-ADDomainController -Filter 'IsReadOnly -eq $false' | ForEach-Object {
    Sync-ADObject -Object $krbtgt -Source $pdc -Destination $_.HostName
}

Überprüfen

# Schlüsselversion und pwdLastSet müssen auf jedem beschreibbaren DC übereinstimmen
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    Get-ADUser krbtgt -Server $dc -Properties msDS-KeyVersionNumber, PasswordLastSet |
        Select-Object @{n='DC';e={$dc}}, msDS-KeyVersionNumber, PasswordLastSet
}

# Replikationsmetadaten zeigen, wann und wo die Kennwortänderung ihren Ursprung hatte
Get-ADReplicationAttributeMetadata -Object (Get-ADUser krbtgt).DistinguishedName `
    -Server (Get-ADDomain).PDCEmulator -Properties unicodePwd, pwdLastSet |
    Select-Object AttributeName, LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity, Version

RODCs halten das Geheimnis des Domänen-krbtgt nicht; prüfen Sie ihre eigenen Konten krbtgt_NNNNN nach der Rotation auf dieselbe Weise. Sicherheitsseitig erzeugt eine krbtgt-Rücksetzung auf dem ausführenden DC die Ereignisse 4724 (Versuch einer Kennwortrücksetzung) und 4738. Alarmieren Sie bei diesen Ereignissen außerhalb geplanter Änderungsfenster: Eine unerwartete krbtgt-Rücksetzung ist entweder ein Fehler oder ein Angreifer, der seine Spuren verwischt. Informieren Sie das SOC vorab über geplante Rotationen, damit die Rotation selbst keinen Vorfall auslöst.

Was dabei bricht

• Eine zu frühe Rücksetzung 2 macht legitime TGTs ungültig: Benutzer sehen Zugriffsverweigerungen oder Anmeldeaufforderungen, bis sie sich neu anmelden, und Dienste mit Tickets schlagen bis zum Neustart fehl.
• Replikationsverzögerung zwischen den Rücksetzungen verursacht sporadische Authentifizierungsfehler, abhängig davon, welchen DC ein Client erreicht. Deshalb sind Konvergenzprüfungen nicht optional.
• Lang laufende Sitzungen und Dienste, die TGTs tagelang zwischenspeichern (manche Linux-Dienste mit k5start, Anwendungsserver mit erneuerbaren Tickets, per Kerberos authentifizierte VPN-Sitzungen), müssen nach Rücksetzung 2 eventuell neu gestartet werden.
• Der Incident-Modus macht jedes TGT auf einmal ungültig – rechnen Sie mit einem Anstieg der Helpdesk-Anrufe und planen Sie die Kommunikation im Voraus.
• Alte krbtgt-Kennwörter aus der Zeit vor AES bedeuten, dass die erste Rotation auch das erste Mal ist, dass krbtgt AES-Schlüssel erhält. Das kann Clients offenlegen, die nur mit RC4 umgehen konnten. Siehe RC4 in Kerberos deaktivieren.

Weiterführende Lektüre: der Bereich Kerberos & Authentifizierung, Tier-0-Assets identifizieren, um alles zu finden, was den neuen Schlüssel preisgeben könnte, und der Plan zur Gesamtstrukturwiederherstellung, in dem die doppelte Rücksetzung ein Pflichtschritt ist.