IT-Sicherheit

Kerberos RC4 ab Juli 2026: Warum Unternehmen ihr Active Directory jetzt prüfen sollten

Mit den Windows-Sicherheitsupdates im Juli 2026 erreicht Microsoft die nächste Stufe der Kerberos-Härtung: Audit-Ausnahmen für RC4 entfallen, Enforcement wird zum Standard. Für viele Unternehmen ist das ein Sicherheitsgewinn. Für Umgebungen mit veralteten Anwendungen, alten Geräten oder ungepflegten Servicekonten kann es aber auch zu Anmelde- und Dienstproblemen kommen.

Was ändert Microsoft im Juli 2026?

Kerberos ist das zentrale Authentifizierungsprotokoll in klassischen Windows-Domänen. Es sorgt dafür, dass Benutzer, Computer und Dienste innerhalb eines Active Directory sicher nachweisen können, wer sie sind. Dabei werden sogenannte Tickets ausgestellt. Diese Tickets werden verschlüsselt. Genau hier setzt die aktuelle Änderung an.

RC4 ist ein älteres Verschlüsselungsverfahren, das in vielen Windows-Umgebungen historisch lange mitgeschleppt wurde. Moderne Domänen sollten bevorzugt AES verwenden. Microsoft hat die Umstellung bereits Anfang 2026 vorbereitet: Seit Januar 2026 gibt es Updates, die Prüf- und Warnereignisse ermöglichen. Mit den Updates ab April 2026 wurde die standardmäßige Annahme für nicht explizit konfigurierte Konten in Richtung AES verschoben. Im Juli 2026 folgt laut Microsoft die finale Enforcement-Phase: Die temporäre Rückfallsteuerung wird entfernt, Audit Mode steht nicht mehr als dauerhafte Ausweichoption zur Verfügung.

Das bedeutet nicht, dass jede Windows-Domäne automatisch ausfällt. Es bedeutet aber: Konfigurationen, die noch stillschweigend auf RC4 angewiesen sind, können ab diesem Zeitpunkt sichtbar werden. Und sichtbar heißt in diesem Fall häufig: Anmeldung schlägt fehl, ein Dienst startet nicht mehr, eine Schnittstelle kann sich nicht authentifizieren oder ein Altgerät verliert den Zugriff auf eine Freigabe.

Warum betrifft das besonders kleine und mittlere Unternehmen?

In KMU sind Active-Directory-Umgebungen oft über viele Jahre gewachsen. Neue Server, alte Fachanwendungen, externe Dienstleister, Scanner, Zeiterfassung, Warenwirtschaft, Terminalserver, Backup-Systeme und NAS-Geräte greifen teilweise auf dieselbe Domäne zu. Viele dieser Systeme funktionieren zuverlässig und werden deshalb im Alltag kaum noch berührt.

Genau diese Stabilität kann zum Risiko werden. Wenn ein Dienstkonto vor Jahren angelegt wurde, nie ein neues Kennwort erhalten hat und keine modernen Verschlüsselungstypen sauber hinterlegt sind, fällt das im Tagesbetrieb nicht unbedingt auf. Solange Windows eine Rückfallmöglichkeit bietet, läuft der Dienst weiter. Wenn diese Rückfallmöglichkeit entfällt, wird aus einer technischen Altlast ein Betriebsrisiko.

Für Geschäftsführer und IT-Verantwortliche ist deshalb wichtig: Die Kerberos-RC4-Härtung ist kein reines Administratorendetail. Sie betrifft die Verfügbarkeit zentraler Geschäftsprozesse. Wenn beispielsweise eine alte ERP-Anbindung, ein Dienst für Dateiablagen oder eine Produktionsschnittstelle Kerberos nicht mehr sauber nutzen kann, entstehen Störungen genau dort, wo sie im Alltag teuer werden.

Warum wird RC4 überhaupt abgeschaltet?

