Kerberos RC4 Abschaltung 2026: So sichern Sie Ihre Windows-Infrastruktur rechtzeitig ab

Die Uhr tickt für veraltete Verschlüsselungsprotokolle in Microsoft-Umgebungen. Mit der Ankündigung der endgültigen Kerberos RC4 Abschaltung im Sommer 2026 setzt Microsoft einen entscheidenden Schritt in Richtung einer sichereren Identitätsinfrastruktur. Für IT-Administratoren und Sicherheitsverantwortliche bedeutet dies jedoch: Handeln Sie jetzt.

Das Kerberos RC4-Protokoll (Rivest Cipher 4) ist ein Relikt aus den 90er Jahren. In einer modernen Bedrohungslandschaft stellt es ein signifikantes Sicherheitsrisiko dar, da es anfällig für diverse Angriffsvektoren ist, die es Angreifern ermöglichen könnten, Identitäten zu kompromittieren und sich seitlich durch Ihr Netzwerk zu bewegen.

In diesem umfassenden Leitfaden analysieren wir die Hintergründe der Abschaltung, basierend auf den neuesten Informationen von Microsoft. Wir führen Sie Schritt für Schritt durch den Prozess der Identifizierung von RC4 in Ihrem Netzwerk, zeigen Ihnen, wie Sie die moderne Alternative AES implementieren und welche Voraussetzungen Sie zwingend erfüllen müssen, um einen Systemausfall im Jahr 2026 zu verhindern. Warten Sie nicht bis zur letzten Minute – die Migration erfordert Zeit, Analyse und Sorgfalt.

RC4 zu AES
RC4 zu AES

Warum die Kerberos RC4 Abschaltung notwendig ist

Die Sicherheitsrisiken von RC4

RC4 ist eine Stromchiffre, die für ihre Einfachheit und Geschwindigkeit bekannt war. Doch kryptografische Forschungen haben über die Jahre massive Schwachstellen aufgedeckt. In der Welt von Kerberos bedeutet die Nutzung von RC4, dass die Tickets (TGTs und Service Tickets), die für die Authentifizierung im Netzwerk genutzt werden, mit einem schwachen Algorithmus verschlüsselt sind.

Angreifer können diese Schwäche durch Methoden wie „Kerberoasting“ ausnutzen. Wenn ein Angreifer ein RC4-verschlüsseltes Ticket abfängt, kann er dieses offline extrem schnell knacken („Brute Force“), um an das Passwort des Dienstkontos oder des Benutzers zu gelangen. Microsoft betont in seiner Ankündigung vom Dezember 2025, dass die Entfernung von RC4 nicht mehr optional, sondern essenziell für die Integrität des Active Directory ist.

Der Zeitplan: Sommer 2026

Laut offiziellen Quellen von Microsoft wird die Unterstützung für RC4 in Kerberos-Authentifizierungen mit den Updates im Sommer 2026 standardmäßig deaktiviert und die Nutzung technisch unterbunden. Das bedeutet, dass Systeme, die bis dahin nicht auf AES umgestellt wurden, keine Authentifizierung mehr durchführen können. Dies betrifft:

  • Anmeldungen von Benutzern an Computern.
  • Zugriffe auf Dateiserver und Drucker.
  • Authentifizierungen von Webservern und Datenbanken.
  • Legacy-Applikationen, die fest auf RC4 kodiert sind.

Zwingende Voraussetzungen für die AES-Migration

Bevor Sie technische Maßnahmen ergreifen, müssen Sie sicherstellen, dass Ihre Infrastruktur bereit für den Wechsel von Kerberos RC4 zu AES (Advanced Encryption Standard) ist. AES ist der heutige Goldstandard für Kerberos-Verschlüsselung in Windows.

1. Domain Functional Level (DFL)

Ihre Domänen- und Gesamtstrukturfunktionsebene sollte mindestens auf Windows Server 2008 R2 liegen, idealerweise jedoch auf Windows Server 2016 oder höher. Während AES technisch bereits ab Server 2008 (Vista) unterstützt wird, bieten neuere Funktionsebenen bessere Verwaltungsoptionen und Sicherheitspatches.

2. Client- und Server-Betriebssysteme

Alle beteiligten Geräte müssen AES unterstützen.

  • Unterstützt: Windows Vista / Server 2008 und neuer (inklusive Windows 10, 11, Server 2019, 2022, 2025).
  • Nicht unterstützt: Windows XP, Server 2003 (Diese Systeme sollten sich ohnehin nicht mehr in einem produktiven Netzwerk befinden).

3. Updates und Patches

Stellen Sie sicher, dass alle Domain Controller (DCs) und Clients vollständig gepatcht sind. Microsoft hat in den letzten Jahren mehrere Updates veröffentlicht, die die Logik der Verschlüsselungsaushandlung verbessert haben.

4. Kennwort-Resets (Kritisch)

