Windows-Update sperrt Domain-Nutzer aus: Was der September-Patch anrichtet

Ein Sicherheitsupdate, das eigentlich schützen soll, hat bei einigen Unternehmen genau das Gegenteil bewirkt: Mitarbeiter kamen nicht mehr an ihre Rechner. Auslöser ist das Windows-Sicherheitsupdate vom September-Patchday, das in On-Premises-Active-Directory-Umgebungen dazu führen kann, dass Geräte die Vertrauensbeziehung zur Domäne verlieren. Wer eine eigene AD-Infrastruktur betreibt und in den vergangenen Tagen gepatcht hat, sollte diesen Beitrag nicht überspringen.

Was genau passiert ist

Laut den Windows-Release-Health-Hinweisen von Microsoft (öffnet in neuem Tab) können nach der Installation des Updates KB5124008 vom 8. September 2026 (oder späterer Updates) bestimmte, durch Credential Guard geschützte Maschinenkonten ihren sicheren Kanal zu einer On-Premises-Active-Directory-Domäne verlieren. Betroffene Nutzer können sich dann nicht mehr interaktiv mit gültigen Domänen-Zugangsdaten anmelden und erhalten laut Microsoft die Meldung, die Vertrauensbeziehung zwischen Gerät und Domäne sei fehlgeschlagen. Die Offline-Anmeldung mit zwischengespeicherten Zugangsdaten funktioniert laut Microsoft weiterhin, ebenso bleiben AD-Replikation und die Dienste auf den Domänencontrollern selbst unberührt.

heise online berichtet (öffnet in neuem Tab) zusätzlich, dass Microsoft dieses Problem zu den weiteren unerwünschten Nebenwirkungen der September-Sicherheitsupdates zählt – nach einem bereits turbulenten Patchday, an dem laut heise online fast 1000 Sicherheitslücken (öffnet in neuem Tab) geschlossen wurden, ein Rekordwert für einen einzelnen Monat.

Warum das Update betroffene Systeme trifft

Ursache ist laut Microsoft eine Funktion namens Machine Identity Isolation, die mit KB5124008 aktiv wird. Wichtig dabei: Das Update aktiviert die Erzwingung dieser Funktion nicht selbst, sondern sorgt dafür, dass Windows ab sofort bereits vorhandene oder per Richtlinie vorgesehene Einstellungen dazu tatsächlich durchsetzt. Problematisch wird das, weil Machine Identity Isolation laut Microsoft nur für Umgebungen vorgesehen ist, die mit Domänencontrollern auf dem Windows Server 2025 Domain Functional Level oder höher verbunden sind. In allen anderen Umgebungen soll die Funktion deaktiviert bleiben – ist sie es nicht, tritt genau der beschriebene Fehler auf.

Betroffen sind laut Microsoft Client-Systeme unter Windows 11, Version 26H1, 25H2 und 24H2, bei denen Machine Identity Isolation aktiviert wurde, ohne dass die Domänencontroller-Umgebung das Windows Server 2025 DFL erreicht. Server-Systeme sind nach Microsofts Angaben nicht betroffen.

Was ein „sicherer Kanal“ zur Domäne überhaupt ist

Für alle, die mit Active Directory nicht täglich arbeiten, lohnt sich die kurze Einordnung: Jeder Rechner, der einer Windows-Domäne beitritt, erhält ein eigenes Maschinenkonto und handelt darüber einen kryptografisch gesicherten Kommunikationskanal mit einem Domänencontroller aus – den sogenannten Secure Channel. Über diesen Kanal laufen unter anderem Anmeldevorgänge: Wenn sich ein Nutzer am Gerät anmeldet, prüft die Maschine im Hintergrund über genau diesen Kanal, ob die Zugangsdaten bei der Domäne gültig sind. Bricht der Kanal ab – etwa weil das Passwort des Maschinenkontos und der beim Domänencontroller hinterlegte Wert nicht mehr übereinstimmen oder, wie hier, weil eine neue Isolationsregel die Kommunikation blockiert –, verliert das Gerät faktisch sein Vertrauensverhältnis zur Domäne. Genau das beschreibt die Fehlermeldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“, die betroffene Nutzer nach der Installation von KB5124008 zu sehen bekommen.

Credential Guard, die Sicherheitsfunktion, in deren Umfeld Machine Identity Isolation angesiedelt ist, verfolgt eigentlich einen defensiven Zweck: Sie isoliert Zugangsdaten und Geheimnisse in einem virtualisierungsbasierten, vom restlichen Betriebssystem abgeschotteten Speicherbereich, damit Schadsoftware sie selbst mit Administratorrechten nicht auslesen kann. Machine Identity Isolation erweitert dieses Prinzip auf die Identität der Maschine selbst – mit dem aktuellen Nebeneffekt, dass sie in nicht dafür vorgesehenen Umgebungen die eigentliche Anmeldung verhindert, die sie eigentlich absichern soll.

Kein Einzelfall in einem ohnehin turbulenten Patch-Monat

