KB5124008 bricht Domänenvertrauensstellung: Workaround

Wer in den vergangenen Tagen das September-Sicherheitsupdate KB5124008 auf domänengebundene Windows-11-Arbeitsplätze ausgerollt hat, kann seit dem Wochenende auf gesperrte Anmeldungen stoßen: Betroffene Rechner melden nach einem Neustart, dass die Vertrauensstellung zwischen Arbeitsstation und Domäne fehlgeschlagen ist, oder weisen gültige Domänenkennwörter als falsch zurück. Microsoft hat das Verhalten am 16. September 2026 als offizielles Known Issue in Windows Release Health aufgenommen und einen Workaround dokumentiert.

Betroffen sind ausschließlich Client-Installationen von Windows 11 in den Versionen 24H2, 25H2 und 26H1, und auch dort nur ein schmaler Ausschnitt: Geräte, auf denen die Funktion Machine Identity Isolation bereits aktiviert war, deren Domänencontroller aber nicht auf der Domänenfunktionsebene von Windows Server 2025 laufen. Windows Server ist laut Microsoft nicht betroffen, Active-Directory-Replikation und die Dienste auf den Domänencontrollern laufen unverändert weiter. Wer Machine Identity Isolation nie eingeschaltet hat, reine Entra-ID-Geräte oder Arbeitsgruppenrechner betreibt, muss nichts tun. Alle anderen sollten den Rollout heute stoppen und die Registry-Werte prüfen, bevor weitere Clients neu starten.

Was ist passiert?

Microsoft hat das kumulative Sicherheitsupdate KB5124008 am 8. September 2026 für Windows 11 veröffentlicht. Es hebt die Systeme auf die Builds 26200.9445 (Version 25H2) beziehungsweise 26100.9445 (Version 24H2). Seit dem 16. September 2026, 14:15 Uhr PT, führt Microsoft dazu den Eintrag Domain-joined devices might lose their secure trust relationship with the domain mit dem Status Mitigated.

Die Ursache ist laut Microsoft nicht das Update selbst, sondern eine Verhaltensänderung: KB5124008 und spätere Updates aktivieren die Erzwingung der Machine Identity Isolation nicht direkt, sorgen aber dafür, dass Windows vorhandene oder per Richtlinie ausgerollte Einstellungen dieser Funktion ab sofort beachtet. Wer die Funktion also irgendwann testweise per Intune, Gruppenrichtlinie oder direkt in der Registry auf den Erzwingungsmodus gesetzt hat, bekommt sie mit diesem Update scharf gestellt.

Machine Identity Isolation gehört zum Umfeld von virtualisierungsbasierter Sicherheit und Credential Guard. Im Erzwingungsmodus verschiebt Windows das Kennwort des Computerkontos in den geschützten Bereich von Credential Guard und entfernt die klassische Kopie aus dem LSA-Speicher. Unterstützt wird das nur gegenüber Domänencontrollern auf der Domänenfunktionsebene von Windows Server 2025 oder höher. In allen anderen Umgebungen passt das lokal hinterlegte Computerkonto-Geheimnis danach nicht mehr zu dem, was das Active Directory erwartet, und der sichere Kanal bricht.

Wer ist betroffen?

Microsoft nennt als betroffene Plattformen die Client-Versionen Windows 11 26H1, 25H2 und 24H2. Für Windows Server wird ausdrücklich keine Betroffenheit gemeldet. Entscheidend ist die Kombination aus drei Bedingungen: aktivierte Machine Identity Isolation im Erzwingungsmodus, Domänenbeitritt an ein lokales Active Directory und Domänencontroller unterhalb der Funktionsebene von Windows Server 2025.

