KRBTGT-Passwort zurücksetzen: Warum zwei Resets notwendig sind und worauf Administratoren achten sollten
Wer eine Active-Directory-Umgebung betreibt, beschäftigt sich früher oder später auch mit dem KRBTGT-Konto. Im normalen IT-Alltag bekommt man von diesem besonderen Benutzerkonto kaum etwas mit. Für die Sicherheit einer Windows-Domäne spielt es allerdings eine entscheidende Rolle.
Besonders interessant wird das Thema, wenn es darum geht, das KRBTGT-Passwort regelmäßig zu ändern oder nach einem Sicherheitsvorfall zurückzusetzen.
Dabei taucht immer wieder eine Frage auf: Warum muss das KRBTGT-Passwort eigentlich zweimal zurückgesetzt werden und wie viel Zeit sollte zwischen beiden Vorgängen liegen?
Ich habe mich mit diesem Thema etwas ausführlicher beschäftigt und verschiedene technische Aussagen mit den offiziellen Dokumentationen von Microsoft sowie Sicherheitsempfehlungen von FBI, NSA und CISA abgeglichen.
Dabei sind einige interessante Details aufgefallen. Vor allem bei der Frage, ob beide Passwortänderungen unmittelbar hintereinander durchgeführt werden dürfen, gibt es unterschiedliche Empfehlungen.
Und genau hier sollte man als Administrator besonders vorsichtig sein.
Was ist das KRBTGT-Konto überhaupt?
Das KRBTGT-Konto gehört zu den wichtigsten integrierten Konten einer Active-Directory-Domäne.
Es wird automatisch bei der Erstellung einer Domäne angelegt und besitzt die feste Relative ID 502.
Obwohl das Konto normalerweise deaktiviert ist, übernimmt es eine wichtige Aufgabe innerhalb der Kerberos-Authentifizierung.
Kerberos sorgt vereinfacht gesagt dafür, dass sich Benutzer und Dienste innerhalb eines Windows-Netzwerks sicher anmelden können.
Dabei werden sogenannte Tickets verwendet.
Meldet sich ein Benutzer an einer Domäne an, erhält er zunächst ein Ticket Granting Ticket, kurz TGT.
Mit diesem Ticket kann er anschließend weitere Tickets für Netzwerkdienste anfordern, ohne bei jedem Zugriff sein Passwort erneut eingeben zu müssen.
Der Kerberos Key Distribution Center (KDC) verwendet Schlüssel, die aus dem Passwort des KRBTGT-Kontos abgeleitet werden, um diese Tickets kryptografisch abzusichern.
Genau deshalb ist das Konto so wichtig.
Gelangen die KRBTGT-Schlüssel in die Hände eines Angreifers, kann dieser unter bestimmten Voraussetzungen eigene gültig erscheinende Kerberos-Tickets erzeugen.
Solche gefälschten Anmeldetickets werden als Golden Tickets bezeichnet.
Damit können Angreifer möglicherweise auch dann weiterhin auf eine Domäne zugreifen, wenn bereits normale Benutzer- oder Administratorkennwörter geändert wurden.
Warum reicht ein einzelner KRBTGT-Reset nicht aus?
Eine Besonderheit des KRBTGT-Kontos ist, dass der Kerberos-Dienst nicht ausschließlich den neuesten Schlüssel verwendet.
Aus Kompatibilitätsgründen kann auch der vorherige Schlüssel weiterhin akzeptiert werden.
Das ist grundsätzlich sinnvoll.
Schließlich sollen bereits ausgestellte Kerberos-Tickets nicht sofort ihre Gültigkeit verlieren, nur weil das KRBTGT-Passwort geändert wurde.
Für die Sicherheit bedeutet das allerdings auch, dass ein einzelner Reset nicht ausreicht, um einen möglicherweise kompromittierten alten Schlüssel vollständig aus der akzeptierten Schlüsselhistorie zu entfernen.
Was passiert beim ersten Reset?
Nehmen wir an, der ursprüngliche Schlüssel heißt K0.
Wird das KRBTGT-Passwort zum ersten Mal zurückgesetzt, erzeugt Windows einen neuen Schlüssel K1.
Anschließend sieht die Situation vereinfacht so aus:
Aktueller Schlüssel: K1
Vorheriger Schlüssel: K0
Neue Tickets werden mit K1 abgesichert.
Bereits vorhandene Tickets, die auf dem ursprünglichen Schlüssel K0 basieren, können allerdings weiterhin akzeptiert werden.
Ein Angreifer, der K0 besitzt, könnte dieses Wissen deshalb unter bestimmten Voraussetzungen noch ausnutzen.
Was passiert beim zweiten Reset?
Beim zweiten Zurücksetzen erzeugt Windows erneut einen Schlüssel.
Nennen wir ihn K2.
Danach ergibt sich folgender Zustand:
Aktueller Schlüssel: K2
Vorheriger Schlüssel: K1
Der ursprüngliche Schlüssel K0 gehört nun nicht mehr zu den beiden akzeptierten Schlüsseln.
Damit können TGTs, die ausschließlich auf K0 basieren, nach vollständiger Übernahme der Änderungen durch die Domänencontroller nicht mehr regulär verarbeitet werden.
Genau deshalb sind zwei KRBTGT-Resets notwendig, um einen alten kompromittierten Schlüssel zuverlässig aus der Schlüsselhistorie zu verdrängen.
Allerdings funktioniert das nur dann wie vorgesehen, wenn auch die Replikation zwischen den Domänencontrollern berücksichtigt wird.
Warum Microsoft mindestens zehn Stunden Abstand empfiehlt
Bei der Frage nach dem zeitlichen Abstand gibt es einen wichtigen Punkt.
In einer technischen Diskussion zum KRBTGT-Reset wird empfohlen, bei einer Active-Directory-Wiederherstellung beide Passwortänderungen unmittelbar hintereinander durchzuführen.
Microsoft beschreibt in seiner offiziellen Dokumentation zur Wiederherstellung einer Active-Directory-Gesamtstruktur allerdings ausdrücklich ein anderes Vorgehen.
Dort werden mindestens zehn Stunden zwischen beiden Passwortänderungen vorgeschrieben.
Der Hintergrund liegt in der standardmäßigen maximalen Lebensdauer von Kerberos-Tickets.
Diese beträgt bei vielen Windows-Domänen zehn Stunden.
Durch die Wartezeit können vorhandene Tickets regulär ablaufen und neue Tickets mit dem bereits geänderten Schlüssel ausgestellt werden.
Gleichzeitig erhalten die Domänencontroller ausreichend Gelegenheit, die erste Passwortänderung zu replizieren.
Wichtig ist allerdings, dass die zehn Stunden kein universeller Wert für jede Umgebung sind.
Wurde die maximale Ticketlebensdauer durch Gruppenrichtlinien erhöht, muss auch der zeitliche Abstand entsprechend angepasst werden.
Neben Microsoft empfehlen auch FBI, NSA und CISA bei einem KRBTGT-Reset ausdrücklich eine Wartezeit von zehn Stunden zwischen beiden Vorgängen.
Ich würde deshalb bei einer regulären Rotation und bei einer geplanten Forest Recovery grundsätzlich die dokumentierte Microsoft-Vorgehensweise zugrunde legen.
Ein sofortiger Doppelreset kann in besonderen, sorgfältig geplanten Notfallsituationen technisch begründbar sein.
Als allgemeine Empfehlung ist er aber nicht geeignet.
Welche Probleme können bei einem zu schnellen Reset auftreten?
Wer beide Passwortänderungen ohne ausreichende Vorbereitung unmittelbar hintereinander durchführt, riskiert Probleme mit der Kerberos-Authentifizierung.
Das bedeutet allerdings nicht automatisch, dass sämtliche bestehenden Netzwerkverbindungen sofort unterbrochen werden.
Hier muss man zwischen verschiedenen Kerberos-Tickets unterscheiden.
Ein Ticket Granting Ticket wird verwendet, um weitere Tickets anzufordern.
Ein Service-Ticket berechtigt dagegen zum Zugriff auf einen bestimmten Dienst.
Solche Service-Tickets werden normalerweise mit dem Schlüssel des jeweiligen Dienstes verschlüsselt.
Allerdings können sie zusätzliche Sicherheitsinformationen enthalten, deren Signaturen vom KRBTGT-Schlüssel abhängen.
Diese Informationen befinden sich im sogenannten Privilege Attribute Certificate, kurz PAC.
Deshalb können bereits bestehende Verbindungen nach einem KRBTGT-Reset unter Umständen zunächst weiter funktionieren.
Probleme entstehen möglicherweise erst dann, wenn ein Ticket erneut überprüft werden muss oder eine neue Authentifizierung erforderlich wird.
Je nach Anwendung können dadurch Anmeldefehler, unterbrochene Dienste oder andere Schwierigkeiten entstehen.
Auch Systeme, die alte Tickets nicht automatisch erneuern, können betroffen sein.
Gerade in größeren Active-Directory-Umgebungen sollte ein KRBTGT-Reset deshalb niemals unvorbereitet durchgeführt werden.
Windows erzeugt das neue KRBTGT-Passwort selbst
Ein weiteres interessantes Detail betrifft das eigentliche Passwort.
Wer das KRBTGT-Konto über die Active-Directory-Verwaltung zurücksetzt, muss zunächst ein neues Passwort eingeben.
Man könnte deshalb annehmen, dass genau dieser eingegebene Wert anschließend als neues KRBTGT-Passwort gespeichert wird.
Tatsächlich funktioniert das anders.
Windows erzeugt beim KRBTGT-Reset automatisch ein eigenes, starkes und zufälliges Passwort.
Der vom Administrator eingegebene Wert wird dafür nicht verwendet.
Das bestätigt Microsoft ausdrücklich in seiner Dokumentation.
Für die Sicherheitsbewertung ist diese Unterscheidung wichtig.
Kennt ein Administrator lediglich das beim Reset eingegebene Passwort, kann er daraus nicht den tatsächlich erzeugten KRBTGT-Schlüssel ableiten.
Anders sieht es aus, wenn ein Angreifer das tatsächlich verwendete KRBTGT-Geheimnis oder die daraus abgeleiteten Schlüssel erlangt.
Dann liegt eine schwerwiegende Kompromittierung vor.
Deshalb wäre die pauschale Aussage, dass die Kenntnis eines KRBTGT-Klartextpassworts grundsätzlich weniger kritisch sei, falsch.
Entscheidend ist immer, von welchem Passwortwert gesprochen wird.
Wie häufig sollte das KRBTGT-Passwort geändert werden?
Auch bei der regelmäßigen Rotation gibt es unterschiedliche Empfehlungen.
Manche Administratoren ändern das KRBTGT-Passwort nur nach einem Sicherheitsvorfall.
Andere Unternehmen haben feste Wartungsintervalle eingerichtet.
Grundsätzlich kann eine regelmäßige Rotation sinnvoll sein, um die langfristige Verwendbarkeit möglicherweise kompromittierter Schlüssel einzuschränken.
Microsoft Defender for Identity bietet dafür inzwischen eine eigene Sicherheitsbewertung.
Diese erkennt KRBTGT-Konten, deren Passwort seit mehr als 180 Tagen nicht geändert wurde.
Damit ergibt sich ein sinnvoller Orientierungspunkt von ungefähr sechs Monaten.
Allerdings handelt es sich dabei nicht um eine technische Pflicht für sämtliche Active-Directory-Umgebungen.
Auch Microsoft weist in seinen allgemeinen Erläuterungen darauf hin, dass das passende Rotationsintervall von den betrieblichen Anforderungen abhängt.
Dazu gehören unter anderem die Sicherheitsrichtlinien, vorhandene Wiederherstellungsverfahren und die Größe der Domäne.
Ich halte einen kontrollierten und dokumentierten Rhythmus für sinnvoller als besonders häufige Passwortänderungen ohne konkrete Notwendigkeit.
Eine tägliche Rotation wäre technisch möglicherweise umsetzbar, bringt aber zusätzlichen Aufwand und potenzielle Risiken mit sich.
Ein allgemeiner Sicherheitsvorteil gegenüber einer sorgfältig geplanten regelmäßigen Rotation ist durch die geprüften Quellen nicht ausreichend belegt.
Die Active-Directory-Replikation darf nicht vergessen werden
Ein besonders wichtiger Punkt ist die Replikation zwischen den Domänencontrollern.
In größeren Netzwerken gibt es häufig mehrere Domain Controller, die Informationen untereinander austauschen.
Dazu gehören auch Änderungen am KRBTGT-Konto.
Wird das Passwort zurückgesetzt, muss der neue Schlüsselzustand zunächst auf die relevanten Domänencontroller übertragen werden.
Solange dieser Vorgang nicht vollständig abgeschlossen ist, können sich einzelne Systeme in unterschiedlichen Zuständen befinden.
Das kann zu Problemen bei der Ticketprüfung führen.
Deshalb sollte nach dem ersten Reset überprüft werden, ob die Replikation erfolgreich abgeschlossen wurde.
Erst danach und nach Ablauf der erforderlichen Wartezeit sollte der zweite Reset erfolgen.
Reicht die Kontrolle der Schlüsselversion aus?
Häufig wird dafür das Attribut msDS-KeyVersionNumber verwendet.
Es gibt Auskunft über die Kerberos-Schlüsselversion eines Kontos.
Allerdings ist dieses Attribut kein gewöhnlicher, unabhängig replizierter Datenbankwert.
Microsoft bezeichnet es als konstruiertes Attribut.
Der jeweilige Domänencontroller stellt den Wert aus seinem eigenen Zustand bereit.
Deshalb ist eine übereinstimmende Schlüsselversion auf mehreren Domänencontrollern zwar ein hilfreicher Hinweis, aber noch kein vollständiger Beweis für eine korrekte Replikation.
Zusätzlich sollten die Replikationsmetadaten, Passwortänderungen und der allgemeine Replikationszustand überprüft werden.
Gerade vor dem zweiten KRBTGT-Reset ist das entscheidend.
Besonderheit: Schreibgeschützte Domänencontroller
Eine weitere Besonderheit betrifft sogenannte Read-Only Domain Controller, kurz RODCs.
Diese kommen beispielsweise in Außenstellen zum Einsatz, in denen kein vollständig beschreibbarer Domänencontroller betrieben werden soll.
RODCs verwenden eigene KRBTGT-Konten und eigene Kerberos-Schlüssel.
Das bedeutet, dass sie bei einer Passwortrotation gesondert berücksichtigt werden müssen.
Ein Reset des normalen KRBTGT-Kontos einer Domäne ersetzt nicht automatisch die gezielte Verwaltung sämtlicher RODC-spezifischer Konten.
Microsoft unterscheidet deshalb auch in seinen Wiederherstellungsanleitungen zwischen beschreibbaren Domänencontrollern und RODCs.
Wer eine entsprechende Umgebung betreibt, sollte die vorhandenen RODCs unbedingt in die Planung aufnehmen.
Das bekannte KRBTGT-Reset-Skript von Jorge
Für die Verwaltung und Rotation des KRBTGT-Passworts existiert ein bekanntes PowerShell-Skript von Jorge de Almeida Pinto.
Das Projekt stellt verschiedene Funktionen bereit, um KRBTGT-Konten auf beschreibbaren Domänencontrollern und RODCs zu prüfen und zurückzusetzen.
Die Dokumentation nennt aktuell die Version 4.1 vom 14. Juli 2026.
Das Skript bietet auch Test- und Simulationsmöglichkeiten.
Solche Funktionen sind besonders hilfreich, um vor einer tatsächlichen Passwortänderung mögliche Probleme zu erkennen.
Allerdings sollte man sich nicht blind auf jede automatisch ermittelte Einstellung verlassen.
Laut Dokumentation kann das Skript bei bestimmten fehlgeschlagenen Gruppenrichtlinien- oder Remoteabfragen auf Standardwerte zurückgreifen.
Dazu gehört beispielsweise eine angenommene Ticketlebensdauer von zehn Stunden.
Wer in seiner Domäne abweichende Kerberos-Richtlinien verwendet, muss diese Einstellungen deshalb selbst überprüfen.
Das Skript ist ein hilfreiches Werkzeug, ersetzt aber keine sorgfältige Planung.
Reicht ein KRBTGT-Reset nach einem Angriff aus?
Nein. Und dieser Punkt ist besonders wichtig.
Wenn Angreifer bereits weitreichenden Zugriff auf eine Active-Directory-Umgebung erlangt haben, reicht eine Änderung des KRBTGT-Passworts allein nicht aus.
Ein Angreifer könnte beispielsweise weitere Administratorzugänge eingerichtet, zusätzliche Konten kompromittiert oder andere Möglichkeiten für einen späteren Zugriff geschaffen haben.
Auch kompromittierte Dienstkonten und andere Zugangsdaten müssen berücksichtigt werden.
Der KRBTGT-Reset kann zwar die Verwendung alter Golden Tickets verhindern, beseitigt aber nicht automatisch sämtliche Spuren eines Angriffs.
Bei einer nachgewiesenen Active-Directory-Kompromittierung sollte der Vorgang deshalb Teil einer umfassenden Incident-Response-Strategie sein.
Dazu gehören die Analyse des Angriffs, das Schließen vorhandener Zugriffswege und die Bereinigung kompromittierter Berechtigungen.
Erst wenn die Umgebung entsprechend abgesichert wurde, kann eine geplante Schlüsselrotation ihre beabsichtigte Wirkung entfalten.
Wie würde ich einen KRBTGT-Reset in einer produktiven Umgebung angehen?
Bei einem so sicherheitskritischen Vorgang würde ich bewusst nicht einfach irgendeinen PowerShell-Befehl ausführen.
Zunächst sollte feststehen, warum der Reset durchgeführt werden soll.
Geht es um eine reguläre Passwortrotation, kann der Vorgang geplant und in einem geeigneten Wartungsfenster durchgeführt werden.
Besteht dagegen der Verdacht auf eine vollständige Domänenkompromittierung, muss das weitere Vorgehen mit dem Incident-Response-Plan abgestimmt werden.
Für eine reguläre Rotation halte ich vor allem folgende Punkte für wichtig:
Den Zustand sämtlicher relevanten Domänencontroller und ihrer Replikation überprüfen.
Die tatsächliche maximale Kerberos-Ticketlebensdauer ermitteln.
Ein geeignetes Wartungsfenster und mögliche Auswirkungen auf Anwendungen berücksichtigen.
Den ersten KRBTGT-Reset durchführen.
Die erfolgreiche Replikation kontrollieren.
Mindestens zehn Stunden beziehungsweise die entsprechend längere konfigurierte Ticketlebensdauer abwarten.
Den zweiten KRBTGT-Reset durchführen.
Anschließend erneut Replikation, Authentifizierung und betroffene Dienste kontrollieren.
Bei einer Forest Recovery sollte dagegen grundsätzlich die offizielle Wiederherstellungsanleitung von Microsoft maßgeblich sein.
Ein abweichender Notfallablauf muss ausdrücklich geplant und technisch begründet werden.
Fazit: Der KRBTGT-Reset ist wichtig, aber kein Vorgang für zwischendurch
Das KRBTGT-Konto gehört zu den sicherheitskritischsten Bestandteilen einer Active-Directory-Domäne.
Seine Schlüssel spielen eine zentrale Rolle bei der Kerberos-Authentifizierung und können bei einer Kompromittierung für besonders gefährliche Angriffe missbraucht werden.
Ein regelmäßiger und kontrollierter Passwortwechsel kann deshalb sinnvoll sein.
Allerdings ist es wichtig, die technischen Zusammenhänge zu verstehen.
Ein einzelner Reset reicht nicht aus, um den ursprünglichen Schlüssel vollständig zu verdrängen. Zwei Resets sind notwendig, und Microsoft schreibt dafür bei der üblichen Ticketlebensdauer mindestens zehn Stunden Abstand vor.
Ebenso wichtig sind eine funktionierende Active-Directory-Replikation und die Berücksichtigung vorhandener Kerberos-Tickets.
Ich würde deshalb grundsätzlich davon abraten, beide Resets ohne entsprechende Planung unmittelbar hintereinander auszuführen.
Besonders in produktiven Unternehmensnetzwerken können solche Eingriffe unerwartete Auswirkungen auf Anwendungen und Anmeldungen haben.
Interessant finde ich außerdem, dass Windows das eigentliche KRBTGT-Passwort selbst erzeugt und Microsoft inzwischen über Defender for Identity eine Sicherheitsbewertung für Passwörter bereitstellt, die älter als 180 Tage sind.
Am Ende zeigt das Thema ziemlich deutlich, dass IT-Sicherheit nicht einfach bedeutet, möglichst häufig irgendwelche Passwörter zu ändern.
Entscheidend ist vielmehr, die richtigen Maßnahmen zum richtigen Zeitpunkt und in der richtigen Reihenfolge durchzuführen.
Gerade beim KRBTGT-Konto ist eine gut geplante Vorgehensweise deutlich wertvoller als ein überstürzter Reset.
Quellen
Microsoft Learn – Active Directory Forest Recovery: Reset the KRBTGT Password
Offizielle Microsoft-Anleitung zum KRBTGT-Reset und zum vorgeschriebenen zeitlichen Abstand zwischen beiden Passwortänderungen.
Microsoft Defender for Identity – Accounts Security Posture Assessments
Informationen zur Sicherheitsbewertung von KRBTGT-Konten mit einem Passwortalter von mehr als 180 Tagen.
https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts
Microsoft Tech Community – FAQs from the Field on KRBTGT Reset
Technische Erläuterungen zur KRBTGT-Schlüsselhistorie, zu bestehenden Tickets und möglichen Auswirkungen eines Resets.
FBI, NSA und CISA – Joint Cybersecurity Advisory
Gemeinsame Sicherheitsempfehlung zur Wiederherstellung kompromittierter Active-Directory-Umgebungen.
https://www.ic3.gov/CSA/2022/220217.pdf
Jorge de Almeida Pinto – KRBTGT Password Reset Script
Dokumentation des PowerShell-Skripts zur Verwaltung und Rotation von KRBTGT-Konten.
https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md
