krbtgt-Passwortrotation, Trust-Konto, Domänencontroller-Computerkennwort: Die drei AD-Geheimnisse, die sich nie von selbst erneuern

Active Directory wirkt wie ein System, das seine eigenen Geheimnisse von selbst frisch hält. Domänenbeigetretene Computer ändern ihr Kennwort nach Zeitplan, Trusts erneuern sich im Hintergrund, und niemand bekommt jemals ein Ticket deswegen. Genau dieser Eindruck ist der Grund, warum die Hygiene von krbtgt-Passwortrotation, Trust-Konto, Domänencontroller-Computerkennwort die stillste Lücke in den meisten AD-Umgebungen ist: Eines dieser drei Geheimnisse hat überhaupt keine automatische Rotation, und die anderen beiden rotieren nur so lange, wie nichts im Stillen kaputt ist. Dieser Artikel beschreibt, was jeder Mechanismus tatsächlich tut, wie Sie alle drei in wenigen Minuten prüfen und wie Sie sie beheben, ohne einen domänenweiten Authentifizierungsausfall auszulösen.

krbtgt-Passwortrotation, Trust-Konto, Domänencontroller-Computerkennwort: Wer rotiert was

Die Falle ist eine völlig nachvollziehbare Schlussfolgerung. Microsofts Richtliniendokumentation stellt fest: „In Active Directory-basierten Domänen besitzt jedes Gerät ein Konto und ein Kennwort. Standardmäßig reichen die Domänenmitglieder alle 30 Tage eine Kennwortänderung ein" (Domain member: Maximum machine account password age). Maschinen halten sich tatsächlich selbst instand, also verallgemeinern Administratoren: Das Verzeichnis kümmert sich um seine eigenen Geheimnisse.

Zwei der drei oben genannten sind tatsächlich automatisch. Aber automatisch bedeutet hier automatisch, solange alles gesund ist — und das mit Abstand wertvollste Geheimnis der Domäne war von Anfang an nie automatisch.

krbtgt: Das Kennwort, das Active Directory niemals für Sie ändert

Im krbtgt-Konto liegt das Kerberos-Schlüsselmaterial der Domäne — jedes TGT in der Domäne wird mit seinem Schlüssel verschlüsselt und signiert. Microsoft beschreibt das Konto genau in diesen Worten: Es „unterstützt die Schlüsselspeicherung in allen Kerberos Key Distribution Centers (KDCs)", und „[u]m die Kerberos-Schlüssel für die TGT-Verschlüsselung zu erneuern, ändern Sie regelmäßig das Kennwort des Kontos krbtgt" (Accounts security posture assessment). Nichts im Verzeichnis führt diese Änderung für Sie durch: Es gibt weder einen Netlogon-Timer noch eine Richtlinieneinstellung dahinter, sondern nur einen Administrator, der den Reset manuell ausführt.

Das ist das ganze Problem. Ohne Rotation schrumpft der Blast Radius einer einzigen historischen Kopie der Kontodatenbank nie, und Microsoft benennt die Konsequenz unmissverständlich: „Wenn das Kennwort des KRBTGT-Kontos kompromittiert wird, kann ein Angreifer dessen Hash verwenden, um gültige Kerberos-Authentifizierungstickets zu erzeugen, was ihm Golden-Ticket-Angriffe und Zugriff auf jede Ressource in der AD-Domäne ermöglicht. Da Kerberos für die Signatur aller Tickets auf das KRBTGT-Kennwort angewiesen ist, sind eine engmaschige Überwachung und die regelmäßige Änderung dieses Kennworts wesentlich, um das Risiko solcher Angriffe zu mindern." Die eigene Baseline von Microsoft gibt regelmäßig eine Zahl: Defender for Identity liefert eine Empfehlung namens Change password for krbtgt account, die „jedes krbtgt-Konto in Ihrer Umgebung auflistet, dessen Kennwort vor mehr als 180 Tagen zuletzt gesetzt wurde". Welche Algorithmen diese Schlüssel verwenden, ist die andere Hälfte der Geschichte und wird in unserem Leitfaden zu Kerberos RC4 Fallback behandelt.

