Vertrauensstellung verloren. Warum?
Was ist der Grund dafür?
Hallo Ihr Lieben
Hier wurden ja schon mehrere Kommentare zum o.g. Thema erstellt und abgegeben, aber was ist der eigentliche Grund für das Verlieren der Vertrauensstellung eines Clientcomputers zur Domäne?
Heute sagt mir nämlich ein Clöientrechner, dass er die Vertrauensstellung zur Domäne verloren hat und ich diese neu einrichten soll. Dass ich den Client in die Workgroup zurücknehmen kann und dann wieder (nach Neustart) in die Domäne heben ist mir klar.
(gehen dabei eigentlich Userdaten verloren? Ich habe hier auch gelesen, dass dann neue Userprofile angelegt werden a la "username.0001" usw.)
Meine eigentliche Frage ist aber, warum kommt es zu diesem Szenario erst, so dass man dies beim nächsten Mal einfach schon verhindern kann?
Gleiche SIDs von Clienten gibt es nicht, da seit Wochen kein neuer Rechner hinzugekommen ist, der zufällig dieselbe SID haben könnte und es über Wochen auch reibungslos funktioniert hat.
Achso wir benutzen einen Server 2003 32bit und einen Server 2003 R2 64bit als Domaincontroller und der Client, den es betrifft, ist ein Win 7 Pro 32bit.
Wer hat eine/mehrere *plausible* Erklärungen, so dass ich diese auch verstehen kann?
Vielen Dank für Eure Mühe!
Gruß Kuli
Hallo Ihr Lieben
Hier wurden ja schon mehrere Kommentare zum o.g. Thema erstellt und abgegeben, aber was ist der eigentliche Grund für das Verlieren der Vertrauensstellung eines Clientcomputers zur Domäne?
Heute sagt mir nämlich ein Clöientrechner, dass er die Vertrauensstellung zur Domäne verloren hat und ich diese neu einrichten soll. Dass ich den Client in die Workgroup zurücknehmen kann und dann wieder (nach Neustart) in die Domäne heben ist mir klar.
(gehen dabei eigentlich Userdaten verloren? Ich habe hier auch gelesen, dass dann neue Userprofile angelegt werden a la "username.0001" usw.)
Meine eigentliche Frage ist aber, warum kommt es zu diesem Szenario erst, so dass man dies beim nächsten Mal einfach schon verhindern kann?
Gleiche SIDs von Clienten gibt es nicht, da seit Wochen kein neuer Rechner hinzugekommen ist, der zufällig dieselbe SID haben könnte und es über Wochen auch reibungslos funktioniert hat.
Achso wir benutzen einen Server 2003 32bit und einen Server 2003 R2 64bit als Domaincontroller und der Client, den es betrifft, ist ein Win 7 Pro 32bit.
Wer hat eine/mehrere *plausible* Erklärungen, so dass ich diese auch verstehen kann?
Vielen Dank für Eure Mühe!
Gruß Kuli
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 162397
Url: https://administrator.de/forum/vertrauensstellung-verloren-warum-162397.html
Ausgedruckt am: 26.12.2024 um 00:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo Kuli,
Wenn du diesen Client als Admin (wie von dir beschrieben) in die Domäne zurückholst und die Frage beim bereits existierenden Computerkonto mit ja beantwortest, dann gibt es keinerlei Probleme bzgl. neuer Profile der User.
Auch nicht bei lokalen Profilen.
Als Begründung könnte eventuell die TSL (Tombstone Lifetime) dienen. Wenn dieser Client eine bestimmte Zeit lang immer mit Cached Credentials angemeldet wurde (ohne LAN-Verbindung), verliert er irgend wann die Vertrauensstellung zur Domäne.
Wann genau, dass ist abhängig vom 1.DC in der Gesamtstruktur und wird hier von Yusuf Dikmenoglu hervorragend erklärt:
http://blog.dikmenoglu.de/PermaLink,guid,98a23bfe-f3ff-4012-8fc3-13b98e ...
PS: Ich hatte dieses Problem auch beim Restoren eines W7-Images (mit BESR gemacht). Raus aus der Domäne und wieder rein genommen und seither läuft dieser Client wie zuvor.
Achso wir benutzen einen Server 2003 32bit und einen Server 2003 R2 64bit als Domaincontroller und der Client, den es betrifft,
ist ein Win 7 Pro 32bit.
Wer hat eine/mehrere *plausible* Erklärungen, so dass ich diese auch verstehen kann?
Ich kenne dieses Problem auch.ist ein Win 7 Pro 32bit.
Wer hat eine/mehrere *plausible* Erklärungen, so dass ich diese auch verstehen kann?
Wenn du diesen Client als Admin (wie von dir beschrieben) in die Domäne zurückholst und die Frage beim bereits existierenden Computerkonto mit ja beantwortest, dann gibt es keinerlei Probleme bzgl. neuer Profile der User.
Auch nicht bei lokalen Profilen.
Als Begründung könnte eventuell die TSL (Tombstone Lifetime) dienen. Wenn dieser Client eine bestimmte Zeit lang immer mit Cached Credentials angemeldet wurde (ohne LAN-Verbindung), verliert er irgend wann die Vertrauensstellung zur Domäne.
Wann genau, dass ist abhängig vom 1.DC in der Gesamtstruktur und wird hier von Yusuf Dikmenoglu hervorragend erklärt:
http://blog.dikmenoglu.de/PermaLink,guid,98a23bfe-f3ff-4012-8fc3-13b98e ...
PS: Ich hatte dieses Problem auch beim Restoren eines W7-Images (mit BESR gemacht). Raus aus der Domäne und wieder rein genommen und seither läuft dieser Client wie zuvor.
Zitat von @kugelschreiber:
Anmerkung: Aber dann müsste doch allerdings auch der Hinweis kommen, dass der User Offline arbeitet, oder sind das 2 Paar
Schuhe?
Anmerkung: Aber dann müsste doch allerdings auch der Hinweis kommen, dass der User Offline arbeitet, oder sind das 2 Paar
Schuhe?
Definitiv 2 Paar Schuhe.
Zum testen kannst du mal deinen Rechner herunterfahren, das Netzwerkkabel ziehen und den Rechner wieder hochfahren.
Log dich ganz normal mit deinem Domänen-Login ein und der Rechner wird keine Anstalten machen, dich nicht reinzulassen (zumindest XP).
Der Rechner vertraut praktisch darauf, dass er noch im Netz hängt und schaut nicht mal wirklich nach. Gibt meines Wissens nach auch keine Meldung, wenn das Home-Laufwerk nicht verbunden werden konnte (was ja schlecht geht, ohne Netzwerkanschluss).
Gruß
Snow
Was die TSL damit zu tun haben soll, ist mir schleierhaft, vielleicht kann Goscho nochmal den Gedankengang verdeutlichen - gelöscht wird hier doch gar nicht.
PS: Ich hatte dieses Problem auch beim Restoren eines W7-Images (mit BESR gemacht)
Das ist erklärbar. Das Systemkonto des PCs wechselt in Abstimmung mit dem DC alle 30 Tage das Kennwort automatisch. Ist das Kennwort im Image nicht mehr übereinstimmend mit dem aktuellen, lässt der DC keine Anmeldungen mehr zu - Vertrauensstellung verloren. Sprich: je näher das Alter des Images an 30 Tagen ist, desto wahrscheinlicher tritt das auf - bei mehr als 30 Tagen mit Gewissheit.
Gut eine Erklärung für das Verhalten gefunden zu haben mit dem ich mich ebenfalls auseinandersetze. Dazu ein paar Fragen:
1. Kann ich als Enduser die Gültigkeit dieses Vertrauenstokens feststellen um zu sehen wann ein neues ausgehandelt wird? Das würde mir helfen entsprechend mit Images zu planen.
2. Kann ich denn einen neuen Vertrauenstoken anfordern bzw. erzwingen? Vielleicht durch eine Passwortänderung?
3. Und gibt es Möglichkeit dieses Problem gleich gänzlich auszuschließen oder vielleicht auf anderem Wege ihm den neuen Vertrauenstoken mitzuteilen? Mal abgesehen davon, dass Konto zu entfernen und neu einzurichten, denn das ist für mich als Enduser ja nicht so eben möglich und ich möchte unseren Admins damit nicht so auf den Wecker fallen.
1. Kann ich als Enduser die Gültigkeit dieses Vertrauenstokens feststellen um zu sehen wann ein neues ausgehandelt wird? Das würde mir helfen entsprechend mit Images zu planen.
2. Kann ich denn einen neuen Vertrauenstoken anfordern bzw. erzwingen? Vielleicht durch eine Passwortänderung?
3. Und gibt es Möglichkeit dieses Problem gleich gänzlich auszuschließen oder vielleicht auf anderem Wege ihm den neuen Vertrauenstoken mitzuteilen? Mal abgesehen davon, dass Konto zu entfernen und neu einzurichten, denn das ist für mich als Enduser ja nicht so eben möglich und ich möchte unseren Admins damit nicht so auf den Wecker fallen.
Hi regtest, ich hab mich mal schlau gemacht und gefunden, was Dir weiterhilft:
*
On the DC or any computer with RSAT you can run dsquery computer -name ComputerName -stalepwd x
ComputerName is the name of the computer you want to check
x is the number of days since the password is last set.
If the password hasn't been set since x number of days, it will return the name and containers of the computer. If the password has been set within the last x days, it will return nothing.
*
Quelle: http://serverfault.com/questions/149558/when-is-a-domain-computer-accou ...
Weiterführender Link: http://blogs.msdn.com/b/sudhakan/archive/2010/01/07/experimenting-with- ...
In letzterem steht auch, wie man die Kennwortzyklen ändert/deaktiviert.
Also:
1) Jein. Nur wenn Du rsat drauf hast und über ein Konto verfügst, dass diese Anfrage machen darf... ich bin nicht sicher, ob das jedes Konto darf
2) Kannst Du... jedoch nicht, nachdem er schon abgelaufen ist ;(
3) Ja, siehe letzteren Link. Dort steht auch, wie man die Kennwortzyklen ändert/deaktiviert.
*
On the DC or any computer with RSAT you can run dsquery computer -name ComputerName -stalepwd x
ComputerName is the name of the computer you want to check
x is the number of days since the password is last set.
If the password hasn't been set since x number of days, it will return the name and containers of the computer. If the password has been set within the last x days, it will return nothing.
*
Quelle: http://serverfault.com/questions/149558/when-is-a-domain-computer-accou ...
Weiterführender Link: http://blogs.msdn.com/b/sudhakan/archive/2010/01/07/experimenting-with- ...
In letzterem steht auch, wie man die Kennwortzyklen ändert/deaktiviert.
Also:
1) Jein. Nur wenn Du rsat drauf hast und über ein Konto verfügst, dass diese Anfrage machen darf... ich bin nicht sicher, ob das jedes Konto darf
2) Kannst Du... jedoch nicht, nachdem er schon abgelaufen ist ;(
3) Ja, siehe letzteren Link. Dort steht auch, wie man die Kennwortzyklen ändert/deaktiviert.
Perfekt. Danke. Habe bereits RSAT installiert und kann mit dquery herausfinden wann das letztemal der Token geändert wurde. Weiterhin nutze ich dann den Command: nltest.exe /sc_change_pwd:mycompany.com um die Änderung des Tokens zu erzwingen. Das ist bereits sehr hilfreich in der Image/VM Pflege.
Ob ich es ganz per Computerrichtlinien deaktivieren kann/darf kläre ich noch. Vielen Dank nochmal.
Ob ich es ganz per Computerrichtlinien deaktivieren kann/darf kläre ich noch. Vielen Dank nochmal.