Ausgangslage: krbtgt ist nicht „nur ein Konto“, sondern die Ticket-Basis

In jeder AD-Domäne gibt es ein Konto namens krbtgt. Vereinfacht: dessen Geheimnis ist zentral dafür, dass Kerberos-Tickets in der Domäne signiert/verschlüsselt und damit als „gültig“ akzeptiert werden.

Das führt zu zwei praktischen Realitäten:

  • Wenn krbtgt kompromittiert wurde, können Tickets über lange Zeit missbraucht werden.
  • Eine krbtgt-Rotation ist wirksam, aber nur dann, wenn sie operational sauber geplant wird (Replikation, Ticket-Lebensdauer, Abhängigkeiten).

Wenn du AD-Hardening ernst meinst, gehört krbtgt als eigenes Projekt-Change auf die Roadmap – nicht als Nebenprodukt von „wir drehen ein paar Passwörter“.

Zielbild: kontrollierte, auditierbare Rotation mit minimalem Risiko

Ein gutes Zielbild ist konkret:

  1. krbtgt wird zweimal rotiert (2-Step-Rotation), mit klaren Wartezeiten.
  2. Der Zeitpunkt ist mit Kerberos-Ticket-Lifetimes abgestimmt (nicht geraten).
  3. Replikation ist vor/nach der Rotation geprüft und stabil.
  4. Rollout ist dokumentiert: Change-Record, Uhrzeiten, Verantwortliche, Monitoring-Signale.
  5. Betrieb behält Handlungsfähigkeit: Breakglass-Plan, Kommunikationsfenster, schnelle Validierung.

Vorab klären: Ticket-Lifetimes, Replikation, Sonderfälle

Bevor du irgendetwas änderst, kläre diese Punkte:

Kerberos-Ticket-Lifetimes (dein Timing-Fundament)

Relevant sind u. a. die Domain Policy Werte wie:

  • Maximum lifetime for user ticket (TGT)
  • Maximum lifetime for user ticket renewal
  • Maximum lifetime for service ticket

Praktisch: lies die effektiven Werte über GPO/Domain Policy aus und dokumentiere sie. Das ist die Basis für die Wartezeit zwischen Rotation 1 und Rotation 2.

Replikation (weil „Passwort geändert“ nicht „überall angekommen“ heißt)

Eine krbtgt-Rotation ist domänenweit nur stabil, wenn die Replikation sauber läuft.

Pragmatische Checks (DC-seitig):

repadmin /replsummary
repadmin /showrepl

Sonderfälle und Abhängigkeiten, die du explizit einplanst

  • RODCs: Falls Read-Only DCs existieren, prüfe, ob und wie sie in deinen Change-Fenstern berücksichtigt werden.
  • Mehrere Domänen / Trusts: krbtgt ist pro Domäne relevant; plane domänenweise.
  • Alt-Systeme / Kerberos-Edge-Cases: Nicht jeder Fehler ist „krbtgt schuld“ – aber Rotation deckt oft alte Drift-Probleme auf (Zeit-Sync, DNS, SPNs, alte Clients).

Umsetzung: Rotation als 2-Step-Change (mit nachvollziehbaren Gateways)

Die operative Leitplanke: Ziel ist nicht „schnell“, sondern vorhersehbar.

Phase 0: Vorbereitung (Messpunkte und Rückfall)

  • Lege ein Change-Fenster fest (typisch außerhalb Peak).
  • Definiere Monitoring/Validierung:
  • Authentifizierung an typischen Services (Fileshare, Intranet, VPN, ADFS/Entra App Proxy falls vorhanden)
  • DC Event Logs auf auffällige Kerberos-Fehler
  • Replikation vor/nach dem Schritt
  • Definiere einen Kommunikationskanal, falls User-Login-Probleme auftreten (Service Desk / Ops).

Phase 1: Erste Rotation

Technisch wird das Passwort von krbtgt zurückgesetzt (nicht „manuell gesetzt“). Ein pragmatisches Beispiel:

Import-Module ActiveDirectory
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (Read-Host -AsSecureString "New krbtgt password")

