Wie kann ich die Vertrauensbeziehung zur Domain so einstellen, dass sie nicht mehr fehlschlägt?


13

Ich habe gerade Windows 10 installiert. Ich war Teil einer Domäne. Wenn ich versuche mich einzuloggen bekomme ich,

"The trust relationship between this workstation and the primary domain failed."

Da ich mich nicht an meine lokalen Konten erinnere, muss ich das lokale Administratorkennwort mit einem Drittanbieter-Tool wie dem Offline-Windows-Kennwort- und Registrierungseditor zurücksetzen und der Domäne wieder beitreten oder netdom auf dem Client verwenden.

Gibt es eine andere Möglichkeit, die Vertrauensbeziehung wiederherzustellen?

Bearbeiten: Ich habe versucht, das Computerkonto in Active Directory-Benutzer und -Computer zurückzusetzen. Gleicher Fehler. (Ja, ich habe neu gestartet).


Ich habe die vorgeschlagenen Änderungen teilweise geändert. Ich glaube, es ist wichtig, den Pogostick-Link zu setzen, damit klar ist, was ich unter Zurücksetzen verstehe. Dass ich so ein Drittanbieter-Tool brauche.
Johnny

Mögliches Duplikat des
erneuten

AFAIK (und da die Antworten in dem markierten möglichen Duplikat ebenfalls übereinstimmen) ist die einzige Möglichkeit, das Vertrauen wiederherzustellen, den Computer von der Domäne zu trennen, sein AD-Konto zu löschen und dann erneut beizutreten.
Ƭᴇcʜιᴇ007


1
Die Antworten zeigen alle, wie man die zerbrochene Vertrauens- / Domain-Beziehung behebt. Ich bin jedoch gespannt, ob jemand antworten möchte, WARUM DAS PASSIERT, wie von @johnny im Titel gefragt?
Gregg

Antworten:


15

Sie können dies beheben, ohne die Domain zu entfernen oder wieder beizutreten, wenn:

A) Sie haben ein lokales Administratorkonto auf dem Computer, für das Sie das Kennwort kennen, oder

B) Sie haben sich in der Vergangenheit mit einem Domänenkonto mit Administratoranmeldeinformationen am Computer angemeldet.

Wenn A, melden Sie sich einfach mit den lokalen Administratoranmeldeinformationen an und fahren Sie mit dem nächsten Teil fort. Wenn B, ziehen Sie das Netzwerkkabel ab, deaktivieren Sie die drahtlose Verbindung usw. und melden Sie sich dann als Ihr lokales Administratordomänenkonto an.

Öffnen Sie PowerShell und führen Sie die folgenden Befehle aus:

$credential = Get-Credential

Geben Sie ein Domain-Administratorkonto ein.

Reset-ComputerMachinePassword -Server DomainControllerName

Dieser Befehl setzt das Computerkennwort mit dem Domänencontroller zurück und Sie sollten jetzt in der Lage sein, den normalen Domänennetzwerkzugriff wieder aufzunehmen.

Ich habe diese Lösung hier gefunden und festgestellt, dass sie mehrfach funktioniert hat: https://community.spiceworks.com/how_to/108912-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed


Und vielleicht wissen Sie, wie Sie dies mithilfe eines Domänenadministratorkontos aus der Ferne tun würden, wenn Sie keinen Zugriff auf das lokale Administratorkonto haben und der Server eine VM ist und Sie das Netzwerkkabel nicht abziehen können?
Vapcguy

Eine VM zu sein sollte keinen Unterschied machen. Sowohl HyperV als auch ESXi können Netzwerkkabel virtuell trennen. Der Remotezugriff setzt in den meisten Fällen eine gewisse Domänenkommunikation voraus und funktioniert daher möglicherweise nicht. Wenn Sie jedoch Zugriff auf den Hypervisor haben, haben Sie Konsolenzugriff, der dem physischen Zugriff beim Umgang mit VMs entspricht. Wie in meiner Antwort klar angegeben, benötigen Sie jedoch ein Administratorkonto, das vom fehlerhaften Computer erkannt wird. Die beiden Fälle (Kenntnis eines lokalen Administratorkontos, Kenntnis eines Domänenkontos mit Administratorrechten) werden in meiner Antwort behandelt.
music2myear

Zum Glück fand ich diesen ... superuser.com/questions/555297/...
vapcguy

1
Das Ausführen dieser beiden Befehle wie oben beschrieben ist für mich fehlgeschlagen. Durch ihre Kombination wurde die Vertrauensbeziehung behoben! Reset-ComputerMachinePassword -Server DomainControllerHostName -Credential DomainAdmin@domain.com
Gregg

17

Ich kann die von music2myear bereitgestellte Lösung nicht kommentieren, es scheint jedoch einen weiteren Schritt in diesem Prozess zu geben. In den Kommentaren unter dem Artikel, der in der Antwort von music2myear verlinkt ist, wird eine vollständigere Antwort bereitgestellt.

Öffnen Sie PowerShell und führen Sie die folgenden Befehle aus:

$credential = Get-Credential

Geben Sie ein Domain-Administratorkonto ein.

Reset-ComputerMachinePassword -Server DomainControllerName -Credential $credential

Ich konnte mein Problem erst beheben, als ich den Berechtigungsnachweis als letzten Parameter angegeben hatte.

Als weiteren Hinweis ging ich davon aus, dass mein Domänencontroller der Domänenname (dh MyDomain.local) ist. Für die DomainControllerNamemusste ich jedoch den Computer- / Hostnamen des Domänencontrollers angeben .


Danke für die Klarstellung. Ich weiß nicht, ob eine andere Powershell-Version das zuvor gespeicherte Argument $ credential automatisch verwendet, aber Ihre Methode ist expliziter und sollte in mehreren Fällen funktionieren.
music2myear

Der Domänencontroller (DC) ist nicht mit dem Domänennamen (DN) identisch. Der DC ist der Computer (oder einer der Computer) mit der DC-Rolle in einem Windows-Netzwerk mit einer Domäne. Der DN ist der Name, den Sie dieser Domain beim Einrichten geben.
music2myear

1
@ music2myear Vorsichtig mit dem Akronym "DN". Der echte "DN", wie er sich auf AD bezieht, bedeutet tatsächlich DistinguishedName und das sieht so aus CN=servername,DC=domain,DC=com. Ganz anders. Aber dein Kommentar ist richtig.
Vapcguy

1

Ich hatte ein ähnliches Problem nach dem Upgrade eines Computers auf Windows 10, obwohl ich das lokale Administratorkennwort kannte! In meinem Fall dachte ich, dass das Umbenennen des Computers, um ein neues AD-Konto dafür zu erhalten, das Problem lösen würde (da dies oft ausreicht, wenn eine VM aufgrund des Zurücksetzens eines Snapshots ausfällt), aber dies funktionierte in diesem Fall nicht.

Die Lösung bestand darin, den Computer vollständig aus der Domäne zu entfernen, neu zu starten, erneut beizutreten und erneut neu zu starten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.