Ausgangslage: Das Ticket ist normal, das schwache Dienstgeheimnis ist das Risiko

Kerberoasting nutzt eine reguläre Eigenschaft von Kerberos. Ein authentifizierter Domänenbenutzer kann für einen Dienst mit registriertem Service Principal Name, kurz SPN, ein Service-Ticket anfordern. Ein Teil dieses Tickets ist mit Schlüsselmaterial des Dienstkontos geschützt. Die Anfrage selbst ist deshalb kein administrativer Vorgang und kein Beweis für einen Angriff.

Das Risiko entsteht anschließend offline: Ist das Kennwort des Dienstkontos kurz, vorhersehbar, wiederverwendet oder seit Jahren unverändert, kann das Ticket eine überprüfbare Grundlage für Kennwortversuche liefern. Die Domain Controller sehen diese Offline-Prüfung nicht. Ein normales Benutzerkonto mit Netzwerkkonnektivität kann damit ausreichen, um ein schwaches Dienstkonto zum Ziel zu machen.

In gewachsenen AD-Umgebungen treffen häufig mehrere ungünstige Eigenschaften zusammen:

  • klassische Benutzerkonten werden als Dienstidentitäten verwendet,
  • Password never expires ersetzt einen echten Rotationsprozess,
  • ein Konto betreibt mehrere Anwendungen oder Umgebungen,
  • SPNs bleiben nach Migrationen am alten Konto zurück,
  • Dienstkonten sind lokal oder in der Domäne überprivilegiert,
  • interaktive Anmeldung und RDP sind weiterhin erlaubt,
  • RC4 wurde für einzelne Konten oder den KDC explizit zugelassen,
  • niemand kann Owner, Zielsysteme und Ausfallwirkung benennen.

Seit den Windows-Sicherheitsupdates vom Juli 2026 werten vollständig aktualisierte Domain Controller den früheren Rollback-Schalter für die Service-Ticket-Ausstellung nicht mehr aus. Hat das Zielkonto keinen expliziten Wert in msDS-SupportedEncryptionTypes und der DC keinen expliziten Wert für DefaultDomainSupportedEncTypes, verwendet der KDC standardmäßig AES-SHA1. Fehlen passende AES-Schlüssel oder bietet der Client kein AES an, wird die Anfrage blockiert. Explizite Konto- und DC-Konfigurationen bleiben jedoch wirksam. Das reduziert eine wichtige Legacy-Schwäche, beseitigt Kerberoasting aber nicht. Gemischte DC-Patchstände können unterschiedliche Ergebnisse liefern, und auch ein AES-geschütztes Ticket bleibt bei einem schwachen Kennwort offline prüfbar.

Kerberoasting ist daher kein reines Kryptografieproblem. Es ist vor allem ein Service-Account-, Rechte- und Betriebsproblem.

Zielbild: Jeder Dienst hat eine verwaltete, begrenzte Identität