Ein häufig übersehener Punkt: Der krbtgt-Account (das Konto, das die Kerberos Tickets signiert) muss AES-Schlüssel besitzen. Wenn Ihre Domäne vor langer Zeit erstellt wurde und das Passwort des krbtgt-Kontos nie geändert wurde, fehlen möglicherweise die AES-Schlüssel im Active Directory.

  • Maßnahme: Setzen Sie das Kennwort des krbtgt-Kontos zweimal zurück (um sicherzustellen, dass die Replikation greift und alte Tickets ungültig werden – beachten Sie hierbei die Wartezeit zwischen den Resets).

Anleitung: Prüfung auf Kerberos RC4 Nutzung

Bevor Sie etwas abschalten, müssen Sie wissen, wo es genutzt wird („Audit Phase“). Blindes Abschalten führt fast garantiert zu Ausfällen.

Die wichtigste Informationsquelle ist das Sicherheitsprotokoll (Security Event Log) auf Ihren Domain Controllern.

Nutzung von Event ID 4769

Das Ereignis 4769 („A Kerberos service ticket was requested“) ist Ihr wichtigster Indikator.

So gehen Sie vor:

  1. Öffnen Sie die Ereignisanzeige auf einem Domain Controller.
  2. Navigieren Sie zu Windows-Protokolle -> Sicherheit.
  3. Erstellen Sie eine Benutzerdefinierte Ansicht oder filtern Sie das aktuelle Protokoll.
  4. Filtern Sie nach der Event-ID 4769.
  5. Suchen Sie im Detailbereich des Events nach dem Feld Ticket Encryption Type (Ticket-Verschlüsselungstyp).

Die Hex-Codes verstehen:

  • 0x17 (oder 23 dezimal): RC4-HMAC (Das ist das Protokoll, das wir eliminieren wollen).
  • 0x12 (oder 18 dezimal): AES256-CTS-HMAC-SHA1-96 (Das ist das Ziel).
  • 0x11 (oder 17 dezimal): AES128-CTS-HMAC-SHA1-96.

Analyse-Strategie: Wenn Sie Einträge mit 0x17 finden, notieren Sie sich:

  • Account Name: Welches Benutzer- oder Computerkonto hat das Ticket angefordert?
  • Service Name: Für welchen Dienst wurde das Ticket ausgestellt?
  • Client Address: Von welcher IP-Adresse kam die Anfrage?

Hinweis: Ignorieren Sie Tickets, die mit einem Dollarzeichen enden und Computerkonten gehören, wenn diese nur vereinzelt auftreten, fokussieren Sie sich primär auf Dienstkonten (Service Accounts) und Benutzer.

Anleitung: Die Alternative AES einrichten und nutzen

AES (Advanced Encryption Standard) ist der Ersatz für Kerberos RC4. Es ist sicherer, schneller auf moderner Hardware und Standard in aktuellen Windows-Versionen. Die Einrichtung erfolgt primär über das Attribut msDS-SupportedEncryptionTypes im Active Directory.

Schritt 1: Konfiguration der Verschlüsselungstypen pro Objekt

Active Directory muss wissen, dass ein Konto AES unterstützt. Dies wird über ein Bitmask-Attribut gesteuert.

  1. Öffnen Sie Active Directory-Benutzer und -Computer (stellen Sie sicher, dass „Erweiterte Features“ im Menü „Ansicht“ aktiviert ist).
  2. Öffnen Sie die Eigenschaften eines Benutzers oder Dienstkontos.
  3. Wechseln Sie zum Reiter Attribut-Editor.
  4. Suchen Sie das Attribut msDS-SupportedEncryptionTypes.

Die Werte: Wenn der Wert 0 oder <nicht gesetzt> ist, verhält sich das System oft so, als wäre RC4 der Standard (abhängig vom Betriebssystem und DFL). Um AES zu erzwingen, müssen Sie die Werte berechnen:

  • RC4 = 4
  • AES 128 = 8
  • AES 256 = 16

Um AES 128 und AES 256 zu unterstützen (empfohlen), addieren Sie 8 + 16 = 24. Tragen Sie den Wert 24 (oder 28, wenn Sie RC4 vorübergehend noch zulassen wollen) in das Attribut ein.

Alternative über die GUI: Im Reiter Konto finden Sie unter „Kontooptionen“ die Checkbox:

  • „Dieses Konto unterstützt Kerberos-AES-128-Bit-Verschlüsselung“
  • „Dieses Konto unterstützt Kerberos-AES-256-Bit-Verschlüsselung“

Das Setzen dieser Haken aktualisiert automatisch das Attribut msDS-SupportedEncryptionTypes.

Schritt 2: Gruppenrichtlinien (GPO) für die Domäne

Sie müssen sicherstellen, dass Ihre Server und Clients auch bereit sind, AES zu sprechen.

  1. Öffnen Sie die Gruppenrichtlinienverwaltung.
  2. Bearbeiten Sie die Default Domain Policy (oder eine dedizierte Sicherheitsrichtlinie).
  3. Navigieren Sie zu: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen
  4. Suchen Sie die Richtlinie: Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren.
  5. Aktivieren Sie diese Richtlinie und wählen Sie:
    • AES256_HMAC_SHA1 (Priorität)
    • AES128_HMAC_SHA1
    • Deaktivieren Sie RC4_HMAC_MD5.