RC4 gilt seit Jahren als veralteter Verschlüsselungsalgorithmus. Im Kerberos-Kontext ist das besonders relevant, weil Angreifer bestimmte Service-Tickets offline analysieren können. Ein bekanntes Angriffsmuster ist Kerberoasting: Angreifer fordern Service-Tickets für Dienstkonten an, speichern diese und versuchen anschließend, die zugehörigen Kennwörter offline zu knacken.

Schwache oder alte Dienstkonto-Kennwörter verschärfen dieses Risiko erheblich. Wird ein privilegiertes Dienstkonto kompromittiert, kann daraus schnell ein größerer Sicherheitsvorfall entstehen. Das Ziel der Microsoft-Härtung ist daher nachvollziehbar: weniger veraltete Verschlüsselung, weniger Angriffsfläche, stärkere Standardwerte für Active Directory.

Aus Sicherheitssicht ist die Änderung also sinnvoll. Entscheidend ist nur, sie nicht unvorbereitet in produktive Umgebungen laufen zu lassen. Eine kontrollierte Prüfung ist deutlich weniger aufwendig als die Fehlersuche nach einem ungeplanten Authentifizierungsproblem.

Typische Anzeichen für RC4-Abhängigkeiten

Ob eine Umgebung noch RC4 nutzt, erkennt man nicht zuverlässig durch einen kurzen Blick in die Benutzerverwaltung. Die Abhängigkeiten liegen häufig in Details: bei Service Principal Names, bei alten Dienstkonten, bei nicht aktualisierten Geräten oder bei Anwendungen, die nur bestimmte Kerberos-Verschlüsselungstypen unterstützen.

Microsoft verweist für die Prüfung unter anderem auf Ereignisse im Systemprotokoll der Domänencontroller. Relevant sind KDCSVC-Ereignisse, die auf unsichere oder künftig nicht mehr unterstützte Verschlüsselungskonfigurationen hinweisen. Dazu gehören Ereignisse im Bereich 201 bis 209. Besonders interessant ist auch Event ID 205, wenn explizit unsichere Cipher in den Default Domain Supported Encryption Types konfiguriert sind.

Welche Systeme sollten Unternehmen besonders prüfen?

In der Praxis sind nicht nur sehr alte Windows-Server relevant. Auch Geräte und Anwendungen, die selten im Fokus stehen, können noch auf veraltete Authentifizierungs- oder Verschlüsselungsmethoden angewiesen sein.

• Servicekonten: Konten für Anwendungen, Datenbanken, Backup-Jobs, Schnittstellen oder geplante Aufgaben.
• Fachanwendungen: ERP, Warenwirtschaft, Zeiterfassung, Dokumentenmanagement oder Branchenlösungen.
• Altserver: ältere Windows-Server, lange nicht aktualisierte Applikationsserver oder Migrationsreste.
• Nicht-Windows-Systeme: Linux-Server, NAS-Systeme, Appliances oder Anwendungen mit Kerberos-Integration.
• Druck- und Scanumgebungen: Multifunktionsgeräte, Scan-to-Folder, Follow-Me-Print oder Authentifizierungsdienste.
• Netzwerk- und Sicherheitslösungen: Firewalls, VPN-Systeme, Proxy-Server oder Monitoring-Lösungen mit Domänenanbindung.

Wichtig ist dabei die Reihenfolge: Erst erfassen, dann bewerten, dann ändern. Wer ohne Bestandsaufnahme pauschal Verschlüsselungstypen deaktiviert, riskiert unnötige Betriebsunterbrechungen. Wer hingegen gar nichts tut, verschiebt das Risiko auf den nächsten Patch-Zyklus.

Empfohlener Prüfplan für KMU

Ein pragmatischer Prüfplan muss nicht kompliziert sein. Entscheidend ist, dass er die wichtigsten Risiken systematisch abdeckt und nicht erst am Tag der Update-Installation beginnt.

