KRBTGT Key Rollover

Wir nutzen wie selbstverständlich verschiedene Dienstkonten im Active Directory und wissen auch, dass wir die Zugriffe darauf eigentlich überwachen sollten. Das BSI ist zwar mittlerweile davon abgekommen, regelmäßige Kennwortänderungen für Anwender zu fordern, weil dies die Sicherheit nicht wirklich verbessert. Aber bei Dienstkonten müssen wir schon noch genauer hinschauen, insbesondere wenn die Dienstkonten sehr umfangreiche Berechtigungen haben. Exchange 2007 und neuer nutzt gar kein Dienstkonto mehr aber viele andere Dienste und auch das "Kerberos Distribution Center (KDC)" nutzen Dienstkonten. Dieses Konto ist sehr sensibel und wenn es bekannt würde, könnte jemand sich ein "Golden Ticket" ausstellen, mit der jede andere Rolle einnehmen kann.

Hinweis
Verwechseln Sie das KRBTGT-Konto auf dieser Seite nicht mit dem Konto AZUREADSSOACC, welches bei Office 365 mit Seamless Single Sign On genutzt und ebenfalls zyklisch geändert werden sollte.

Hinweis
Wenn sie in ihrem Active Directory eine Kerberos RC4 Abschaltung vornehmen wollen, dann prüfen Sie, ob für das Konto "KRBTGT" auch schon ein AES-Hashwert des Kennworts hinterlegt wurde. Das ist erst seit Windows 2008 oder neue der Fall. Am einfachsten ist es, das Kennwort zu ändern, was sie sowieso regelmäßig tun sollten.

Weckruf - Golden Ticket

Die meisten Firmen merken aber gar nicht, dass das KRBTGT-Konto vielleicht kompromittiert wurde. Ein Angreifer mit diesem Kennwort sich auch schön verborgen bleiben, denn er hat den Master-Key für ihre Active Directory. Insofern ist die Empfehlung von Microsoft hier schon ernst zu nehmen, dieses Kennwort ab und an zu ändern.

Angriffe können aber auch über schwache Verschlüsselungsverfahren erfolgen. Hier ist eine Überwachung der Zugriffe und "Versuche" wichtig. Wenn Sie z.B. Defender ATP einsetzen, dann protokolliert diese Komponenten die verwendeten Verfahren und alarmiert, wenn ein Downgrade versucht wird.

So einen Event sollten Sie dann schon etwas genauer untersuchen, welche Benutzer auf welchem System davon betroffen sind.

Mitigating Pass-the-Hash and Other Credential Theft, version 2
http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf

Protection from Kerberos Golden Ticket - Mitigating pass the ticket on Active Directory
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf

Was ist das KRBTGT-Konto?

Das KRBTGT-Konto gibt es in jeder Active Directory-Domäne und liegt normalerweise in der OU "Users". In jeder Domain gibt es ein "Kerberos Key Distribution Center (KDC)", welcher Kerberos-Tickets ausstellt, die digital signiert sind, Dazu benötigt der KDC eine "geheime Information", mit der die Tickets signiert werden. Diese Information muss aber auf allen Domain Controllern vorliegen und dafür ist das KRBTGT-Konto der Platz. Für das Konto speichert das Active Directory das Kennwort als HASH-Wert. Bis Windows 2008R2 war das "nur" ein RC4-Hash. Erst mit Windows 2008 wurde auch AES als HAsh aufgenommen (siehe auch Kerberos RC4 Abschaltung). Kontrollieren Sie daher schnell mal, wann das Kennwort des KRBTGT zuletzt geändert wurde.

Get-ADUser  krbtgt -Properties PasswordLastSet,*creat*

DistinguishedName : CN=krbtgt,CN=Users,DC=msxfaq,DC=de
Enabled           : False
GivenName         :
Name              : krbtgt
ObjectClass       : user
PasswordLastSet   : 21.07.2019 15:10:43
SamAccountName    : krbtgt
SID               : S-1-5-21-12345678-12345678-12345678-502
Surname           :
UserPrincipalName :

Achtung
Eine Änderung nach 2008 bedeutet nicht automatisch, dass ein AES-Hash erzeugt wurde. Die Version des Domain Controllers und der ForestMode war bei der Änderung wichtig. Weitere Details finden Sie auf Kerberos RC4 Abschaltung.

Durch den Wechsel des Forest Functional Level auf Windows 2008 wird das Kennwort einmal geändert, damit es AES-verschlüsselt gespeichert wird. Mein Forest gab es natürlich schon länger.

The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory. KRBTGT is also the security principal name used by the KDC for a Windows Server domain ...

...The TGT password of the KRBTGT account is known only by the Kerberos service. ..

