RC4- und AD-Migration: Entdecken Sie die in Ihrer Quelldomäne verborgenen Fehlerfälle

Stellen Sie sich Folgendes vor.

Bei einer routinemäßigen Active-Directory-Migration scheint alles reibungslos zu verlaufen. Ein Dienstkonto wird problemlos von einer Quelldomäne in eine Zieldomäne verschoben. Die Berechtigungen scheinen korrekt zu sein. Die Gruppenzugehörigkeiten sind intakt. Die SID-Historie bleibt erhalten.

Eine Woche später treten dann bei der Anwendung hinter diesem Konto zeitweise Störungen auf. Bis jemand den Zusammenhang zwischen den Störungen und der Migration herstellt, hat der Helpdesk bereits 40 offene Tickets. Und niemand kann sich das erklären.

Was hat sich geändert? Das Konto verfügte im Quellsystem über reine RC4-Kerberos-Schlüssel. Die Standard-Migrationswerkzeuge kopierten den NTLM-Hash. Die Zieldomäne – neu eingerichtet, mit den neuesten Patches und den Standard-AES-Einstellungen – verfügt über keine AES-Schlüssel für dieses Konto.

Und nach dem 14. April 2026 greifen aktualisierte DCs bei Konten ohne explizite RC4-Konfiguration nicht mehr implizit auf die RC4-Verschlüsselung zurück. Die Authentifizierung wird einfach unterbrochen.

Falls Sie ein Projekt zur Migration, Konsolidierung oder vertrauensbasierten Identitätsverwaltung in Active Directory durchführen, das über den Stichtag für die Durchsetzung im Juli 2026 (RC4) hinausgeht, besteht dieses Risiko möglicherweise bereits in Ihrer Umgebung.

Im Blog „So überprüfen Sie Ihre Umgebung auf RC4-Verschlüsselung“stellen meine Kollegen Guido Grillenmeier und Rich Peckham Beispielabfragen zur Verfügung, die Sie als Vorlagen verwenden können, um Ihre Umgebung zu überprüfen und RC4-abhängige Konten zu identifizieren.

Was Sie jetzt brauchen, ist ein Aktionsplan, der Ihnen hilft, diese potenziellen Kontoausfälle zu vermeiden.

Was Sie in diesem Beitrag erfahren werden

• Wo es am ehesten zu Migrationsfehlern im Zusammenhang mit RC4 kommt
• Welche Arten von Störungen auftreten können – und worauf Sie achten sollten
• So beurteilen Sie Ihre Umgebung systematisch und decken Konten auf, bei denen die Gefahr eines Ausfalls besteht
• Welche kostenlosen Tools können Ihnen bei Ihrer Recherche helfen?
• Maßnahmen, die Sie jetzt ergreifen sollten, um der Umstellung auf AES einen Schritt voraus zu sein

Warum sind Migrationsprojekte in besonderem Maße von Änderungen an RC4 betroffen?

Der Zeitplan für die Einstellung von RC4 ist gut dokumentiert.

• Januar 2026: Microsoft führte die Protokollierung ein und die RC4DefaultDisablementPhase Registrierungsschlüssel.
• April 2026: Microsoft hat die KDC-Standardeinstellung für Konten, die nicht über die msDS-SupportedEncryptionTypes Das Attribut wurde explizit festgelegt.
• Juli 2026: Microsoft entfernt den Überwachungsmodus und berücksichtigt die RC4DefaultDisablementPhase die Registrierungsschlüssel vollständig zurückgesetzt werden, sodass nur noch Konten mit expliziten RC4-Ausnahmen weiterhin RC4-Tickets empfangen können.

Der Beitrag von Semperis zum Audit-Walkthrough behandelt die Erfassung im Normalbetrieb ausführlich. Was dieser Walkthrough jedoch nicht behandelt, ist das Migrationsszenario, in dem sich das Risiko auf drei spezifische Arten zeigt:

• Bei Migrationen werden Konten über Sicherheitsgrenzen hinweg verschoben. Ein Konto, das sich heute in der Quelle erfolgreich authentifiziert, kann in dem Moment, in dem es in einer Zielumgebung mit strengeren Sicherheitsrichtlinien landet, fehlschlagen – selbst wenn die Sicherheitsrichtlinien in der Quelle eher locker sind.
  
• Migrationswerkzeuge behandeln Anmeldedaten auf unterschiedliche Weise. Standardmäßige Migrationswerkzeuge kopieren den NTLM-Hash, jedoch nicht die AES-Schlüssel. In Teil 4 der AD-Hardening-Reihe von Microsoft wird dies klar zum Ausdruck gebracht: Wenn die Zieldomäne RC4 nicht unterstützt, müssen Sie das Kennwort des Kontos in der Zieldomäne zurücksetzen, damit Kerberos funktioniert. Dies gilt für jedes Konto, dessen Schlüssel auf der Quellseite ausschließlich auf RC4 basieren.
  