Ein belastbarer Zielzustand lässt sich konkret prüfen:

  1. Jeder produktive SPN hat einen Owner. Anwendung, Dienst, Host, Umgebung, Verantwortlicher und Wiederanlaufverfahren sind dokumentiert.
  2. Ein Dienstzweck verwendet eine eigene Identität. Konten werden nicht zwischen Produktion, Test, geplanten Tasks und mehreren unabhängigen Anwendungen geteilt.
  3. gMSA ist der bevorzugte Standard. Unterstützte Windows-Dienste und Serverfarmen verwenden automatisch verwaltete, hochentropische Geheimnisse.
  4. Legacy-Konten haben lange zufällige Geheimnisse und einen echten Rotationsprozess. Kennwortablage, Wechsel, Verteilung, Test und Recovery sind automatisiert oder mindestens belastbar dokumentiert.
  5. SPNs sind eindeutig und aktuell. Verwaiste und doppelte Einträge werden nach Abhängigkeitsprüfung entfernt; SPN-Schreibrechte sind eng delegiert.
  6. Dienstidentitäten sind nicht privilegierter als ihre Aufgabe. Keine pauschalen Administratorgruppen, keine unnötigen Verzeichnisrechte und keine unkontrollierte Delegation.
  7. Anmeldung ist auf Zweck und Hosts begrenzt. Nur die benötigten Service- oder Batch-Rechte sind auf den vorgesehenen Systemen vorhanden; lokale und RDP-Anmeldung sind gesperrt, soweit die Anwendung das zulässt.
  8. AES ist nachgewiesen, RC4 ist eine befristete Ausnahme. Entscheidend sind tatsächlich ausgestellte Tickets und aktuelle KDC-Ereignisse, nicht nur ein gesetztes Kontoattribut.
  9. Kerberos-Tickets werden zentral überwacht. Event 4769 und die aktuellen KDC-Service-Ereignisse werden mit einer belastbaren Normalbaseline ausgewertet.
  10. Neue Dienstkonten durchlaufen einen Freigabeprozess. Owner, gMSA-Eignung, SPN, Rechte, Zielhosts, Rotation, Monitoring und Stilllegung sind vor Produktivnahme geklärt.

Das Ziel ist nicht, Service-Tickets zu verhindern. Kerberos braucht sie. Das Ziel ist, dass ein angefordertes Ticket kein wirtschaftlich sinnvolles Ziel für Offline-Kennwortangriffe darstellt und ein kompromittiertes Dienstkonto nur einen eng begrenzten Schaden verursachen kann.

Umsetzung: Vom SPN-Inventar zum kontrollierten Dienstbetrieb

1) SPN-tragende Benutzerkonten read-only erfassen

Beginne mit den Konten, die wie normale AD-Benutzerobjekte geführt werden und mindestens einen SPN besitzen. Genau dort finden sich häufig manuell verwaltete Dienstkennwörter. Die folgende Abfrage verändert nichts:

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop

$properties = @(
  'Description'
  'Enabled'
  'LastLogonDate'
  'MemberOf'
  'msDS-SupportedEncryptionTypes'
  'PasswordLastSet'
  'PasswordNeverExpires'
  'ServicePrincipalName'
)