Quelle: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#krbtgt-account

Alle KDCs nutzen also dieses Konto um Tickets auszustellen und zu verifizieren. Wenn ich also als Angreifer dieses Kennwort kenne, dann kann ich mir selbst entsprechende Tickets ausstellen, die von allen KDCs als "gültig" angesehen werden.

KRBTGT-Kontenpflege

Auf der gleichen Seite gibt es aber auch weitere Hinweise zur Pflege dieses Kontos:

A strong password is assigned to the KRBTGT account automatically. Be sure that you change the password on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. 

On occasion, the KRBTGT account password requires a reset, for example, when an attempt to change the password on the KRBTGT account fails. In order to resolve this issue, you reset the KRBTGT user account password twice by using Active Directory Users and Computers. You must reset the password twice because the KRBTGT account stores only two of the most recent passwords in the password history.

Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. 

Quelle: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#krbtgt-account

Nur gibt es keinen Automatismus und die wenigsten Administratoren habe das Kennwort schon je geändert. Es könnte ja auch nach hintern losgehen und die Funktion stören. Und vielleicht ist das alles ja gar nicht so schlimm.

Wann muss ich ein Key Rollover machen?

Ich habe mich natürlich aufgrund der Meldung des Defender ATP noch mal mit dem Thema beschäftigt und einige Fakten zusammen getragen:

  • Der KDC prüft Tickets anhand des aktuellen und des vorherigen Kennworts
    Wenn ich das Kennwort also einmalig ändere, dann funktioniert alles weiter, da neue Tickets mit dem neuen Kennwort signiert werden und früher ausgestellte Tickets weiterhin gültig sind, bis die Tickets ablaufen. (ca. 2-12 Stunden)
  • Wenn alles Tickets abgelaufen sind, dann kann ich nochmal das Kennwort ändern
    Die Clients haben ja mittlerweile schon neue Tickets mit dem neuen Kennwort und ich kann noch mal ein Rollover machen damit das vorvorherige Kennwort verschwunden ist. Damit hätte dann auch ein Angreifer keinen Eingang mehr, da das aktuelle und das vorherige Kennwort geändert sind. Das Problem ist dabei aber die Zeit dazwischen, wenn ich ein neues Kennwort habe aber das alte eben auch noch gilt. Ein Angreifer könnte sich dann auch als "Domain Controller" ausgeben und sie so auch das neue Kennwort beschaffen.
  • Einbruch bedeutet 2x ändern
    Wenn ich also den Verdacht habe, dass jemand das KRBTGT-Kennwort erhalten hat, dann darf ich nicht warten, sondern muss das Kennwort zweimal kurz hintereinander ändern und hoffen, dass der Angreifer keine Hintertür hat, z.B. ein Admin-Konto oder ein privilegiertes Computerkonto o.ä. Auch der erste Weg das Kennwort überhaupt zu erhalten, muss natürlich geschlossen worden sein. Also ist das eher ein Shutdown des Netzwerks und kontrolliertes Starten. Wobei die Clients nach einem zweimaligen Kennwortwechsel mit ihren noch zeitlich gültigen Tickets dennoch keinen Zugriff mehr erhalten. Um einen Neustart der Clients bzw. der Dienste oder ein Purge der Kerberos Tickets für alle angemeldeten Benutzer kommen Sie dann eh nicht vorbei. Für das "Local System"-Konto hilft ein "klist -li 0x3e7 purge" als Admin

Es ist aber unkritisch, das Kennwort ab und an zu ändern. Sie können das ganz einfach über "Active Directory Benutzer und Computer" machen und prüfen, dass die AD-Replikation funktioniert und alle KDCs das neue Kennwort möglichst schnell erhalten. Sonst könnte es ja passieren, dass ein Client von einem schon aktualisierten DC ein Ticket bekommt, um damit auf einen Server zugreifen zu können, der noch mit einem DC mit dem alten Kennwort kommuniziert. Dann wäre das Ticket ungültig.

Wenn ihr Kennwort des KRBTGT noch zu Zeiten von Windows 2000/2003 das letzte Mal gesetzt wurde, könnte es sein, dass es noch keinen AES-Hash hat. Dann lesen Sie unbedingt die Seite Kerberos RC4 Abschaltung.

Details aus einem Forum

Auf https://docs.microsoft.com/en-us/answers/questions/87978/reset-krbtgt-password.html gibt es eine ausführliche Antwort von "FanFan-MSFT" (https://docs.microsoft.com/en-us/users/fanfan-msft/), die ich als Archiv hier ausnahmeweise komplett zitiere:

FanFan-MSFT answered · Sep 08 2020 at 3:44 AM BEST ANSWERACCEPTED ANSWER
Hi,