• Die Fehler treten unbemerkt auf. RC4-Abhängigkeiten im stationären Zustand werden als KDCSVC-Ereignisse 201–209 gemeldet. Durch die Migration verursachte Fehler tun dies oft nicht. Stattdessen zeigen sie sich als Anwendungsfehler ohne offensichtlichen Bezug zur Verschlüsselungsart. Die Ursache muss logisch hergeleitet werden und lässt sich nicht direkt beobachten.

In ihrer Gesamtheit führen diese Faktoren dazu, dass eine einzelne PowerShell-Abfrage nicht ausreicht. Migrationsteams benötigen einen strukturierten Erfassungsprozess.

Welche Konten sind von Migrationsfehlern im Zusammenhang mit RC4 betroffen?

Bevor wir fortfahren, zunächst eine Einschätzung: Die Patches vom April 2026 wurden ohne die von einigen Branchenberichten erwarteten weitreichenden Störungen bereitgestellt – zumindest nach unseren Beobachtungen in der Praxis. In den meisten Kundenumgebungen bleibt die konfigurierte Kerberos-Verschlüsselung erhalten, und die Authentifizierung funktioniert weiterhin wie gewohnt.

In diesem Beitrag wird nicht behauptet, dass der Himmel einstürzt.
Vielmehr wird darin dargelegt, dass ein bestimmter, identifizierbarer Fehlermodus weiterhin besteht – und dass Migrationsumstellungen genau die Ereignisse sind, bei denen dieser am ehesten zutage tritt.

Drei Umstände, die ein Konto gefährden

Unauffällige Fehler bei der RC4-Migration treten in der Regel dann auf, wenn alle drei der folgenden Bedingungen zutreffen:

• AES angegeben, aber nicht geliefert. Das Konto msDS-SupportedEncryptionTypes Das Attribut wird mit AES-Bits gefüllt oder ist null, wobei die Domänenvoreinstellung auf AES gesetzt ist. Das KDC interpretiert dies als „AES wird unterstützt“ und versucht, AES-Tickets für das Konto auszustellen.
  
• Im Zielsystem ist kein AES-Schlüsselmaterial vorhanden. AES-Schlüssel werden nur generiert, wenn in einer DFL 2008-Umgebung oder höher ein Passwort festgelegt wurde. Die Konten mit dem höchsten Risiko sind alte, nie zurückgesetzte Konten sowie migrierte Konten, bei denen die Anmeldedaten kopiert wurden, ohne dass neue AES-Schlüssel generiert wurden. Das Attribut gibt „AES“ an; die Schlüssel weisen jedoch nur RC4 auf.
  
• Das Konto führt eine aktive Authentifizierung über Kerberos durch. Der Fehler tritt erst dann zutage, wenn das Konto ein Kerberos-Ticket anfordert. In diesem Moment versucht der KDC, AES auszuführen (gemäß Bedingung 1), findet jedoch keinen AES-Schlüssel (gemäß Bedingung 2), woraufhin die Authentifizierung fehlschlägt. Inaktive Konten und Konten, die sich ausschließlich über NTLM authentifizieren, bleiben unentdeckt, da der fehlerhafte Zustand nie zum Tragen kommt.

Welche Kontotypen sind am stärksten gefährdet?

In den meisten Unternehmen ist die Gruppe der risikobehafteten Konten nicht zufällig verteilt. Sie konzentriert sich in der Regel auf fünf Kontotypen – genau diese Kategorien sollten in jedem Gespräch zur Projektplanung vor der Migration thematisiert werden.

• Alte Dienstkonten aus der ersten Active-Directory-Bereitstellung, die zwischen 2000 und 2010 angelegt und nie aktualisiert wurden. Diese stellen den mit Abstand häufigsten Eintrag in der Risikogruppe dar.
• Konten bei PASSWD_CANT_CHANGE oder DONT_EXPIRE_PASSWORD UAC-Flags sind gesetzt. Diese Flags stehen in engem Zusammenhang mit Passwörtern, die bei der Bereitstellung einmalig festgelegt und nie geändert wurden.
• Nicht-Windows-Systeme mit lokal gespeicherten Kerberos-Anmeldedaten – Linux-Hosts mit Keytab-Dateien, Java-Anwendungsserver mit fest codierten krb5.conf, der Domäne angeschlossene NAS-Geräte, Netzwerkgeräte mit zwischengespeicherten Anmeldedaten.
• Dienstkonten, die ehemaligen Administratoren gehörten, für die zwar Anmeldedaten vorliegen, bei denen jedoch das institutionelle Wissen darüber, was von diesem Konto abhängt, verloren gegangen ist.
• Computerkonten, bei denen die automatische Passwortänderung nicht funktioniert hat – seit langem offline befindliche Rechner, verwaisten Konten, Konten mit PasswordNeverExpires falsch eingestellt.

Wie viele Konten sind bei einer AD-Migration im Durchschnitt von RC4 betroffen?

Aufgrund der praktischen Erfahrungen aus verschiedenen Migrationsprojekten liegt die Anzahl der gefährdeten Konten in einer bestimmten Umgebung in der Regel innerhalb dieser Spannen.