Betroffen: Domänengebundene Windows-11-Clients mit KB5124008 oder neuer, auf denen der Wert MachineIdentityIsolation auf 2 steht.
Betroffen: Umgebungen, in denen die Funktion früher zu Testzwecken per Intune oder Gruppenrichtlinie verteilt und nie zurückgenommen wurde, weil sie bis zu diesem Update wirkungslos blieb.
Nicht betroffen: Windows Server in allen unterstützten Versionen, einschließlich der Domänencontroller selbst.
Nicht betroffen: Geräte, die ausschließlich in Entra ID eingebunden sind, sowie Rechner in Arbeitsgruppen ohne Domänenbeitritt.
Nicht betroffen: Clients, auf denen Machine Identity Isolation nie aktiviert wurde, also der Registry-Wert fehlt oder auf 0 steht.
Vermutlich unkritisch: Domänen, deren Domänenfunktionsebene bereits auf Windows Server 2025 liegt, weil die Funktion dort unterstützt wird.

Das Fehlerbild in der Praxis ist eindeutig: Die interaktive Anmeldung mit gültigen Domänenanmeldedaten scheitert, teils mit dem klassischen Hinweis auf die fehlgeschlagene Vertrauensstellung, teils mit der irreführenden Meldung über einen falschen Benutzernamen oder ein falsches Kennwort. Die Anmeldung mit zwischengespeicherten Anmeldeinformationen kann weiterhin funktionieren, solange das Gerät offline ist. Genau diese Kombination ist der beste Indikator dafür, dass nicht das Kennwort des Benutzers, sondern der Kanal des Computerkontos das Problem ist.

Wie kritisch ist das?

Es handelt sich nicht um eine Sicherheitslücke, sondern um einen Verfügbarkeitsfehler. Es gibt keine CVE-Nummer, keinen Angriffspfad und keine Rechteausweitung. Der Schaden liegt im Betrieb: Ein Arbeitsplatz, der sich nicht mehr an der Domäne anmelden kann, ist für den Anwender komplett blockiert, und die Reparatur erfordert ein Konto mit Berechtigung zum Zurücksetzen des sicheren Kanals sowie einen Neustart.

Der Kreis der betroffenen Geräte ist klein, der Ausfall pro Gerät aber vollständig. Ein Administrator berichtete gegenüber BleepingComputer von 11 betroffenen Geräten bei rund 256 aktualisierten Windows-11-25H2-Clients, andere Meldungen beschreiben dagegen ganze Standorte, an denen jede aktualisierte Arbeitsstation gültige Domänenanmeldedaten zurückwies. Diese Streuung deckt sich mit der Erklärung von Microsoft, weil sie davon abhängt, ob die Funktion in der jeweiligen Umgebung jemals gesetzt wurde.

Microsoft stuft den Eintrag als Mitigated ein, also mit dokumentierter Umgehungslösung, aber ohne fertigen Fix. Als nächsten Schritt kündigt Microsoft an, die Erzwingung der Machine Identity Isolation in einem künftigen Windows-Update vorübergehend zu unterbinden, während die Funktion überarbeitet wird. Ein Known Issue Rollback wird in dem Eintrag nicht genannt. Ein Deinstallieren von KB5124008 ist wegen der darin enthaltenen Sicherheitskorrekturen nur als letzte Option sinnvoll.

So prüfen Admins ihre Umgebung

Die Prüfung dauert wenige Minuten und lässt sich vor dem nächsten Rollout-Ring durchziehen. Wichtig ist die Reihenfolge: erst feststellen, ob die Funktion überhaupt gesetzt ist, danach den Patchstand und zuletzt den Zustand des sicheren Kanals.

# 1. Ist Machine Identity Isolation gesetzt? Beide Pfade pruefen
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v MachineIdentityIsolation
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v MachineIdentityIsolation

# 2. Ist KB5124008 oder ein spaeteres Update installiert?
wmic qfe list brief /format:table

# 3. Zustand des sicheren Kanals pruefen, ohne ihn zu veraendern
powershell -Command "Test-ComputerSecureChannel -Verbose"

# 4. Gegenprobe ueber nltest
nltest /sc_verify:FIRMA.LOCAL

Liefert Test-ComputerSecureChannel den Wert False oder meldet nltest einen Fehler im Umfeld des LSA-Geheimnisses des Computerkontos, passt das Bild zum beschriebenen Known Issue. Zusätzlich lohnt ein Blick in das Ereignisprotokoll unter System auf Netlogon-Einträge sowie unter Sicherheit auf gescheiterte Kerberos-Anmeldungen, die anschließend auf NTLM zurückfallen. Genau diese Abfolge haben mehrere Administratoren in ihren Berichten beschrieben.