Was ein Angreifer mit diesem Schlüssel anstellt, behandeln wir ausführlich in unserem Leitfaden zum Golden-Ticket-Angriff — in diesem Artikel geht es um die Rotationshygiene, die dafür sorgt, dass ein gefälschtes Ticket abläuft, statt ewig gültig zu bleiben.

Trust-Kennwörter: Automatisch, aber nur von einer Seite

Inter-Domain-Trusts rotieren tatsächlich, und zwar ohne dass jemand danach fragen muss. Microsofts Dokumentation zu den internen Abläufen von Trusts beschreibt den Mechanismus: „Beide Domänen einer Trust-Beziehung teilen sich ein Kennwort, das im TDO-Objekt in Active Directory gespeichert wird. Im Rahmen der Kontowartung ändert der Domänencontroller der vertrauenden Domäne alle dreißig Tage das im TDO gespeicherte Kennwort" (How Domain and Forest Trusts Work — ein archiviertes Windows-Server-2003-Dokument, das nach wie vor die detaillierteste öffentliche Beschreibung dieses Prozesses ist).

Drei Details aus diesem Dokument sind für den Betrieb relevant:

• Nur eine Seite steuert den Vorgang. „Ein Domänencontroller der vertrauten Domäne initiiert die Kennwortänderung niemals; sie wird stets vom PDC-Emulator der vertrauenden Domäne initiiert."
• Das alte Kennwort wird bewusst aufbewahrt. Schlägt die Authentifizierung mit dem neuen Kennwort fehl, „versucht der Domänencontroller der vertrauenden Domäne, sich mit dem alten Kennwort zu authentifizieren", und wenn das gelingt, „nimmt er den Kennwortänderungsprozess innerhalb von 15 Minuten wieder auf" — deshalb liegen sowohl der alte als auch der neue Wert im TDO.
• Für die Replikation gibt es eine harte Frist. „Aktualisierungen des Trust-Kennworts müssen innerhalb von 30 Tagen zu den Domänencontrollern beider Seiten des Trusts repliziert werden. Wird das Trust-Kennwort nach 30 Tagen geändert und verfügt ein Domänencontroller danach nur noch über das N-2-Kennwort, kann er den Trust von der vertrauenden Seite aus nicht nutzen und auf der vertrauten Seite keinen sicheren Kanal aufbauen."

Das Geheimnis selbst ist kein gewöhnliches Kennwortattribut: Microsoft merkt an, dass Trust-Geheimnisse „durch spezielle Attribute auf den Interdomain-Trust-Konten repräsentiert werden" — trustAuthIncoming auf der vertrauten Seite und trustAuthOutgoing auf der vertrauenden Seite — und dass sie „vom Domänencontroller gepflegt werden, der in der vertrauenden Domäne die FSMO-Rolle (Flexible Single Master Operation) des primären Domänencontroller-Emulators (PDC) innehat" (UserAccountControl property flags).

Was Sie lesen können, ist das Interdomain-Trust-Konto, das zum TDO gehört. Laut MS-ADTS besitzen Trusts, deren trustDirection eingehend oder bidirektional ist, ein zugehöriges Benutzerkonto im Standard-Users-Container, und die beiden Objekte sind über den NetBIOS-Namen des Partners verknüpft: Der flatName des TDO entspricht dem sAMAccountName des Kontos ohne das abschließende $. ANSSIs Prüfpunkt Trust account passwords unchanged for more than a year liest genau das pwdLastSet dieses Kontos, und sein Fazit ist es wert, zitiert zu werden: Ein veralteter Wert „kann auf gelöschte Trust-Beziehungen hindeuten, deren zugehörige Trust-Konten noch vorhanden sind", und ist der Trust noch aktiv, „sollte die Ursache für die fehlende automatische Erneuerung untersucht werden".

Wenn Sie Trusts umfassender prüfen, kombinieren Sie das mit unseren Artikeln zu Trust-Angriffspfaden und zur Prüfung von SID-Filterung und selektiver Authentifizierung.

Domänencontroller-Computerkennwörter: Automatisch, bis etwas sie blockiert

