Die Vertrauensstellung zur Domäne ist einer der stillen Helden im Active Directory – bis sie plötzlich weg ist. Genau das ist seit September 2026 vielen Windows-11-Admins passiert: Nach der Installation von KB5124008 verloren zahlreiche Rechner ihre Vertrauensstellung zur Domäne, und Nutzer konnten sich trotz korrekter Zugangsdaten nicht mehr anmelden. Das Problem ist zwar aktuell, allerdings kein Einzelfall. Windows Updates greifen tief in die Authentifizierung ein und können die Vertrauensstellung zwischen Arbeitsstation und Domäne jederzeit beschädigen.
KB5124008 als aktueller Auslöser – ein wiederkehrendes Problem
Laut Berichten auf Reddit und in Microsofts Q&A-Forum verloren betroffene Windows-11-25H2-Geräte nach einem Neustart ihre sichere Verbindung zu Active Directory. Ein Administrator meldete, dass 11 von rund 256 aktualisierten Geräten in seinem Netzwerk die Vertrauensstellung verloren. Auffällig: Zwischengespeicherte Anmeldedaten funktionierten weiterhin offline, während die Domänenanmeldung fehlschlug – ein klares Indiz dafür, dass nicht das Nutzerpasswort, sondern der Secure Channel selbst betroffen war. Microsoft hat das Problem gegenüber BleepingComputer bestätigt und untersucht es aktuell noch.
Was ist die Vertrauensstellung (Secure Channel) zwischen Client und Domain Controller wirklich?
Jeder domänenbeigetretene Rechner besitzt ein eigenes Computerkonto in Active Directory, inklusive eines automatisch generierten Kennworts. Dieses Kennwort wird lokal in der LSA (Local Security Authority) gespeichert und alle 30 Tage automatisch erneuert. Client und Domain Controller nutzen dieses gemeinsame Geheimnis, um den sogenannten Secure Channel aufzubauen – die Basis für Kerberos- und NTLM-Authentifizierung. Stimmen die lokal gespeicherten Anmeldedaten nicht mehr mit dem Wert in Active Directory überein, bricht die Vertrauensstellung zusammen. Das Ergebnis: Nutzer erhalten Fehlermeldungen, obwohl ihr Passwort korrekt ist.
Warum Windows Updates die Vertrauensstellung zur Domäne stören können
Updates verändern regelmäßig, wie Windows mit Computerkonto-Kennwörtern, NTLM-Fallbacks und Kerberos-Tickets umgeht. Deshalb reicht schon eine kleine Änderung an der Sicherheitsarchitektur, um die Vertrauensstellung zu gefährden. Bei KB5124008 deutet vieles auf eine Funktion namens Machine Identity Isolation hin, die Teil der Virtualization-Based Security (VBS) und von Credential Guard ist.
Machine Identity Isolation als vermuteter Auslöser
Machine Identity Isolation isoliert das Computerkonto-Geheimnis in Credential Guard. Im Enforcement-Modus entfernt Windows die klassische Kopie aus der LSA vollständig. Mehrere Admins berichteten, dass der Registry-Wert nach der Installation von KB5124008 automatisch auf den Wert 2 (Enforcement) gesetzt wurde:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
"MachineIdentityIsolation" = 2In diesem Modus verwarf Windows offenbar das lokale LSA-Secret, wodurch die Vertrauensstellung zwischen Arbeitsstation und Domäne nicht mehr hergestellt werden konnte. Allerdings ist Vorsicht geboten: Wer den Wert einfach auf 0 setzt, riskiert laut Microsoft-Dokumentation zu Credential Guard ebenfalls einen Bruch der Vertrauensstellung, wenn das Feature zuvor im Enforcement-Modus aktiv war. In diesem Fall bleibt oft nur ein Domain-Rejoin.
Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne: Symptome erkennen
Das klassische Symptom ist die Fehlermeldung: „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“ Zusätzlich zeigen betroffene Systeme oft:
- Anmeldung mit Domänenkonto schlägt fehl, obwohl das Passwort korrekt ist
- Cached Credentials funktionieren weiterhin (Offline-Anmeldung möglich)
- Kerberos-Fehler im Event-Log, gefolgt von NTLM- und Netlogon-Fallbacks
- Fehlerhafte Anmeldung tritt reproduzierbar nach jedem Neustart auf
Diese Symptome solltest du in jedem Fall dokumentieren, bevor du mit der Reparatur startest – das hilft später bei der Nachbereitung im Rahmen eines Incident Response Plans, falls der Ausfall größere Kreise zieht.
Vertrauensstellung zur Domäne überprüfen: Diagnose mit Bordmitteln
Bevor du reparierst, solltest du die Vertrauensstellung sauber prüfen. Windows liefert dafür bereits alle nötigen Werkzeuge mit.
# Secure Channel testen
Test-ComputerSecureChannel -Verbose
# Alternative über nltest
nltest /sc_query:contoso.localZusätzlich lohnt sich ein Blick ins System-Log. Achte auf Event-ID 5719 (Netlogon-Fehler) sowie auf Kerberos-Fehlermeldungen mit Fehlercode KRB_AP_ERR_MODIFIED. Beides deutet zuverlässig auf ein defektes Computerkonto-Kennwort und damit auf eine gebrochene Vertrauensstellung hin.
Vertrauensstellung neu einrichten: Schnelle Reparatur ohne Neubeitritt
In den meisten Fällen lässt sich die Vertrauensstellung ohne kompletten Domain-Rejoin reparieren. Am zuverlässigsten funktioniert das über PowerShell, direkt auf dem betroffenen Client mit einem Konto, das Rechte zum Zurücksetzen des Computerkontos besitzt.
# Als Administrator ausführen
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Alternativ funktioniert auch der klassische Weg über netdom oder das PowerShell-Cmdlet Reset-ComputerMachinePassword:
netdom resetpwd /server:DC01 /userd:contoso\Administrator /passwordd:*
# oder
Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential)Anschließend startest du den Client neu. War die Ursache tatsächlich ein abweichendes Computerkonto-Kennwort, ist die Vertrauensstellung danach in der Regel sofort wiederhergestellt. Mehrere Admins meldeten in den Foren genau diesen Ablauf als erfolgreiche Lösung – wichtig ist dabei, vorher den Wert von Machine Identity Isolation zu prüfen und gegebenenfalls anzupassen, bevor du die Reparatur startest.
Wann ein Domain-Rejoin unumgänglich ist
Reicht die einfache Reparatur nicht aus, bleibt nur der komplette Weg über Austritt und erneuten Beitritt zur Domäne. Das ist vor allem dann nötig, wenn Machine Identity Isolation zuvor im Enforcement-Modus lief und danach deaktiviert wurde – laut Microsoft-Dokumentation bricht das die Vertrauensstellung endgültig, ein einfacher Reset reicht dann nicht mehr.
# Rechner aus der Domäne entfernen
Remove-Computer -UnjoinDomainCredential (Get-Credential) -Restart
# Nach Neustart wieder beitreten
Add-Computer -DomainName contoso.local -Credential (Get-Credential) -RestartBei größeren Stückzahlen solltest du diesen Prozess automatisieren, etwa über ein PowerShell-Skript im Rahmen von Intune-Remediation oder einem Startup-Task. So vermeidest du manuelle Klickarbeit auf jedem einzelnen Client.
KB5124008 im Detail: Was Microsoft bisher bestätigt hat
Microsoft hat bestätigt, an dem Problem zu arbeiten, bislang aber keine offizielle Ursache oder einen offiziellen Workaround veröffentlicht. Betroffene Admins berichten übereinstimmend, dass die Deinstallation von KB5124008 in Kombination mit einer Reparatur der Vertrauensstellung das Problem zuverlässig behebt – eine erneute Installation lässt den Fehler jedoch wieder auftreten. Wer das Update noch nicht ausgerollt hat, sollte es daher vorerst in einem Pilotring testen, bevor eine breite Verteilung erfolgt.
Patch-Management-Lessons: Pilotringe und Monitoring
Der Fall KB5124008 zeigt erneut, wie wichtig gestaffelte Rollouts sind. Setze Updates zuerst auf einer kleinen Testgruppe ein, die repräsentativ für deine Domänenumgebung ist. Beobachte anschließend gezielt Event-ID 5719 und Anmeldefehler im Security-Log. Zudem hilft ein einfaches Monitoring-Skript, das täglich per Test-ComputerSecureChannel den Status aller Clients prüft und Abweichungen meldet, bevor Nutzer den Helpdesk anrufen. Wer ohnehin regelmäßig Systemdateien mit sfc /scannow repariert, sollte diesen Check direkt in dieselbe Wartungsroutine integrieren.
Fazit: Checkliste für Sysadmins bei Domain-Trust-Problemen
Bricht die Vertrauensstellung nach einem Patch-Day, hilft ein strukturiertes Vorgehen: Zuerst Symptome und Event-Logs dokumentieren, dann mit Test-ComputerSecureChannel oder nltest die Vertrauensstellung überprüfen, anschließend gezielt reparieren – ohne Neubeitritt, wenn möglich. Bei KB5124008 lohnt zusätzlich ein Blick auf den Registry-Wert von Machine Identity Isolation. Und langfristig gilt: Pilotringe und sauberes Monitoring sparen dir am nächsten Patch-Day viel Ärger. Wer zusätzlich ein sauberes Active-Directory-Backup vorhält, ist auch bei größeren Ausfällen abgesichert, und wer die passenden PowerShell-Parameter kennt, repariert die Vertrauensstellung in wenigen Minuten.
FAQ
Was bedeutet die Fehlermeldung “Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden”?
Diese Meldung zeigt, dass das lokal gespeicherte Computerkonto-Kennwort nicht mehr mit dem Wert in Active Directory übereinstimmt. Die Vertrauensstellung ist dadurch unterbrochen, obwohl das Nutzerpasswort selbst korrekt bleibt.
Wie überprüfe ich die Vertrauensstellung zur Domäne?
Am schnellsten geht das mit dem PowerShell-Cmdlet Test-ComputerSecureChannel oder alternativ mit nltest /sc_query. Beide Befehle zeigen sofort, ob der Secure Channel zum Domain Controller intakt ist.
Wie richte ich die Vertrauensstellung neu ein, ohne den Rechner aus der Domäne zu entfernen?
Führe Test-ComputerSecureChannel -Repair mit einem berechtigten Konto aus, oder nutze alternativ netdom resetpwd beziehungsweise Reset-ComputerMachinePassword. In den meisten Fällen ist die Vertrauensstellung danach ohne erneuten Domänenbeitritt wiederhergestellt.
Was tun, wenn die Vertrauensstellung nach einem Windows Update verloren geht?
Prüfe zuerst, ob wie bei KB5124008 eine Sicherheitsfunktion wie Machine Identity Isolation die Ursache ist. Hilft eine Reparatur nicht, bleibt als letzter Schritt nur, den Rechner aus der Domäne zu entfernen und sauber neu beizutreten.