Get-ADUser `
  -LDAPFilter '(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))' `
  -Properties $properties |
  Select-Object `
    SamAccountName,
    Enabled,
    PasswordLastSet,
    PasswordNeverExpires,
    LastLogonDate,
    @{Name = 'SpnCount'; Expression = { @($_.ServicePrincipalName).Count }},
    @{Name = 'Spns'; Expression = { $_.ServicePrincipalName -join '; ' }},
    @{Name = 'SupportedEncryptionTypes'; Expression = {
      $_.'msDS-SupportedEncryptionTypes'
    }},
    @{Name = 'DirectGroupCount'; Expression = { @($_.MemberOf).Count }},
    Description,
    DistinguishedName |
  Sort-Object PasswordLastSet, SamAccountName

Die Ausgabe ist ein Startpunkt, keine vollständige Risikobewertung. LastLogonDate ist verzögert und beweist weder aktive Dienstnutzung noch Stillstand. MemberOf enthält nur direkte Mitgliedschaften; verschachtelte Gruppen, delegierte ACLs und lokale Rechte müssen separat aufgelöst werden. Ein leerer Wert bei msDS-SupportedEncryptionTypes bedeutet außerdem nicht automatisch, dass aktuell RC4 verwendet wird. Maßgeblich ist, was der KDC unter dem geltenden Patch- und Policy-Stand tatsächlich ausstellt.

Ergänze das Benutzerinventar um gMSA, sMSA, Computerobjekte mit anwendungsspezifischen SPNs und nicht Windows-basierte Kerberos-Principals. Diese Klassen werden getrennt bewertet: gMSA- und Computerkennwörter haben normalerweise eine andere Entropie und Rotation als manuell gepflegte Benutzerkennwörter. Bei gMSA sind zu breite Abrufrechte für das verwaltete Kennwort ein eigenes Risiko. Falsche SPNs und überhöhte Privilegien können beide Kontoklassen unsicher machen.

2) Owner, Dienst und Abhängigkeiten zusammenführen

Ein SPN allein sagt nicht, ob ein Konto noch benötigt wird. Verknüpfe deshalb die AD-Daten mit dem realen Betrieb:

  • Windows-Dienste, IIS Application Pools und geplante Tasks,
  • Datenbanken, Backup-, Monitoring- und Middleware-Komponenten,
  • Cluster- und Farmknoten,
  • nicht Windows-basierte Anwendungen und Appliances,
  • Secret-Vault- oder Deployment-Einträge,
  • ausgestellte Service-Tickets auf den Domain Controllern,
  • Change-, CMDB- und Verantwortlichkeitsdaten.

Für jedes Konto braucht es mindestens Dienstname, fachlichen und technischen Owner, produktive Hosts, SPNs, benötigte Rechte, Starttyp, Neustartreihenfolge, Wartungsfenster und Recovery-Verfahren. Kann niemand diese Angaben liefern, ist das Konto nicht automatisch verwaist. Es ist zunächst ein unkontrolliertes Betriebsrisiko.

Prüfe doppelte SPNs forestweit und kläre jeden Treffer vor einer Änderung. Ein SPN darf nur einem Security Principal zugeordnet sein. Blindes Löschen oder Verschieben kann Kerberos-Ausfälle und KRB_AP_ERR_MODIFIED verursachen. Auch verwaiste SPNs werden erst entfernt, wenn Telemetrie, Owner und Anwendungstest übereinstimmen.

3) Nach Auswirkung statt nur nach Kennwortalter priorisieren

Nicht jedes SPN-Konto hat dasselbe Risiko. Eine belastbare Priorisierung kombiniert mindestens:

  • privilegierte Gruppenmitgliedschaften und verschachtelte Gruppen,
  • direkte Rechte auf OUs, GPOs, Server, Datenbanken, Backup- oder Virtualisierungsplattformen,
  • Password never expires, hohes Kennwortalter oder unbekannte Kennwortquelle,
  • mehrere SPNs, Anwendungen oder Umgebungen auf derselben Identität,
  • explizite RC4-Unterstützung oder beobachtete RC4-Tickets,
  • Unconstrained Delegation oder eine andere weitreichende Delegationskonfiguration,
  • erlaubte lokale, RDP-, Batch- und Service-Anmeldung,
  • Zugriff auf Tier-0-Systeme oder besonders schützenswerte Daten,
  • fehlender Owner, unklare Nutzung oder keine verwertbare Telemetrie.

Ein schwaches Konto ohne besondere Rechte ist relevant. Ein schwaches Konto mit SPN, Backup-Rechten und Zugriff auf Domain Controller ist jedoch ein anderer Projektfall. Bearbeite zuerst Konten, bei denen Geheimnisstärke und mögliche Auswirkung gleichzeitig schlecht sind.

4) Geeignete Dienste auf gMSA migrieren

Group Managed Service Accounts sind für viele Windows-Dienste der sauberste Zielzustand. Active Directory erzeugt ein langes zufälliges Geheimnis und rotiert es standardmäßig automatisch. Der Dienst muss kein statisches Kennwort aus einer Konfigurationsdatei, einem Skript oder einer manuellen Übergabe beziehen.

Die Migration braucht trotzdem Planung:

  1. Prüfe, ob Produkt und Diensttyp gMSA unterstützen und der Hersteller den Einsatz im vorgesehenen Cluster- oder Farmmodell freigibt.
  2. Stelle sicher, dass der KDS Root Key im Forest korrekt verfügbar und repliziert ist.
  3. Verwende ein eigenes gMSA pro klar abgegrenztem Dienstzweck.
  4. Plane nur die benötigten SPNs für das neue Konto und weise ihre Eindeutigkeit vor dem Cutover nach.
  5. Erlaube den Abruf des verwalteten Kennworts nur einer dedizierten Gruppe mit den tatsächlich benötigten Computerobjekten.
  6. Teste Test-ADServiceAccount auf jedem vorgesehenen Knoten.
  7. Stelle Dienst und benötigte SPNs in einem Pilotfenster um und prüfe Start, Failover, Kerberos, Zugriffe und Passwortwechsel.
  8. Entferne nach einer definierten Beobachtungsphase verbliebene alte Rechte und deaktiviere das Vorgängerkonto.

Eine breite Gruppe wie Domain Computers bei PrincipalsAllowedToRetrieveManagedPassword unterläuft die Host-Bindung. Wer das gMSA-Geheimnis abrufen darf, gehört zur Schutzgrenze und muss ebenso streng geprüft werden wie die Rechte des Kontos selbst.

gMSA ist außerdem kein Privilegienfilter. Ein automatisch rotiertes Konto in einer hochprivilegierten Gruppe bleibt ein hochprivilegiertes Konto. Rotation schützt das Geheimnis; Least Privilege begrenzt die Auswirkung.

5) Nicht migrierbare Konten mit langen zufälligen Geheimnissen betreiben

Legacy-Produkte, nicht Windows-basierte Dienste oder Herstellergrenzen können gMSA verhindern. Dann braucht jedes Dienstkonto ein eindeutiges, kryptografisch zufällig erzeugtes Geheimnis in der maximal zuverlässig unterstützten Länge. In der Praxis sind 32 oder 64 und mehr zufällige Zeichen ein sinnvoller Ausgangspunkt, sofern Anwendung, Protokoll und Deploymentpfad diese Länge vollständig verarbeiten.

Der Kennwortprozess muss mehr können als einen Wert im Vault speichern:

  • Erzeugung mit einem kryptografisch sicheren Zufallszahlengenerator,
  • keine Wiederverwendung zwischen Diensten, Umgebungen oder Notfallkonten,
  • Zugriff nur für den automatisierten Verteilpfad und eng begrenzte Betreiber,
  • atomare oder abgestimmte Aktualisierung aller Dienstknoten,
  • Funktionstest mit neu ausgestelltem Ticket,
  • kontrollierter Neustart und dokumentierter Rollback,
  • Rotation nach einem festen, technisch erprobten Intervall sowie sofort bei Verdacht auf Offenlegung,
  • Monitoring auf veraltete Deployments und fehlgeschlagene Anmeldungen.

Password never expires kann bei einer Anwendung verhindern, dass ein unkoordinierter Ablauf den Dienst stoppt. Es darf aber nicht mit „Kennwort wird nie gewechselt“ gleichgesetzt werden. Wenn der AD-Ablaufmechanismus nicht genutzt wird, muss ein eigener nachweisbarer Rotationsprozess übernehmen.

6) AES nachweisen und RC4-Ausnahmen abbauen

Seit den Juli-2026-Updates wird RC4DefaultDisablementPhase auf aktualisierten Domain Controllern nicht mehr ausgewertet. Hat das Zielkonto keinen expliziten Wert in msDS-SupportedEncryptionTypes und der DC keinen expliziten DefaultDomainSupportedEncTypes-Wert, verwendet der KDC für die Service-Ticket-Auswahl standardmäßig AES-SHA1, Bitmaske 0x18. Fehlen passende AES-Schlüssel oder bietet der Client kein AES an, wird die Anfrage blockiert. Explizite Konto- und DC-Konfigurationen bleiben wirksam.

Trotzdem sind drei Prüfungen nötig:

  • Sind wirklich alle Domain Controller auf einem Update-Stand ab Juli 2026 und neu gestartet?
  • Erlaubt ein Dienstkonto RC4 weiterhin explizit in msDS-SupportedEncryptionTypes?
  • Wurde DefaultDomainSupportedEncTypes auf einem DC unsicher überschrieben?

Wird AES für ein altes Konto neu aktiviert, rotiere anschließend das Kennwort. Erst dadurch entsteht das passende AES-Schlüsselmaterial, falls das Kennwort seit der AES-Unterstützung nie geändert wurde. Teste danach die Anwendung mit frischen Tickets und prüfe die KDC-Ereignisse. Nur Checkboxen oder Attribute zu setzen, ist kein Wirksamkeitsnachweis.

Verwechsle dabei nicht zwei unterschiedliche Werte: Im Kontoattribut bedeutet 0x18 AES128 plus AES256. Im Feld Ticket Encryption Type von Event 4769 steht 0x11 für AES128, 0x12 für AES256 und 0x17 für RC4-HMAC. 0x18 bezeichnet dort RC4-HMAC-EXP und ist kein AES-Nachweis.

AES erhöht den Aufwand für Offline-Kennwortprüfungen, macht ein menschlich gewähltes Dienstkennwort aber nicht stark. Die Reihenfolge bleibt: verwaltetes oder langes zufälliges Geheimnis, Least Privilege, AES und Monitoring.

7) Rechte und Anmeldewege pro Dienst begrenzen

Für jedes Konto muss sichtbar sein, was nach einer Kompromittierung tatsächlich möglich wäre. Entferne pauschale Mitgliedschaften in lokalen Administratoren, Server Operators, Backup Operators, Domain Admins und vergleichbaren Gruppen, sofern keine belegte technische Notwendigkeit besteht. Ersetze breite Gruppenrechte durch konkrete Datei-, Datenbank-, Service- oder API-Berechtigungen.

Gewähre Log on as a service oder Log on as a batch job nur auf den vorgesehenen Hosts und nur, wenn der Workload es braucht. Sperre interaktive und RDP-Anmeldung für reine Dienstidentitäten nach einem Anwendungstest. Blockiere Netzwerk-Logon nicht pauschal: Viele Dienste benötigen ihn für Backend-Zugriffe. User-Rights-Assignments haben weitreichende Wirkung und gehören in rollenbezogene GPOs, nicht in eine globale Liste ohne Abhängigkeitsmodell.

Nimm Dienst- und Computerkonten nicht in Protected Users auf: Für Service Accounts kann dadurch die gesamte eingehende Authentifizierung fehlschlagen. Verwende für unterstützte Managed Service Accounts stattdessen pilotierte Authentication Policies und Silos, wenn eine engere Host-Bindung benötigt wird.

8) Ticketnutzung und Kontoänderungen zentral überwachen

Aktiviere auf Domain Controllern die erweiterte Überwachungsrichtlinie Audit Kerberos Service Ticket Operations mindestens für erfolgreiche Vorgänge und sammle Event 4769 zentral. Das Volumen ist hoch; eine bloße Weiterleitung ohne Kapazitäts- und Erkennungsmodell erzeugt Kosten, aber wenig Schutz.

Eine brauchbare Baseline verbindet Anforderer, Client Address, Ziel-SPN, Dienstkonto, Ticket-Verschlüsselung, Zeitpunkt und Häufigkeit. Relevante Abweichungen sind beispielsweise:

  • ein Client fordert in kurzer Zeit Tickets für viele unterschiedliche SPNs an,
  • ein normaler Benutzer oder ein ungewohnter Quellhost fordert ein Ticket für einen besonders wertvollen Dienst an,
  • ein lange ungenutzter SPN erhält wieder Tickets,
  • nach der Migration erscheinen weiterhin Tickets für das alte Konto,
  • Ticket Encryption Type ist trotz Zielbild 0x17,
  • Service-Ticket-Fehler steigen nach einer AES- oder Kontoumstellung,
  • SPNs oder relevante Verschlüsselungsattribute werden außerhalb eines Changes geändert.

Filtere nicht ausschließlich auf RC4. Kerberoasting bleibt mit AES grundsätzlich möglich, und nach der Juli-2026-Härtung wäre eine reine RC4-Regel blind für den größeren Teil der Umgebung. Nutze XML-Feldnamen statt fester Property-Indizes, weil das Schema von 4769 durch neuere Updates erweitert wurde.

Überwache SPNs und msDS-SupportedEncryptionTypes zusätzlich über eine Verzeichnisänderungsüberwachung oder den Change-Feed des eingesetzten Identity-Managements. Event 5136 kann das geänderte Attribut auf Domain Controllern protokollieren, wenn Audit Directory Service Changes aktiviert ist und eine passende SACL auf den betroffenen Objekten greift. Pilotiere SACL und Datenvolumen zuerst; ein fehlendes 5136 beweist ohne diese Voraussetzungen keine unveränderte Konfiguration.

Ergänze auf aktualisierten Domain Controllern die Systemereignisse des KDC-Service im Bereich 201 bis 209. Die Enforcement-Ereignisse 203 und 208 zeigen RC4-only-Clients; 204 und 209 zeigen fehlende AES-Schlüssel am Dienstkonto. 205 weist auf einen explizit unsicheren Domain-Default hin. Sammle bei gemischten Patchständen weiterhin den gesamten Bereich. Die Abwesenheit dieser Ereignisse beweist nicht, dass jede nicht Windows-basierte Integration funktioniert. Reale Anwendungstests bleiben erforderlich.

Defender for Identity oder ein vergleichbares Identity-Threat-Detection-System kann ungewöhnliche SPN-Ermittlung und Ticketmuster ergänzend erkennen. Es ersetzt weder das Service-Account-Inventar noch die zentrale KDC-Telemetrie.

9) Pro Dienst pilotieren und Altbestand kontrolliert stilllegen

Plane keine forestweite Kennwortrotation als ersten Schritt. Baue Ringe nach Anwendungskritikalität und technischer Ähnlichkeit:

  1. dokumentierter, nicht kritischer Windows-Dienst,
  2. repräsentative Anwendung mit mehreren Knoten,
  3. geplante Tasks und Batch-Verarbeitung,
  4. Datenbank-, Backup- und Middleware-Dienste,
  5. geschäftskritische und Tier-0-nahe Identitäten.

Jeder Change prüft Dienststart, Authentifizierung, Backend-Zugriffe, Failover, Tickettyp, Logs, Monitoring und Recovery. Ticket-Caches können den alten Zustand kurzfristig verdecken; teste deshalb mit neu ausgestellten Tickets und nach dem vorgesehenen Neustart.

Halte das Vorgängerkonto nur während des definierten Rollback-Fensters dokumentiert und reaktivierbar; es darf nicht parallel für den Normalbetrieb genutzt werden. Danach werden verbliebene SPNs und Rechte entfernt, das Konto bleibt deaktiviert und wird nach der Aufbewahrungsfrist gelöscht. Ein dauerhaft aktives Vorgängerkonto ist kein Rollback, sondern ein zweiter Angriffsweg.

Vorteile

  • Offline-Kennwortangriffe werden wirtschaftlich unattraktiver: gMSA und lange zufällige Geheimnisse entziehen Wörterbuch- und Musterangriffen die Grundlage.
  • Die mögliche Auswirkung sinkt: Eindeutige Identitäten und Least Privilege begrenzen einen Vorfall auf einen Dienstzweck.
  • Kennwortwechsel werden beherrschbar: Automatische oder getestete Rotation ersetzt jahrelange statische Geheimnisse.
  • SPN-Hygiene verbessert Kerberos insgesamt: Eindeutige Zuordnung reduziert Fehlkonfigurationen und schwer erklärbare Authentifizierungsfehler.
  • AES-Abhängigkeiten werden messbar: Tatsächliche Tickettypen und KDC-Ereignisse zeigen den Zustand statt nur eine Sollkonfiguration.
  • Der Betrieb gewinnt Ownership: Anwendungen, Konten, Hosts, Rechte und Recovery werden konsistent verbunden.
  • Erkennung wird zielgerichteter: Eine bekannte Ticketbaseline macht ungewöhnliche Quellen und Massenanfragen sichtbar.
  • Stilllegung wird möglich: Verwaiste Konten und SPNs können mit Evidenz statt Vermutung entfernt werden.

Nachteile und Grenzen

  • Die Inventarisierung ist arbeitsintensiv: AD-Attribute allein liefern weder Owner noch vollständige Anwendungsabhängigkeiten.
  • gMSA wird nicht von jeder Anwendung unterstützt: Legacy-Produkte, Appliances und bestimmte Deploymentmodelle brauchen einen anderen sicheren Secret-Prozess.
  • Rotation kann Ausfälle verursachen: Nicht aktualisierte Knoten, Tasks, Pools oder Konfigurationsdateien verwenden sonst das alte Geheimnis weiter.
  • AES beseitigt Kerberoasting nicht: Schwache Kennwörter bleiben offline prüfbar; der Aufwand steigt, der Grundmechanismus bleibt.
  • Event 4769 ist sehr volumenstark: Speicherung, Normalisierung und Erkennungslogik müssen geplant werden.
  • Least Privilege kann versteckte Abhängigkeiten aufdecken: Historisch breite Rechte haben oft undokumentierte Nebenfunktionen ermöglicht.
  • SPN-Änderungen sind betriebskritisch: Falsches Entfernen oder Verschieben kann Kerberos sofort stören.
  • gMSA hat eine eigene Schutzgrenze: Zu breite Rechte zum Abruf des verwalteten Kennworts schwächen den Vorteil erheblich.
  • Gemischte DC-Patchstände erschweren den Nachweis: Service-Tickets können je nach kontaktiertem KDC unterschiedlich behandelt werden.
  • Erkennung ist nicht Prävention: Ein Alert auf verdächtige Ticketmuster schützt kein schwaches Dienstkennwort rückwirkend.

Typische Stolperfallen

  • Nur nach Password never expires suchen: Auch Konten ohne dieses Flag können alte oder schwache Geheimnisse haben.
  • Jeden SPN-Benutzer automatisch löschen: Ein scheinbar inaktives Konto kann einen kritischen Dienst betreiben.
  • LastLogonDate als Nutzungsbeweis behandeln: Der Wert ist verzögert und bildet Service-Tickets nicht zuverlässig allein ab.
  • Nur direkte Gruppenmitgliedschaften prüfen: Verschachtelte Gruppen und delegierte ACLs bestimmen oft die eigentliche Auswirkung.
  • gMSA mit Domain Computers zur Kennwortabfrage freigeben: Damit wird die vorgesehene Host-Bindung unnötig breit.
  • Das alte Konto nach Migration aktiv lassen: SPNs, Rechte und statisches Geheimnis bleiben dann als zweiter Pfad bestehen.
  • AES-Checkboxen ohne Kennwortrotation setzen: Dem Konto kann weiterhin das benötigte AES-Schlüsselmaterial fehlen.
  • Attribut-Bitmaske und Ticket-Etype verwechseln: 0x18 hat in beiden Kontexten eine unterschiedliche Bedeutung.
  • Juli 2026 mit vollständigem RC4-Verbot gleichsetzen: Explizite Ausnahmen, unsichere Defaults und ungepatchte DCs müssen weiter geprüft werden.
  • Nur RC4-Tickets alarmieren: AES-Tickets können bei schwachen Kennwörtern ebenfalls relevant sein.
  • Event-Felder nach Position parsen: Updates haben das Schema erweitert; feste Indizes brechen still.
  • Dienst- oder Computerkonten in Protected Users verschieben: Für Service Accounts kann dadurch die gesamte eingehende Authentifizierung fehlschlagen.
  • Netzwerk-Logon pauschal verweigern: Backend-, Datei- oder Datenbankzugriffe können dadurch ausfallen.
  • Kennwortwechsel ohne Neustart- und Cache-Test: Alte Tickets oder laufende Prozesse verschleiern eine unvollständige Umstellung.
  • Ein globaler RC4-Rollback als Recovery: Seit Juli 2026 ist der frühere Rollbackpfad auf aktualisierten DCs entfernt und sicherheitlich ohnehin kein Zielzustand.
  • Owner nur als Freitext pflegen: Ohne verbindlichen Review bei Personal-, Produkt- oder Systemwechsel veraltet die Zuordnung schnell.

Projekt-Checkliste

  • [ ] Alle Benutzerkonten mit SPNs read-only inventarisiert.
  • [ ] gMSA, sMSA, Computerobjekte und nicht Windows-basierte Principals separat erfasst.
  • [ ] Doppelte SPNs forestweit geprüft und einem Owner zugeordnet.
  • [ ] Doppelte SPNs nach Owner- und Abhängigkeitsprüfung bereinigt und Eindeutigkeit nachgewiesen.
  • [ ] Anwendung, Hosts, Umgebung, Starttyp und Recovery pro Dienstidentität dokumentiert.
  • [ ] Fachlicher und technischer Owner mit Review-Termin festgelegt.
  • [ ] Verschachtelte Gruppen, direkte ACLs und lokale Rechte bewertet.
  • [ ] Delegationskonfiguration und Tier-0-Zugriffe geprüft.
  • [ ] Konten nach Geheimnisstärke und möglicher Auswirkung priorisiert.
  • [ ] gMSA-Unterstützung mit Hersteller und realem Diensttyp verifiziert.
  • [ ] KDS Root Key und Replikation vor gMSA-Rollout geprüft.
  • [ ] PrincipalsAllowedToRetrieveManagedPassword auf dedizierte Zielhostgruppe begrenzt.
  • [ ] SPNs am Zielkonto eindeutig registriert.
  • [ ] gMSA auf jedem vorgesehenen Knoten getestet.
  • [ ] Für nicht migrierbare Konten lange zufällige Geheimnisse im Vault erzeugt.
  • [ ] Rotation, Verteilung, Neustart, Test und Rollback technisch erprobt.
  • [ ] Geheimnisse zwischen Diensten und Umgebungen getrennt.
  • [ ] Unnötige privilegierte Gruppen und Verzeichnisrechte entfernt.
  • [ ] Service- und Batch-Anmeldung auf die benötigten Hosts begrenzt.
  • [ ] Interaktive und RDP-Anmeldung nach Kompatibilitätstest gesperrt.
  • [ ] Alle Domain Controller auf Update-Stand ab Juli 2026 gebracht und neu gestartet.
  • [ ] Explizite RC4-Bits an Dienstkonten und unsichere KDC-Defaults geprüft.
  • [ ] Nach AES-Aktivierung alte Kontokennwörter rotiert.
  • [ ] Event 4769 zentral gesammelt und anhand von XML-Feldnamen normalisiert.
  • [ ] Normalbaseline für Anforderer, Quellhost, Ziel-SPN, Tickettyp und Frequenz erstellt.
  • [ ] KDC-Service-Ereignisse 201 bis 209 in das Monitoring aufgenommen.
  • [ ] Alerting nicht ausschließlich auf RC4 ausgerichtet.
  • [ ] SPN- und Verschlüsselungsänderungen außerhalb genehmigter Changes überwacht.
  • [ ] Migration pro Dienst mit frischen Tickets, Failover und Backend-Zugriff getestet.
  • [ ] Alte SPNs und Rechte nach der Beobachtungsphase entfernt.
  • [ ] Vorgängerkonten deaktiviert und für kontrollierte Löschung terminiert.
  • [ ] Befristete Ausnahmen mit Owner, Kompensation, Ablaufdatum und Migrationsplan dokumentiert.
  • [ ] Vierteljährlichen Service-Account- und SPN-Review eingeplant.