Umgebungstyp	Durchschnittliche Risikogruppe
Nach 2010 eingerichtete Greenfield-Umgebungen mit strenger Identitätsverwaltung	0–10 Konten
Ein typisches mittelständisches bis großes Unternehmen mit einer mindestens zehnjährigen AD-Geschichte	20–200 Konten
Umgebungen, die durch Fusionen und Übernahmen entstanden sind, ohne dass anschließend eine Identitätskonsolidierung erfolgte	Mehrere Hundert bis einige Tausend
Übernommene Umgebungen, in denen die übernehmende Organisation die Identitätsbereinigung noch nicht abgeschlossen hat	Sehr stark schwankend, manchmal über dem M&A-Bereich liegend

HINWEIS: Hierbei handelt es sich um Anhaltspunkte für die Einstufung von Gesprächen, nicht um Messwerte. Die tatsächliche Zielgruppe lässt sich erst durch die Analysearbeit bestätigen, die wir gemeinsam durchführen werden.

Warum die Umstellung bei der AD-Migration das Risiko konzentriert

Diese RC4-abhängigen Konten können in der Produktionsumgebung jahrelang ohne Ausfälle bestehen bleiben. Ihre Kerberos-Authentifizierung stützt sich auf zwischengespeicherte Tickets und seltene erneute Authentifizierungen, wodurch die fehlenden AES-Schlüssel im normalen Betrieb nicht auffallen.

Die Umstellung im Rahmen der Migration ändert dies. Sie macht zwischengespeicherte Anmeldedaten für die gesamte Benutzergruppe gleichzeitig ungültig, erzwingt innerhalb eines kurzen Zeitfensters neue AS-REQs und TGS-REQs und bringt den Fehlermodus genau in dem Moment zum Vorschein, in dem das Wissen der Verantwortlichen bereits veraltet ist und die Ursachenanalyse am schwierigsten ist.

Die beiden Fehlerarten, nach denen Sie suchen

Bevor wir uns mit der Ermittlungsmethodik befassen, ist es hilfreich, die beiden unterschiedlichen Kategorien von Ausfallrisiken zu benennen, die Sie aufdecken möchten.

• Latente Konfigurationsabweichungen. Konten, die heute noch einwandfrei erscheinen, bei einer Durchsetzung jedoch versagen würden – die oben definierte Risikogruppe. Die AD-Attribute sagen das eine, das tatsächliche Schlüsselmaterial hingegen etwas anderes. Dies lässt sich nicht erkennen, wenn man lediglich die AD-Attribute abfragt.
  
• Risiko im Zusammenhang mit Migrationsmechanismen. Fehler, die speziell auf die Art und Weise zurückzuführen sind, wie die Migration Identitätsdaten überträgt. Diese treten in der Telemetrie im Normalbetrieb auf keiner der beiden Seiten auf und umfassen:
  • SID-Abhängigkeiten
  • Szenarien mit doppeltem Betrieb, bei denen sich dieselbe logische Identität in beiden Bereichen authentifiziert
  • Der DFL-Wert liegt unter dem Wert von 2008 (wird bei jeder Passwortzurücksetzung nach der Migration unbemerkt überschritten)
  • Nicht übereinstimmende Vertrauensattribute.

Für beide Kategorien sind Nachweise erforderlich. Keine davon lässt sich zuverlässig mit Tools ermitteln, die nur eine Signalquelle berücksichtigen.

So bereiten Sie sich auf die Umstellung von RC4 auf AES vor: Eine sechsstufige Methodik zur Ermittlung des Migrationsbedarfs

Wenn Sie den Kontext kennen, in dem Ihre RC4-abhängigen Konten betrieben werden – und die möglichen Fehlerarten, auf die Sie stoßen könnten –, erhalten Sie einen Rahmen, an dem Sie sich orientieren können, während Sie diese Konten ausfindig machen und für AES konfigurieren.

Dies ist die praxiserprobte Vorgehensweise, die wir bei Migrationsprojekten mit unseren Kunden anwenden. In jeder Phase werden Erkenntnisse gewonnen, die in die abschließende Matrix der Ausfallszenarien einfließen.

Phase 0: Schaffung der Rahmenbedingungen

Bevor Sie nach Problemen suchen, sollten Sie sowohl die Quell- als auch die Zielumgebung dokumentieren. Eine Asymmetrie zwischen beiden stellt an sich bereits eine wesentliche Risikoquelle dar.

Erfassen Sie für jede Domain Folgendes:

• Funktionsstufe „Wald“ und „Gebiet“
• Betriebssystemversion jedes DC
• Aktuellstes kumulatives Update
• Der Wert von RC4DefaultDisablementPhase auf jedem domain controller DC)

Es kann sein, dass einige DCs nicht über RC4DefaultDisablementPhase oder DefaultDomainSupportedEncTypes überhaupt nicht festgelegt. Das bedeutet in der Regel, dass die Einstellung nicht explizit konfiguriert wurde und der DC seinem aktuellen Standardverhalten für das jeweilige Betriebssystem und den jeweiligen Patch-Stand folgt.