1. Domänencontroller aktualisieren: Stellen Sie sicher, dass alle unterstützten Domänencontroller aktuelle Windows-Sicherheitsupdates erhalten haben.
2. Systemprotokolle auswerten: Prüfen Sie KDCSVC-Ereignisse auf Hinweise zu RC4, unsicheren Ciphern oder fehlender AES-Unterstützung.
3. Servicekonten inventarisieren: Erfassen Sie Dienstkonten, SPNs, alte Kennwörter, Berechtigungen und genutzte Anwendungen.
4. Altsysteme identifizieren: Suchen Sie gezielt nach Geräten und Anwendungen, die nicht regelmäßig gepatcht werden.
5. Testfenster einplanen: Prüfen Sie kritische Anwendungen in einem Wartungsfenster oder einer Testumgebung, bevor Änderungen breit ausgerollt werden.
6. AES-Fähigkeit herstellen: Aktualisieren oder ersetzen Sie Systeme, die moderne Kerberos-Verschlüsselung nicht sauber unterstützen.
7. Dokumentation aktualisieren: Halten Sie fest, welche Konten, Dienste und Systeme geprüft oder angepasst wurden.

Besonders Servicekonten verdienen Aufmerksamkeit. Viele Sicherheitsprobleme entstehen nicht durch eine einzelne Schwachstelle, sondern durch lange gewachsene Kombinationen: zu weitreichende Rechte, selten geänderte Kennwörter, fehlende Zuständigkeit und alte Verschlüsselung. Die Kerberos-Umstellung ist daher eine gute Gelegenheit, diese Konten grundsätzlich zu bereinigen.

Was sollte man nicht tun?

In hektischen Patch-Situationen entstehen oft schnelle Workarounds. Bei Kerberos und Active Directory ist Vorsicht geboten. Änderungen an Verschlüsselungstypen, Registry-Werten oder Dienstkonten können weitreichende Folgen haben.

• Keine pauschalen Registry-Anpassungen ohne Verständnis der betroffenen Umgebung.
• Keine dauerhafte Ausnahme für RC4, nur weil eine Altanwendung noch funktioniert.
• Keine Änderung an produktiven Domänencontrollern ohne Wartungsfenster und Rückfallplan.
• Keine alleinige Prüfung auf Client-Seite, denn die entscheidenden Hinweise liegen häufig auf den Domänencontrollern.
• Keine Vernachlässigung von Nicht-Windows-Systemen, die Kerberos gegen Active Directory nutzen.

Eine Ausnahme kann im Einzelfall nötig sein, etwa wenn ein kritisches Altsystem nicht kurzfristig ersetzt werden kann. Dann sollte sie aber dokumentiert, zeitlich begrenzt und mit einem Modernisierungsplan verbunden sein. Dauerhafte technische Schulden bleiben ein Sicherheitsrisiko.

Wie SCHEIRO Unternehmen unterstützen kann

Für viele KMU ist die Herausforderung nicht das einzelne Microsoft-Update, sondern die Gesamtsicht auf die Umgebung. Welche Systeme authentifizieren gegen Active Directory? Welche Dienstkonten sind kritisch? Welche Altgeräte werden noch gebraucht? Welche Anwendungen müssen vor einem Update getestet werden?

SCHEIRO unterstützt Unternehmen dabei, diese Fragen strukturiert zu klären. Dazu gehören die Prüfung von Domänencontrollern, die Auswertung relevanter Ereignisprotokolle, die Bewertung von Servicekonten, die Planung sicherer Wartungsfenster und die Abstimmung mit Fachanwendungsherstellern. Ziel ist nicht, Änderungen möglichst kompliziert zu machen. Ziel ist, Sicherheitsupdates planbar einzuspielen, ohne unnötige Ausfälle zu riskieren.

FAQ: Kerberos RC4 und Active Directory

Fazit: Jetzt prüfen statt später suchen

Die Kerberos-RC4-Härtung ist ein gutes Beispiel für moderne IT-Sicherheit: Sie verbessert den Schutz, zwingt Unternehmen aber auch dazu, alte Abhängigkeiten sichtbar zu machen. Wer sein Active Directory regelmäßig pflegt, Servicekonten sauber dokumentiert und Updates planvoll einspielt, wird die Änderung wahrscheinlich gut beherrschen. Wer hingegen viele unbekannte Altlasten betreibt, sollte nicht bis zum nächsten Ausfall warten.