Was sich seit April 2026 praktisch ändert

Die Kerberos-RC4-Härtung ist kein abstraktes Kryptothema mehr. Seit den Windows-Sicherheitsupdates vom April 2026 ändert sich das Standardverhalten von Domain Controllern für Konten, bei denen kein expliziter Wert in msDS-SupportedEncryptionTypes gesetzt ist: Der KDC nimmt für diese Konten nicht mehr stillschweigend RC4 als kompatiblen Fallback an, sondern geht in Richtung AES-SHA1.

In sauberen Umgebungen ist das unspektakulär. In gewachsenen ADs kann es aber genau die Systeme treffen, die niemand mehr im Blick hat: alte Service Accounts mit SPNs, technische Benutzer für Drittanbieter-Applikationen, Appliances, Java-/Linux-Stacks, alte IIS-/SQL-/Middleware-Integrationen oder Domänen mit historisch gewachsenen GPO- und Registry-Ausnahmen.

Das Risiko ist zweigeteilt:

  • Sicherheitsrisiko: RC4-basierte Kerberos-Service-Tickets sind ein unnötig schwacher Zielpunkt für Offline-Angriffe gegen Service-Account-Passwörter.
  • Betriebsrisiko: Wenn eine Anwendung faktisch nur RC4 verträgt, kann der Wechsel auf AES zu Authentifizierungsfehlern führen.

Die richtige Reaktion ist deshalb nicht “Registry-Key setzen und weitermachen”, sondern ein kontrollierter Abbau der RC4-Abhängigkeiten.

Welche Systeme zuerst auf die Liste gehören

Priorisiere nicht nach Bauchgefühl, sondern nach Kerberos-Relevanz:

  1. Service Accounts mit SPNs: klassische Treffer für Kerberos-Tickets und damit erste Kandidaten für RC4-Risiko.
  2. Konten ohne gesetztes msDS-SupportedEncryptionTypes: hier greifen die neuen Defaults besonders sichtbar.
  3. Konten mit RC4-only oder DES/RC4-lastiger Konfiguration: technisch und organisatorisch meist Altlast.
  4. Legacy-Applikationen und Appliances: häufig nicht sauber im Windows-Standardbetrieb sichtbar.
  5. Domänen mit manuell gesetztem DefaultDomainSupportedEncTypes: hier muss klar sein, ob die Konfiguration bewusst, sicher und dokumentiert ist.

Wichtig: Ein gesetzter Wert ist nicht automatisch gut. Entscheidend ist, ob AES128/AES256 unterstützt wird und ob RC4 wirklich noch erforderlich ist.

Read-only-Prüfungen, die du sofort fahren kannst

Starte mit einer Bestandsaufnahme der Service Accounts mit SPNs und Encryption-Type-Konfiguration:

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' `
  -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select-Object SamAccountName, Enabled, PasswordLastSet, msDS-SupportedEncryptionTypes, servicePrincipalName

Für Computer- oder gMSA-basierte Dienste entsprechend:

Get-ADServiceAccount -Filter * -Properties msDS-SupportedEncryptionTypes, PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, Enabled, msDS-SupportedEncryptionTypes, PrincipalsAllowedToRetrieveManagedPassword

Auf Domain Controllern solltest du parallel die Kerberos-/KDC-Events auswerten. Ziel ist nicht “ein Logscreen”, sondern eine Liste mit:

  • Konto / SPN
  • Client-System
  • angefragtem Encryption Type
  • Fehlerbild oder Warnung
  • verantwortlichem App-Owner
  • geplanter Remediation

Wenn du bereits ein SIEM hast, ist das ein guter Kandidat für ein temporäres Dashboard: Top-Konten mit RC4-Nutzung, Top-Clients mit Kerberos-Fehlern, Entwicklung pro Tag nach DC-Patching.

Zielbild für die Remediation

Ein sauberes Zielbild sieht so aus:

  • Service Accounts unterstützen AES128 und AES256.
  • RC4 ist nicht mehr stiller Fallback für “unbekannte” Konten.
  • Service-Account-Passwörter wurden nach Encryption-Type-Anpassungen kontrolliert rotiert, wenn nötig.
  • gMSA wird für geeignete Windows-Dienste bevorzugt.
  • Ausnahmen sind zeitlich begrenzt, einem Owner zugeordnet und im Risiko akzeptiert.