Hinweise für den Betrieb:

  • Halte das Passwort nicht „irgendwo“ fest. Es ist ein Domänenkonto-Secret; das Ziel ist Rotation, nicht Wiederverwendung.
  • Dokumentiere exakt: Startzeit, ausführender Admin, betroffene Domäne, Replikationsstatus direkt davor/danach.

Phase 2: Warten, bis alte Tickets realistisch abgelaufen sind

Zwischen Rotation 1 und 2 brauchst du eine Wartezeit, die zu deiner Umgebung passt:

  • Als Minimum: länger als die maximale relevante Ticket-Lifetime (inkl. Sicherheitsaufschlag).
  • Zusätzlich: Zeit für Replikation und „Edge“-Logins (Remote-User, Offline-Notebooks, selten genutzte Services).

Die häufigste Ursache für Drama ist nicht die Rotation selbst, sondern „zu früh die zweite Rotation“.

Phase 3: Zweite Rotation (Ticket-Entwertung „vollständig“ machen)

Dann folgt derselbe Reset erneut:

Import-Module ActiveDirectory
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (Read-Host -AsSecureString "New krbtgt password (2nd rotation)")

Anschließend:

  • Replikation erneut prüfen.
  • Stichprobenartige Service-Validierung durchführen.
  • Change dokumentieren und abschließen.

Vorteile und Nachteile/Grenzen (explizit)

Vorteile

  • Starke Ticket-Entwertung: Nach sauberer 2-Step-Rotation verlieren alte, ggf. missbräuchlich nutzbare Kerberos-Tickets ihre Wirksamkeit.
  • Messbarer Hardening-Baustein: Du kannst den Change sauber belegen (Zeitpunkte, Replikation, Outcome).
  • Gute Grundlage für Incident Response: Rotation ist ein Standardhebel, wenn ein Tier-0-Verdacht im Raum steht (ohne dass du sofort „alles neu“ machen musst).

Nachteile / Grenzen

  • Operatives Risiko bei schlechtem Timing: Wenn Replikation/Ticket-Lifetimes ignoriert werden, sind Auth-Probleme möglich.
  • Kein Ersatz für Root-Cause: Wenn Tier-0 kompromittiert ist, ist Rotation nur ein Baustein; du brauchst parallel Forensik, Credential Hygiene, Privileged Access Redesign.
  • Deckt Drift auf: Zeit-Sync/DNS/alt Kerberos-Verhalten wird nicht durch Rotation „repariert“, sondern sichtbar (was gut ist, aber Tickets erzeugt).

Typische Stolperfallen (die in Projekten regelmäßig passieren)

  • Rotation 2 zu früh (Ticket-Lifetimes nicht verstanden).
  • Replikation „ungefähr ok“ statt objektiv geprüft.
  • „Wir machen das nachts“ ohne definierte Validierungsschritte und Owner.
  • Mehrdomänen/Trust-Umgebung ohne domänenweise Planung.
  • Service Accounts/Legacy-Systeme werden vorher nicht in ein Smoke-Test-Set aufgenommen.

Projekt-Checkliste: krbtgt-Rotation sauber liefern

  • [ ] Domänen-Scope und Reihenfolge festgelegt (bei mehreren Domänen).
  • [ ] Ticket-Lifetime Werte dokumentiert (Quelle: effektive Domain Policy).
  • [ ] Replikation vor Change geprüft (repadmin), Fehler behoben oder Risiko akzeptiert.
  • [ ] Change-Fenster + Kommunikationsplan + Owner stehen.
  • [ ] Validierungs-Szenarien definiert (mind. 5–10 kritische Services/Logon-Pfade).
  • [ ] Rotation 1 durchgeführt, Replikation nachgewiesen, Validierung ok.
  • [ ] Wartezeit (>= Ticket-Lifetime + Puffer) eingehalten, dokumentiert.
  • [ ] Rotation 2 durchgeführt, Replikation nachgewiesen, Validierung ok.
  • [ ] Lessons learned festgehalten (wichtig: welche Services/Clients Probleme machten).