Wichtig: Diese Richtlinie steuert, welche Verschlüsselungstypen der Client dem KDC (Key Distribution Center) anbietet.

Anleitung: Wie Kerberos RC4 abgeschaltet wird

Nachdem Sie auditiert haben und sichergestellt haben, dass alle Konten AES unterstützen (insbesondere Service Accounts!), können Sie an die Abschaltung gehen. Dies sollte schrittweise geschehen.

Phase 1: Soft-Disable über Registry (Testing)

Sie können auf einzelnen Servern testen, wie diese reagieren, wenn RC4 nicht mehr verfügbar ist. Microsoft dokumentiert hierfür Registry-Keys unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.

Erstellen oder ändern Sie den DWORD-Wert SupportedEncryptionTypes. Setzen Sie diesen auf 0x7ffffff8 (dies entfernt RC4, welches Bit 2 ist). Dies zwingt den Client/Server dazu, nur noch AES (oder neuere Verfahren) zu nutzen.

Phase 2: Domänenweite Abschaltung

Die effektivste Methode ist die oben genannte Gruppenrichtlinie (Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren).

Wenn Sie in dieser GPO den Haken bei „RC4_HMAC_MD5“ entfernen und die Richtlinie auf alle Domain Controller und Clients anwenden, wird Kerberos RC4 effektiv in der Domäne deaktiviert.

Phase 3: Active Directory Härtung

Stellen Sie sicher, dass keine Konten mehr existieren, die explizit auf RC4 konfiguriert sind. Prüfen Sie via PowerShell, ob Benutzerkonten das Attribut Use DES encryption types (sehr alt) oder spezifische Legacy-Settings haben.

Ein PowerShell-Snippet zur Suche nach Konten ohne explizite AES-Freigabe (vereinfacht):

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or $_."msDS-SupportedEncryptionTypes" -band 4 }

Hinweis: Dieser Befehl dient der Analyse und zeigt Konten, die potentiell noch RC4 nutzen oder es nicht explizit ausgeschlossen haben.

Häufige Probleme und Fallstricke

Bei der Migration von Kerberos RC4 auf AES treten erfahrungsgemäß folgende Probleme auf:

1. Legacy Storage-Systeme und Drucker

Ältere NAS-Systeme (Network Attached Storage) oder Multifunktionsdrucker, die „Scan-to-Folder“ nutzen, haben oft veraltete Firmware, die nur RC4 unterstützt.

  • Lösung: Firmware-Update durchführen. Wenn dies nicht möglich ist, muss das Gerät isoliert oder ersetzt werden. Es gibt keine sichere Koexistenz nach 2026.

2. Vertrauensstellungen (Forest Trusts)

Wenn Sie Vertrauensstellungen zu anderen Active Directory Forests haben, müssen diese ebenfalls AES unterstützen.

  • Prüfung: Öffnen Sie Active Directory-Domänen und -Vertrauensstellungen, Eigenschaften des Trusts -> Reiter „Sicherheit“. Stellen Sie sicher, dass „Der andere Domänen unterstützt Kerberos AES-Verschlüsselung“ aktiviert ist.

3. Java-Applikationen

Ältere Java-Versionen haben standardmäßig starke Verschlüsselung (wie AES 256) deaktiviert (wegen alter US-Exportbeschränkungen).

  • Lösung: Installieren Sie die „Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files“ oder aktualisieren Sie auf eine moderne Java-Version.

Fazit: Agieren statt Reagieren

Die Kerberos RC4 Abschaltung im Jahr 2026 ist kein Vorschlag von Microsoft, sondern ein notwendiger Schnitt, um die Sicherheit der Windows-Welt zu gewährleisten. Wer bis zum Sommer 2026 wartet, riskiert massive Betriebsstörungen.

Die Migration auf AES ist nicht nur eine Compliance-Aufgabe, sondern ein direktes Upgrade Ihrer Sicherheitsarchitektur gegen moderne Angriffe wie Kerberoasting.

Handlungsempfehlung:

  1. Beginnen Sie heute mit dem Audit Ihrer Event Logs (Event ID 4769).
  2. Identifizieren Sie Legacy-Systeme und planen Sie deren Austausch.
  3. Aktivieren Sie AES auf allen Service Accounts.
  4. Testen Sie die Deaktivierung von RC4 in Testumgebungen vor dem Stichtag.

Schützen Sie Ihre Identitäten. Die Zeit von RC4 ist abgelaufen.

Haftungsausschluss: Die in diesem Artikel beschriebenen Eingriffe in die Systemkonfiguration erfolgen auf eigene Gefahr. Erstellen Sie vor Änderungen immer Backups und testen Sie Einstellungen in einer isolierten Umgebung. Beachten Sie die offiziellen Dokumentationen von Microsoft.

Nach oben scrollen