Windows 11 KB5124008: Microsoft bestätigt jetzt offiziell die Probleme mit der Domänen-Vertrauensstellung

Vor zwei Tagen hatte ich bereits darüber berichtet, dass KB5124008 bei Windows-11-Rechnern die Vertrauensstellung zur Active-Directory-Domäne beschädigen kann und dass auch das außerplanmäßige Update KB5129195 dieses Problem nicht behebt. Mein bisheriger Beitrag zu KB5124008 und KB5129195

Damals basierten die Erkenntnisse vor allem auf reproduzierbaren Berichten von Administratoren. Inzwischen gibt es ein wichtiges Update: Microsoft hat den Fehler offiziell bestätigt und nennt nun auch die genaue Ursache.

Damit wissen wir jetzt deutlich besser, was hier eigentlich passiert.

Was ich bereits im vorherigen Beitrag beschrieben hatte

Das Fehlerbild war ziemlich eindeutig:

Nach der Installation des September-Sicherheitsupdates KB5124008 konnten bestimmte Windows-11-Clients plötzlich ihre sichere Verbindung zur Domäne verlieren.

Betroffene Rechner meldeten beispielsweise, dass:

• die Vertrauensstellung zur Domäne fehlgeschlagen ist

• die Anmeldung mit gültigen Domänen-Zugangsdaten nicht mehr funktioniert

• der Secure Channel beschädigt ist

• nltest beziehungsweise Netlogon Fehler melden

• eine Offline-Anmeldung mit zwischengespeicherten Zugangsdaten weiterhin möglich ist

In meinem vorherigen Beitrag hatte ich außerdem beschrieben, dass Machine Identity Isolation auffällig häufig mit dem Problem zusammenhing. Das Deaktivieren der Funktion und eine anschließende Reparatur des Secure Channels half in mehreren Umgebungen. (SeiboldSoft Blog)

Genau dieser Verdacht wurde jetzt von Microsoft bestätigt.

Microsoft nennt Machine Identity Isolation als Ursache

Microsoft erklärt inzwischen, dass KB5124008 und spätere Updates dafür sorgen, dass Windows vorhandene Einstellungen für Machine Identity Isolation tatsächlich berücksichtigt und durchsetzt.

Das ist ein wichtiger Unterschied.

Das Update setzt die Funktion also nicht einfach überall neu auf „aktiv“. Wenn Machine Identity Isolation allerdings bereits:

• per Gruppenrichtlinie

• über Intune

• oder direkt über die Registry

konfiguriert wurde, greift diese Einstellung nach dem Update plötzlich tatsächlich.

Und genau das kann die Domänenanmeldung beschädigen.

Der entscheidende Punkt: Windows Server 2025 Domain Functional Level

Microsoft nennt jetzt eine ziemlich klare Voraussetzung:

Machine Identity Isolation wird nur für Umgebungen unterstützt, die mindestens mit Windows Server 2025 Domain Functional Level arbeiten.

In älteren Active-Directory-Umgebungen sollte die Funktion deaktiviert sein.

Das erklärt auch, warum die ersten Berichte insbesondere aus Umgebungen mit Windows Server 2019 und später auch Windows Server 2022 als Domain Controller kamen.

Genau dort kann die neue Durchsetzung zum Problem werden. Berichte zu dem inzwischen bestätigten Problem nennen Windows 11 24H2, 25H2 und 26H1 als betroffene Client-Plattformen.

Das passt exakt zu den bisherigen Beobachtungen

Damit ergibt das Ganze rückblickend deutlich mehr Sinn.

In meinem vorherigen Beitrag hatte ich bereits beschrieben, dass Administratoren den Wert:

MachineIdentityIsolation

teilweise auf:

2

vorfanden.

Nachdem dieser auf:

0

gesetzt wurde, konnte die Vertrauensstellung in mehreren Fällen wiederhergestellt werden.

Damals war das noch ein aus der Praxis ermittelter Workaround.

Jetzt empfiehlt Microsoft genau diesen Weg offiziell.

Microsoft nennt zwei Registry-Pfade

Falls Machine Identity Isolation direkt über die Registry aktiviert wurde, sollen Administratoren unter Windows 11 24H2 beziehungsweise 25H2 folgende Pfade prüfen:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation

sowie:

HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

Steht dort:

MachineIdentityIsolation = 2

soll der Wert laut Microsoft auf:

0