Entscheidend ist nun, ob dieses effektive Verhalten domänenübergreifend sowie zwischen Ausgangs- und Zielsprache konsistent ist.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Achten Sie auf Asymmetrien: Wenn eine Quelldomäne mit DFL 2003 und noch nicht festgelegter Phase mit einer Zieldomäne mit DFL 2016 gekoppelt ist, die sich bereits in Phase 2 befindet, führt dies dazu, dass jedes migrierte Konto, für das keine AES-Schlüssel vorliegen, bei der Umstellung ausfällt.

Bitte beachten Sie: Alle DCs, auf denen Server 2012 oder 2012 R2 mit abgelaufener ESU läuft, erhalten die Patches vom Juli 2026 nicht und stellen unumgängliche RC4-Quellen dar.

Falls die Registrierungsschlüssel fehlen: Überprüfen Sie die Betriebssystemversion und den Patch-Stand des Domänencontrollers sowie, ob andere Domänencontroller in derselben Domäne eindeutige Werte aufweisen. Das Warnsignal ist nicht das Fehlen des Schlüssels an sich, sondern eine uneinheitliche Umgebung, in der sich einige Domänencontroller effektiv in einem bestimmten Verhaltenszustand befinden, andere hingegen in einem anderen.

Behandeln Sie Abweichungen zwischen Quell- und Zielsystem als Risikosignal: Fehlende Schlüssel im Quellsystem in Verbindung mit expliziten Phaseneinstellungen im Zielsystem oder Null-Standardwerte auf der einen Seite und explizite RC4-Ausnahmen auf der anderen Seite sind genau jene Kombinationen, die Probleme bei der Migration bis zur Umstellung verbergen.

Dokumentieren Sie die Migrationsvertrauensstellung: Eine Treuhandgesellschaft mit msDS-SupportedEncryptionTypes Die Einstellung auf 0x4 (nur RC4) stellt einen garantierten Bruchpunkt im Juli 2026 dar. Eine Vertrauensinstanz mit dem Attribut „null“ folgt dem neueren AES-Standardverhalten und ist weitaus weniger wahrscheinlich als Bruchpunkt als eine Vertrauensinstanz, die explizit auf RC4 festgelegt ist.

Phase 1: Überprüfen Sie, ob beide Domänen den RC4-Datenverkehr empfangen können

Was nicht protokolliert wird, lässt sich nicht finden. Überprüfen Sie die Kerberos-Protokollierung auf jedem Domänencontroller in beiden Domänen:

      auditpol /get /subcategory:"Kerberos-Authentifizierungsdienst"
auditpol /get /subcategory:"Kerberos-Dienstticket-Vorgänge"

Beide sollten sowohl Erfolge als auch Fehler melden. Ist dies nicht der Fall , wenden Sie das standardmäßige Kerberos-Überwachungs-GPO (Group Policy ) auf die Organisationseinheit (OU) Domain Controlleran, bevor Sie fortfahren.

Auf Domänencontrollern, die auf den Stand Januar 2026 oder später aktualisiert wurden, sollten im Systemprotokoll auch die KDCSVC-Ereignisse 201–209 erfasst werden. Das vollständige Fehlen dieser Ereignisse in einer Umgebung mit bekannten Legacy-Anwendungen deutet in der Regel eher auf eine Lücke in der Protokollierung als auf eine saubere Umgebung hin. Überprüfen Sie daher die Installation der Patches und die Erfassung der Protokolle, bevor Sie davon ausgehen, dass keine RC4-Sicherheitslücke vorliegt.

Achten Sie auch auf eingeschränkte Sichtbarkeit: Wenn die Überwachung auf einigen Domänencontrollern aktiviert ist, auf anderen jedoch nicht, wenn Ereignisse nur aus einem Teil der Infrastruktur weitergeleitet werden oder wenn die Aufbewahrungsfristen zu kurz sind, um selten genutzte Dienstkonten zu erfassen.

Phase 2: Erkennung der Konfigurationsebene

In dieser Phase werden Ausfallszenarien ermittelt, die allein anhand von AD-Attributen erkennbar sind. Der schnellste Weg ist die Open-Source-Lösung RC4-ADAssessment PowerShell-Modul, das auf beiden Domänen ausgeführt wird:

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

Dieses Modul erfasst:

• Konfiguration der Gleichstromverschlüsselung
• Vertrauensverschlüsselung
• KRBTGT-Passwortalter
• Jedes Dienstkonto, das als „nur RC4“ oder „DES-fähig“ gekennzeichnet ist
• Konten bei der USE_DES_KEY_ONLY UAC-Flag
• Konten mit expliziten RC4-Ausnahmen
• Konten mit veralteten Passwörtern

