13
Vertrauensstellung zwischen Arbeitsstation und primärer Domäne geht regelmäßig verloren
Hallo zusammen,
wir hatten vor einigen Tagen einen mehrstündigen Stromausfall, bei dem dann unsere USV die Luft ausgegangen ist und sich unser vmware Host dementsprechend unsanft beendet hat.
Auf dem Host laufen mehrere virtuelle Windows 2019 Server, in einer Domäne.
Nach dem Wiederhochfahren des Systems meldete unser Terminalserver beim Anmelden dann "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Also habe ich mich als lokaler Admin angemeldet und konnte mit dem Cmdlet Reset-ComputerMachinePassword das Computerpasswort neu setzen und eine Anmeldung war wieder möglich.
Einige Tage später bekam ich die selbe Meldung auf einem unserer Anwendungsserver. Dort meldete das Cmdlet dann einen "lokalen Fehler" weshalb ich den Server dann aus der Domäne entfernt und erneut hinzugefügt habe. Danach ging auch wieder alles.
Nun bekam ich gestern schon wieder von unserem Terminalserver die Meldung bzgl. der Vertrauensstellung. Also habe ich diesmal auch diesen Server aus der Domäne entfernt und erneut hinzugefügt. Danach war dann die Anmeldung wieder möglich.
Jetzt bekomme ich heute Morgen schon wieder die Fehlermeldung und frage mich wie es dazu kommen kann, dass die Vertrauensstellung wiederholt verloren geht.
Hat jemand von euch eine Idee wie ich mich am besten auf Ursachenforschung begeben kann?
Beste Dank
wir hatten vor einigen Tagen einen mehrstündigen Stromausfall, bei dem dann unsere USV die Luft ausgegangen ist und sich unser vmware Host dementsprechend unsanft beendet hat.
Auf dem Host laufen mehrere virtuelle Windows 2019 Server, in einer Domäne.
Nach dem Wiederhochfahren des Systems meldete unser Terminalserver beim Anmelden dann "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Also habe ich mich als lokaler Admin angemeldet und konnte mit dem Cmdlet Reset-ComputerMachinePassword das Computerpasswort neu setzen und eine Anmeldung war wieder möglich.
Einige Tage später bekam ich die selbe Meldung auf einem unserer Anwendungsserver. Dort meldete das Cmdlet dann einen "lokalen Fehler" weshalb ich den Server dann aus der Domäne entfernt und erneut hinzugefügt habe. Danach ging auch wieder alles.
Nun bekam ich gestern schon wieder von unserem Terminalserver die Meldung bzgl. der Vertrauensstellung. Also habe ich diesmal auch diesen Server aus der Domäne entfernt und erneut hinzugefügt. Danach war dann die Anmeldung wieder möglich.
Jetzt bekomme ich heute Morgen schon wieder die Fehlermeldung und frage mich wie es dazu kommen kann, dass die Vertrauensstellung wiederholt verloren geht.
Hat jemand von euch eine Idee wie ich mich am besten auf Ursachenforschung begeben kann?
Beste Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2198167699
Url: https://administrator.de/contentid/2198167699
Ausgedruckt am: 26.11.2024 um 05:11 Uhr
13 Kommentare
Neuester Kommentar
Moin,
schau mal hier:
https://www.windowspro.de/wolfgang-sommergut/loesung-fuer-vertrauensstel ...
Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Gruß
Doskias
schau mal hier:
https://www.windowspro.de/wolfgang-sommergut/loesung-fuer-vertrauensstel ...
Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Test-ComputerSecureChannel -Repair -Server MyDC -Credential contoso\admin
Gruß
Doskias
Das habe ich auch probiert. Er schreibt in dem Artikel, dass dieser Befehl eine Alternative ist. Insgesamt sind die CmdLets aber ja auch nur eine Möglichkeit, um um das Verlassen der Domäne herumzukommen, soweit ich das verstanden habe.
Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Zitat von @Doskias:
Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Doch, das Reset-ComputerMachinePassword ... reicht aus.Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Test-ComputerSecureChannel -Repair -Server MyDC -Credential contoso\admin
Das Test-ComputerSecureChannel ... ist nur eine Alternative. Genauso wir der Weg über netdom.
Zitat von @Plinko:
Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Sind das AD Member, welche i.A. jeden Tag im LAN sind? Oder sind diese z.Z. oft und lange außer Haus?Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Kannst Du ausschließen, dass die Namen der betroffenen Computer doppelt verwendet werden?
Uhrzeiten synchron? Sind das vielleicht VM, welche beim Start (Einschalten) eine "schiefe" Zeit vom Host übernehmen?
Die Server sind alles AD-Member die auf dem selben Hypervisor laufen. Die Uhrzeiten sind alle synchron mit dem DC.
Zitat von @Plinko:
Die Server sind alles AD-Member die auf dem selben Hypervisor laufen. Die Uhrzeiten sind alle synchron mit dem DC.
Womit Du aber leider nicht eine meiner Fragen wirklich beantwortet hast.Die Server sind alles AD-Member die auf dem selben Hypervisor laufen. Die Uhrzeiten sind alle synchron mit dem DC.
Zitat von @emeriks:
Das Test-ComputerSecureChannel ... ist nur eine Alternative. Genauso wir der Weg über netdom.
Zitat von @Doskias:
Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Doch, das Reset-ComputerMachinePassword ... reicht aus.Kurz gesagt: Du führst zwar einen Reset durch, reparierst aber nicht. Dazu fehlt meiner Meinung nach
Test-ComputerSecureChannel -Repair -Server MyDC -Credential contoso\admin
Das Test-ComputerSecureChannel ... ist nur eine Alternative. Genauso wir der Weg über netdom.
Interessant. Ich berichte hier mal kurz von meinem Erlebnis diesbezüglich:
Rechner Windows 10 hat die Vertrauensstellung verloren. Hab das Reset gemacht, Anmeldung ging. Nächster Tag, gleiches Problem. Reset gemacht, Anmeldung ging. Das ganze 4 Tage hintereinander. Am 4ten Tag dann nach dem Reset ein Test-ComputerSecureChannel gemacht. Ergebnis: false. Also nochmal ein Test-ComputerSecureChannel mit dem Repair nachgeschoben: undnochmal getestet: true. Seitdem keine Zickereien mehr.
Irgendwann hatte ich den den nächsten Rechner mit dem gleichen Problem. Also wieder "nur" mit dem Repair angefangen. Ergebnis des Test anschließend: wieder false. Mit der Vermutung, dass es wieder auftritt den Rechner neu gestartet: Trat wieder auf. Wieder beides gemacht, Ergebnis: ging wider.
Seitdem mach ich gute Erfahrung einfach immer beides zu machen, obwohl laut dem Artikel eins ausreichen sollte. Habe da bislang keine Erklärung für gefunden, aber ich kann damit leben. man muss nicht alles erklären was MS so macht.
Aber das bringt uns zu einer Frage: Wenn du dich nach dem Reset anmelden kannst, welches Ergebnis bringt der Test-ComputerSecureChannel?
Gruß
Doskias
@Doskias
Danke für den Hinweis!
Danke für den Hinweis!
Zitat von @Doskias:
Wenn du dich nach dem Reset anmelden kannst, welches Ergebnis bringt der Test-ComputerSecureChannel?
Ich kann dir nur das Testergebnis sagen, nachdem ich den Rechner neu in die Domäne aufgenommen habe. Das liefert True. Wie der Test verläuft wenn es mal wieder nicht geht kann ich aktuell leider nicht sagen. Da habe ich aber ja wie gesagt das Problem das ich als Fehlermeldung "lokaler Fehler" bekomme wenn ich den Reset machen will.Wenn du dich nach dem Reset anmelden kannst, welches Ergebnis bringt der Test-ComputerSecureChannel?
Zitat von @emeriks:
Kannst Du ausschließen, dass die Namen der betroffenen Computer doppelt verwendet werden?
Uhrzeiten synchron? Sind das vielleicht VM, welche beim Start (Einschalten) eine "schiefe" Zeit vom Host übernehmen?
Zitat von @Plinko:
Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Sind das AD Member, welche i.A. jeden Tag im LAN sind? Oder sind diese z.Z. oft und lange außer Haus?Warum es zum Verlust der Vertrauensstellung kommt ist damit aber leider auch nicht geklärt.
Kannst Du ausschließen, dass die Namen der betroffenen Computer doppelt verwendet werden?
Uhrzeiten synchron? Sind das vielleicht VM, welche beim Start (Einschalten) eine "schiefe" Zeit vom Host übernehmen?
Es handelt sich um Server auf dem selben Host, Sie sind also 24x7 im selben LAN, laufen die ganze Zeit und werden im Normalfall auch nicht ausgeschaltet oder regelmäßig neu gestartet. Die Uhrzeiten sind auch alles synchron.
Das Maschinenkennwort wird alle 30 Tage neu gesetzt (automatisch). Wenn ein Replikationsproblem im AD vorliegt, bekommt das evtl. nicht jeder DC mit und sagt dem Server dann "nee, Vertrauensstellung verloren".
Prüfe also mit dcdiag auf jedem DC, ob die Replikation als ok eingestuft wird.
Prüfe also mit dcdiag auf jedem DC, ob die Replikation als ok eingestuft wird.
Hallo nochmal...
sorry, aber ich habe einiges von Euren Erläuterungen nicht wirklich verstanden.
Ich habe den Mini-PC nun ohne NW-Kabel neu gestartet.
Dann konnte ich mich mit dem Admin-Login anmelden (ist offenbar lokal + NW das Gleiche).
Danach habe ich das NW-Kabel wieder eingesteckt und konnte dann auch auf Server-Verzeichnisse zugreifen.
Dann ging ich in Pause und als ich zurück kam, hatte der PC sich abgemeldet.
Nun gut... dann habe ich mich (nun mit eingesteckten NW-Kabel) wieder mit dem Admin-Login angemeldet und erhielt wieder die obige Fehlermeldung
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden"
Zur Info:
- der Mini-PC taucht in der AD auf mit seinem Namen
- als ich den PC in eine Arbeitsgruppe aufnehmen wollte, um ihn danach erneut in die Domäne aufzunehmen, erhielt ich den Hinweis, dass ich dann das Login des lokalen Adminkontos benötige... Da war ich aber jetzt nicht wirlich sicher und habe es mal gelassen.
- es könnte aber auch sein, dass der PC-Name einfach doppelt verwendet wurde. Vielleicht versuche ich mal, diesen Mini-PC einfach umzunennen....
Was tun?
Grüße von
Yan
sorry, aber ich habe einiges von Euren Erläuterungen nicht wirklich verstanden.
Ich habe den Mini-PC nun ohne NW-Kabel neu gestartet.
Dann konnte ich mich mit dem Admin-Login anmelden (ist offenbar lokal + NW das Gleiche).
Danach habe ich das NW-Kabel wieder eingesteckt und konnte dann auch auf Server-Verzeichnisse zugreifen.
Dann ging ich in Pause und als ich zurück kam, hatte der PC sich abgemeldet.
Nun gut... dann habe ich mich (nun mit eingesteckten NW-Kabel) wieder mit dem Admin-Login angemeldet und erhielt wieder die obige Fehlermeldung
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden"
Zur Info:
- der Mini-PC taucht in der AD auf mit seinem Namen
- als ich den PC in eine Arbeitsgruppe aufnehmen wollte, um ihn danach erneut in die Domäne aufzunehmen, erhielt ich den Hinweis, dass ich dann das Login des lokalen Adminkontos benötige... Da war ich aber jetzt nicht wirlich sicher und habe es mal gelassen.
- es könnte aber auch sein, dass der PC-Name einfach doppelt verwendet wurde. Vielleicht versuche ich mal, diesen Mini-PC einfach umzunennen....
Was tun?
Grüße von
Yan
UPDATE:
PC ist jetzt umbenannt, aber Login geht weiterhin nur OHNE Netzwerkverbindung.
Bei Start mit NW-Kabel kommt wieder die obige Fehlermeldung.
Grüße von
Yan
PC ist jetzt umbenannt, aber Login geht weiterhin nur OHNE Netzwerkverbindung.
Bei Start mit NW-Kabel kommt wieder die obige Fehlermeldung.
Grüße von
Yan
