Windows 11: Vertrauensstellung zur Domäne fehlgeschlagen – was tun?

„Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“ bedeutet nicht automatisch, dass das Benutzerkennwort falsch ist. Häufig ist der sichere Verbindungskanal zwischen Computer und Active Directory gestört. Seit dem September-Update 2026 gibt es zusätzlich einen dokumentierten Sonderfall mit Machine Identity Isolation.

Die folgende Anleitung richtet sich an Administratoren von Windows-11-Rechnern mit klassischem AD-Domänenbeitritt. Sie ist keine Reparaturanleitung für reine Microsoft-Entra-Join-Geräte und nicht für Domänencontroller gedacht. Recherche-Stand: 20. September 2026.

Was steckt hinter der fehlgeschlagenen Vertrauensstellung?

Auch ein Domänencomputer besitzt ein eigenes Konto und ein Kennwort. Wenn die lokal gespeicherten Informationen nicht mehr zur Kopie im Active Directory passen, kann die Computerauthentifizierung scheitern. Ebenso können Netzwerkprobleme den sicheren Kanal unterbrechen. Microsoft nennt beide Ursachen ausdrücklich in seiner Dokumentation zu Secure-Channel-Problemen.

Eine Anmeldung mit zwischengespeicherten Zugangsdaten beweist deshalb nicht, dass die Verbindung zur Domäne funktioniert. Umgekehrt ist ein fehlgeschlagener Verbindungstest ohne erreichbaren Domänencontroller noch kein Nachweis für ein falsches Computerkontokennwort. Prüfe die Voraussetzungen, bevor du Konten zurücksetzt.

Aktuell: Vertrauensstellung nach KB5124008 gestört

Microsoft meldet seit dem 16. September 2026 einen Fehler nach KB5124008 vom 8. September 2026 oder späteren Updates. Betroffen sein können Windows 11 24H2, 25H2 und 26H1 mit entsprechend konfigurierten, durch Credential Guard geschützten Computerkonten. Die Anmeldung kann trotz gültiger Benutzerdaten scheitern; zwischengespeicherte Offline-Anmeldungen können weiter funktionieren.

Die Tabelle gilt ausschließlich für 24H2 und 25H2. Microsoft führt den Vorfall zum Recherchezeitpunkt als „Mitigated“, also mit einer Zwischenlösung. Eine allgemeine endgültige Korrektur ist im Eintrag noch angekündigt. Quelle: Windows Release Health für Windows 11 25H2 und 24H2.

1. Zuerst lokalen Zugang und Domänennetz prüfen

Sichere vor Änderungen einen funktionierenden lokalen Administratorzugang. Im Anmeldefeld bezeichnet beispielsweise .\LokalerAdmin ein lokales Konto; „LokalerAdmin“ musst du durch den tatsächlichen Kontonamen ersetzen. Ein vorhandenes Benutzerprofil allein garantiert keinen administrativen Zugang. Bei Remote-Arbeit muss nach einem Neustart auch der benötigte Verwaltungs- oder VPN-Zugang wieder verfügbar sein.

Öffne am betroffenen Rechner die Eingabeaufforderung und lies die Netzwerkkonfiguration aus:

ipconfig /all

Kontrolliere den tatsächlich verwendeten Netzwerkadapter, seine IP-Konfiguration und die eingetragenen DNS-Server. Vergleiche sie mit der vorgesehenen Konfiguration deines Unternehmens. Ein öffentlicher DNS-Server löst interne AD-Namen normalerweise nicht auf; trage aber keine geratenen Serveradressen ein. Bei VPN-Verbindungen muss auch die interne Namensauflösung funktionieren. Der Befehl verändert nichts. Referenz: ipconfig.

Behebe festgestellte Verbindungsprobleme zuerst. Ein bloßer Internetzugang oder erfolgreicher Ping reicht als Nachweis für eine funktionierende AD-Kommunikation nicht aus. Microsoft verweist bei Secure-Channel-Störungen ausdrücklich auf die benötigten Netzwerkverbindungen und Ports.

2. Sicheren Kanal mit PowerShell testen

Starte Windows PowerShell als Administrator auf dem betroffenen Mitgliedsrechner:

Test-ComputerSecureChannel -Verbose

• True: Der geprüfte sichere Kanal funktioniert zu diesem Zeitpunkt.
• False: Der Test war nicht erfolgreich. Lies die zusätzliche Ausgabe und prüfe die Verbindungsvoraussetzungen.
• Eine Fehlermeldung statt eines Ergebnisses muss separat ausgewertet werden.

Auf Domänencontrollern ist dieser Test ungeeignet. Microsoft warnt dort vor irreführenden Fehlerergebnissen. Dokumentation: Test-ComputerSecureChannel.

Notiere außerdem über winver Windows-Version und Build sowie im Windows-Updateverlauf den Zeitpunkt der Aktualisierung. Wenn gleichzeitig viele gleich konfigurierte Rechner betroffen sind, ist die gemeinsame Konfiguration besonders relevant für die weitere Untersuchung.

3. Sonderfall prüfen: Machine Identity Isolation

Machine Identity Isolation verlagert die Zugangsdaten des AD-Computerkontos in die geschützte Umgebung von Credential Guard. Im Enforcement-Modus wird die bisherige Kopie in der Local Security Authority entfernt. Deshalb kann eine Änderung dieser Einstellung Auswirkungen auf die Computerauthentifizierung haben. Das ist eine eigene Funktion und nicht gleichbedeutend mit „Credential Guard insgesamt abschalten“. Hintergrund: Credential Guard protected machine accounts.

