RC4 seit den April-2026-Updates deaktiviert? Temporäre RC4-Freigabe für die NT-Hash-Migration

Microsoft reduziert die Verwendung von RC4 in Kerberos schrittweise, und viele Active-Directory-Umgebungen bewegen sich inzwischen in Richtung reiner AES-Authentifizierung. Das ist eine positive Sicherheitsverbesserung, kann aber bei Projekten zur Passwort- oder Kontomigration ein bestimmtes Kompatibilitätsproblem sichtbar machen.

Wenn nur der NT-Hash eines Benutzerpassworts migriert wird, verfügt das Zielkonto über das Anmeldematerial, das für RC4-kompatible Kerberos-Authentifizierung und NTLM-Authentifizierung erforderlich ist. AES-Kerberos-Schlüssel sind jedoch gesalzen und werden aus dem Klartextpasswort abgeleitet. Sie können nicht allein aus dem NT-Hash neu erstellt werden.

Aus diesem Grund können in Umgebungen, in denen RC4 deaktiviert ist, Authentifizierungsprobleme für migrierte Benutzer auftreten, wenn die Migration ausschließlich auf NT-Hash-Migration basiert. In diesem speziellen Szenario kann für die betroffenen migrierten Benutzerkonten eine temporäre und gezielte RC4-Freigabe erforderlich sein, bis ihre Passwörter geändert oder so synchronisiert wurden, dass gültige AES-Schlüssel in der Zieldomäne erstellt werden.

NT-Hashes sind sensibles Anmeldematerial. Die folgende Anleitung ist nur für kontrollierte Migrationskompatibilitätsfälle gedacht, in denen NT-Hash-Migration tatsächlich erforderlich ist. Sie ist keine allgemeine Sicherheitsempfehlung, keine breite Rücknahme von RC4-Einschränkungen und nicht für AES-only-Migrationspfade gedacht, die Passwortsynchronisierung statt NT-Hash-Migration verwenden. Falls Ihr Migrationsszenario einen Migrationspfad ausschließlich mit AES erfordert, lesen Sie bitte stattdessen den Blogbeitrag „Migrieren von Active Directory-Passwörtern mit deaktiviertem RC4 (Kerberos AES)“.

CopyRight2 Build 727 und neuer: Ein Benutzer-Transformationsskript ist nicht mehr erforderlich, um RC4 bei der Migration von NT-Hashes vorübergehend zuzulassen. Aktivieren Sie stattdessen auf der Seite Settings des User & Group Migration Jobs die Option "Temporarily allow RC4".

Bei älteren CopyRight2-Builds können Sie die unterstützten Kerberos-Verschlüsselungstypen des Zielbenutzers mit folgendem Benutzer-Transformationsskript festlegen:

Destination("msDS-SupportedEncryptionTypes")=60

Dezimal 60 entspricht hexadezimal 0x3C. Dieser Wert umfasst RC4-HMAC, AES128, AES256 und AES-Session-Key-Unterstützung. Praktisch bedeutet das: Das migrierte Konto kann während der temporären NT-Hash-Kompatibilitätsphase weiter funktionieren, indem RC4 zusammen mit den AES-Verschlüsselungsflags explizit erlaubt wird.

Dadurch wird vermieden, dass für das Konto die AES-only-Standardkonfiguration greift, bevor aktuelle AES-Kerberos-Schlüssel verfügbar sind. Mit diesem praktischen Encryption Type Calculator können Sie die Bitmaske der Verschlüsselungstypen visualisieren und sehen oder ändern, welche Optionen aktiviert sind.

Verwenden Sie diese Einstellung nur als gezielte Migrationshilfe. Wenden Sie sie nur auf Benutzer oder Migrationswellen an, die tatsächlich NT-Hash-Migration benötigen, und dokumentieren Sie, auf welche Benutzer sie angewendet wurde. Beziehen Sie, falls zutreffend, die zuständigen Sicherheitsverantwortlichen ein.

