{"id":36,"date":"2018-03-03T17:27:07","date_gmt":"2018-03-03T16:27:07","guid":{"rendered":"https:\/\/pascal-korz.de\/blog\/?p=36"},"modified":"2018-11-19T21:28:15","modified_gmt":"2018-11-19T20:28:15","slug":"verlorene-vertrauensstellung-wiederherstellen","status":"publish","type":"post","link":"https:\/\/pascal-korz.de\/blog\/2018\/03\/03\/verlorene-vertrauensstellung-wiederherstellen\/","title":{"rendered":"Verlorene Vertrauensstellung wiederherstellen"},"content":{"rendered":"<p>Es ist ein unangenehmes Gef\u00fchl, von seinem Rechner ausgesperrt zu werden. Leider eines, welches Benutzer in Windows-Dom\u00e4nen gelegentlich erleben. In der Regel gibt der Anwender tats\u00e4chlich einen falschen Benutzernamen oder ein falsches oder abgelaufenes Kennwort ein, aber manchmal sieht er sich auch mit der folgenden Meldung konfrontiert:<\/p>\n<blockquote><p>Die Vertrauensstellung zwischen dieser Arbeitsstation und der prim\u00e4ren Dom\u00e4ne konnte nicht hergestellt werden.<\/p><\/blockquote>\n<p>Oder auf Englisch:<\/p>\n<blockquote><p>The trust relationship between this workstation and the primary domain failed.<\/p><\/blockquote>\n<p>Im Gegensatz zu vielen anderen Fehlermeldungen in diesen seltener werdenden Momenten, in denen welche ausgegeben werden, dr\u00fcckt sich Windows hier klar und pr\u00e4zise aus \u2013 leider meist nicht f\u00fcr den Anwender, der sie liest.<\/p>\n<p>Administratoren reagieren auf diese Meldung gerne routinem\u00e4\u00dfig mit der Entfernung und der anschlie\u00dfenden Wiederaufnahme des Computers in die Dom\u00e4ne. Wenn diese Methode auch funktioniert, ist sie sehr rabiat und verursacht mit den zwei ben\u00f6tigten Neustarts unverh\u00e4ltnism\u00e4\u00dfig viel Aufwand \u2013 gerade in Situationen, in denen man Anwendern an Remote-Standorten aus der Misere helfen muss. Es hilft nat\u00fcrlich nicht, dass Microsoft <a href=\"https:\/\/support.microsoft.com\/de-de\/help\/2771040\/the-trust-relationship-between-this-workstation-and-the-primary-domain\" title=\"Fehlermeldung \u201eDie Vertrauensstellung zwischen dieser Arbeitsstation und der prim\u00e4ren Dom\u00e4ne konnte nicht hergestellt werden\u201c beim Anmelden bei Windows 7\">diese<\/a> Vorgehensweise auf einer seiner zahlreichen Support-Websites selber empfiehlt.<\/p>\n<p>Es hilft stattdessen, zu verstehen, woher der Anmeldefehler tats\u00e4chlich r\u00fchrt: Wenn der Rechner mit der Dom\u00e4ne verbunden ist (direkt oder per VPN mit der Netzwerkanmeldung im Windows-Anmeldebildschirm) wird der Anwender nach Eingabe von Benutzername und Kennwort gegen den Domain Controller authentifiziert. Zu diesem Zweck muss der Rechner eine Verbindung zum Domain Controller aufbauen. Der Rechner selber ist ebenfalls Mitglied der Dom\u00e4ne und im Active Directory durch ein Computerobjekt repr\u00e4sentiert. Genau wie der Benutzer hat auch der Computer ein eigenes Kennwort. Anwender m\u00fcssen sich um dieses Kennwort nicht k\u00fcmmern, wissen in der Regel nicht einmal von seiner Existenz. Wenn nicht anders von Dom\u00e4nenadministratoren konfiguriert, aktualisiert ein Computer, der Mitglied der Dom\u00e4ne ist, sein Kennwort,falls m\u00f6glich, gem\u00e4\u00df der standardm\u00e4\u00dfigen Richtlinie alle 30 Tage. Der Computer speichert eine verschl\u00fcsselte Form des alten und des neuen Kennworts in der Registry unter HKLM\\SECURITY\\Policy\\Secrets\\$machine.ACC. Auch das Active Directory speichert diese Kennw\u00f6rter im entsprechenden Computerobjekt in den Attributen lmpwdHistory und unicodepwd.<\/p>\n<p>Das Kennwort auf dem Rechner und das im Computerobjekt im Active Directory gespeicherte Kennwort sind also normalerweise synchron. Wenn das Betriebssystem allerdings aus irgendeinem Grund mithilfe eines Wiederherstellungspunkts, eines Backup-Images, eines Snapshots der virtuellen Maschine oder anderer Methoden auf einen fr\u00fcheren Stand mit einem \u00e4lteren lokal gespeicherten Computerkennwort zur\u00fcckgesetzt wird, stimmen das lokale Computerkennwort und das am Active Directory f\u00fcr dieses Computerobjekt gespeicherte Kennwort nicht mehr \u00fcberein, weshalb die sichere Verbindung zum Domain Controller und damit zur Benutzerauthentifizierung nicht hergestellt werden kann.<\/p>\n<p>Testen l\u00e4sst sich der Secure Channel mit folgendem PowerShell-Befehl auf dem betroffenen Rechner:<\/p>\n<pre>Test-ComputerSecureChannel<\/pre>\n<p>Lautet das Ergebnis &#8222;False&#8220; ist der Secure Channel besch\u00e4digt. Mit folgendem Befehl, der als lokaler Administrator und mit den Anmeldedaten eines Dom\u00e4nenadministrators ausgef\u00fchrt wird, kann er repariert werden:<\/p>\n<pre>Test-ComputerSecureChannel -Repair -Credential DOM\u00c4NE\\Dom\u00e4nen-Administrator-Konto<\/pre>\n<p>Wird &#8222;True&#8220; ausgegeben, war der Befehl erfolgreich, und die Vertrauensstellung wurde wiederhergestellt. Es findet also kein Rauswurf aus und keine Wiederaufnahme in die Dom\u00e4ne statt, und der Computer muss nicht mehrmals neugestartet werden.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Es ist ein unangenehmes Gef\u00fchl, von seinem Rechner ausgesperrt zu werden. Leider eines, welches Benutzer in Windows-Dom\u00e4nen gelegentlich erleben. In der Regel gibt der Anwender tats\u00e4chlich einen falschen Benutzernamen oder ein falsches oder abgelaufenes Kennwort ein, aber manchmal sieht er sich auch mit der folgenden Meldung konfrontiert: Die Vertrauensstellung zwischen dieser Arbeitsstation und der prim\u00e4ren&hellip; <a class=\"more-link\" href=\"https:\/\/pascal-korz.de\/blog\/2018\/03\/03\/verlorene-vertrauensstellung-wiederherstellen\/\"><span class=\"screen-reader-text\">Verlorene Vertrauensstellung wiederherstellen<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":6,"featured_media":38,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,3],"tags":[],"class_list":["post-36","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","category-windows","entry"],"_links":{"self":[{"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/posts\/36","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/comments?post=36"}],"version-history":[{"count":4,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/posts\/36\/revisions"}],"predecessor-version":[{"id":265,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/posts\/36\/revisions\/265"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/media\/38"}],"wp:attachment":[{"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/media?parent=36"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/categories?post=36"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pascal-korz.de\/blog\/wp-json\/wp\/v2\/tags?post=36"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}