Before going further, i would like to explain why we need to reset the password 2 times :
The Kerberos TGT is encrypted and signed by the KRBTGT account. This means that anyone can create a valid Kerberos TGT if they have the KRBTGT password hash. Furthermore, despite the Active Directory domain policy for Kerberos ticket lifetime, the KDC trusts the TGT, so the custom ticket can include a custom ticket lifetime.
If the krbtgt account is compromised, attackers can create valid Kerberos Ticket Granting Tickets (TGT).It attempts to decrypt with the current password and if that fails, it attempts again with the previous one (assuming it has it).So the password must be changed twice to effectively remove the password history. Changing once, waiting for replication to complete and changing again reduces the risk of issues. Changing twice in rapid succession forces clients to re-authenticate (including application services) but is desired if a compromise is suspected.

For your questions:
1,There is no need to wait 10 hours, only need to wait for the replication.There are Two Change Scenarios as following for different situations (both you mentioned):

If there are any chance that the KRBTGT account is compromised.
Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).

2, For your second question:From my personal understanding, if it is a regular maintenance it is totally ok to reset the password at the nest day to wait for the replication if you have multi-sites.

3, As mentioned above,changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs.
Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

So before changing the password, i would recommend you to check the replication status before perform this task, to be sure that the new passwords will be replicated on all domain controllers.Following command :
Repadmin /showrepl >C:\repl.txt
Repadmin /showreps *
Repadmin /syncall /APeD

Key Rollover und Trusts

Auch zwischen Domänen gibt es eine Authentifizierung, wenn Sie per Trust "verbunden" sind. Diese Geheimnisse sind aber nicht an das KGBTGT-Konto der Domain gekoppelt, sondern separate Credentials. Ein KRBTGT-Rollover betrifft nicht diese Verbindungen. Sie können natürlich die Credentials einen Trusts zwischen Forests ebenfalls aktualisieren. Aber ich habe noch keine Empfehlungen gesehen, die dies als erforderlich ansehen.

  • Kerberos Cross Forest - Wie funktioniert eine Kerberos-Authentifizierung ich mit zwei Forests, z.B. bei Migrationen und Koexistenz?

Key Rollover und Azure AD

In Verbindung mit Entra ID/Azure AD gibt es ebenfalls Kerberos und damit entsprechende Schlüssel. Dazu gibt es dann aber auch wieder ein eigenes Computerkonto (AzureADKerberos), dessen Konto regelmäßig rotiert werden sollte. Zumindest sollten Sie das Vorgehen kennen, wenn ihr lokales AD kompromittiert sein könnte und jemand das Geheimnis des Computerkontos kennt.

Microsoft Rollover Script (EOL)

Natürlich können Sie einfach mal schnell das Kennwort des KRBTGT-Kontos ändern und hoffen, dass alles funktioniert. Viele Firmen wissen aber gar nicht, ob ihre AD-Replikation wirklich bis zum letzten DC sauber funktioniert und alle DCs online sind und die Änderung mitbekommen. Kerberos ist nämlich auch für die Authentifizierung zwischen den DCs und damit der Replikation erforderlich. Es ist daher ratsam, vorab einige Prüfungen und Tests vorzunehmen und nach der Änderung auf jeden Fall zu prüfen, dass die Änderung auf allen DCs angekommen ist. Dies gilt umso mehr, wenn Sie das Kennwort zweimal in kurzer Zeit ändern müssen, um einen möglichen Einbruch zu stoppen.

Hinweis: Wenn Sie das Konto zweimal schneller ändern als Kerberos Tickets ablaufen (8h), dann haben Computer keine gültigen Kerberos-Tickets mehr und Zugriffe scheitern bis zum Neustart oder Ablauf der Tickets. Ein "KLIST /PURGE" löscht nur die Tickets des Users aber nicht des Computerkontos. Notfalls sind die Clients und Member-Server neu zu starten.

Schon früh hat Microsoft ein Skript bereitgestellt, welches den Rollover-Prozess in drei Phasen begleitet. Allerdings war es nie ein offizielles Tool und mittlerweile sind die verantwortlichen Personen in anderen Projekten:


Quelle: https://github.com/microsoftarchive/New-KrbtgtKeys.ps1/tree/master

Frühere Version
TechNet Gallery wurde abgeschaltet. https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
Sie finden das Skript auf dem GIT https://gist.GitHub.com/mubix/fd0c89ec021f70023695
Ich habe mir hier (Reset-KrbtgtKeyInteractive.ps1) die Version 1.4 gesichert. Der Verlust der TechNet Gallery zeigt doch immer mal wieder, wie schnell wichtige Tools verloren gehen könnten.