Diese Einstellung erstellt keine AES-Schlüssel für das Konto. Eine Passwortänderung, ein Passwort-Reset oder ein Passwortsynchronisierungsereignis ist weiterhin erforderlich, damit die Zieldomäne aktuelle, aus dem Passwort abgeleitete Kerberos-Schlüssel erhält.

Wichtig für SID-History: Das vorübergehende Aktivieren von RC4 ersetzt nicht die Notwendigkeit von AES-Schlüsseln, wenn migrierte Benutzer über SID-History auf Ressourcen zugreifen, die sich weiterhin in der Quelldomäne befinden, in der RC4 deaktiviert ist, ebenso wie in der Zieldomäne nach den Windows-Updates vom April 2026. Hat ein Benutzer der Zieldomäne sein Kennwort seit der Migration noch nicht geändert, verfügt das Konto möglicherweise noch nicht über AES-Schlüssel. Ohne AES-Schlüssel kann die Authentifizierung an der Ressource in der Quelldomäne mit Zugriff verweigert fehlschlagen, obwohl die frühere SID des Benutzers in sIDHistory vorhanden ist und der Benutzer sich aufgrund des vorübergehend aktivierten RC4-Kerberos-Verschlüsselungstyps an der Zieldomäne anmelden kann. Stellen Sie sicher, dass alle betroffenen Benutzer AES-Schlüssel erhalten, bevor sie den Zugriff über SID-History benötigen. Sie können die vorübergehende RC4-Aktivierung mit einer verpflichtenden Kennwortänderung bei der ersten Anmeldung kombinieren. Alternativ können Sie das Password Synchronization Add-On verwenden. Dadurch verfügen migrierte Benutzer bereits bei der ersten Anmeldung über AES-Schlüssel und können ihr bestehendes Kennwort weiterverwenden.

Nach Abschluss des Kompatibilitätszeitraums sollten Sie die temporäre RC4-Freigabe entfernen oder das Konto auf die normale Kerberos-Verschlüsselungsbaseline Ihrer Organisation zurücksetzen. Eine Passwortänderung allein leert das Attribut msDS-SupportedEncryptionTypes nicht und entfernt auch nicht das RC4-Bit, wenn es explizit konfiguriert wurde.

Ein praktikables Vorgehensmodell ist:

1. Identifizieren Sie die Benutzer oder Migrationswellen, die tatsächlich NT-Hash-Migration benötigen.
2. Aktivieren Sie "Temporarily allow RC4" nur für diese Benutzer.
3. Optional können Sie in den Job-Einstellungen erzwingen, dass Benutzer ihr Passwort bei der ersten Anmeldung an der Zieldomäne ändern müssen.
4. Schließen Sie die Migration ab.
5. Wenn Sie die erzwungene Passwortänderung verwenden, stellen Sie sicher, dass sich alle Benutzer mindestens einmal angemeldet und ihr Passwort geändert haben. Alternativ warten Sie, bis das definierte maximale Kennwortalter abgelaufen ist.
6. Entfernen Sie die temporäre RC4-Freigabe oder stellen Sie die normale Verschlüsselungstyp-Baseline wieder her.
7. Dokumentieren Sie die Ausnahme und die Bereinigung, damit die Kompatibilitätseinstellung nicht länger als erforderlich bestehen bleibt.

So bleibt der Migrationspfad verfügbar, ohne dass aus einer eng begrenzten Kompatibilitätsanforderung eine langfristige Sicherheitsausnahme wird.

Weitere produktspezifische Migrationsdetails finden Sie im Password Synchronization & Migration Add-On Administrator Guide. Wenn Sie nicht sicher sind, ob Ihre Umgebung diese Einstellung benötigt, wenden Sie sich an den Sys-Manage Support, bevor Sie Ihren Migrationsplan ändern. Wir können Ihnen helfen zu klären, ob das Problem damit zusammenhängt, dass RC4 für betroffene Active-Directory-/Kerberos-Konten deaktiviert ist, ob NT-Hash-Migration tatsächlich erforderlich ist, ob Passwortsynchronisierung der bessere Ansatz ist und welche Bereinigung nach der Migration geplant werden sollte.