Jeder Befund wird mit direkt integrierten Behebungsbefehlen zum Kopieren und Einfügen exportiert. Betrachten Sie die Ausgabe eher als eine nach Priorität geordnete Kandidatenliste denn als endgültigen Beweis. Phase 2 gibt Ihnen Hinweise darauf, wo Sie nachforschen sollten, doch erst die Ereignisdaten und der Anwendungskontext bestätigen ein tatsächliches Szenario für einen Migrationsfehler.

Achten Sie besonders auf Dienstkonten, deren PasswordLastSet stammt aus der Zeit vor dem DFL-Upgrade der Quelldomäne auf 2008. Es handelt sich hierbei um Kandidaten mit hoher Priorität aus der oben definierten Risikogruppe, die anhand von Ereignisdaten und Migrationsverläufen überprüft werden sollten.

Phase 3: Erforschung des Verhaltens

Die Konfiguration gibt an, was zulässig ist. Ereignisse zeigen, was tatsächlich geschieht. Oft stimmen diese beiden Angaben nicht überein.

Führen Sie die Überprüfung mit aktivierter Ereignisprotokollanalyse durch oder fragen Sie Sentinel oder Splunk direkt ab:

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

Das besonders aussagekräftige Ergebnis ist die Korrelation zwischen der Konfiguration für AES und der tatsächlichen Verwendung von RC4: Konten, bei denen AD angibt, „AES zu unterstützen“, während die Ereignisprotokolle zeigen, dass RC4-Tickets ausgestellt werden. Genau diese Diskrepanz ist der Fehlermodus, der während der Migration zutage treten wird.

Insbesondere bei Migrationsprojekten sollten Sie auch TGS-Anfragen zwischen verschiedenen Realms abrufen. Suchen Sie in 4769 Ereignissen nach Service-Tickets, bei denen ServiceName befindet sich in einer anderen Welt und TicketEncryptionType beträgt 0x17. Der realmübergreifende RC4-Datenverkehr dient als Frühwarnindikator für Fehler im Migrationsvertrauenspfad bei der Durchsetzung, und selbst bei wenigen Feststellungen ist eine direkte Untersuchung erforderlich, da die betroffene Anwendung geschäftskritisch sein könnte.

Achten Sie auch auf Dienstkonten, die sich nur während Batch-Fenstern, bei der Monatsabschlussverarbeitung oder bei geplanten Aufgaben authentifizieren; diese können in kurzen Erfassungsfenstern leicht übersehen werden und sorgen oft für die unangenehmsten Überraschungen bei der Umstellung.

Phase 4: Erkennung auf Anwendungsebene

Genau hier scheitern die meisten Migrationen, und genau hier bieten AD-kompatible Tools die geringste Transparenz.

Überprüfen Sie jeden Linux-, Java- und Netzwerk-Appliance-Host, der AD-basiertes Kerberos verwendet.

Bestandsaufnahme der Keytab-Dateien; alles, was nur arcfour-hmac Die Einträge sind RC4-verschlüsselt. Es ist davon auszugehen, dass zumindest einige Nicht-Windows-Systeme noch immer Keytabs verwenden, die vor Jahren erstellt wurden.

Überprüfen /etc/krb5.conf für fest codierte default_tkt_enctypes oder permitted_enctypes wobei nur RC4 aufgeführt ist. Beide werden nach Juli 2026 nicht mehr funktionieren, unabhängig davon, was AD unternimmt – und die Neuanpassung des Keytabs an die Ziel-Realm erfordert, dass das migrierte Konto über AES-Schlüssel verfügt, was uns wieder zu den Erkenntnissen aus Phase 2 zurückführt.

Führen Sie den Verantwortlichen bei jeder Anwendung, die die Kerberos-Authentifizierung nutzt, durch folgende Schritte:

• Das derzeit verwendete Dienstkonto und dessen msDS-SupportedEncryptionTypes Wert
• Wo die Anwendung gehostet wird
• Ob ein Keytab verwendet wird und wann es erstellt wurde
• Ob in den Herstellerunterlagen die erforderlichen Kerberos-Verschlüsselungsarten angegeben sind
• Ob die Vorabauthentifizierung RC4-gebunden ist

Rechnen Sie mit Lücken in der Dokumentation. Viele Betreiber wissen nicht, wann das Keytab erstellt wurde oder ob der Anbieter AES ordnungsgemäß unterstützt, und diese Ungewissheit ist an sich schon ein nützlicher Risikoindikator.

Überprüfen Sie außerdem, ob an Stellen, die von der AD-Attributermittlung nicht erfasst werden, fest codierte Verschlüsselungskonfigurationen vorhanden sind:

• Die Network security: Configure encryption types allowed for Kerberos GPO-Einstellung
• Verknüpfte SQL Server-Server
• IIS-Anwendungspool-Identitäten mit veralteten Passwörtern
• Java-Anwendungen mit -Dsun.security.krb5.permitted_enctypes JVM-Flags

Phase 5: Migrationsspezifische Risiken

Die in dieser Phase auftretenden Störungsszenarien treten ausschließlich während der Umstellung auf das neue System auf. Sie sind eher auf den Migrationsmechanismus zurückzuführen als auf eine der beiden Domänen im Normalbetrieb.

