KB5124008: Windows 11 verliert die Vertrauensstellung zur Domäne. Microsoft bestätigt Machine Identity Isolation als Ursache

In der Nachlese zum September-Patchday hatte ich den Verlust der Domänen-Vertrauensstellung nach KB5124008 noch als offenen Punkt geführt: reproduzierbar, aber ohne Erklärung und ohne offizielle Stellungnahme. Beides gibt es jetzt. Microsoft hat das Problem am 16. September 2026 als Known Issue ins Release-Health-Dashboard aufgenommen, die Ursache benannt und einen Workaround veröffentlicht. Die Kurzfassung vorab: Betroffen ist nur, wer die Funktion Machine Identity Isolation irgendwann einmal konfiguriert hat und dessen Domänencontroller nicht auf der Funktionsebene Windows Server 2025 laufen. Für alle anderen ist dieser Beitrag Hintergrundlektüre. Für die Betroffenen ist er eine Anleitung, die man vor dem nächsten Client-Neustart gelesen haben sollte.

Was passiert

Das Muster ist in allen Berichten dasselbe. Windows 11 24H2 oder 25H2, KB5124008 wird installiert, der Rechner startet neu, und ab dem nächsten Anmeldeversuch lehnt das System gültige Domänenkonten ab. Entweder erscheint die klassische Meldung, dass die Vertrauensstellung zwischen Arbeitsstation und Domäne fehlgeschlagen ist, oder Windows behauptet schlicht, Benutzername oder Kennwort seien falsch. Beides stimmt nicht: Das Kennwort ist korrekt, die Maschine hat nur ihren sicheren Kanal zum Domänencontroller verloren.

Zwei Details helfen bei der Abgrenzung von anderen Anmeldeproblemen. Erstens funktioniert die Anmeldung mit zwischengespeicherten Anmeldeinformationen weiterhin, solange der Rechner offline ist. Wer das Netzwerkkabel zieht, kommt also auf den Desktop. Zweitens zeigt das Ereignisprotokoll auf betroffenen Systemen gehäuft Kerberos-Fehler, gefolgt von Rückfällen auf NTLM und Netlogon-Fehlern.

Der Administrator Alex Turner, der das Problem im Microsoft-Q&A-Forum dokumentiert hat, konnte es sauber reproduzieren: Update deinstallieren und Vertrauensstellung reparieren, alles läuft; Update erneut installieren, Fehler kehrt zurück. Auf Reddit meldete ein Kollege 11 von rund 256 Windows-11-25H2-Geräten betroffen, ein anderer sprach von sämtlichen 25H2-Arbeitsplätzen in seinem Netz. Dass die Quote so unterschiedlich ausfällt, erklärt sich mit der Ursache.

Die Ursache: Machine Identity Isolation

Domänenmitglieder authentifizieren sich gegenüber dem Domänencontroller mit ihrem Computerkonto. Dessen Geheimnis liegt traditionell als LSA-Secret in der Registry, und genau das war Microsoft schon länger ein Dorn im Auge: Wer lokaler Administrator ist, kann es auslesen, und seit gMSA, dMSA und Kerberos Armoring auf Computerkonten aufbauen, ist ein ausgelesenes Maschinengeheimnis mehr wert als früher.

Mit Windows Server 2025 hat Microsoft deshalb Credential-Guard-geschützte Computerkonten eingeführt, gesteuert über die Einstellung Machine Identity Isolation (MII). Sie kennt drei Zustände:

Wert	Modus	Verhalten
0	Deaktiviert	Computerkonto-Secret bleibt wie gehabt in LSA
1	Audit	Neues Secret in Credential Guard, Kopie in LSA; bei Fehlern Rückfall auf LSA
2	Enforcement	Secret wird nach Credential Guard verschoben und aus LSA gelöscht

Im Enforcement-Modus gibt es das Geheimnis also nur noch innerhalb der virtualisierungsbasierten Sicherheit. Jede Maschinenauthentifizierung läuft dann über Credential Guard, und die Domänencontroller müssen mit diesem Verfahren umgehen können. Das tun sie nach Microsofts Angabe nur ab der Domänenfunktionsebene Windows Server 2025.

Der Haken hat eine Vorgeschichte. Bereits im April 2025 hatte Microsoft die Funktion mit KB5055523 in Windows Server 2025 und Windows 11 24H2 vorübergehend abgeschaltet, weil sie mit der Kerberos-Kennwortrotation für Computerkonten kollidierte. Seither stand die Einstellung in vielen Umgebungen zwar noch in Gruppenrichtlinien, Intune-Baselines oder der Registry, tat aber nichts. Genau das hat KB5124008 geändert. Microsoft formuliert es so: Das Update aktiviere die Durchsetzung nicht selbst, sorge aber dafür, dass Windows vorhandene oder per Richtlinie ausgerollte MII-Einstellungen wieder berücksichtige.