Registry-Werte und ihre Bedeutung

Der gesamte Fehler hängt an einem einzigen Wert, der an zwei Stellen liegen kann. Der Pfad unter Policies wird von Gruppenrichtlinien und Intune beschrieben, der Pfad unter Lsa enthält die wirksame Einstellung.

Wert	Modus	Wirkung auf domänengebundene Clients
`0` oder nicht vorhanden	Deaktiviert	Computerkonto-Geheimnis bleibt im LSA, Anmeldung an der Domäne funktioniert wie bisher.
`1`	Überwachung	Windows protokolliert, greift aber nicht ein. In Berichten dennoch als Auslöser genannt, von Microsoft nicht als Ursache benannt.
`2`	Erzwingung	Geheimnis wandert nach Credential Guard, LSA-Kopie entfällt. Ohne Domänenfunktionsebene Windows Server 2025 bricht der sichere Kanal.

Beide zu prüfenden Pfade lauten HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation und HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation. Vor jeder Änderung an der Registry gehört eine Sicherung der betroffenen Schlüssel dazu, darauf weist auch Microsoft im Workaround ausdrücklich hin.

Was sollten Admins jetzt tun?

Erst die Betroffenheit klären: In Intune, in der Gruppenrichtlinienverwaltung und per Registry-Abfrage prüfen, ob Machine Identity Isolation in der Umgebung jemals ausgerollt wurde. Ist der Wert nirgends gesetzt, besteht kein Handlungsbedarf.
Domänenfunktionsebene feststellen: Mit Get-ADDomain die aktuelle Funktionsebene ermitteln. Liegt sie unterhalb von Windows Server 2025, ist die Funktion in dieser Domäne nicht unterstützt und muss deaktiviert werden.
Rollout anhalten: Solange die Prüfung läuft, KB5124008 über WSUS, Windows Update for Business oder Intune für die verbleibenden Ringe pausieren. Das betrifft die Verteilung, nicht die Sicherheitsstrategie insgesamt.
Workaround gezielt setzen: Die Funktion mit demselben Verwaltungsweg deaktivieren, über den sie aktiviert wurde. Wurde sie per Intune verteilt, ist die Richtlinie in Intune zurückzunehmen, bei Gruppenrichtlinien entsprechend im GPO, und nur bei direkt gesetzten Registry-Werten wird der Wert von 2 auf 0 geändert.
Sicheren Kanal reparieren: Nach dem Deaktivieren das Gerät neu starten und anschließend den Kanal zurücksetzen, ohne den Rechner aus der Domäne zu nehmen.
Hochrisikosysteme zuerst: Arbeitsplätze in Produktion, Leitstand, Empfang oder Kasse zuerst behandeln, weil dort ein blockierter Anmeldevorgang direkt auf den Betrieb durchschlägt.
Protokolle auswerten: Netlogon- und Kerberos-Ereignisse der letzten Tage durchsehen, um weitere Geräte zu finden, die den Kanal bereits verloren haben, aber noch mit zwischengespeicherten Anmeldeinformationen laufen.
Deinstallation nur als letzte Stufe: Wenn der Workaround in der eigenen Umgebung nicht greift, lässt sich KB5124008 entfernen. Das nimmt dem System jedoch die September-Sicherheitskorrekturen, deshalb nur befristet und mit Wiedervorlage.
Wiederherstellung absichern: Vor Änderungen an Registry und Richtlinien eine aktuelle Sicherung der Clients und der Gruppenrichtlinien vorhalten, damit ein misslungener Eingriff nicht in einer Neuaufnahme in die Domäne endet.

Der von Microsoft dokumentierte Reparaturschritt für den sicheren Kanal ist ein einzelner PowerShell-Aufruf mit administrativen Rechten und einem Domänenkonto, das den Computer zurücksetzen darf:

