4
Fehler: Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt
Hallo zusammen,
ich habe das gleiche Problem wie hier beschrieben:
Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt ...
Es wird beschrieben dass es an folgende Punkte liegen kann:
-die Uhrzeit auf Client und Server unterscheiden sich stark --> Ist nicht der Fall
-der Client wurde geklont und (zumindest kurzzeitig) parallel mit dem Klon eingesetzt --> wir betreiben tatsächlich ein Imagein, das würde ja bedeutet doppelte SID, richtig?
-der Client wurde aus einem Image erstellt/restored, das älter als 30 Tage ist ->in diesem Fall ist das Kennwort des Computerkontos nämlich nicht mehr identisch mit dem, welches der DC gespeichert hat. Der DC ruft die Computerobjekte alle 30 Tage zu einer Kennwortänderung auf. --> Verstehe ich nicht ganz die Aussage: Natürlich ist ein Image im normallfall älter als 30 Tage alt aber was hat es damit zu tun? Man spielt das Image ein, welches zuvor mit Sysprep ausgeführt wurde. Somit wird ein neuer lokaler account angelegt ( der sollte dadurch eine andere SID erhalten) meldet diesen ab oder löscht ihn und meldet sich mit dem Domänenbenutzer an.
Fragen:
1. Die SID bezieht sich doch auf den benutzeraccount oder? Was hat das Imagein des Rechners damit zu tun? DIe Benutzer werden ja im AD angelegt..
2. Wo kann ich mir im AD die SID anzeigen lassen?
3. Ist es möglich über den AD mir auf einen Blick alle SIDs anzeigen zu lassen? Um überprüfen zu können ob tatsächlich eine doppelt vergeben war/ist.
Wäre über jede Hilfe dankbar!
Gruß
Grecho
ich habe das gleiche Problem wie hier beschrieben:
Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt ...
Es wird beschrieben dass es an folgende Punkte liegen kann:
-die Uhrzeit auf Client und Server unterscheiden sich stark --> Ist nicht der Fall
-der Client wurde geklont und (zumindest kurzzeitig) parallel mit dem Klon eingesetzt --> wir betreiben tatsächlich ein Imagein, das würde ja bedeutet doppelte SID, richtig?
-der Client wurde aus einem Image erstellt/restored, das älter als 30 Tage ist ->in diesem Fall ist das Kennwort des Computerkontos nämlich nicht mehr identisch mit dem, welches der DC gespeichert hat. Der DC ruft die Computerobjekte alle 30 Tage zu einer Kennwortänderung auf. --> Verstehe ich nicht ganz die Aussage: Natürlich ist ein Image im normallfall älter als 30 Tage alt aber was hat es damit zu tun? Man spielt das Image ein, welches zuvor mit Sysprep ausgeführt wurde. Somit wird ein neuer lokaler account angelegt ( der sollte dadurch eine andere SID erhalten) meldet diesen ab oder löscht ihn und meldet sich mit dem Domänenbenutzer an.
Fragen:
1. Die SID bezieht sich doch auf den benutzeraccount oder? Was hat das Imagein des Rechners damit zu tun? DIe Benutzer werden ja im AD angelegt..
2. Wo kann ich mir im AD die SID anzeigen lassen?
3. Ist es möglich über den AD mir auf einen Blick alle SIDs anzeigen zu lassen? Um überprüfen zu können ob tatsächlich eine doppelt vergeben war/ist.
Wäre über jede Hilfe dankbar!
Gruß
Grecho
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: 294506
Url: https://administrator.de/contentid/294506
Ausgedruckt am: 18.11.2024 um 03:11 Uhr
4 Kommentare
Neuester Kommentar
Hi.
1 Nein, auf den Rechner, nicht den Nutzer.
2 in den Eigenschaften des Objektes, Reiter "Attribute"
3 Nein. Du könntest allenfalls mittels Skripten so eine Liste erzeugen.
"wir betreiben tatsächlich ein Imagein, das würde ja bedeutet doppelte SID, richtig?" - das kann man erst beantworten, wenn man weiß, wie Ihr klont. Wenn ich ein Image nehme und es auf neue Hardware aufspiele, dann fahre ich den rechner offline hoch und nehme ihn aus der Domäne, verbinde ihn wieder und nehme ihn wieder rein in die Domäne - da kommt es zu keinen Problemen mit der Vertrauensstellung, da aus Sicht des DCs nie zweimal die selbe SID online war.
1 Nein, auf den Rechner, nicht den Nutzer.
2 in den Eigenschaften des Objektes, Reiter "Attribute"
3 Nein. Du könntest allenfalls mittels Skripten so eine Liste erzeugen.
"wir betreiben tatsächlich ein Imagein, das würde ja bedeutet doppelte SID, richtig?" - das kann man erst beantworten, wenn man weiß, wie Ihr klont. Wenn ich ein Image nehme und es auf neue Hardware aufspiele, dann fahre ich den rechner offline hoch und nehme ihn aus der Domäne, verbinde ihn wieder und nehme ihn wieder rein in die Domäne - da kommt es zu keinen Problemen mit der Vertrauensstellung, da aus Sicht des DCs nie zweimal die selbe SID online war.
Zitat von @Grecho:
ich habe das gleiche Problem wie hier beschrieben:
Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt ...
ich habe das gleiche Problem wie hier beschrieben:
Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt ...
Wo ich das gerade lese, ich hatte das Problem auch kürzlich, und zwar bei einem Rechner, der vorher problemlos funktionierte.
Ich habe mich dann als lokaler Administrator angemeldet, und plötzlich fragte Windows erneut nach der Einordnung des Netzwerks (Heimnetz, Arbeitsplatznetzwerk oder öffentliches Netzwerk). Als ich Arbeitsplatznetzwerk angegeben habe, funktionierte die Domänenanmeldung wieder, auch ohne dass ich den Rechner aus der Domäne genommen und wieder eingefügt habe. Kann sich (und mir) das jemand erklären?
Schöne Grüße,
Sarek \\//_
Hi Grecho,
teste mal in der Powershell am Clienten: Test-ComputerSecureChannel –Repair
und/oder
Reset-ComputerMachinePassword -Server Domänencontroller -Credential Domäne\Benutzer
mfg
kowa
teste mal in der Powershell am Clienten: Test-ComputerSecureChannel –Repair
und/oder
Reset-ComputerMachinePassword -Server Domänencontroller -Credential Domäne\Benutzer
mfg
kowa
Hallo,
das gleiche Problem hatte ich auch soeben mit einem Rechner.
Habe ihn aus der Domäne raus und wieder rein, funktioniert wieder.
Im Attribut-Editor habe ich folgenden Eintrag gefunden, der sonst bei anderen Clients auf 0 steht:
badpasswordtime: heutiges Datum sowie Zeit.
Kann das Attribut allerdings nicht auf 0 setzen.
Gruß
das gleiche Problem hatte ich auch soeben mit einem Rechner.
Habe ihn aus der Domäne raus und wieder rein, funktioniert wieder.
Im Attribut-Editor habe ich folgenden Eintrag gefunden, der sonst bei anderen Clients auf 0 steht:
badpasswordtime: heutiges Datum sowie Zeit.
Kann das Attribut allerdings nicht auf 0 setzen.
Gruß
