Die Meldung über eine fehlgeschlagene Vertrauensstellung bedeutet, dass Windows den sicheren Kanal zwischen dem PC und der Active-Directory-Domäne nicht mehr bestätigen kann. Meist stimmen das lokale Computerkontokennwort und der im Active Directory gespeicherte Stand nicht mehr überein, oder der Rechner erreicht keinen passenden Domänencontroller. Prüfe zuerst Netzwerk, DNS und Uhrzeit; repariere danach den sicheren Kanal mit PowerShell. Das Entfernen und erneute Hinzufügen zur Domäne ist die Rückfalllösung, nicht der erste Schritt.
Ob Windows 11 tatsächlich als Version 26H2 installiert ist, lässt sich mit winver prüfen. Ohne bestätigte versionsbezogene Dokumentation sollte der Fehler nicht automatisch dem Funktionsupdate zugeschrieben werden: Eine Wiederherstellung, ein zurückgesetztes Computerkonto, ein geklonter Rechner oder ein DNS-Problem kann zeitlich mit dem Update zusammenfallen und denselben Anmeldefehler auslösen.
Was bei der Vertrauensstellung technisch nicht mehr stimmt
Ein Mitgliedscomputer besitzt in Active Directory ein eigenes Computerkonto. Zwischen diesem Konto und Windows besteht ein Kennwort, das der Rechner selbst verwaltet. Dieses Maschinenkennwort ist nicht das Kennwort des angemeldeten Benutzers. Weichen die beiden gespeicherten Zustände voneinander ab, kann der Domänencontroller die Identität der Arbeitsstation nicht mehr zuverlässig bestätigen.
Typisch ist dieser Zustand nach dem Zurückspielen eines älteren Systemabbilds oder Snapshots. Der PC verwendet dann möglicherweise ein älteres Maschinenkennwort, während Active Directory bereits den neueren Stand gespeichert hat. Auch ein manuell zurückgesetztes oder neu angelegtes Computerkonto, ein unsauber geklonter Rechner sowie widersprüchliche Replikationsstände zwischen Domänencontrollern kommen infrage.
Daneben gibt es Fehler, die ähnlich aussehen, obwohl der sichere Kanal nicht dauerhaft beschädigt ist. Verwendet der Client einen öffentlichen DNS-Server statt des internen AD-DNS, findet er die erforderlichen Domänendienste nicht. Eine stark abweichende Systemzeit kann die Kerberos-Authentifizierung verhindern. Im Homeoffice fehlt möglicherweise lediglich die VPN-Verbindung, bevor Windows einen Domänencontroller erreichen kann.
Vor der Reparatur den Zugriff auf den PC sichern
Für die folgenden Arbeiten brauchst du lokale Administratorrechte. Stelle vor Änderungen sicher, dass du dich mit einem bekannten lokalen Administratorkonto anmelden kannst. Ein Domänenkonto mit zwischengespeicherten Anmeldedaten reicht als Rückweg nicht zuverlässig aus, weil eine spätere Trennung von der Domäne die Anmeldung verändern kann.
Am Anmeldebildschirm lässt sich ein lokales Konto über den Computernamen oder mit diesem Präfix auswählen:
.\LokalerBenutzerFalls eine Domänenanmeldung noch über zwischengespeicherte Daten funktioniert, melde dich zunächst ohne Netzwerk oder vor Aufbau der VPN-Verbindung an. Sichere wichtige lokale Daten und prüfe anschließend, ob das lokale Administratorkonto tatsächlich funktioniert. Auf Firmenrechnern mit zentraler Verwaltung, BitLocker, Gerätezertifikaten, WLAN-Profilen oder Softwareverteilung sollte die IT-Abteilung die Reparatur übernehmen. Ein eigenmächtiger Domänenaustritt kann Verwaltungsrichtlinien und den Fernzugriff beeinträchtigen.
Die Ursache in einer festen Reihenfolge eingrenzen
- Versionsstand notieren: Öffne
winverund notiere Edition, Version und Betriebssystembuild. So lässt sich unterscheiden, ob der Fehler wirklich unmittelbar nach einem Versionswechsel begann oder nur zeitgleich sichtbar wurde. - Verbindung zum Firmennetz herstellen: Nutze LAN, Unternehmens-WLAN oder eine VPN-Lösung, die bereits vor der Domänenprüfung verfügbar ist. Eine normale Internetverbindung allein genügt nicht.
- DNS-Konfiguration prüfen: Der Client muss die DNS-Server verwenden, welche die Active-Directory-Zone auflösen können. Öffentliche Resolver oder der DNS-Server eines Heimrouters sind für die AD-Namensauflösung normalerweise ungeeignet.
- Uhrzeit kontrollieren: Prüfe Datum, Uhrzeit und Zeitzone. Eine auffällige Abweichung muss vor der Reparatur behoben werden.
- Sicheren Kanal testen: Erst wenn ein Domänencontroller erreichbar ist, liefert der Test eine aussagekräftige Unterscheidung zwischen Verbindungsproblem und beschädigter Vertrauensstellung.
DNS und Domänencontroller überprüfen
Öffne eine Eingabeaufforderung und zeige die vollständige Netzwerkkonfiguration an:
ipconfig /allSuche beim aktiven Netzwerkadapter nach den eingetragenen DNS-Servern. In einer klassischen Active-Directory-Umgebung sollten dort interne DNS-Adressen stehen, die die Domäne kennen. Ändere die Einstellung nicht auf Verdacht, wenn DHCP, VPN oder eine zentrale Geräteverwaltung sie vorgibt.
Ob Windows einen Domänencontroller für die eigene Domäne findet, lässt sich ohne fest eingetragenen Servernamen testen:
nltest /dsgetdc:%USERDNSDOMAIN%Der Befehl setzt voraus, dass USERDNSDOMAIN in der aktuellen Sitzung vorhanden ist. Erscheint ein Domänencontroller mit Adresse und Domäneninformationen, funktioniert die grundlegende Suche. Ist die Variable leer oder meldet der Befehl, dass keine Domäne gefunden wurde, prüfe die Anmeldung, die Netzwerkverbindung und den DNS-Suffix. Trage nicht einfach irgendeinen Domänencontroller in die Hosts-Datei ein; Active Directory benötigt mehrere DNS-Einträge und Dienstlokalisierung über SRV-Records.
Zeitstatus und sicheren Kanal getrennt testen
Der Zeitdienst lässt sich in einer als Administrator gestarteten Eingabeaufforderung abfragen:
w32tm /query /statusEntscheidend sind eine plausible Quelle und eine zur Domänenumgebung passende Uhrzeit. Ist der PC monatelang ausgeschaltet gewesen oder wurde die Firmware-Uhr zurückgesetzt, korrigiere zuerst die Zeit nach den Vorgaben der Organisation.
Starte danach Windows PowerShell als Administrator. Der folgende Befehl liest den Zustand des sicheren Kanals aus und verändert noch nichts:
Test-ComputerSecureChannel -VerboseTrue spricht für einen funktionierenden sicheren Kanal. Dann liegt die Ursache eher bei der Erreichbarkeit während der Anmeldung, DNS, einem bestimmten Domänencontroller, dem Benutzerkonto oder einer Richtlinie. False bestätigt einen defekten sicheren Kanal, sofern der Rechner während des Tests einen Domänencontroller erreichen kann. Eine Ausnahme oder eine Meldung über eine nicht verfügbare Domäne ist dagegen noch kein Beweis für ein beschädigtes Computerkonto.
Als zweite Prüfung kann die Eingabeaufforderung den Kanal gegenüber der Anmeldedomäne untersuchen:
nltest /sc_verify:%USERDNSDOMAIN%Eine erfolgreiche Prüfung und ein gleichzeitig auftretender Anmeldefehler sprechen dafür, dass das Problem nur einen bestimmten Netzwerkzustand, Domänencontroller oder Benutzer betrifft. Scheitern beide Tests bei funktionierender Namensauflösung, ist eine Reparatur des Maschinenkennworts der passende nächste Schritt.
Den sicheren Kanal reparieren, ohne die Domäne zu verlassen
PowerShell kann den sicheren Kanal neu aufbauen. Das bewahrt Domänenmitgliedschaft, Computerprofil und lokale Benutzerprofile. Du benötigst ein Domänenkonto, das das Computerkonto reparieren darf; in verwalteten Netzen können diese Rechte an den Helpdesk delegiert sein.
Führe in Windows PowerShell mit Administratorrechten aus:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -VerboseIm Anmeldedialog gibst du ein berechtigtes Domänenkonto im Format DOMÄNE\Benutzer oder als Benutzerprinzipalname ein. Das Kennwort gehört ausschließlich in den geschützten Anmeldedialog und nicht in den Befehl. Meldet PowerShell eine erfolgreiche Reparatur, starte den PC neu und teste anschließend zuerst die Verbindung zum Firmennetz und dann die Domänenanmeldung.
Falls die automatische Auswahl des Domänencontrollers zu wechselnden Ergebnissen führt, kann ein Administrator einen bekannten, erreichbaren Domänencontroller vorgeben. Der Platzhalter muss durch den vollständigen DNS-Namen eines echten Servers der eigenen Umgebung ersetzt werden:
Test-ComputerSecureChannel -Repair -Server dc01.example.local -Credential (Get-Credential) -VerboseDie Vorgabe eines Servers ist nur sinnvoll, wenn die IT dessen Zustand und Replikation geprüft hat. Ein beliebig ausgewählter oder nicht mehr aktiver Domänencontroller verschleiert die Ursache.
Maschinenkennwort gezielt zurücksetzen
Eine weitere PowerShell-Methode setzt das Kennwort des lokalen Computerkontos gegenüber einem angegebenen Domänencontroller zurück. Sie verändert die Domänenmitgliedschaft nicht, benötigt aber ebenfalls lokale Administratorrechte und passende Domänenberechtigungen:
Reset-ComputerMachinePassword -Server dc01.example.local -Credential (Get-Credential)Ersetzt werden muss nur dc01.example.local. Nach dem Befehl ist ein Neustart sinnvoll. Prüfe danach den Kanal erneut:
Test-ComputerSecureChannel -VerboseErwartet wird True. Bleibt das Ergebnis False, sollte nicht derselbe Befehl mehrfach wiederholt werden. Dann sind das Computerkonto im Active Directory, die DNS-Auflösung, die Replikation der Domänencontroller und mögliche doppelte Computerobjekte zu untersuchen.
Wenn die Reparatur scheitert: Ergebnis richtig auswerten
- Domäne oder Domänencontroller nicht gefunden: Zuerst DNS, VPN, Routing und Firewall prüfen. Ein Kennwort-Reset löst keine fehlende Verbindung.
- Zugriff verweigert: Das verwendete Domänenkonto besitzt nicht die nötigen Rechte, oder eine Sicherheitsrichtlinie verhindert die Aktion. Verwende kein persönliches Administratorkonto außerhalb des vorgesehenen IT-Prozesses.
- Reparatur erfolgreich, Fehler nach Neustart erneut vorhanden: Möglich sind Replikationsprobleme, ein zurückgesetzter Snapshot, ein geklonter Computer mit widersprüchlicher Identität oder die Kommunikation mit unterschiedlichen Domänencontrollern.
- Test ist erfolgreich, Anmeldung scheitert weiter: Prüfe den genauen Meldungstext und teste ein anderes berechtigtes Domänenkonto. Der sichere Kanal ist dann nicht mehr die naheliegendste Ursache.
- Nur außerhalb des Firmennetzes tritt der Fehler auf: Die Voranmeldung per VPN oder der Zugriff auf zwischengespeicherte Anmeldedaten ist zu prüfen. Das ist von einer dauerhaft beschädigten Vertrauensstellung zu unterscheiden.
Administratoren sollten das Computerkonto in Active Directory-Benutzer und -Computer anhand des exakten Rechnernamens suchen. Ein deaktiviertes Konto, ein Objekt in einer unerwarteten Organisationseinheit oder mehrere ähnlich benannte Objekte liefern wichtige Hinweise. Das pauschale Löschen des Kontos ist riskanter als ein gezieltes Zurücksetzen, weil Gruppenmitgliedschaften, Berechtigungszuweisungen und Verwaltungsbezüge betroffen sein können.
Domäne verlassen und erneut beitreten – nur als Rückfallweg
Ein erneuter Domänenbeitritt ist sinnvoll, wenn die Reparatur des sicheren Kanals trotz erreichbarem Domänencontroller und korrekter DNS-Konfiguration scheitert oder das Computerkonto bewusst neu aufgebaut werden soll. Vorher müssen ein funktionierendes lokales Administratorkonto, der BitLocker-Wiederherstellungsschlüssel und wichtige lokale Daten verfügbar sein. Auf zentral verwalteten Geräten ist außerdem zu klären, wie Zertifikate, Gerätekonfiguration und Softwareverteilung wiederhergestellt werden.
- Melde dich mit einem lokalen Administratorkonto an.
- Öffne die erweiterten Systemeigenschaften mit
sysdm.cpl. - Wähle auf der Registerkarte Computername die Schaltfläche zum Ändern der Mitgliedschaft.
- Wechsle vorübergehend von der Domäne in eine Arbeitsgruppe und bestätige die erforderlichen Anmeldedaten.
- Starte Windows neu und melde dich lokal an.
- Öffne denselben Dialog erneut, trage die vollständige DNS-Bezeichnung der Domäne ein und authentifiziere dich mit einem berechtigten Konto.
- Starte den Rechner erneut und prüfe die Domänenanmeldung sowie
Test-ComputerSecureChannel -Verbose.
Die genaue Berechtigung zum Entfernen, Zurücksetzen oder erneuten Verbinden eines Computerkontos hängt von der Delegation im Active Directory ab. Das Recht, einen PC ursprünglich zur Domäne hinzuzufügen, garantiert nicht in jeder Organisation, dass derselbe Benutzer das vorhandene Konto zurücksetzen darf.
Welche Rolle Windows 11 26H2 bei dem Fehler spielt
Der zeitliche Zusammenhang mit 26H2 beweist keine updatebedingte Ursache. Versionsupdates können einen Neustart, eine längere Trennung vom Unternehmensnetz oder geänderte Treiber- und VPN-Bedingungen mit sich bringen. Dadurch kann ein bereits vorhandenes DNS-, Netzwerk- oder Kontoproblem erstmals auffallen. Der zugrunde liegende AD-Mechanismus bleibt jedoch die Prüfung des sicheren Kanals zwischen Mitgliedscomputer und Computerkonto.
Notiere den mit winver festgestellten Build, den Installationszeitpunkt im Windows-Updateverlauf, den genauen Wortlaut der Meldung und das Ergebnis der beiden Kanaltests. Tritt der Fehler auf mehreren 26H2-Geräten derselben Organisation gleichzeitig auf, sollte die IT zusätzlich VPN-Client, Netzwerkprofile, Domänencontroller-Ereignisse, DNS und zentrale Änderungen untersuchen. Betrifft er nur einen Rechner nach einer Image-Wiederherstellung, ist ein abweichendes Maschinenkennwort wahrscheinlicher.
Abbruchgrenzen für die Selbsthilfe
Beende eigene Reparaturversuche, wenn kein lokales Administratorkonto verfügbar ist, BitLocker-Wiederherstellungsdaten fehlen oder der PC durch Intune, Gruppenrichtlinien, Zertifikate oder eine andere Unternehmensverwaltung eingebunden ist. Gleiches gilt, wenn mehrere Geräte betroffen sind oder Active Directory-Replikationsfehler vermutet werden. In diesen Fällen muss die Domänenadministration sowohl den Client als auch die beteiligten Domänencontroller prüfen.
Für einen einzelnen erreichbaren PC lautet die sichere Route: lokalen Zugriff absichern, internen DNS und Uhrzeit prüfen, den sicheren Kanal nur lesend testen, ihn einmal mit berechtigten Anmeldedaten reparieren und das Ergebnis nach einem Neustart kontrollieren. Erst wenn diese Route scheitert, ist ein sauber vorbereiteter Austritt mit anschließendem Domänenbeitritt angemessen.