Anders gesagt: Eine Konfiguration, die seit anderthalb Jahren wirkungslos war, wurde über ein monatliches Sicherheitsupdate scharf geschaltet, ohne Hinweis in den Release Notes. Und wo die Domänencontroller die Funktionsebene 2025 nicht haben, was in der öffentlichen Verwaltung und im Mittelstand der Regelfall sein dürfte, läuft die Maschinenauthentifizierung gegen eine Wand. Das erklärt auch die unterschiedlichen Trefferquoten: Wer MII über eine gezielte Gruppenrichtlinie auf einige Geräte verteilt hatte, verliert genau diese; wer die Einstellung in einer breiten Sicherheits-Baseline hatte, verliert alle.

Ein Randaspekt aus dem Q&A-Thread: Microsoft nennt im Workaround nur den Wert 2. Mindestens ein Administrator berichtet jedoch, dass bei ihm der Wert 1 (Audit) stand und das Zurücksetzen auf 0 ebenfalls nötig war. Wer prüft, sollte also jeden Wert ungleich 0 als verdächtig behandeln.

Wer betroffen ist

Microsoft grenzt den Kreis klar ein. Betroffen sind ausschließlich Client-Systeme:

• Windows 11 24H2 und 25H2 mit KB5124008 (Build 26100.9445 bzw. 26200.9445)
• Windows 11 26H1 mit KB5124012

und auch dort nur unter zwei gleichzeitig erfüllten Bedingungen: MII ist auf dem Gerät konfiguriert, und die Domänencontroller laufen unterhalb der Funktionsebene Windows Server 2025.

Nicht betroffen sind Windows Server, die Domänencontroller selbst, die AD-Replikation, reine Entra-ID-Geräte, Arbeitsgruppenrechner und alle Clients, auf denen MII nie gesetzt wurde. Wer die Einstellung nicht kennt und nie eine Security-Baseline von Microsoft oder einem Drittanbieter ungeprüft übernommen hat, ist mit hoher Wahrscheinlichkeit außen vor.

Zuerst prüfen, bevor etwas kaputtgeht

Bevor Sie am Workaround arbeiten, lohnt sich ein Blick auf die Flotte, idealerweise bevor weitere Clients nach dem Update neu starten. Zwei Registry-Pfade sind relevant, einer für die effektive Einstellung, einer für die Richtlinienvorgabe:

powershell

$paths = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa',
         'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard'