Erfassen Sie die Passwortverwaltung Ihres Migrationstools. Wenn das Tool Passwörter kopiert, werden alle vorhandenen Anmeldedaten übernommen. Ein Konto, das im Quellsystem ausschließlich RC4-Schlüssel enthält, wird im Zielsystem ebenfalls nur mit RC4-Schlüsseln übernommen. Die übliche Abhilfemaßnahme – die erzwungene Passwortzurücksetzung nach der Migration – kann zu Ausfällen abhängiger Dienste führen, wenn die Anwendung gerade ausgeführt wird.

Für jedes Dienstkonto ist ein dokumentierter Plan für die Zurücksetzung nach der Migration mit einem Wartungsfenster erforderlich.

Bewerten Sie Ansätze zur Passwortsynchronisierung objektiv. Einige Migrationswerkzeuge bieten Filter für die Passwortsynchronisierung an, die Änderungen auf den Quell-Domänencontrollern erfassen und auf dem Ziel wiedergeben. Diese lösen zwar das Problem der AES-Schlüsselgenerierung auf dem Ziel – jedoch:

• Richten Sie einen privilegierten Codepfad auf den Quell-Domänencontrollern ein
• Klartext vorübergehend im Speicher offenlegen
• Nur bei Passwortänderungen auslösen (inaktive Konten und Service-Konten ohne Passwortwechsel werden dabei vollständig außer Acht gelassen)
• Es besteht ein Betriebsrisiko, falls der Filter ohne Vorwarnung ausfällt

Der Einsatz solcher Werkzeuge ist in begrenzten Koexistenzfenstern, in denen die Kompromisse dokumentiert und akzeptiert sind, durchaus legitim – stellt jedoch keinen Ersatz für die oben beschriebene Ermittlungsarbeit dar.

Erfassen Sie Szenarien mit doppelter Ausführung. Während des Migrationsfensters können Benutzer und Dienste sowohl in der Quell- als auch in der Zielumgebung vorhanden sein. Ermitteln Sie Fälle, in denen sich dieselbe logische Identität von beiden Seiten aus authentifiziert – typischerweise über domänenübergreifende Vertrauensstellungen, Verbundkonfigurationen oder einen synchronisierten Entra ID-Mandanten.

Jede dieser Stellen stellt eine potenzielle Schwachstelle dar, da die Verschlüsselungsaushandlung von Seite zu Seite unterschiedlich ist.

Erfassen Sie die Abhängigkeiten der SID-Historie. Die SID -Historie gewährleistet den Zugriff auf Ressourcen; die Verschlüsselungsschlüssel sind jedoch unabhängig davon. Eine Anwendung, die die Autorisierung über die SID-Historie vornimmt, Tickets jedoch über die Schlüssel des Zielkontos ausstellt, kann fehlschlagen, wenn diese Schlüssel ausschließlich RC4 unterstützen.

Stellen Sie sicher, dass die Ziel-DFL mindestens 2008 beträgt. Bei Konsolidierungen, die erworbene Umgebungen betreffen, liegt die Ziel-DFL manchmal unter dem erwarteten Wert. Unterhalb der DFL 2008 werden bei Passwortzurücksetzungen keine AES-Schlüssel generiert, sodass der gesamte Plan für die Passwortzurücksetzung nach der Migration stillschweigend fehlschlägt. Überprüfen Sie dies vor der Umstellung, nicht währenddessen.

Das eigentliche Risiko in dieser Phase liegt in der Kombination verschiedener Faktoren, nicht in einzelnen Fakten. Zum Beispiel:

• Migrationen mit Passwortkopie ohne dokumentiertes Zeitfenster für die Zurücksetzung
• Parallelausführung von Identitäten ohne Prüfung auf Pfad-für-Pfad-Einstimmung
• Die SID-Historie wird als Authentifizierungskorrektur behandelt
• Ein Problem mit dem Ziel-DFL, das erst nach der Umstellung des Pilotprojekts entdeckt wurde

Dies sind die migrationsspezifischen Muster, die aus überschaubaren Befunden Ausfall-Szenarien werden lassen.

Phase 6: Erstellen Sie die Matrix für Ausfallszenarien

Das Ergebnis der ersten fünf Phasen ist keine allgemeine Risikoliste. Es handelt sich um eine Matrize mit Ausfallszenarien: eine Zeile für jede identifizierbare Möglichkeit, wie die Migration fehlschlagen kann. Halten Sie sie kompakt. Erfassen Sie für jede Zeile das Szenario, was es auslöst, wie es sich äußert und welche Maßnahmen vor der Umstellung erforderlich sind.

Die Ergebnisse der Phasen 2, 3 und 4 bilden in der Regel die ersten Zeilen.

In Phase 5 werden die reinen Migrationsszenarien hinzugefügt, die bei der Erfassung im Normalbetrieb nicht berücksichtigt werden.