geändert werden. Anschließend muss der Rechner neu gestartet werden.

Nicht einfach die Registry ändern, wenn eine Richtlinie dahintersteckt

Das ist für Unternehmensumgebungen wichtig.

Wenn Machine Identity Isolation über Intune aktiviert wurde, sollte sie auch über Intune deaktiviert werden.

Wurde sie über eine Gruppenrichtlinie gesetzt, sollte die entsprechende GPO geändert werden.

Nur wenn die Einstellung tatsächlich direkt in der Registry vorgenommen wurde, sollte man dort eingreifen.

Sonst besteht die Gefahr, dass eine Richtlinie den Wert beim nächsten Refresh einfach wieder zurücksetzt.

Danach den Secure Channel reparieren

Allein das Deaktivieren von Machine Identity Isolation reicht bei einem bereits betroffenen Rechner unter Umständen nicht aus.

Die beschädigte Vertrauensstellung muss anschließend noch repariert werden.

Microsoft nennt dafür folgenden PowerShell-Befehl:

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

Danach werden die Anmeldedaten eines entsprechend berechtigten Kontos abgefragt.

Wenn die Reparatur erfolgreich durchläuft, sollte die sichere Verbindung zur Domäne anschließend wieder funktionieren.

KB5129195 war also tatsächlich nicht die Lösung

Das ist auch im Hinblick auf meinen vorherigen Artikel interessant.

Microsoft hatte kurz nach dem September-Patchday mit KB5129195 ein außerplanmäßiges Update veröffentlicht.

Damit wurden unter anderem Probleme bei:

• Remote Desktop

• USB-Audio

• Hyper-V

behoben.

Die beschädigte Domänen-Vertrauensstellung gehörte allerdings nicht dazu.

Deshalb blieb das Problem auch nach Installation von KB5129195 bestehen – genau wie bereits in den ersten Administrator-Berichten beobachtet.

Status „Mitigated“ bedeutet noch nicht behoben

Microsoft führt das Problem aktuell als „Mitigated“.

Das bedeutet nicht, dass KB5124008 inzwischen automatisch repariert wurde.

Vielmehr gibt es jetzt einen dokumentierten Workaround.

Microsoft plant nach aktuellem Stand ein zukünftiges Windows-Update, das die Durchsetzung von Machine Identity Isolation vorübergehend verhindern soll, während die Funktion weiter überarbeitet wird.

Ein endgültiger Fix ist also noch nicht da.

Wer sollte jetzt genauer hinschauen?

Besonders interessant ist das Thema für Unternehmen mit:

Windows 11 + lokalem Active Directory + älteren Domain Controllern.

Ich würde dort jetzt konkret prüfen:

• Ist Machine Identity Isolation irgendwo per GPO gesetzt?

• Gibt es eine entsprechende Intune-Richtlinie?

• Steht MachineIdentityIsolation auf 2?

• Welches Domain Functional Level verwendet die Umgebung?

• Gibt es nach KB5124008 Netlogon- oder Secure-Channel-Fehler?

• funktionieren Offline-Anmeldungen, aber Online-Anmeldungen nicht?

Gerade bei größeren Umgebungen würde ich nicht anfangen, betroffene Rechner massenhaft aus der Domäne zu nehmen und wieder hinzuzufügen, bevor diese Einstellung geprüft wurde.

Fazit

Damit ist jetzt offiziell bestätigt, was sich in den vergangenen Tagen bereits ziemlich deutlich abgezeichnet hatte.

KB5124008 sorgt dafür, dass vorhandene Einstellungen für Machine Identity Isolation wirksam werden. In Active-Directory-Umgebungen unterhalb von Windows Server 2025 Domain Functional Level kann das dazu führen, dass Windows-11-Clients ihre sichere Vertrauensstellung zur Domäne verlieren.

Mein vorheriger Beitrag lag damit bei der entscheidenden Spur richtig: Machine Identity Isolation war tatsächlich der Knackpunkt. (SeiboldSoft Blog)

Die gute Nachricht ist, dass wir jetzt eine offizielle Erklärung und einen dokumentierten Workaround haben.

Die weniger gute Nachricht: Einen endgültigen Fix gibt es weiterhin nicht.

Wer betroffen ist, sollte Machine Identity Isolation kontrolliert deaktivieren, den Rechner neu starten und anschließend den Secure Channel reparieren – und danach auf das angekündigte Windows-Update von Microsoft warten.