foreach ($p in $paths) {
    $v = (Get-ItemProperty -Path $p -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
    '{0}: {1}' -f $p, $(if ($null -eq $v) { 'nicht gesetzt' } else { $v })
}

Alles, was nicht auf „nicht gesetzt“ oder 0 steht, ist ein Kandidat. Das Skript lässt sich per Invoke-Command, über die RMM-Lösung oder als Inventarabfrage im Patch-Management gegen alle Windows-11-Clients fahren.

Die zweite Frage ist die Domänenfunktionsebene:

powershell

(Get-ADDomain).DomainMode

Steht dort etwas anderes als Windows2025Domain, hat MII in Ihrer Umgebung nichts verloren, egal ob das Update schon installiert ist oder nicht.

Ob der sichere Kanal eines konkreten Rechners noch intakt ist, verrät Test-ComputerSecureChannel -Verbose oder klassisch nltest /sc_verify:<Domäne>.

Der Workaround

Microsofts Anweisung ist im Kern eine Regel: MII muss auf demselben Weg deaktiviert werden, auf dem es aktiviert wurde. Wer die Einstellung über Intune (Policy CSP DeviceGuard/MachineIdentityIsolation) verteilt hat, setzt sie dort auf deaktiviert. Wer sie per Gruppenrichtlinie gesetzt hat, findet sie unter Computerkonfiguration → Administrative Vorlagen → System → Device Guard → Virtualisierungsbasierte Sicherheit aktivieren, Unterpunkt Machine Identity Isolation Configuration, und stellt dort auf Deaktiviert um. Ein Praxishinweis aus dem Q&A-Thread: Bei mindestens einem Administrator hat die Gruppenrichtlinie den Wert auf den Clients nicht zuverlässig zurückgesetzt, er musste zusätzlich die Registry direkt anfassen.

Wurde MII direkt in der Registry gesetzt, oder greift die Richtlinie nicht, geht es so:

1. Registry sichern.
2. In beiden Pfaden den Wert MachineIdentityIsolation auf 0 setzen:

   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation
   HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

3. Neustart.
4. Sicheren Kanal reparieren, in einer administrativen PowerShell:

powershell

   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Abgefragt wird ein Konto, das die Maschine in der Domäne reparieren darf.

Achtung beim Abtippen aus Microsofts Support-Eintrag: Dort steht hinter dem Befehl ein überzähliges Hochkomma, das PowerShell mit einer Fehlermeldung quittiert. Günter Born hat darauf hingewiesen; die Zeile oben ist die korrekte Fassung.

Das Henne-Ei-Problem in der Praxis: Der Rechner nimmt keine Domänenanmeldung mehr an, aber Sie brauchen eine Anmeldung, um den Wert zu ändern. Der Weg, der sich im Q&A-Thread bewährt hat: Netzwerk trennen (Dock abziehen, WLAN aus), mit einem Domänenkonto über den Anmeldecache einloggen, Netzwerk wieder verbinden, dann per Fernwartung oder mit dem lokalen Administratorkonto aus LAPS den Registry-Wert setzen, reparieren, neu starten. Ohne LAPS oder ein anderes verwaltetes lokales Admin-Konto wird es an dieser Stelle unangenehm.

Warum das Deaktivieren selbst gefährlich sein kann

Hier liegt der Teil, der in vielen Kurzmeldungen fehlt. Microsofts eigene Dokumentation warnt: War MII im Enforcement-Modus aktiv und wird dann deaktiviert, kann das Gerät sich nicht mehr authentifizieren und muss aus der Domäne genommen und neu aufgenommen werden. Das gilt, weil im Enforcement-Modus das LSA-Secret gelöscht wurde; nach dem Abschalten ist schlicht kein Geheimnis mehr da, mit dem sich die Maschine ausweisen könnte.

Ein Administrator im Q&A-Thread hat das schmerzhaft bestätigt: Nach dem Umstellen von Audit bzw. Enforcement auf Deaktiviert verloren in seiner Umgebung flächendeckend Geräte die Vertrauensstellung, darunter auch solche, auf denen KB5124008 nie installiert war. Wer die Einstellung per Gruppenrichtlinie auf alle Clients gleichzeitig zurückdreht, riskiert also, das Problem zu verbreitern statt es zu lösen.

Die Konsequenz für die Reihenfolge:

• Nicht die Richtlinie blind auf „Deaktiviert“ stellen und auf den nächsten Neustart warten.
• Erst prüfen, welche Geräte MII tatsächlich effektiv hatten und ob sie den Enforcement-Modus schon durchlaufen haben (Wert 2 in HKLM\SYSTEM\...\Lsa).
• Für diese Geräte den Repair-Schritt fest einplanen, und für den Fall, dass Test-ComputerSecureChannel scheitert, Domänenaustritt und Neubeitritt mit lokalem Admin-Konto vorbereiten.
• Den Rollout von KB5124008 an Clients mit MII-Konfiguration anhalten, bis die Einstellung bereinigt ist.

Was Microsoft noch plant

Microsoft will die Durchsetzung von Machine Identity Isolation in einem kommenden Windows-Update vorübergehend wieder aussetzen, während an der Funktion weitergearbeitet wird. Einen Termin gibt es nicht; der Oktober-Patchday am 13. Oktober ist die naheliegende Vermutung. Wer den Workaround anwendet, sollte die Deaktivierung als Dauerzustand betrachten, bis Microsoft die Unterstützung für ältere Funktionsebenen dokumentiert. Die Einstellung im Oktober einfach wieder auf 2 zu setzen, wie es ein Kollege im Q&A-Thread vorhat, ist ohne Domänencontroller auf 2025-Niveau kein Plan, sondern eine Wiederholung.

Bleibt die Einordnung. Das ist bereits das zweite Mal, dass Microsoft dieselbe Funktion per Monatsupdate an- oder abschaltet, ohne dass es in den Release Notes stünde. Im April 2025 wurde sie still deaktiviert, im September 2026 still reaktiviert, und beide Male haben Administratoren die Folgen ausbaden dürfen. Eine Funktion, die Microsoft selbst nur für die Funktionsebene 2025 freigibt, hätte auf Clients gegen ältere Domänencontroller nie greifen dürfen. Dass die Prüfung fehlt, ist kein Bug im eigentlichen Sinne, sondern eine Designentscheidung, und die liegt in Redmond. Für die Zeit bis zum Fix gilt der Hinweis, der nach diesem Patchday ohnehin auf jedem Tisch liegen sollte: Erst die Flotte inventarisieren, dann patchen.

Quellen

• Microsoft Release Health: Domain-joined devices might lose their secure trust relationship with the domain (16.09.2026)
• Microsoft Learn: Credential Guard protected machine accounts
• Microsoft Q&A: KB5124008 (26200.9445) breaks machine secure channel / domain trust