Der September-Patchday war schon vor diesem Fund kein reibungsloser Durchlauf. Laut heise online (öffnet in neuem Tab) schloss Microsoft an diesem Termin knapp 1000 Sicherheitslücken – ein Rekordwert. Nach einem derart umfangreichen Update-Paket ist die Wahrscheinlichkeit ungewollter Nebenwirkungen höher als bei einem schlanken Patch, schon weil mehr Codepfade gleichzeitig verändert werden. Die Domain-Trust-Problematik ist im Microsoft-Message-Center nicht der einzige seit dem 8. September 2026 gemeldete Vorfall zum selben Update KB5124008: Auch Probleme mit Remote Desktop Services, mit Hyper-V-basierten Linux-VMs und mit einzelnen USB-Audiogeräten gehen auf dasselbe Update zurück, wie aus den Windows-Release-Health-Hinweisen hervorgeht – ein Hinweis darauf, wie viele unterschiedliche Systemebenen ein einzelnes kumulatives Sicherheitsupdate inzwischen berührt.

Wie die Gegenmaßnahme aussieht

Microsoft stuft den Status des Problems aktuell als „Mitigated“ ein – also mit einem Workaround versehen, aber noch nicht dauerhaft behoben. Die Lösung besteht darin, Machine Identity Isolation über denselben Weg zu deaktivieren, über den sie ursprünglich aktiviert wurde:

1. Per Intune-Richtlinie aktiviert: Deaktivierung ebenfalls über die entsprechende Intune-Policy.
2. Per Gruppenrichtlinie aktiviert: Rücknahme über dieselbe Gruppenrichtlinie.
3. Direkt in der Registry gesetzt: Microsoft nennt dafür zwei Registry-Pfade, HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation und HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation. Steht der Wert dort auf 2, muss er laut Microsoft auf 0 zurückgesetzt werden.

Nach der Deaktivierung ist laut Microsoft ein Neustart des betroffenen Geräts erforderlich. Anschließend muss der sichere Kanal zur Domäne noch einmal aktiv zurückgesetzt werden, mit dem PowerShell-Befehl Test-ComputerSecureChannel -Repair -Credential (Get-Credential). Diese Workarounds bleiben relevant für Geräte, die noch kein Update nach dem 22. September 2026 installiert haben – für alle anderen gibt es inzwischen einen regulären Fix, siehe Nachtrag am Ende dieses Beitrags.

Was das für Ihre IT bedeutet, wenn Sie eine eigene Domäne betreiben

Der Fall ist ein Lehrbeispiel dafür, warum ein September-Patchday mit fast 1000 geschlossenen Lücken nicht automatisch heißt, dass jedes Update ohne Prüfung ausgerollt werden sollte – gerade wenn im eigenen Haus eine On-Premises-Active-Directory-Struktur läuft, die nicht auf dem aktuellsten Windows-Server-Stand ist:

• Prüfen, ob Machine Identity Isolation überhaupt aktiv ist. Wurde die Funktion nie bewusst eingeschaltet, ist das Risiko gering. Wurde sie irgendwann per Gruppenrichtlinie, Intune oder Registry gesetzt – etwa im Rahmen einer früheren Sicherheitshärtung –, lohnt sich die Kontrolle vor dem nächsten Update-Rollout.
• Domain Functional Level der eigenen Umgebung kennen. Nur wer bereits auf Windows Server 2025 DFL migriert ist, kann die Funktion unbedenklich aktiviert lassen.
• Vor einem flächendeckenden Rollout an einer Testgruppe prüfen, ob sich Nutzer nach der Installation noch normal an der Domäne anmelden können – gerade bei Notebooks, die zwischen Homeoffice und Büro wechseln und auf funktionierende Domänenanmeldung angewiesen sind.
• Support-Kanäle im Blick behalten. Microsoft aktualisiert den Status im Message-Center laufend – der Fall gilt inzwischen als behoben, siehe Nachtrag.

Wer eine hybride oder rein cloudbasierte Anmeldung über Entra ID nutzt, ist von diesem konkreten Fehler nicht betroffen – das Problem entsteht ausschließlich in der Kombination aus lokalem Active Directory und der neuen Isolationsfunktion. Für alle anderen gilt: Ein einzelner falsch konfigurierter Registry-Wert kann nach diesem Patch aus einem Routine-Update einen Aussperr-Vorfall machen, wenn niemand vorher hinschaut, welche Sicherheitsfunktionen in der eigenen Umgebung überhaupt aktiv sind.

Nachtrag vom 9. Oktober 2026: Microsoft hat das Problem behoben

Laut den Windows-Release-Health-Hinweisen von Microsoft (öffnet in neuem Tab) gilt der Fall inzwischen als „Resolved": Microsoft löste das Problem mit dem Update KB5124010 (öffnet in neuem Tab) vom 22. September 2026, indem die Erzwingung von Machine Identity Isolation darin vollständig unterbunden wird – unabhängig davon, wie die Funktion zuvor konfiguriert war. Wer ein Update ab diesem Stand oder neuer installiert hat, braucht laut Microsoft keinen der oben beschriebenen Workarounds mehr.

Für Geräte, die noch auf einem älteren Patchstand stehen, bleiben die manuelle Deaktivierung über Registry, Gruppenrichtlinie oder Intune sowie die Known-Issue-Rollback-Gruppenrichtlinie weiterhin die einzigen Mittel, bis das nächste Update eingespielt ist. Wer im September aus Vorsicht einen Update-Stopp für betroffene Maschinen verhängt hat, kann die Freigabe jetzt an diesen KB-Stand koppeln, statt weiter manuell auf jedem Gerät zu prüfen, ob Machine Identity Isolation aktiv ist.