New-KrbtgtKeys.ps1
https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1
https://github.com/microsoftarchive/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1
Neuere und deutlich umfangreichere Version

Das Skript "Reset-KrbtgtKeyInteractive.ps1" prüft "Strings" und funktioniert daher nur auf englischen Servern. Für Deutsch sind zwei Änderungen erforderlich:
Zeile 32: If ($RpcPingResult -like "*abgeschlossen*")
Zeile 54: If ($RepAdminResult -like "*erfolgreich*")

Schritt Phase Beschreibung

1

Information

Das Skript liest und prüft nur, ob alle Voraussetzungen erfüllt sind.

2

Simulation

Das Skript führt neben den Schritten aus Phase 1 zusätzlich noch eine einmalige Replikation aus. Es weist also alle DCs an, die vom PDC-Emulator nun das aktuelle, aber immer noch unveränderte Kennwort zu replizieren.

3

Reset

Erst hier wird das Kennwort des KDC-Service auf dem PDC-Emulator geändert und dann die Replikation ausgeführt.

Das Skript akzeptiert keine Parameter o.ä. sondern fordert Sie als Administrator zur Auswahl auf.

Das Skript macht ein Update des KRBTGT-Konto-Kennworts sicherer, da es die Replikation forciert und verschiedene Voraussetzungen prüft. Aber es ist kein "Schutz" gegen "Golden Ticket"-Angriffe.

Hinweis:
Das PowerShell-Script startet Programme wie "RPCPING" und "REPADMIN" und wertet die Bildschirmausgabe aus. Dies funktioniert nur mit englischen Servers. Wenn ihr Server eine andere Sprache hat, dann müssen Sie das PS1-Skript anpassen.

3rd Party Skripte

Ich kann zwar immer noch nicht verstehen, warum Microsoft die Weiterentwicklung dieses Skripts nicht in eigene Hänge legt oder sogar ins Betriebssystem als automatisierten Wartungstask einbaut. An andere Stelle gibt es ja auch schon neue Funktionen wie dMSA - Delegated Managed Service Accounts und GMSA - Group Managed Service Account, die so ein Rollover automatisieren oder sogar selbst machen könnten. Aber mittlerweile haben sich andere Entwickler den Code als Fork weiter entwickelt.

Da sie diese Skripte mit den maximalen Rechten ausführen und diese nicht signiert sind, müssen Sie sich schon selbst vergewissern, das die Skripte auch nur das tun, was Sie tun sollen.

Unter der Adresse https://github.com/microsoftarchive/New-KrbtgtKeys.ps1/forks können Sie sehen, welche  anderen Entwickler eine eigene Instanz weiterpflegen. Im Feb 2026 waren von 105 Forks aber nur drei auch die letzten 2 Jahre aktiv und hatten nicht mal eine eigene MD5-Dokumentation angepasst. Nach meiner Ansicht bleibt eigentlich nur das Skript von Jorge de Almeida Pinto [MVP Identity And Access - Security] übrig, welches kontinuierlich weiter entwickelt wird.

Das Skript ist (Stand Feb 2026) deutlich erweitert worden und es gibt viel mehr und aufwändigere Bildschirmausgabe:

 

im nächsten Schritt werden einige PowerShell Module nachgeladen und dann die folgende Auswahl angeboten:

Die mittlerweile neun Optionen erklären sich eigentlich alleine

- 1 - Informational Mode (No Changes At All)
- 2 - Simulation Mode | Temporary Canary Object Created To Test Replication Convergence!
- 3 - Simulation Mode | Use TEST/BOGUS KrbTgt Accounts - No Password Reset/WhatIf Mode!
- 4 - Real Reset Mode | Use TEST/BOGUS KrbTgt Accounts - Password Will Be Reset Once!
- 5 - Simulation Mode | Use PROD/REAL KrbTgt Accounts - No Password Reset/WhatIf Mode!
- 6 - Real Reset Mode | Use PROD/REAL KrbTgt Accounts - Password Will Be Reset Once!
- 7 - Golden Ticket Monitor Mode | Checking Domain Controllers For Event ID 4769 With Specific Error Codes (EXPERIMENTAL!)
- 8 - Create TEST/BOGUS KrbTgt Accounts
- 9 - Cleanup TEST/BOGUS KrbTgt Accounts 

Wer vorab erst einmal testen will, legt mit "8" ein entsprechendes Testkonto an, welche dann über "3" oder "4" bearbeitet werden kann, Wenn all das funktioniert, dann dürfte auch der reale Rollover mit Option 5 und 6 funktionieren, ehe Sie dann die Testkonten mit Option 9 wiedere entfernen.

Vergessen Sie nicht sich einen Merker zu setzen, wann Sie den nächsten Rollover durchführen wollen.

Weitere Links