Laut aktueller Microsoft-Meldung beginnen die September-Updates, bereits vorhandene oder per Richtlinie verteilte Enforcement-Einstellungen zu berücksichtigen. Sie aktivieren Enforcement nicht pauschal auf jedem Gerät. Die dokumentierte Voraussetzung ist eine Domänenfunktionsebene Windows Server 2025 oder höher. Ein einzelner neuer Domänencontroller ist kein ausreichender Nachweis.

Die Funktionsebene kann ein Administrator beispielsweise auf einer Verwaltungsstation mit installiertem ActiveDirectory-PowerShell-Modul prüfen:

$adDnsName = Read-Host 'DNS-Name der betroffenen AD-Domaene'
Get-ADDomain -Identity $adDnsName |
    Select-Object DNSRoot, DomainMode

Verwende den tatsächlichen DNS-Namen deiner AD-Domäne. Das Modul ist nicht auf jedem Windows-Client installiert; eine fehlende Befehlsdefinition bedeutet daher nicht, dass die Domäne defekt ist. Eine Erhöhung der Funktionsebene ist eine eigenständige Infrastrukturänderung und gehört nicht in diese Fehlerbehebung. Referenz: Get-ADDomain.

Ob Credential Guard selbst läuft, lässt sich zusätzlich über msinfo32.exe unter den ausgeführten virtualisierungsbasierten Sicherheitsdiensten kontrollieren. Diese Anzeige bestätigt allein noch keinen Machine-Identity-Isolation-Enforcement-Modus. Quelle: Credential Guard überprüfen.

4. Nur beim passenden September-Sonderfall: Richtlinie korrigieren

Wenn die beschriebenen Voraussetzungen zutreffen, empfiehlt Microsoft, Machine Identity Isolation mit derselben Verwaltungsmethode zu deaktivieren, mit der sie eingerichtet wurde: Intune, Gruppenrichtlinie oder direkte Registry-Konfiguration. Gemeint ist die konkrete Machine-Identity-Isolation-Einstellung, nicht das pauschale Abschalten von VBS oder Credential Guard.

Für direkt per Registry konfigurierte Windows-11-Geräte mit 24H2 oder 25H2 nennt Microsoft diese Schlüssel:

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

Sichere die betroffenen Schlüssel und dokumentiere die ursprünglichen Werte. Laut Microsoft soll ein dort vorhandener Wert MachineIdentityIsolation mit dem Inhalt 2 auf 0 gesetzt werden. Lege fehlende Schlüssel nicht auf Verdacht an. Bei zentraler Verwaltung korrigiere die zuweisende Richtlinie, statt sie lokal zu übersteuern.

Danach ist ein Neustart vorgesehen, anschließend die Reparatur des sicheren Kanals. Die aktuelle, versionsbezogene Vorgehensweise steht im KB5124008-Artikel unter „Domain-joined devices“. Diese Zwischenlösung gilt nicht automatisch für jede fehlgeschlagene Vertrauensstellung.

5. Sicheren Kanal reparieren und Ergebnis kontrollieren

Wenn die Netzwerkverbindung funktioniert und gegebenenfalls die fehlerauslösende Einstellung korrigiert wurde, versuche in der administrativen Windows PowerShell:

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

Gib im Dialog ein Domänenkonto mit den erforderlichen Berechtigungen für die Reparatur an. Das Kennwort gehört nicht als Klartext in ein Skript. -Repair ist ein verändernder Schritt: Der sichere Kanal wird neu aufgebaut. Prüfe danach erneut:

Test-ComputerSecureChannel -Verbose

Teste die Domänenanmeldung bei bestehender Verbindung zum Domänennetz und den Zugriff auf eine berechtigte interne Ressource. Der lokale Administratorzugang bleibt für die Kontrolle verfügbar. Maßgeblich sind sowohl der Kanaltest als auch das ursprüngliche Fehlerszenario.

Was tun, wenn die Reparatur scheitert?

Halte den vollständigen Fehlertext fest. Prüfe mit der AD-Administration den Zustand des Computerobjekts, die verwendeten Berechtigungen und die Erreichbarkeit der zuständigen Domänencontroller. Netlogon-Ereignisse wie 5719, 5722 oder 5723 können zur Einordnung beitragen; sie sind kein eindeutiger Nachweis für den September-Bug.

Entferne den Computer nicht reflexartig aus der Domäne und lösche sein AD-Objekt nicht als ersten Versuch. Ein erneuter Domänenbeitritt kann nötig werden, sollte aber mit gesichertem lokalem Zugang und dokumentierter Geräteverwaltung erfolgen. Bei wiederkehrenden Fehlern muss die Ursache geklärt werden, statt nur den Kanal erneut zurückzusetzen.

Fazit

Die richtige Reihenfolge lautet: Zugang sichern, Domänennetz prüfen, sicheren Kanal testen und den aktuellen Update-Sonderfall gezielt abgleichen. Erst danach folgt die passende Reparatur. So bleibt erkennbar, ob ein Verbindungsproblem, das Computerkonto oder eine konkrete Sicherheitskonfiguration hinter der Meldung steckt.