Domänencontroller sind ebenfalls Domänenmitglieder, und ihre Computerkonten rotieren nach demselben Netlogon-Zeitplan wie eine Workstation. Microsofts KB 154501 sagt es unmissverständlich: „Ab Windows-2000-basierten Computern ändert sich das Kennwort des Computerkontos automatisch alle 30 Tage" (Disable machine account password changes). Die Richtlinie, die das Intervall steuert, erlaubt eine „benutzerdefinierte Anzahl von Tagen zwischen 1 und 999", mit einem effektiven Standardwert von 30 Tagen auf Domänencontrollern, Mitgliedservern und Clients gleichermaßen.

Ein DC, dessen Computerkennwort sich seit Monaten nicht geändert hat, ist deshalb keine Richtlinienentscheidung — es ist ein Signal. ANSSIs Prüfpunkt Domain controllers with passwords unchanged for more than 45 days ist eindeutig: „Einige Domänencontroller haben ihr Kennwort seit mehr als 45 Tagen nicht geändert, was darauf hindeutet, dass ihre Geheimnisse nicht erneuert werden", und „der Grund dafür, dass diese Änderung nicht ordnungsgemäß erfolgt, muss untersucht werden, da dies auf eine Kompromittierung hindeuten kann."

Die üblichen Ursachen liegen lokal auf der Maschine:

• DisablePasswordChange auf 1 gesetzt unter HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — das verhindert, dass die Maschine überhaupt eine Änderung einreicht; dieser Wert ist es, der das eigene Geheimnis eines Domänencontrollers einfriert.
• Ein weit nach hinten verschobener MaximumPasswordAge-Wert, oder ein GPO, das einen der beiden Werte still setzt.
• Der Netlogon-Dienst läuft nicht, oder ein sicherer Kanal ist bereits unterbrochen.

Ein Registry-Wert wird hier oft zu Unrecht beschuldigt. RefusePasswordChange auf 1 „bewirkt, dass der Domänencontroller Kennwortänderungsanfragen nur von Workstations oder Mitgliedservern ablehnt, auf denen Windows NT Version 4.0 oder höher läuft" — er friert die Computerkennwörter Ihrer Mitglieder ein, nicht das des DC selbst. Prüfen Sie ihn, wenn Mitgliedsobjekte aufhören zu rotieren: Bei RefusePasswordChange „stoppt der Replikationsverkehr, aber nicht der Clientverkehr", während DisablePasswordChange beides stoppt.

Microsofts eigene Warnung zum Abschalten dieser Funktion ist es wert, wiederholt zu werden: „Wenn Sie Änderungen des Computerkontokennworts deaktivieren, entstehen Sicherheitsrisiken, da der sichere Kanal für Pass-Through-Authentifizierung verwendet wird. Entdeckt jemand ein Kennwort, kann er möglicherweise Pass-Through-Authentifizierung gegenüber dem Domänencontroller durchführen." Die Richtliniendokumentation ergänzt die andere Hälfte: „Eine deutliche Verlängerung des Kennwortänderungsintervalls (oder das Deaktivieren von Kennwortänderungen) gibt einem Angreifer mehr Zeit für einen Brute-Force-Angriff zum Erraten des Kennworts eines der Computerkonten."

Das Geheimnis eines Computerkontos ist zugleich Service-Ticket-Material für alles, was auf diesem Host läuft — das ist der Mechanismus hinter einem Silver-Ticket-Angriff — und auf einem Domänencontroller verdienen Anomalien rund um das Computerobjekt dieselbe Aufmerksamkeit wie eine unerwartete Replikationsquelle, der Trick hinter DCShadow. Für das größere Bild der Maschinenidentität siehe unsere Aufschlüsselung der Angriffsfläche von Computerobjekten.

Erkennung

Drei Abfragen, ausgeführt von einer domänenbeigetretenen Admin-Workstation mit RSAT, decken alle drei ab.

1. Die krbtgt-Konten, einschließlich der RODC-spezifischen:

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. Die Interdomain-Trust-Konten, aufgelöst direkt aus den TDOs:

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