Der wichtigste Punkt aus Projektsicht: Encryption Types und Passwortmaterial hängen zusammen. Wenn ein Konto historisch nur RC4 genutzt hat, reicht ein Attributwechsel nicht in jedem Fall als saubere Maßnahme. Plane Passwortrotation, Service-Restarts und App-Tests ein.

Rollout ohne Überraschungen

Ein belastbarer Ablauf:

  1. DC-Patchstand klären: Welche Domain Controller haben Januar-/April-2026-Updates? Gibt es Sites, die hinterherlaufen?
  2. Audit-Daten sammeln: mindestens mehrere Business-Zyklen, nicht nur eine Stunde am Vormittag.
  3. SPN-Konten klassifizieren: Business-kritisch, technisch unklar, eindeutig modern, eindeutig Legacy.
  4. Pilotgruppe festlegen: wenige gut betreute Anwendungen, deren Owner erreichbar sind.
  5. AES aktivieren und testen: erst in kontrollierten Gruppen, danach breiter.
  6. Passwörter rotieren: vor allem bei privilegierten oder lange nicht geänderten Service Accounts.
  7. Monitoring nachziehen: Kerberos-Fehler, Helpdesk-Tickets und App-Logs korrelieren.

Bei größeren Umgebungen lohnt sich ein Change-Fenster pro Applikationscluster statt ein globaler “Kerberos-Tag”. Kerberos-Probleme sehen auf den ersten Blick oft wie App-, DNS-, Zeit- oder SPN-Probleme aus. Ohne Owner und Tests wird Ursachenanalyse unnötig teuer.

Was du nicht als Dauerlösung planen solltest

Temporäre Kompatibilitätshebel können beim Stabilisieren helfen, ersetzen aber keine Remediation. Kritisch sind vor allem:

  • RC4 wieder pauschal als Default zu erlauben.
  • msDS-SupportedEncryptionTypes blind massenhaft zu setzen.
  • Service Accounts ohne Passwortrotation weiterlaufen zu lassen.
  • Ausnahmen ohne Ablaufdatum zu dokumentieren.
  • Nicht-Windows-Systeme nur über AD-Attribute zu bewerten, ohne echte Authentifizierungstests.

Das Fehlen von Warn-Events ist ebenfalls kein belastbarer Freibrief. Manche Nicht-Windows- oder Appliance-Szenarien fallen erst beim konkreten Ticket-Flow auf.

Vorteile der Umstellung

  • Reduziert Kerberoasting-Risiko, weil RC4-basierte Service-Tickets aus der Fläche verschwinden.
  • Erzwingt Service-Account-Hygiene, inklusive SPN-Inventar und Passwortrotation.
  • Verbessert Betriebswissen, weil App-Owner, SPNs und technische Konten wieder sauber zugeordnet werden.
  • Bereitet die Juli-2026-Phase vor, in der temporäre Audit-/Rollback-Mechaniken weiter an Bedeutung verlieren.

Nachteile und Grenzen

  • Legacy-Bruchstellen sind real: alte Appliances, Middleware oder Drittanbieterprodukte können AES nicht sauber nutzen.
  • Attributänderungen sind nicht genug: ohne Test, Passwortrotation und Service-Neustart bleibt der Zustand oft unklar.
  • Monitoring ist verteilt: DC-Events, App-Logs, SIEM und Helpdesk müssen zusammen betrachtet werden.
  • Ausnahmen bleiben Angriffsfläche: jedes RC4-abhängige Konto ist ein bewusst akzeptiertes Risiko.

Projekt-Checkliste

  • [ ] Alle Domain Controller auf Patchstand und Kerberos-Härtungsphase geprüft.
  • [ ] SPN-Konten, gMSAs und technische Benutzer inventarisiert.
  • [ ] msDS-SupportedEncryptionTypes nach “fehlend”, “AES-fähig”, “RC4-only” und “unklar” gruppiert.
  • [ ] Kerberos-/KDC-Events zentral gesammelt und nach Konto, Client und SPN ausgewertet.
  • [ ] App-Owner für kritische Service Accounts benannt.
  • [ ] Pilot-Cutover mit Rollback-Plan und Monitoring durchgeführt.
  • [ ] Passwortrotation für betroffene Service Accounts geplant oder abgeschlossen.
  • [ ] Temporäre RC4-Ausnahmen mit Ablaufdatum dokumentiert.
  • [ ] Juli-2026-Readiness als eigener Meilenstein im AD-Hardening-Backlog geführt.