Ein aktuelles Sicherheitsupdate für Windows 11 sorgt in einigen Unternehmen für erhebliche Probleme: Nach der Installation von KB5124008 (Build 26200.9445) verlieren domänengebundene Windows-Clients offenbar ihre Vertrauensstellung zur Active-Directory-Domäne. Die Folge: Nutzer können sich am betroffenen Rechner nicht mehr anmelden, obwohl Benutzername und Kennwort korrekt sind. Ein Administrator hat das Verhalten in der Microsoft-Community beschrieben, reproduziert und einen vorläufigen Workaround gefunden.

Was nach der Installation von KB5124008 passiert

Laut dem dokumentierten Fall betrifft das Problem domänengejointe Arbeitsplatzrechner unter Windows 11 (25H2). Nach dem Einspielen des Updates bricht die sogenannte Secure-Channel-Beziehung (die Vertrauensbeziehung zwischen Client und Domänencontroller) weg. In der Praxis äußert sich das dadurch, dass die interaktive Anmeldung am Gerät scheitert.

Der Administrator konnte den Fehler auf mehreren Systemen zuverlässig nachstellen und hat daraufhin den unternehmensweiten Rollout des Updates zunächst gestoppt.

Symptome: Anmeldung schlägt fehl – trotz korrekter Daten

Bei der Anmeldung erscheint eine Meldung, die sinngemäß behauptet, Benutzername oder Kennwort seien falsch. Gleichzeitig funktioniert eine Offline-Anmeldung mit zwischengespeicherten Anmeldedaten weiterhin, was den Verdacht auf ein Problem in der Domänenkommunikation lenkt.

Zur Diagnose wurden unter anderem diese Hinweise genannt:

– Das PowerShell-Diagnosekommando „Test-ComputerSecureChannel“ liefert „False“.
– „nltest“ meldet den Fehler ERROR_NO_TRUST_LSA_SECRET.
– Auf den Domänencontrollern (im beschriebenen Fall Windows Server 2019) taucht parallel Ereignis 4625 im Security-Log auf. Betroffen ist dabei das Computerkonto, und es wird ein fehlgeschlagener NTLM-Logon protokolliert.
– Netzwerkbasierte Anmeldungen können mit denselben Zugangsdaten weiterhin funktionieren, während die lokale, interaktive Anmeldung am Client scheitert.

Typische Ursachen wurden ausgeschlossen

Im Forumseintrag wird beschrieben, dass der Administrator mehrere bekannte Fehlerquellen systematisch überprüft und ausgeschlossen hat. Dazu zählen unter anderem doppelte SIDs, Probleme mit Kennwortrotationen, DNS- oder Replikationsprobleme, Zeitabweichungen sowie Kontosperrungen. Das Verhalten blieb jedoch eindeutig an die Installation des Updates gekoppelt.

Standard-Reparaturen reichen nicht aus

Um den defekten Vertrauenskanal wiederherzustellen, reichten übliche Maßnahmen wie das reine Zurücksetzen des Computerkennworts offenbar nicht. Erst ein kompletter Domänen-Austritt und anschließender erneuter Domänen-Beitritt stellte die Funktionsfähigkeit wieder her.

Wird das Update danach erneut installiert, tritt das Problem laut Bericht wieder auf. Diese Reproduzierbarkeit spricht stark dafür, dass die Ursache im Update bzw. in einer damit aktivierten Sicherheitsfunktion liegt – und nicht in einer individuellen Netzwerk- oder AD-Fehlkonfiguration.

Ursache laut Forum: „Machine Identity Isolation“ im Enforcement-Modus

Gemeinsam mit anderen Nutzern wurde als Auslöser eine Funktion namens „Machine Identity Isolation“ identifiziert. Sie war im „Enforcement“-Modus aktiv und soll in dieser Konstellation die Aushandlung des sicheren Kanals zum Domänencontroller blockieren.

Als Workaround wurde die Funktion deaktiviert – sowohl per Gruppenrichtlinie als auch über die Intune-Sicherheitsbaseline. Da die GPO den gewünschten Wert auf den Clients offenbar nicht zuverlässig setzte, wurde zusätzlich ein entsprechender Registry-Wert manuell erzwungen.

Der Administrator plant, die Funktion nach den nächsten Patch-Runden erneut testweise zu aktivieren, um zu prüfen, ob Microsoft das Problem inzwischen behoben hat. Eine offizielle Stellungnahme oder ein Hotfix wurde zum Zeitpunkt der Meldung noch nicht genannt.