Dieselben Konten lassen sich auch direkt über das INTERDOMAIN_TRUST_ACCOUNT-Flag auflisten — dezimal 2048, hexadezimal 0x0800 — mithilfe der LDAP_MATCHING_RULE_BIT_AND-Matching-Rule-OID 1.2.840.113556.1.4.803 (Search Filter Syntax):

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Jedes Domänencontroller-Computerobjekt:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Lesen Sie die Ausgabe anhand dieser Schwellenwerte:

Die dazugehörigen Ereignisprotokoll-Signale:

Event 4742 wird „nur auf Domänencontrollern generiert", weshalb eine Erfassung auf DC-Seite für diese Prüfung ausreicht. Auf einer verdächtigen Maschine liefert nltest /sc_query:<domain> ERROR_ACCESS_DENIED, wenn der sichere Kanal unterbrochen ist (Broken trust relationship between a domain-joined device and its domain).

Behebung

🚨 Gefahr: Führen Sie die beiden krbtgt-Resets niemals unmittelbar hintereinander aus. Der zweite Reset, bevor der erste vollständig repliziert ist, macht Tickets in der gesamten Domäne ungültig und kann die Authentifizierung mit sich reißen.

krbtgt in Etappen rotieren

1. Zuerst die Replikation prüfen. Das Zwei-Reset-Verfahren funktioniert nur, wenn jeder Domänencontroller das erste neue Kennwort gesehen hat, bevor das zweite eintrifft. Bestätigen Sie daher vor dem Start, dass die Replikation gesund ist. repadmin /replsummary „identifiziert Domänencontroller, bei denen die eingehende oder ausgehende Replikation fehlschlägt, und fasst die Ergebnisse in einem Bericht zusammen".
2. Einmal zurücksetzen, mit dem unterstützten Verfahren aus AD Forest Recovery – Reset the krbtgt password. Das eingegebene Kennwort ist irrelevant: „das System generiert automatisch ein starkes Kennwort, unabhängig vom angegebenen Kennwort".
3. Warten. Microsoft: „Sie sollten diesen Vorgang zweimal durchführen. Zwischen den Kennwort-Resets müssen Sie 10 Stunden warten. 10 Stunden sind die Standardwerte der Richtlinieneinstellungen Maximum lifetime for user ticket und Maximum lifetime for service ticket; ändert sich also die maximale Lebensdauer, sollte die minimale Wartezeit zwischen den Resets größer sein als der konfigurierte Wert." Betrachten Sie 10 Stunden als Untergrenze, nicht als Zielwert: In einer großen oder langsam replizierenden Gesamtstruktur kostet es nichts, einen vollen Tag zwischen den beiden Resets liegen zu lassen.
4. Ein zweites Mal zurücksetzen. Beide Resets sind notwendig, weil „der Kennworthistorie-Wert für das krbtgt-Konto 2 beträgt, das heißt, er umfasst die beiden letzten Kennwörter" — ein einzelner Reset lässt den vorherigen Schlüssel weiterhin nutzbar in der Historie stehen. Microsoft: „Indem Sie das Kennwort zweimal zurücksetzen, löschen Sie effektiv alle alten Kennwörter aus der Historie, sodass kein anderer DC mehr mit diesem DC unter Verwendung eines alten Kennworts replizieren kann."
5. Einen festen Termin einplanen. Defender for Identity beginnt ab 180 Tagen, das Konto zu markieren, was eine zweimal jährliche Rotation zu einem vertretbaren Standard macht. Welches Intervall Sie auch wählen — die Rotation existiert nur, wenn jemand dafür verantwortlich ist.

Ein veraltetes Trust-Kennwort beheben