Sobald diese Matrix ausgefüllt ist, dient sie als Cutover-Tracker und als Grundlage für die Go/No-Go-Entscheidung.

Szenario	Auslöser	Wie sich dies äußert	Maßnahmen vor der Umstellung
Das Dienstkonto wurde mit konfiguriertem AES migriert, es sind jedoch keine AES-Schlüssel vorhanden	Umschaltung oder erste neue Kerberos-Anfrage	Die App-Authentifizierung schlägt nach der Migration fehl; geplante Aufgaben oder Dienste schlagen fehl, sobald zwischengespeicherte Tickets ablaufen	Setzen Sie das Passwort in der Zielumgebung zurück, überprüfen Sie die Generierung des AES-Schlüssels, testen Sie die App erneut und planen Sie die Änderung in einem Wartungsfenster ein
Linux- oder Unix-Host mit einer Keytab, die ausschließlich RC4 unterstützt	Juli 2026: Umsetzung oder Umstellung auf die Zielumgebung	Die Kerberos-Authentifizierung schlägt auf dem Nicht-Windows-Host fehl; der Dienst weicht auf einen Fallback zurück oder wird beendet	Erstellen Sie das Keytab mit AES-fähigen Anmeldedaten neu, nachdem Sie sich vergewissert haben, dass das migrierte Konto über AES-Schlüssel verfügt
Reichsübergreifendes Vertrauen, das explizit an RC4 gebunden ist	Inkrafttreten im Juli 2026	Anfragen für domänenübergreifende Tickets schlagen während der Koexistenz oder des stufenweisen Zugriffs fehl	Entfernen Sie die Einstellung für die ausschließliche RC4-Vertrauenswürdigkeit und überprüfen Sie das Vertrauensverhalten vor der Umstellung anhand von direktem Testdatenverkehr
Zielbereich unterhalb von DFL 2008	Plan für die Wiederherstellung nach der Migration	Das Zurücksetzen des Passworts scheint erfolgreich zu sein, doch es werden keine AES-Schlüssel generiert, und die App stürzt weiterhin ab	Erhöhen Sie den DFL-Zielwert vor der Migration oder überarbeiten Sie den Sanierungsplan vor dem ersten Pilotprojekt
In Java, der Appliance oder der lokalen Kerberos-Konfiguration fest auf RC4 festgelegt	Umstellung, Durchsetzung oder erste Anfrage nach neuen Tickets	Eine App-Ebene fällt aus, obwohl die Einstellungen auf der AD-Seite korrekt erscheinen	Entfernen Sie die RC4-Bindung, überprüfen Sie die Herstellerunterstützung für AES und testen Sie den genauen Anwendungsweg vor der Produktionsumgebung
Identität, die auf zwei Systemen ausgeführt wird und sich bei Quelle und Ziel unterschiedlich authentifiziert	Koexistenzphase oder schrittweise Migrationswelle	Das Zugriffsverhalten variiert je nach Bereich, Host oder Pfad, was zu uneinheitlichen Auswirkungen auf die Benutzer führt	Dokumentieren Sie das Verhalten der einzelnen Pfade, reduzieren Sie Überschneidungen, wo dies möglich ist, und testen Sie den Koexistenzpfad explizit

Was Sie tatsächlich vorfinden werden

Bei Migrationsprojekten lassen sich die Ergebnisse mit dem größten Nutzen in der Regel vier Kategorien zuordnen:

• Dienstkonten, bei denen AES konfiguriert ist, jedoch keine AES-Schlüssel vorhanden sind. Dabei handelt es sich häufig um alte, nie zurückgesetzte Konten oder migrierte Konten, bei denen die Anmeldedaten kopiert wurden, ohne dass neue AES-Schlüssel generiert wurden. Das AD-Attribut liefert hier falsche Angaben. Die Korrelation der Ereignisprotokolle in Phase 3 ist die einzige zuverlässige Methode, um diese Konten zu identifizieren. Sie lassen sich zudem am einfachsten beheben. Ein Passwort-Reset in einer DFL 2008- oder höheren Umgebung generiert die AES-Schlüssel. Zwei aufeinanderfolgende Resets mit einer zeitlichen Verzögerung dazwischen werden manchmal als Maßnahme zur Replikationssicherheit empfohlen.
• Linux-Hosts mit Keytabs, die ausschließlich RC4 verwenden. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL mit GSSAPI – alles gängige Verfahren, die alle Keytabs für die zum Zeitpunkt der Erstellung vorhandenen Verschlüsselungsarten generieren. Die Lösung besteht darin, nach der Migration eine Neuschlüsselung für den Zielbereich durchzuführen; hierfür muss das migrierte Konto jedoch zunächst über AES-Schlüssel verfügen.
• Der DFL der übernommenen Umgebung sorgt für Überraschungen. Wenn das Zielunternehmen das kleinere der beiden übernommenen Unternehmen war oder wenn Konsolidierungen in die falsche Richtung erfolgten, liegt der DFL unter dem Wert von 2008, und niemand bemerkt dies bis zur Umstellung. Überprüfen Sie dies in Phase 0; überprüfen Sie es erneut vor jeder Migrationswelle.
• Trusts mit expliziten RC4-Attributen. Weniger verbreitet als die anderen, aber von großer Bedeutung, wenn vorhanden. Ein Treuhandfonds mit msDS-SupportedEncryptionTypes = 0x4 wird der Migrationsmechanismus selbst fehlschlagen, nicht nur bestimmte Konten.