# Nach dem Deaktivieren und einem Neustart ausfuehren
# Fragt nach Domaenen-Anmeldedaten mit ausreichender Berechtigung
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Dieser Weg stellt die Vertrauensstellung wieder her, ohne den Rechner aus der Domäne zu entfernen und neu aufzunehmen. Das spart gegenüber einer Neuaufnahme sowohl das Zurücksetzen von Gruppenrichtlinienzuweisungen als auch das erneute Anwenden von Zertifikaten und Softwareverteilung.

Unbestätigte Berichte sauber einordnen

Neben der offiziellen Erklärung kursieren weitere Deutungen, die bislang nicht von Microsoft bestätigt sind und deshalb nicht als Arbeitsgrundlage taugen. In deutschsprachigen Leserberichten auf Borns IT- und Windows-Blog vom 11. September 2026 wird eine Regression bei der Aushandlung des sicheren Netlogon-Kanals zwischen Windows-11-Clients und Domänencontrollern unter Windows Server 2019 vermutet, teils in Verbindung mit Secure-Boot-Fehlern nach der Update-Installation auf bestimmten Geräteserien. Als Indiz wird dort der Fehler ERROR_NO_TRUST_LSA_SECRET mit dem Code 1786 aus nltest genannt.

Dieses Fehlerbild passt zur Beschreibung von Microsoft, die Ursachenzuschreibung auf Netlogon ist aber eine Vermutung aus einem Forenbeitrag und keine Herstelleraussage. Ebenfalls unbestätigt ist die Beobachtung einzelner Administratoren, dass bereits der Wechsel vom Überwachungs- in den deaktivierten Modus zu Ausfällen führen kann, auch auf Systemen ohne KB5124008. Wer diesen Fall befürchtet, sollte die Umstellung zuerst an wenigen Testgeräten durchführen und erst danach breit ausrollen.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen mit lokalem Active Directory ist der praktische Kern dieser Meldung weniger der Fehler selbst als die Mechanik dahinter. Eine Sicherheitsfunktion, die vor Monaten testweise per Richtlinie gesetzt und dann vergessen wurde, blieb solange folgenlos, bis ein reguläres Sicherheitsupdate sie plötzlich beachtet. Genau dieses Muster trifft Umgebungen, in denen Richtlinien wachsen, aber selten aufgeräumt werden.

Daraus folgen zwei Dinge für den Alltag. Erstens gehört eine Inventur der aktiven Sicherheitsrichtlinien in den Wartungsplan, insbesondere für Einstellungen rund um Credential Guard und virtualisierungsbasierte Sicherheit, deren Voraussetzungen an die Domänenfunktionsebene geknüpft sind. Zweitens zeigt der Fall erneut den Wert gestaffelter Update-Ringe: Ein erster Ring mit wenigen repräsentativen Domänenclients hätte den Ausfall in diesem Fall vor dem breiten Rollout sichtbar gemacht, weil das Problem reproduzierbar nach dem ersten Neustart auftritt.

KB5124008 ist zudem nicht das einzige gemeldete Problem dieses Updates. Microsoft führt für denselben Patch weitere Einträge, darunter Störungen an USB-Audiogeräten mit Code 10 sowie Instabilitäten der Remotedesktopdienste, letztere inzwischen mit dem Out-of-Band-Update KB5129195 vom 14. September 2026 behoben. Wer ohnehin noch nicht flächendeckend verteilt hat, sollte den September-Rollout daher insgesamt einmal sauber durchplanen statt einzelne Symptome nachzuziehen.

Passende Anleitungen auf S-EDV

Windows 11: USB-Audio fällt nach KB5124008 aus, Code 10 im Geräte-Manager: das zweite bestätigte Known Issue desselben Updates, inklusive Einordnung des RDS-Problems.
Windows-Updates mit WSUS und Update for Business steuern: wie sich Update-Ringe aufbauen und einzelne Patches gezielt pausieren lassen.
Gruppenrichtlinien: Grundlagen und Praxis: nützlich, um vergessene Richtlinieneinstellungen wie Machine Identity Isolation zu finden und zurückzunehmen.

Quellen

Alle Quellen abgerufen am 17. September 2026.