1. Entscheiden, ob der Trust noch existiert. Vergleichen Sie die gefundenen Trust-Konten mit den aktiven TDOs. ANSSIs Remediation für verwaiste Konten ist unmissverständlich: „Es können Trust-Konten übrig bleiben, obwohl die zugehörigen Trust-Beziehungen entfernt wurden. Sie sollten manuell gelöscht werden."
2. Bei einem aktiven Trust zunächst den sicheren Kanal prüfen, bevor Sie irgendetwas ändern: netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — der Parameter /verify „überprüft die Secure-Channel-Geheimnisse für eine bestimmte Trust-Beziehung" (netdom trust).
3. Vor dem Zurücksetzen untersuchen. Ein Trust-Kennwort, das sich seit Monaten nicht geändert hat, bedeutet, dass der PDC-Emulator der vertrauenden Domäne den Austausch nicht abschließen konnte — prüfen Sie die Konnektivität zum Partner, den Zustand der PDC-Emulator-Rolle und die TDO-Replikation auf beiden Seiten, unter Berücksichtigung der oben genannten N-2-Regel.
4. Das Trust-Geheimnis nur in einem Change-Fenster zurücksetzen, mit Anmeldeinformationen auf beiden Seiten: netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. Der Parameter /reset „setzt das Trust-Geheimnis zwischen vertrauten Domänen oder zwischen dem Domänencontroller (DC) und der Workstation zurück".

Einen Domänencontroller wieder zum Rotieren bringen

1. Bestätigen Sie, dass der Dienst läuft: sc.exe query netlogon.
2. Prüfen Sie die beiden Netlogon-Registry-Werte unter HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — ANSSIs Remediation erwartet, dass DisablePasswordChange 0 oder nicht vorhanden ist und MaximumPasswordAge 30 beträgt, und fordert Sie auf, zu bestätigen, dass kein GPO diese Werte überschreibt.
3. Bestätigen Sie, dass das Computerkennwort mit dem Verzeichnis übereinstimmt: nltest /sc_verify:<NetBIOSDomainName> sollte 0 0x0 NERR_Success zurückgeben.
4. Ist der DC nicht mehr synchron, weil er aus einem älteren Zustand wiederhergestellt wurde, behandeln Sie das als Reparatur des sicheren Kanals und nicht als Rotationsproblem — Microsoft dokumentiert beide Richtungen dieser Diskrepanz (das Gerät neuer als AD, und AD neuer als das Gerät).

Rotationshygiene steht neben dem Rest Ihrer Credential-Posture — schwache Richtlinien, nicht ablaufende Kennwörter und Klartext-Speicherung behandeln wir in Active Directory Password Security, und die drei oben genannten Prüfungen fügen sich direkt in ein umfassenderes Active-Directory-Sicherheitsaudit ein.

Wie EtcSec das erkennt

Ein EtcSec-Audit prüft alle drei Geheimnisse im selben Durchgang. ANSSI_R28_KRBTGT_NOT_ROTATED (Kritisch) liest pwdLastSet auf jedem krbtgt-Konto und markiert Domänen jenseits der 180-Tage-Marke. ANSSI_R42_TRUST_PASSWORD_OLD (Hoch) löst jedes Trusted-Domain-Objekt zu seinem Interdomain-Trust-Konto auf und meldet Kennwörter, die aufgehört haben zu rotieren — einschließlich der verwaisten Konten, die von gelöschten Trusts zurückgelassen wurden. ANSSI_R43_DC_PASSWORD_OLD (Hoch) und COMPUTER_PASSWORD_OLD vergleichen jeden Domänencontroller und jedes Mitglieds-Computerobjekt mit dem 30-Tage-Netlogon-Rhythmus, sodass ein blockierter sicherer Kanal als Befund auffällt statt als Support-Ticket sechs Monate später. GOLDEN_TICKET_RISK verknüpft den krbtgt-Befund mit dem, was ein Angreifer tatsächlich mit einem Schlüssel anstellt, der sich nie ändert.

Referenzen

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed und 4724(S, F): An attempt was made to reset an account's password
• Microsoft (archiviert) — New-KrbtgtKeys.ps1, schreibgeschützt seit 8. März 2024
• ANSSI / CERT-FR — Points de controle Active Directory (CERTFR-2020-DUR-001), Sammlung der Prüfpunkte unter cert.ssi.gouv.fr/uploads/ad_checklist.html — Prüfpunkte Trust account passwords unchanged for more than a year und Domain controllers with passwords unchanged for more than 45 days