Sollte die Zeit für die Analyse begrenzt sein, sollten Sie der Korrelation in Phase 3 (AES-konfiguriert, aber RC4 verwendet) sowie der Keytab-Bestandsaufnahme in Phase 4 Vorrang einräumen. Zusammen liefern diese in der Regel 60–80 % der tatsächlichen Liste der geknackten Passwörter.

Hilfsmittel und Ressourcen

Die oben beschriebenen Ermittlungsmaßnahmen lassen sich mithilfe von Open-Source-Tools und nativen AD-Befehlen umsetzen. Nachfolgend finden Sie einige bewährte Ressourcen zur Erkennung und Behebung von RC4-abhängigen Konten; alle sind frei verfügbar.

• Der Semperis RC4-Audit-Leitfaden : So prüfen Sie Ihre Umgebung auf RC4-Verschlüsselung von Guido Grillenmeier und Rich Peckham. KQL- und Splunk-Abfragen im Steady-State-Modus für die Ereignisse 4768 und 4769. (Der Begleitartikel zu diesem Beitrag.)
• Das PowerShell-Modul „RC4-ADAssessment“ von Jan Tiedemann (BetaHydri). Konfigurations- und Ereignisprotokoll-Korrelation domänenübergreifend. Erhältlich in der PowerShell Gallery als Version 4.0.0.
• Das Kerberos-Crypto-Repository von Microsoft. Offizielle PowerShell-Skripte, darunter „Get-KerbEncryptionUsage.ps1“ und „List-AccountKeys.ps1“, vom Windows-Kerberos-Team.
• KB5073381. Die verbindlichen Microsoft-Bereitstellungshinweise zu CVE-2026-20833.
• „RC4-Nutzung in Kerberos erkennen und beheben“ auf Microsoft Learn. Die offizielle Verfahrensanleitung zur umgebungsweiten Erkennung von RC4.
• Jerry DeVores „AD Hardening“-Reihe – Teil 4: Durchsetzung von AES für Kerberos. Die maßgebliche Microsoft-Quelle für Einzelheiten zum Umgang mit Anmeldeinformationen in Migrationswerkzeugen.

Für Unternehmen, die diese Bewertung im Rahmen eines laufenden Migrationsprojekts durchführen, wendet Semperis Professional Services diese Methodik regelmäßig als Vorbereitung auf die Migration an. Die Migrationsgemeinschaft arbeitet zudem aktiv an Ansätzen, die die durch Unterbrechungen für die Benutzer verursachten Kosten bei der Passwortzurücksetzung nach der Migration senken – ein Folgebeitrag wird diese Ansätze behandeln, sobald sie ausgereift sind.

Wo soll ich diese Woche anfangen?

Wenn Sie ein Migrationsprojekt haben, das über den Juli 2026 hinausgeht, und noch nicht mit den Arbeiten begonnen haben, sollten Sie mit diesen vier Schritten beginnen:

• Führen Sie heute Phase 0 durch. Es handelt sich um eine 30-minütige Übung pro Domäne, die die Asymmetrien zwischen DFL und Patch-Status aufzeigt, die für alles andere ausschlaggebend sind.
• Überprüfen Sie die Überwachung in beiden Domänen (Phase 1). Falls diese nicht aktiviert ist, beheben Sie das noch diese Woche. Jeder Tag, an dem Telemetriedaten fehlen, ist ein Tag, an dem ein Ausfallrisiko besteht, das Sie nicht erkennen können.
• Laufen RC4-ADAssessment mit -AnalyzeEventLogs für beide Bereiche (Phasen 2 und 3 zusammen). Die Kategorie „AES-konfiguriert, aber RC4 verwendet“ ist Ihr wertvollster Ergebnis.
• Planen Sie die Begehungen mit den Anwendungsverantwortlichen für Phase 4 ein. Dies ist der größte Zeitfresser. Beginnen Sie jetzt damit und führen Sie sie parallel zu allen anderen Aufgaben durch.

Die Umstellung im Rahmen der Migration und die Durchsetzungsfrist im Juli 2026 sind zwei unterschiedliche Ereignisse. Die Vorbereitungsarbeiten, die Sie auf das eine vorbereiten, bereiten Sie auch auf das andere vor.

Beginnen Sie jetzt, und die von Ihnen erstellte Matrix dient als operativer Leitfaden für beide.

Haben Sie Fragen zu dieser Methodik oder dazu, wie Semperis Sie bei einem laufenden Migrationsprojekt unterstützen kann? Kontaktieren Sie uns – wir helfen Ihnen gerne weiter.