5
Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden", wenn Sie sich an einem Computer anmelden, auf dem Windows 7 ausgeführt wird
hi, habe das oben genannte Problem wie viele hier, aber unter folgenden Voraussetzungen, zu der ich keine Lösung finde:
Umgebung: alles 2012r2, DC1 und DC2 virtualisiert in HyperV in Failover Cluster, AD Synchronisation funktioniert.
ca. 25 Clients, die meisten noch Windows 7, reibungslos in die Domain gejoint. Solange der User sein Kennwort nicht ändert, keine Probleme. es besteht seitens kunde kein wunsch nach einer richtlinie zur regelmäßigen änderung, daher kein riesendrama, aber das nervt natürlich schon, weils irgendwo einfach unsauber ist und ich den fehler nicht sehe oder finde...
Aaaaaber ... ändert der User sein Kennwort und startet neu, bekommt er bei der nächsten Anmeldung die Fehlermeldung "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden..."
das deaktivieren von IPv6 bringt da keine änderung.
ich hab das ganze in einem windows 7 testrechner (in einer VM) getestet, da habe ich keine Probleme, zigmal auf verschiedenen wegen das passwort geändert, jedesmal einloggen können.
nur bei physikalischen rechnern besteht das thema. woran hängts? verliert der rechner nach der passwort änderung den kontakt zum dc? da ich mich ja nur noch mit dem lokalen admin anmelden kann, weder domain-admin noch domain-user, liegt die vermutung nahe, dass die daten des DC nicht auf dem rechner landen ...
aus gründen der ordnung in der AD wurden OUs mit unterordnern angelegt und die user verschoben, während die rechner alle im standardordner "computers" landen. liegt hier der fehler? habe aber mit besagtem testuser in der test-VM keine Probleme.
besteht das problem bei windows 10 auch noch? der Kunde wäre mit einem Update grundsätzlich einverstanden, ich sah bisher keinen Grund dazu ... das wäre einer.
das workaround (domain rejoin) ist keine lösung.
Danke für eure Hilfe!
Umgebung: alles 2012r2, DC1 und DC2 virtualisiert in HyperV in Failover Cluster, AD Synchronisation funktioniert.
ca. 25 Clients, die meisten noch Windows 7, reibungslos in die Domain gejoint. Solange der User sein Kennwort nicht ändert, keine Probleme. es besteht seitens kunde kein wunsch nach einer richtlinie zur regelmäßigen änderung, daher kein riesendrama, aber das nervt natürlich schon, weils irgendwo einfach unsauber ist und ich den fehler nicht sehe oder finde...
Aaaaaber ... ändert der User sein Kennwort und startet neu, bekommt er bei der nächsten Anmeldung die Fehlermeldung "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden..."
das deaktivieren von IPv6 bringt da keine änderung.
ich hab das ganze in einem windows 7 testrechner (in einer VM) getestet, da habe ich keine Probleme, zigmal auf verschiedenen wegen das passwort geändert, jedesmal einloggen können.
nur bei physikalischen rechnern besteht das thema. woran hängts? verliert der rechner nach der passwort änderung den kontakt zum dc? da ich mich ja nur noch mit dem lokalen admin anmelden kann, weder domain-admin noch domain-user, liegt die vermutung nahe, dass die daten des DC nicht auf dem rechner landen ...
aus gründen der ordnung in der AD wurden OUs mit unterordnern angelegt und die user verschoben, während die rechner alle im standardordner "computers" landen. liegt hier der fehler? habe aber mit besagtem testuser in der test-VM keine Probleme.
besteht das problem bei windows 10 auch noch? der Kunde wäre mit einem Update grundsätzlich einverstanden, ich sah bisher keinen Grund dazu ... das wäre einer.
das workaround (domain rejoin) ist keine lösung.
Danke für eure Hilfe!
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: 302489
Url: https://administrator.de/contentid/302489
Ausgedruckt am: 26.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Hi,
E.
Aaaaaber ... ändert der User sein Kennwort und startet neu, bekommt er bei der nächsten Anmeldung die Fehlermeldung "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden..."
Hört sich so an, als wenn das Computerpasswort nicht mehr stimmt. Wo auch immer da der Zusammenhang sein soll. Aber einfach mal testen. Passwort ändern. Neustart. Wenn der Fehler kommt, dann mit lokalem Admin anmelden. Aus der Domäne aus- und wieder eintreten. Geht dann die Anmeldung mit dem geänderten Passwort? Nur mal zum Test.ich hab das ganze in einem windows 7 testrechner (in einer VM) getestet, da habe ich keine Probleme, zigmal auf verschiedenen wegen das passwort geändert, jedesmal einloggen können.
OK, der Test war erstmal richtig. Sind die VM's sonst identisch zu den Phy.PC installiert?nur bei physikalischen rechnern besteht das thema. woran hängts? verliert der rechner nach der passwort änderung den kontakt zum dc? da ich mich ja nur noch mit dem lokalen admin anmelden kann, weder domain-admin noch domain-user, liegt die vermutung nahe, dass die daten des DC nicht auf dem rechner landen ...
Nur mal gestochert: Sind diese Rechner vielleicht alle vom selben HDD-Image geklont worden, ohne ne neue SID zu generieren?aus gründen der ordnung in der AD wurden OUs mit unterordnern angelegt und die user verschoben, während die rechner alle im standardordner "computers" landen. liegt hier der fehler? habe aber mit besagtem testuser in der test-VM keine Probleme.
Nee, daran kann das nicht liegen. Das macht keinen Unterschied.das workaround (domain rejoin) ist keine lösung.
Doch, nur zum Test. Wenn das wiederholt nach einem Passwortwechsel erforderlich wird, dann ist wohl die Installation buggy. Siehe auch meine o.g. Frage nach dem HDD-Image. Wenn es nur einmalig erforderlich ist, dann ist das u.U. die "Lösung".E.
Hi,
auch einfach mal ins Blaue gestochert. Beim Thema "Domäne und Vertrauensstellung" ist mir spontan eingefallen, daß solche Probleme häufig von einer falschen Uhrzeit ausgelöst werden. Das wird vermutlich bei Dir nicht das Problem sein, aber trotzdem mal Uhrzeit/Zeitzone auf den Kisten checken. Hatte ich einmal und musste auch relativ lange suchen
An dieser Stelle hätte ich es ebenfalls probiert, aus der Domäne raus, Reboot und neu in die Domäne joinen.
Des Weiteren hätte ich dann noch geprüft, ob die Namensauflösung im Netzwerk korrekt funktioniert und ob vielleicht Rechnernamen mehrfach vergeben wurden.
Ich wünsche viel Erfolg und bin gespannt, was die Ursache war
Gruß
Andy
auch einfach mal ins Blaue gestochert. Beim Thema "Domäne und Vertrauensstellung" ist mir spontan eingefallen, daß solche Probleme häufig von einer falschen Uhrzeit ausgelöst werden. Das wird vermutlich bei Dir nicht das Problem sein, aber trotzdem mal Uhrzeit/Zeitzone auf den Kisten checken. Hatte ich einmal und musste auch relativ lange suchen
An dieser Stelle hätte ich es ebenfalls probiert, aus der Domäne raus, Reboot und neu in die Domäne joinen.
Des Weiteren hätte ich dann noch geprüft, ob die Namensauflösung im Netzwerk korrekt funktioniert und ob vielleicht Rechnernamen mehrfach vergeben wurden.
Ich wünsche viel Erfolg und bin gespannt, was die Ursache war
Gruß
Andy
Hallo,
schau in deinem DC-Log mal nach der Ereignis-ID 5722 und kontrollier die DNS und WINS Einträge. Das könnte mit doppelten/falschen Einträgen zusammenhängen.
Es könnte auch ein Virenscanner oder eine Desktopfirewall schuld sein. Das wäre der Fall wenn die Passwortwortaushandlung für die sichere Verbindung mit dem DC unterbunden wird. Diese findet aber alle 30 Tage statt. Sollte also auch die PCs betreffen, auf denen die Benutzer das Passwort nicht ändern.
Können sich die Benutzer mit Ihrem neuen Passwort auf einem anderen PC anmelden?
mfg
schau in deinem DC-Log mal nach der Ereignis-ID 5722 und kontrollier die DNS und WINS Einträge. Das könnte mit doppelten/falschen Einträgen zusammenhängen.
Es könnte auch ein Virenscanner oder eine Desktopfirewall schuld sein. Das wäre der Fall wenn die Passwortwortaushandlung für die sichere Verbindung mit dem DC unterbunden wird. Diese findet aber alle 30 Tage statt. Sollte also auch die PCs betreffen, auf denen die Benutzer das Passwort nicht ändern.
Können sich die Benutzer mit Ihrem neuen Passwort auf einem anderen PC anmelden?
mfg
sorry alle zusammen, habs erst jetzt gesehen ... im endeffekt hatten zwei maschinen den gleichen namen, warum der DC das beim Domainjoin zugelassen hat, ist mir nicht erklärbar, schlussendlich hats aber seit raus-aus-der-domain und mit anderem namen wieder rein keine probleme mehr gegeben ... draufgekommen bin ich durch 2 unterschiedliche ip adressen im dhcp für den selben namen ...
völlig vernagelt. aber passiert. seltsames verhalten des DC. aber final gelöst.
völlig vernagelt. aber passiert. seltsames verhalten des DC. aber final gelöst.
warum der DC das beim Domainjoin zugelassen hat, ist mir nicht erklärbar
Das ist Standardverhalten und allgemein bekannt.
