32
Zeitsynchronisation für Windows-Clients im Netzwerk
Hallo miteinander,
ich stehe vor folgendem Problem und wüßte nicht, welcher Lösungsweg der 'Beste' ist. Ich hoffe auf Eure Hilfe und Unterstützung. Folgendes Szenario:
- IPCop mit Zeitserverdient (lauscht auf UDP:123) und hat immer die aktuelle Uhrzeit, da er sie sich vom Internet alle paar Stunden holt.
- Mein PDC ist ein Sambaserver und mittels dem Paket NTP halte ich die Linuxsystemzeit immer aktuell mit dem IPCop.
- Auf dem PDC/Sambaserver verwende ich "time server = yes" somit funktioniert er auch als Zeitserver. Alle Windows-Clients, die sich an dieser Domäne anmelden erhalten also die Anweisung ihre Zeit mit ihm zu aktualisieren.
Problem --> Das funktioniert aber leider nur, wenn der anmeldende Domänenbenutzer an dem Windows-Client mindestens Hauptbenutzerrechte hat. Leider sind meine Domänenbenutzer keine Hauptbenutzer, sondern nur "normale" Benutzer. Sie haben also kein Recht die Systemzeit zu ändern.
Ich kann jetzt natürlich auf dem Client die lokale Gruppenrichtlinie/Benutzerrechte so einstellen, dass auch diese 'normale' Domänenuser oder einfachhalber "JEDER" die Systemzeit ändern kann. Dann klappt das auch, nach der Anmeldung wird die "richtige" Uhrzeit vom PDC geholt und lokal am Client eingestellt.
Jetzt habe ich aber wirklich keine Lust auf 200 Clients diese Einstellung durchzuführen, denn von Turnschuhadministration halte ich nicht viel. Jetzt sagen die meisten sicherlich: dann verteils per GPO! Ich würd's ja liebend gerne, aaaaaber: ich verwende kein AD und hab leider keine GPOs (jaja, hoffentlich kommt bald Samba4 stable *gääähn*)
Wie soll ich die lokalen Gruppenrichtlinien all der Windows-Clients so abändern,dass alle User das Recht besitzen die Systemzeit zu ändern???
Selbst wenn ich das irgendwie hinkriegen sollte, stellt sich für mich noch folgendes Problem: die Zeitanpassung würde dann quasi nur nach einer Anmeldung an der Domäne erfolgen. Der Domänenuser XY loggt sich an der Domäne an und erhält dadurch die Zeit von diesem PDC. Er hat das Recht und passt seine lokale Systemzeit an. Soweit ok, aber: es gibt teilweise Rechner die nutzen einen Domänenaccount, die sind aber monatelang non-stop eingeloggt ohne sich abzumelden. Das sind meist irgendwelche lokalen Serverdienste oder Spezialfälle. Das bedeutet, dass solche Clients nicht up-to-date wären, denn ihre Systemzeit aktualisiert sich nur bei den Domänenlogins.
Also wäre es nicht besser, dass ich auf allen Clients die Internetzeit-Synchronisation einstelle? Ab WinXP gibts das doch, Win2k hat das glaub gar nicht ??? Rechtsklick auf die Uhr, Datum/Uhrzeit ändern, und dann ganz rechts auf den Reiter [Internetzeit] klicken. Dort kann ich einen Server einstellen. Die entsprechenden Registry-Keys sind dann auf
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time
Das scheint mir doch die 'richtige' Lösung zu sein, und sehr naheliegend dass es sich hier um einen NTP-Client handelt. Oder irre ich mich? Ich würde also als Server entweder IPCOP eintragen oder von mir aus die IP des PDC/Domänencontrollers, denn beide können NTP-dienste leisten.
Allerdings bin ich auch hier auf Skepsis gestossen, denn: der Versuch bei einigen Windows-Clients (XP + Win7) hierdurch die Zeit zu syncen schlug fehl mit Ergebnis TimeOut-Fehler. Irgendwann hats geklappt, aber ich fand keinen Zusammenhang. Linux-Clients haben null Probleme, dessen NTP-Dienst kann problemlos mit meinem NTP-Dienst auf IPCOP oder dem DOMÄNENCONTROLLER kommunizieren und die Zeit abholen. Kann es sein, dass es evtl. daran liegt ==> http://www.meinberg.de/german/faq/faq_28.htm
Wie sehen die Meinungen der Pro's aus, und welchen Weg würdet ihr mir empfehlen, damit ich alle Windows-Clients synchron halte?
Danke an Allen im Voraus.
ich stehe vor folgendem Problem und wüßte nicht, welcher Lösungsweg der 'Beste' ist. Ich hoffe auf Eure Hilfe und Unterstützung. Folgendes Szenario:
- IPCop mit Zeitserverdient (lauscht auf UDP:123) und hat immer die aktuelle Uhrzeit, da er sie sich vom Internet alle paar Stunden holt.
- Mein PDC ist ein Sambaserver und mittels dem Paket NTP halte ich die Linuxsystemzeit immer aktuell mit dem IPCop.
- Auf dem PDC/Sambaserver verwende ich "time server = yes" somit funktioniert er auch als Zeitserver. Alle Windows-Clients, die sich an dieser Domäne anmelden erhalten also die Anweisung ihre Zeit mit ihm zu aktualisieren.
Problem --> Das funktioniert aber leider nur, wenn der anmeldende Domänenbenutzer an dem Windows-Client mindestens Hauptbenutzerrechte hat. Leider sind meine Domänenbenutzer keine Hauptbenutzer, sondern nur "normale" Benutzer. Sie haben also kein Recht die Systemzeit zu ändern.
Ich kann jetzt natürlich auf dem Client die lokale Gruppenrichtlinie/Benutzerrechte so einstellen, dass auch diese 'normale' Domänenuser oder einfachhalber "JEDER" die Systemzeit ändern kann. Dann klappt das auch, nach der Anmeldung wird die "richtige" Uhrzeit vom PDC geholt und lokal am Client eingestellt.
Jetzt habe ich aber wirklich keine Lust auf 200 Clients diese Einstellung durchzuführen, denn von Turnschuhadministration halte ich nicht viel. Jetzt sagen die meisten sicherlich: dann verteils per GPO! Ich würd's ja liebend gerne, aaaaaber: ich verwende kein AD und hab leider keine GPOs (jaja, hoffentlich kommt bald Samba4 stable *gääähn*)
Wie soll ich die lokalen Gruppenrichtlinien all der Windows-Clients so abändern,dass alle User das Recht besitzen die Systemzeit zu ändern???
Selbst wenn ich das irgendwie hinkriegen sollte, stellt sich für mich noch folgendes Problem: die Zeitanpassung würde dann quasi nur nach einer Anmeldung an der Domäne erfolgen. Der Domänenuser XY loggt sich an der Domäne an und erhält dadurch die Zeit von diesem PDC. Er hat das Recht und passt seine lokale Systemzeit an. Soweit ok, aber: es gibt teilweise Rechner die nutzen einen Domänenaccount, die sind aber monatelang non-stop eingeloggt ohne sich abzumelden. Das sind meist irgendwelche lokalen Serverdienste oder Spezialfälle. Das bedeutet, dass solche Clients nicht up-to-date wären, denn ihre Systemzeit aktualisiert sich nur bei den Domänenlogins.
Also wäre es nicht besser, dass ich auf allen Clients die Internetzeit-Synchronisation einstelle? Ab WinXP gibts das doch, Win2k hat das glaub gar nicht ??? Rechtsklick auf die Uhr, Datum/Uhrzeit ändern, und dann ganz rechts auf den Reiter [Internetzeit] klicken. Dort kann ich einen Server einstellen. Die entsprechenden Registry-Keys sind dann auf
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time
Das scheint mir doch die 'richtige' Lösung zu sein, und sehr naheliegend dass es sich hier um einen NTP-Client handelt. Oder irre ich mich? Ich würde also als Server entweder IPCOP eintragen oder von mir aus die IP des PDC/Domänencontrollers, denn beide können NTP-dienste leisten.
Allerdings bin ich auch hier auf Skepsis gestossen, denn: der Versuch bei einigen Windows-Clients (XP + Win7) hierdurch die Zeit zu syncen schlug fehl mit Ergebnis TimeOut-Fehler. Irgendwann hats geklappt, aber ich fand keinen Zusammenhang. Linux-Clients haben null Probleme, dessen NTP-Dienst kann problemlos mit meinem NTP-Dienst auf IPCOP oder dem DOMÄNENCONTROLLER kommunizieren und die Zeit abholen. Kann es sein, dass es evtl. daran liegt ==> http://www.meinberg.de/german/faq/faq_28.htm
Wie sehen die Meinungen der Pro's aus, und welchen Weg würdet ihr mir empfehlen, damit ich alle Windows-Clients synchron halte?
Danke an Allen im Voraus.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 189678
Url: https://administrator.de/forum/zeitsynchronisation-fuer-windows-clients-im-netzwerk-189678.html
Ausgedruckt am: 14.03.2025 um 08:03 Uhr
32 Kommentare
Neuester Kommentar
Danke für den Link, aber: das erklärt leider nicht mein angesprochenes Rechteproblem und Lösungsansatz. Außerdem frage ich mich, wie ich all die W2k-Clients ebenso mitsyncen soll, bei denen fehlt der Reiter "Internetzeit" komplett.
Übrigens: Hab ich das emfohlene Verhalten (hier beschrieben http://www.meinberg.de/german/faq/faq_28.htm) getestet. Da wird ja der Wert 0x8 für den abzufragenden Server angegeben. Wenn man das Kommando "w32tm blabla" auf der Kommandozeile eingibt, dann wird dabei der Schlüssel "NtpServer" in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters angepasst. Stand vorher drin "meinntpserver,0x1" steht nach Absetzen des Kommandos "meinntpserver,0x8" drin. Wer nachlesen möchte wo die Unterschiede zwischen 0x1 (SpecialInterval) und 0x8 (Client) liegen, kann das gerne hier --> http://go.microsoft.com/fwlink/?LinkId=208012
Wenn ich 0x1 (also default) nutze, und die Zeit durch meinen Server holen möchte, dann sehe ich dass paar Sekunden versucht wird die Zeit zu holen. Danach erscheint ein Fehler, dass das Timeout überschritten wurde und gleich danach in der nächsten Zeile steht dass die Zeit gesynct wurde. Das widerspricht sich natürlich und die Zeit hat sich natürlich nicht gesynct. Doch wie von Geisterhand nach ca. 10 Sekunden wird daraufhin die korrekte Zeit gesynct. Das ist sehr komisch, ich vermute dass es daran liegt durch den 0x1 Modus (Sync-Modus).
Wenn man dem Client 0x8 mitgibt veranlasst man ihn, lediglich als NTP-Client aufzutreten. So funktioniert der Timesync gleich auf Anhieb.
Win7-Clients verwenden übrigens defaultmässig 0x9, worüber ich noch keine Infos finden konnte.
Ich vermute diese ganze wirre Problematik besteht darin, dass mein Samba-PDC 'richtiges' NTP spricht, wogegen der Windows-Client nur das SNTP (simple NTP) spricht. SNTP ist halt nicht so zuverlässig und genau wie NTP, ich denke dass es deswegen so verkompliziert wird. Gibts keinen reinen NTP-Client für Windows-Clients? Klar --> http://www.nist.gov/pml/div688/grp40/softwarelist.cfm Aber das ist sicherlich nix für einen Domänenbetrieb und Setup übr GPOs. Grmbl,hmpf
Übrigens: Hab ich das emfohlene Verhalten (hier beschrieben http://www.meinberg.de/german/faq/faq_28.htm) getestet. Da wird ja der Wert 0x8 für den abzufragenden Server angegeben. Wenn man das Kommando "w32tm blabla" auf der Kommandozeile eingibt, dann wird dabei der Schlüssel "NtpServer" in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters angepasst. Stand vorher drin "meinntpserver,0x1" steht nach Absetzen des Kommandos "meinntpserver,0x8" drin. Wer nachlesen möchte wo die Unterschiede zwischen 0x1 (SpecialInterval) und 0x8 (Client) liegen, kann das gerne hier --> http://go.microsoft.com/fwlink/?LinkId=208012
Wenn ich 0x1 (also default) nutze, und die Zeit durch meinen Server holen möchte, dann sehe ich dass paar Sekunden versucht wird die Zeit zu holen. Danach erscheint ein Fehler, dass das Timeout überschritten wurde und gleich danach in der nächsten Zeile steht dass die Zeit gesynct wurde. Das widerspricht sich natürlich und die Zeit hat sich natürlich nicht gesynct. Doch wie von Geisterhand nach ca. 10 Sekunden wird daraufhin die korrekte Zeit gesynct. Das ist sehr komisch, ich vermute dass es daran liegt durch den 0x1 Modus (Sync-Modus).
Wenn man dem Client 0x8 mitgibt veranlasst man ihn, lediglich als NTP-Client aufzutreten. So funktioniert der Timesync gleich auf Anhieb.
Win7-Clients verwenden übrigens defaultmässig 0x9, worüber ich noch keine Infos finden konnte.
Ich vermute diese ganze wirre Problematik besteht darin, dass mein Samba-PDC 'richtiges' NTP spricht, wogegen der Windows-Client nur das SNTP (simple NTP) spricht. SNTP ist halt nicht so zuverlässig und genau wie NTP, ich denke dass es deswegen so verkompliziert wird. Gibts keinen reinen NTP-Client für Windows-Clients? Klar --> http://www.nist.gov/pml/div688/grp40/softwarelist.cfm Aber das ist sicherlich nix für einen Domänenbetrieb und Setup übr GPOs. Grmbl,hmpf
Eigentlich und ganz simpel ausgedrückt:
wie kann ich all meinen Windows-Clients (Win2000, WinXP, Win7) mit einem Schlag die Richtlinie "Ändern der Systemzeit" auch für "MYDOMAIN\DOMAIN USERS" (oder JEDER) übermitteln? Ich hab leider kein AD und kann keine GPOs verteilen. Wie könnte ich das also zentral von meinem Terminal an alle Clients übertragen? Sie brauchen ja auf jeden Fall das Recht, die Systemzeit ändern zu können, oder nicht?
wie kann ich all meinen Windows-Clients (Win2000, WinXP, Win7) mit einem Schlag die Richtlinie "Ändern der Systemzeit" auch für "MYDOMAIN\DOMAIN USERS" (oder JEDER) übermitteln? Ich hab leider kein AD und kann keine GPOs verteilen. Wie könnte ich das also zentral von meinem Terminal an alle Clients übertragen? Sie brauchen ja auf jeden Fall das Recht, die Systemzeit ändern zu können, oder nicht?
Moin.
200 Clients und keine GPOs? Wer verantwortet denn sowas? Sei's drum.
Du kannst folgendes machen: Mit psexec kannst Du ja nahezu alles remote machen, wenn Du nur über ein Adminkennwort verfügst. Privilegien kannst Du mit der ntrights.exe (->resourcekit, google mal danach) per Kommando setzen.
200 Clients und keine GPOs? Wer verantwortet denn sowas? Sei's drum.
Du kannst folgendes machen: Mit psexec kannst Du ja nahezu alles remote machen, wenn Du nur über ein Adminkennwort verfügst. Privilegien kannst Du mit der ntrights.exe (->resourcekit, google mal danach) per Kommando setzen.
der Betrieb der eben mit Samba-Domänen arbeitet und nicht mit Windows-Servern. Aber das wäre jetzt off-topic, fakt ist, dass eben kein AD zur Verfügung steht.
ich kann mit psexec Kommandos absetzen, aber könnte ich auch solche Gruppenrichtlinien per Kommandozeilenbefehle durchgeben? Welche Befehl wäre hierfür zuständig? Ich kann doch nicht einfach "mmc" absetzen, da müssten doch sicherlich etliche Optionen noch mitgegeben werden (wenn das überhaupt denn funktioniert).
ich kann mit psexec Kommandos absetzen, aber könnte ich auch solche Gruppenrichtlinien per Kommandozeilenbefehle durchgeben? Welche Befehl wäre hierfür zuständig? Ich kann doch nicht einfach "mmc" absetzen, da müssten doch sicherlich etliche Optionen noch mitgegeben werden (wenn das überhaupt denn funktioniert).
Mir scheint, Du hast meinen Beitrag nur überflogen. Alle benötigten infos sind drin.
Tatsächlich, ich hatte das mit ntrights übersehen. Werde das aus dem RK mal installieren und probieren. danke dir
Hallo nochmal,
ich hab mich da ein wenig eingelesen und hab hierzu noch einige Fragen offen. Also mit ntrights könnte ich arbeiten, um die Rechte an den Clients so anzupassen dass auch "normale Benutzer" die Zeit ändern können. Jedoch würde ein Client nur dann die korrekte Uhrzeit vom PDC erhalten wenn er sich an der Domäne anmeldet und durch sein Loginskript mit dem Befehl "w32time bla" die Zeit richtig gesetzt würde. Würde sich aber ein Benutzer 4 Wochen lang nicht abmelden, dann würde er auch nie eine Zeitsynchronisation erfahren, da sein Loginskript nicht abgearbeitet wird. Ich denke daher die Zeitsetzung durch Loginskripts ist ziemlich blöd. Deswegen hat sich wohl Windows auch die "Domain-Zeit-Synchronisierung" wohl ausgedacht mit "w32time /config /syncfromflags:domhier /update" veranlasst man den Windows-Client, sich die Zeit von der zuständigen Domain zu holen. Das ist auch der Defaultwert bei Windows-Clients.
http://technet.microsoft.com/en-us/library/cc758905(v=ws.10)
in der Windows-Registry unter HKLM/System/CurrentControlSet/Services/W32Time/Parameters überprüfe ich, dass unter dem Feld "Type" auch NT5DS steht. Das ist nämlich der Schlüssel, der für diese DOMHIERARCHY SYNCHRONISIERUNG steht. (http://support.microsoft.com/default.aspx?scid=kb;de;223184&FR=1&am ..)
Jedoch kann ich selbst das in meinem Falle nicht nutzen, da ich kein AD verwende, aber für diese Funktion zwingend AD erforderlich ist. Bleibt mir also nichts anderes übrig, dass ich jedem Client quasi manuell den NTP-Server mitgeben muss, an dem er sich syncen soll. Das funktioniert entweder in Windows in der Zeiteinstellungen im Reiter [INTERNETZEIT], durch Nutzung der Kommandozeile "w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de" /syncfromflags:MANUAL oder eben durch manuelles Setzen der entsprechenden Registry-Werte.
Soweit so gut, würde auch funktionieren, habs getestet. Jedoch überlege ich mir nun: wie soll ich all meinen Clients diese Einstellung übermitteln? Ich könnte im zentralen Loginskript natürlich das hier verwenden:
w32tm /config /manualpeerlist:mein.internet.zeitserver /syncfromflags:MANUAL
aber das würde beim Client fehlschlagen, da für das Konfigurieren des Zeitdiensten höhere Rechte erforderlich sind. Mit ntrights irgendwas ändern bringt mir ja nichts, ich will ja nur temporär und zwar während dem Loginskript dem Client Rechte geben, so daß er w32tm.exe nutzen darf.
Wie mache ich das?
ich hab mich da ein wenig eingelesen und hab hierzu noch einige Fragen offen. Also mit ntrights könnte ich arbeiten, um die Rechte an den Clients so anzupassen dass auch "normale Benutzer" die Zeit ändern können. Jedoch würde ein Client nur dann die korrekte Uhrzeit vom PDC erhalten wenn er sich an der Domäne anmeldet und durch sein Loginskript mit dem Befehl "w32time bla" die Zeit richtig gesetzt würde. Würde sich aber ein Benutzer 4 Wochen lang nicht abmelden, dann würde er auch nie eine Zeitsynchronisation erfahren, da sein Loginskript nicht abgearbeitet wird. Ich denke daher die Zeitsetzung durch Loginskripts ist ziemlich blöd. Deswegen hat sich wohl Windows auch die "Domain-Zeit-Synchronisierung" wohl ausgedacht
mit "w32time /config /syncfromflags:domhier /update" veranlasst man den Windows-Client, sich die Zeit von der zuständigen Domain zu holen. Das ist auch der Defaultwert bei Windows-Clients.http://technet.microsoft.com/en-us/library/cc758905(v=ws.10)
in der Windows-Registry unter HKLM/System/CurrentControlSet/Services/W32Time/Parameters überprüfe ich, dass unter dem Feld "Type" auch NT5DS steht. Das ist nämlich der Schlüssel, der für diese DOMHIERARCHY SYNCHRONISIERUNG steht. (http://support.microsoft.com/default.aspx?scid=kb;de;223184&FR=1&am ..)
Jedoch kann ich selbst das in meinem Falle nicht nutzen, da ich kein AD verwende, aber für diese Funktion zwingend AD erforderlich ist. Bleibt mir also nichts anderes übrig, dass ich jedem Client quasi manuell den NTP-Server mitgeben muss, an dem er sich syncen soll. Das funktioniert entweder in Windows in der Zeiteinstellungen im Reiter [INTERNETZEIT], durch Nutzung der Kommandozeile "w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de" /syncfromflags:MANUAL oder eben durch manuelles Setzen der entsprechenden Registry-Werte.
Soweit so gut, würde auch funktionieren, habs getestet. Jedoch überlege ich mir nun: wie soll ich all meinen Clients diese Einstellung übermitteln? Ich könnte im zentralen Loginskript natürlich das hier verwenden:
w32tm /config /manualpeerlist:mein.internet.zeitserver /syncfromflags:MANUAL
aber das würde beim Client fehlschlagen, da für das Konfigurieren des Zeitdiensten höhere Rechte erforderlich sind. Mit ntrights irgendwas ändern bringt mir ja nichts, ich will ja nur temporär und zwar während dem Loginskript dem Client Rechte geben, so daß er w32tm.exe nutzen darf.
Wie mache ich das?
Du kannst anstelle des Loginscripts ein Startskript nutzen, das hat hohe (=Systemrechte) Rechte.
Kannst du mir nähere Infos zu diesem STARTSKRIPT geben? Wo finde ich dieses Startskript auf Samba? Das sagt mir jetzt auf Anhieb erstmal gar nix :S
Bevor wir uns da verzetteln: Nimm einfach psexec dafür und gut.
Wir verzetteln uns nicht, erklär mir doch bitte wie das mit dem Startskript gehen soll, dass du angesprochen hast. PSEXEC im Logonskript? ich möchte ja nix remote ausführen, jetzt reden wir aneinander vorbei. Ausserdem wird mit psexec das Passwort im Klartext angegeben, mit welchem man superuser Rechte erzielt. Das ist hier wirklich nicht das Gelbe vom Ei, wenn der Benutzer so etwas abfangen könnte. Dazu gibts Tools wie CPAU, die ich ja bereits ausprobiert habe. Da kann man das ganze encrypten und in einem Jobfile hinterlegen. Soweit funktioniert das auch ganz gut, nur mit Win7 Clients gehts nicht, da scheints trotz Beachtung der Anleitung mit der notwendigen Schaltern nicht zu funktionieren.
Wie um alles in der Welt kann ich einfach ein Logonskript namens "powerlogonscript.bat" auf meinem Samba Netlogon-Share erstellen, dort die gewünschten Kommandos reinpacken (net stop, net start, usw...) und dass diese auf den Windows-Clients auch ausgeführt werden können?
Wie um alles in der Welt kann ich einfach ein Logonskript namens "powerlogonscript.bat" auf meinem Samba Netlogon-Share erstellen, dort die gewünschten Kommandos reinpacken (net stop, net start, usw...) und dass diese auf den Windows-Clients auch ausgeführt werden können?
Moin.
Ich weiß nicht, wie man ein Startskript realisieren sollte, ohne es zuvor auf den Clients einzutragen im lokalen gpedit.msc. Geht vielleicht auch bei Samba-Domains, aber ich weiß nicht wie. Deshalb mein Vorschlag mit psexec.
Bei psexec wird genau dann kein Klartext-Passwort übermittelt, wenn Du bereits die Shell mit einem Konto gestartet hast, das auch remote Adminrechte hat - so ist es sicher.
Nur wenn das nicht möglich ist, würde ich auf andere Pfade abbiegen.
Ich weiß nicht, wie man ein Startskript realisieren sollte, ohne es zuvor auf den Clients einzutragen im lokalen gpedit.msc. Geht vielleicht auch bei Samba-Domains, aber ich weiß nicht wie. Deshalb mein Vorschlag mit psexec.
Bei psexec wird genau dann kein Klartext-Passwort übermittelt, wenn Du bereits die Shell mit einem Konto gestartet hast, das auch remote Adminrechte hat - so ist es sicher.
Nur wenn das nicht möglich ist, würde ich auf andere Pfade abbiegen.
...und Startup scripts?______________
Skript beim Maschinen-Account anlegen, nicht beim User. Die Maschine "logt" sich auch ein, wenn sie hochfährt. Dann kann sie auch skripten ausführen.
lks
lks
Leut, ich hab kein GPO nicht vergessen. Ich möchte nicht auf jedem einzelnen Client irgendwelche Anpassungen vornehmen müssen.
@Lochkartenstanzer: Worauf möchtest du in Oreilly Samba verweisen? Ich versteh nicht ganz. ich kenn zwar diese Seite, finde aber darin keinen Hinweis, dass mir hier helfen könnte.
@Lochkartenstanzer: Worauf möchtest du in Oreilly Samba verweisen? Ich versteh nicht ganz. ich kenn zwar diese Seite, finde aber darin keinen Hinweis, dass mir hier helfen könnte.
Darauf, daß man in Samba Logon-Skripten mitgeben kann. Da die maschinen auch jeweils sich an de Domäne anmelden müssen, kann man diesen auch Logon-Skripten mitgeben. Ist zwar etwas knifflig, das ganze zum laufen zu bekommen, funktioniert aber. Habe auf die Art mal bei einem Kunden bestimmte Aktionen gestartet, wenn ein Rechner eingeschaltet wurde. Ist aber wieder aber ein paar Jahre her, daß ich die Details nicht mehr genau weiß, aber prinzipiell funktionert es.
lks
Nachtrag: Ich erinnere mich dunkel, daß ich da noch irgenedwas in der registry rumfummeln mußte, weiß aber nciht mehr was das war. Ich schau mal, ob ich noch an die Infromation komme.
lks
Nachtrag: Ich erinnere mich dunkel, daß ich da noch irgenedwas in der registry rumfummeln mußte, weiß aber nciht mehr was das war. Ich schau mal, ob ich noch an die Infromation komme.
an der registry rumfummeln bedeutet aber dass das wieder an allen Clients durchgeführt werden sollte. Das würde ja alles wieder kaputtmachen. Es soll doch zentral verwaltbar sein.
Also ich bin so langsam echt am Verzweifeln und hab so 'n Hals weil ich schon seit mehreren Tagen damit verbringe diese ** Zeitsynchronisierung herzustellen. Microsoft zieht mir hier einen dicken Strich durch die Rechnung, weil ich eben kein ActiveDirectory verwende, sondern einen Samba-Server ohne AD. Das bedeutet als Folge:
a.) ich kann die automatische Zeitsynchronisierung innerhalb einer Windows-Domäne nicht nutzen, die man normalerweise mit dem Befehl "w32tm /config /syncfromflags:domhier /update" jederzeit auch aktivieren. Ist aber normal default Einstellung nach einer Windows-Installation (http://technet.microsoft.com/en-us/library/cc758905(v=ws.10).aspx)
w32tm /monitor und Debugmeldungen zeigen deutlich, dass nach einem AD-Controller gesucht wird. Ein Windows-NT PDC greift da nicht, und genau das ist aber mein Samba3 Server. Grrrr!
b.) Also dachte ich mir, ich richte die Clients eben als NTP-Clients ein wie hier beschrieben (http://support.microsoft.com/kb/307897/de). Da hierfür der Dienst "W32Time" notwendig ist, funktioniert das erst ab WindowsXP. Win2000 Clients müssen noch mit "net time /setsntp:1.2.3.4" konfiguriert werden. Davor muss aber mit "net stop time" der Windows-Zeitgeber beendet werden, und wenn man mit "net time /setsntp:1.2.3.4" den NTP-server eingegeben hat, muss auch mit "net start time" der DIenst wieder gestartet werden. Ab XP läuft das unter dem Dienst w32time und dieser muss auch zwingend laufen, bevor man überhaupt "w32tm /config ...kommandos...." absetzen kann.
Also versuche ich wie wild in meinem Logonskript so ein Verhalten zu steuern. Jedoch kann ich das niemals ohne Powerrechte auf dem Client erreichen. Also habe ich mich dem Tool "CPAU" von http://www.joeware.net/freetools/tools/cpau/ bedient. Schön und gut, funktioniert aber auch nicht, weil die Powerrechte nicht weiterveräußert werden können, sobald das ganze chiffriert als Job generiert wurde. Microsoft schreibt dazu, dass ab Windows Vista kein "power right elevation" mehr gestattet wird.
Ich hab alles mögliche probiert, mit Powerrechten meine 4 Zeilen auszuführen, aber leider erfolglos. Probiert habe ich das ganze an mehreren Win2k, WinXP und Win7 Clients, natürlich mit verschiedenen Benutzeraccounts um den ganzen Sachverhalt analysieren zu können.
So langsam hab ich echt kein Bock mehr und frage mich also:
Da draußen auf der Welt gibt's doch sicherlich nen Haufen Netzwerk, die auch mit Samba laufen und ohne AD. Wie habt ihr Admins denn dort die Zeitsynchronisierung gesteuert? Was ich nicht möchte: in einem logonscript á-la "net time /set /yes" nutzen, weil dadurch nur diejenigen Clients die Zeit richtig gesetzt bekommen, die sich auch am PDC anmelden. Es gibt aber Clients, die sind mit einem User eingeloggt, und bleiben auch wochen- oder monatelang angemeldet ohne sich abzumelden. Die würden davon leider unberührt bleiben und bekommen keine Zeitsynchronisierung mitgeteilt. Am allerliebsten hätte ich ja /DOMHIERARCHY Sync verwendet, geht ja aber nicht weil ich kein AD habe. Also würde ich gerne meinen Clients zwei NTP-Server mitgeben: einerseits meinen lokalen Zeitserver im LAN und auch 0.de.pool.ntp.org (damit sich das auch in den Notebooks einnistet, und diese auch bei mehrmonatigen externen Aufenthalt eine korrekte Zeit durch den 0.de.pool.ntp.org holen können).
Ich bin ratlos und hoffe auf eure Hilfe
Also ich bin so langsam echt am Verzweifeln und hab so 'n Hals weil ich schon seit mehreren Tagen damit verbringe diese ** Zeitsynchronisierung herzustellen. Microsoft zieht mir hier einen dicken Strich durch die Rechnung, weil ich eben kein ActiveDirectory verwende, sondern einen Samba-Server ohne AD. Das bedeutet als Folge:
a.) ich kann die automatische Zeitsynchronisierung innerhalb einer Windows-Domäne nicht nutzen, die man normalerweise mit dem Befehl "w32tm /config /syncfromflags:domhier /update" jederzeit auch aktivieren. Ist aber normal default Einstellung nach einer Windows-Installation (http://technet.microsoft.com/en-us/library/cc758905(v=ws.10).aspx)
w32tm /monitor und Debugmeldungen zeigen deutlich, dass nach einem AD-Controller gesucht wird. Ein Windows-NT PDC greift da nicht, und genau das ist aber mein Samba3 Server. Grrrr!
b.) Also dachte ich mir, ich richte die Clients eben als NTP-Clients ein wie hier beschrieben (http://support.microsoft.com/kb/307897/de). Da hierfür der Dienst "W32Time" notwendig ist, funktioniert das erst ab WindowsXP. Win2000 Clients müssen noch mit "net time /setsntp:1.2.3.4" konfiguriert werden. Davor muss aber mit "net stop time" der Windows-Zeitgeber beendet werden, und wenn man mit "net time /setsntp:1.2.3.4" den NTP-server eingegeben hat, muss auch mit "net start time" der DIenst wieder gestartet werden. Ab XP läuft das unter dem Dienst w32time und dieser muss auch zwingend laufen, bevor man überhaupt "w32tm /config ...kommandos...." absetzen kann.
Also versuche ich wie wild in meinem Logonskript so ein Verhalten zu steuern. Jedoch kann ich das niemals ohne Powerrechte auf dem Client erreichen. Also habe ich mich dem Tool "CPAU" von http://www.joeware.net/freetools/tools/cpau/ bedient. Schön und gut, funktioniert aber auch nicht, weil die Powerrechte nicht weiterveräußert werden können, sobald das ganze chiffriert als Job generiert wurde. Microsoft schreibt dazu, dass ab Windows Vista kein "power right elevation" mehr gestattet wird.
Ich hab alles mögliche probiert, mit Powerrechten meine 4 Zeilen auszuführen, aber leider erfolglos. Probiert habe ich das ganze an mehreren Win2k, WinXP und Win7 Clients, natürlich mit verschiedenen Benutzeraccounts um den ganzen Sachverhalt analysieren zu können.
So langsam hab ich echt kein Bock mehr und frage mich also:
Da draußen auf der Welt gibt's doch sicherlich nen Haufen Netzwerk, die auch mit Samba laufen und ohne AD. Wie habt ihr Admins denn dort die Zeitsynchronisierung gesteuert? Was ich nicht möchte: in einem logonscript á-la "net time /set /yes" nutzen, weil dadurch nur diejenigen Clients die Zeit richtig gesetzt bekommen, die sich auch am PDC anmelden. Es gibt aber Clients, die sind mit einem User eingeloggt, und bleiben auch wochen- oder monatelang angemeldet ohne sich abzumelden. Die würden davon leider unberührt bleiben und bekommen keine Zeitsynchronisierung mitgeteilt. Am allerliebsten hätte ich ja /DOMHIERARCHY Sync verwendet, geht ja aber nicht weil ich kein AD habe. Also würde ich gerne meinen Clients zwei NTP-Server mitgeben: einerseits meinen lokalen Zeitserver im LAN und auch 0.de.pool.ntp.org (damit sich das auch in den Notebooks einnistet, und diese auch bei mehrmonatigen externen Aufenthalt eine korrekte Zeit durch den 0.de.pool.ntp.org holen können).
Ich bin ratlos und hoffe auf eure Hilfe
MOin.
Du hast 2 Lösungen bekommen: psexec (kein Reggefummel) und das Startskript. Wenn Du dazu Fragen hast, oder Lochkartenstanzers Anleitung, wie ein Startskript einzubinden ist, nicht verstehst, dann lies es erneut und dann frag uns wieder. Nicht verzweifeln.
Warum nimmst Du nicht psexec? Die Sicherheitsbedenken habe ich ausgeräumt.
Du hast 2 Lösungen bekommen: psexec (kein Reggefummel) und das Startskript. Wenn Du dazu Fragen hast, oder Lochkartenstanzers Anleitung, wie ein Startskript einzubinden ist, nicht verstehst, dann lies es erneut und dann frag uns wieder. Nicht verzweifeln.
Warum nimmst Du nicht psexec? Die Sicherheitsbedenken habe ich ausgeräumt.
bitte erkläre mir wie ich psexec einsetzen sollte, ich kann dir wirklich nicht folgen. Soll PsExec von meinem eigenen Client ausgeführt werden, und ich schreib manuell in einer Dateiliste all die Rechner rein, auf die es ausgeführt werden soll? oder soll ich das über mein Logonskript ausführen lassen und dann psexec \\localhost -u DOMAINNAME\Poweruser -p mypwd net stop w32time && net time /setsntp:1.2.3.4 && net start w32time && w32tm /config /syncfromflags:manual /manualpeerlist:"1.2.3.4 0.de.pool.ntp.org" /update reinschreiben?
bitte erläutere mir das näher, wie du das genau meinst. Und natürlich sollte der Domänenuser keine Passwörter in cleartext sehen können.
PS: Mit LKS Beschreibung wegen den Computer-Startskripten habe ich selbst in O'reillys Beitrag gesucht, finde aber keine Ansätze darüber. Entweder bin ich blind, oder es wird dort nicht beschrieben.
bitte erläutere mir das näher, wie du das genau meinst. Und natürlich sollte der Domänenuser keine Passwörter in cleartext sehen können.
PS: Mit LKS Beschreibung wegen den Computer-Startskripten habe ich selbst in O'reillys Beitrag gesucht, finde aber keine Ansätze darüber. Entweder bin ich blind, oder es wird dort nicht beschrieben.
psexec habe ich beschrieben: von Deinem Gerät aus eine Liste abarbeiten lassen. Die Rechner müssen dafür natürlich allesamt verfügbar sein, evtl. also auch Firewalls ausschalten.
nunja. Dann muss ich mir also erstmal eine Liste der ganzen PCs erstellen. Dabei sehe ich bereits folgende Problematik: die Änderungen die ich mittels psexec remote übertragen möchte, würden nur bei den Maschinen ankommen, die auch momentan erreichbar sind. Alle offline Hosts wären nicht betroffen.
Daher war mir ja der Ansatz mit dem Loginskript am liebsten, denn so 'zieht' sicher jeder Client die Config bei seiner Anmeldung an der Domäne. Wie könnte ich das denn lösen?
Daher war mir ja der Ansatz mit dem Loginskript am liebsten, denn so 'zieht' sicher jeder Client die Config bei seiner Anmeldung an der Domäne. Wie könnte ich das denn lösen?
Wenn Du da mit CPAU und anderem arbeiten willst, kannst Du es so lösen, ich kann Dir aber keine auf win7 getesteten Programme nennen - deshalb psexec. Mögliche Tools: sudowin, runasspc.
Neuer Gedanke: am sinnvollsten für die Zukunft wäre, ein Startskript lokal am Client über gpedit.msc zu etablieren, das auf eine Batch/.vbs am Server zeigt, die ihr immer nur zentral anpasst.
Müsstest Du nur einmal überall manuell einrichten, dann hast Du für die Zukunft Ruhe.
Neuer Gedanke: am sinnvollsten für die Zukunft wäre, ein Startskript lokal am Client über gpedit.msc zu etablieren, das auf eine Batch/.vbs am Server zeigt, die ihr immer nur zentral anpasst.
Müsstest Du nur einmal überall manuell einrichten, dann hast Du für die Zukunft Ruhe.
Die fehlenden GPOs machen mir wirklich zu schaffen wie du merkst. Das soll in Zukunft durch den neuen Samba4 Server abgelöst werden, der dann auch AD kann. Ich hoffe dann somit viele Probleme aus dem Weg zu räumen. Ich hab einen Weg mit psexec gefunden. Ich wußte gar nciht, dass man psexec auch ohne Angabe eines "Remote-Hosts" ausführen kann. Das klappt wie ich getestet habe. Dazu habe ich einfach die psexec.exe in die netlogon Freigabe hineinkopier und ein Loginskript "zeitsync.bat" vorbereitet das ungefähr so aussieht:
@echo off
cls
rem Falls ein Client den Zeitgeberdienst deaktiviert hat, dann setze ich ihn hiermit auf Automatisch
rem Wichtig! nach dem Wort auto= muss eine Leerzeile erfolgen bevor das Wort auto kommt!!
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd sc config w32time start= auto
rem Um Win2k/XP Clients zu konfigurieren, die noch mit net time arbeiten
rem Ich halte den Zeitgeberdienst an
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net stop w32time
rem Ich geb dem Win2k Client meinen lokalen NTP-Server mit. Die Win7-Clients können mit der Eingabe nix anfangen
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net time /setsntp:"192.168.0.1 0.de.pool.ntp.org"
rem Zeitgeberdienst wieder starten, weil das darauffolgende kommando einen laufenden Zeitgeberdienst voraussetzt
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net start w32time
rem
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd w32tm /config /syncfromflags:manual /manualpeerlist:"192.168.0.1 0.de.pool.ntp.org" /update
Vielleicht hilft's ja den einen oder anderen.
EDIT: An einem Notebook/Win7, welches über VPN an der Domäne angemeldet ist, funktionierts noch nicht weil "Zugriff verweigert" wird. Muss ich noch überprüfen...
@echo off
cls
rem Falls ein Client den Zeitgeberdienst deaktiviert hat, dann setze ich ihn hiermit auf Automatisch
rem Wichtig! nach dem Wort auto= muss eine Leerzeile erfolgen bevor das Wort auto kommt!!
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd sc config w32time start= auto
rem Um Win2k/XP Clients zu konfigurieren, die noch mit net time arbeiten
rem Ich halte den Zeitgeberdienst an
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net stop w32time
rem Ich geb dem Win2k Client meinen lokalen NTP-Server mit. Die Win7-Clients können mit der Eingabe nix anfangen
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net time /setsntp:"192.168.0.1 0.de.pool.ntp.org"
rem Zeitgeberdienst wieder starten, weil das darauffolgende kommando einen laufenden Zeitgeberdienst voraussetzt
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd net start w32time
rem
psexec.exe -h -u Domainname\meinPowerUser -p MeinPwd w32tm /config /syncfromflags:manual /manualpeerlist:"192.168.0.1 0.de.pool.ntp.org" /update
Vielleicht hilft's ja den einen oder anderen.
EDIT: An einem Notebook/Win7, welches über VPN an der Domäne angemeldet ist, funktionierts noch nicht weil "Zugriff verweigert" wird. Muss ich noch überprüfen...
Also...
Bislang dachte ich, Du wolltest das Kennwort nicht lesbar im Loginskript haben und jetzt machst Du es doch?
Zu Deinem verw. zugriff: ist normal und zu erwarten, wenn die UAC an ist. Ist sie aus, geht es.
Bislang dachte ich, Du wolltest das Kennwort nicht lesbar im Loginskript haben und jetzt machst Du es doch?
Zu Deinem verw. zugriff: ist normal und zu erwarten, wenn die UAC an ist. Ist sie aus, geht es.
bei den anderen test-Clients (Win7) war sie auch an, da hats aber auf Anhieb geklappt. Muss das noch detaillierter ausprobieren und dem Problem auf die Schliche kommen.
EDIT: Hab am Notebook "msconfig" gestartet, dann unter Tools die UAC Settings gestartet, und den Regler ganz runtergedreht. Auch in der Registry unter HKLM\Software\Microsoft\Windows\Current Version\Policies\System das Feld EnableLUA auf 0 gesetzt. Rebootet und nochmals getestet, aber immer noch Zugriff verweigert.
Der Hund liegt woanders begraben --> an meinen vorherigen Tests klappte das, weil ich dort mit einem Administrator-Domänenaccount angemeldet war. Sobald aber ein normaler Domänenuser an dem Client angemeldet ist, darf er die Psexec Kommandos nicht absetzen. Es kommt ständig Zugriff verweigert. Toll! Wobei ich wieder am Anfang angelangt wäre, es geht nicht. Wieos aber???
EDIT ==> Lösung: Der Schalter -h darf nicht gesetzt werden im Psexec Kommando, dann funktionierts auch.
Ich würde natürlich sehr gerne vermeiden das Kennwort in cleartext übertragen, wüßte aber nicht wie obwohl du es angesprochen hattest. Wenn du mir nähere Details hierzu nennen kannst??
PS:* Jetzt habe ich aber noch das Problem das die einzelnen Psexec Schritte wirklich sehr lange dauern, bis sie abgearbeitet werden. Ich verstehe aber nicht, wieso Psexec dafür so lange benötigt um den Befehl abzusetzen? An der Netzwerkgeschwindigkeit liegts definitiv nicht. Wer weiß was Psexec da im Hintergrund abfrägt oder wartet???
EDIT: Hab am Notebook "msconfig" gestartet, dann unter Tools die UAC Settings gestartet, und den Regler ganz runtergedreht. Auch in der Registry unter HKLM\Software\Microsoft\Windows\Current Version\Policies\System das Feld EnableLUA auf 0 gesetzt. Rebootet und nochmals getestet, aber immer noch Zugriff verweigert.
Der Hund liegt woanders begraben --> an meinen vorherigen Tests klappte das, weil ich dort mit einem Administrator-Domänenaccount angemeldet war. Sobald aber ein normaler Domänenuser an dem Client angemeldet ist, darf er die Psexec Kommandos nicht absetzen. Es kommt ständig Zugriff verweigert. Toll! Wobei ich wieder am Anfang angelangt wäre, es geht nicht. Wieos aber???
EDIT ==> Lösung: Der Schalter -h darf nicht gesetzt werden im Psexec Kommando, dann funktionierts auch.
Ich würde natürlich sehr gerne vermeiden das Kennwort in cleartext übertragen, wüßte aber nicht wie obwohl du es angesprochen hattest. Wenn du mir nähere Details hierzu nennen kannst??
PS:* Jetzt habe ich aber noch das Problem das die einzelnen Psexec Schritte wirklich sehr lange dauern, bis sie abgearbeitet werden. Ich verstehe aber nicht, wieso Psexec dafür so lange benötigt um den Befehl abzusetzen? An der Netzwerkgeschwindigkeit liegts definitiv nicht. Wer weiß was Psexec da im Hintergrund abfrägt oder wartet???
Es steht doch da. psexec gegen eine Liste laufen lassen von Deinem Rechner aus. Was anderes habe ich nicht parat.
Nochmal: Richte ein Startskript ein, dann hast Du die Probleme nie wieder.
Nochmal: Richte ein Startskript ein, dann hast Du die Probleme nie wieder.
Wie gesagt: gegen eine Liste laufen lassen ist IMHO ungeschickt weil alle OFFLINE Rechner somit nicht erreicht werden könnten. Trotzdem danke.
Hast du ein Idee warum Psexec so langsam alles abarbeitet?
Hast du ein Idee warum Psexec so langsam alles abarbeitet?
psexec richtet einen Dienst ein, evtl. dauert das bei manchen lange. Auch psexec hat Bugs, kamm nich erinnern, dass es hier bei einem von 10 Rechnern auch sehr lange dauerte ohne erkennbaren Grund
Mein letztes Angebot hier:
Wenn Du die rechner nicht alle einschalten kannst, weil außer haus, dann nimm das Startskript. Auch dazu müssen Sie zur einmaligen Einrichtung EINMAL an sein, ja klar.
Ist das zu aufwendig, lies nochmal bei Oreilly nach - dort taucht der Begriff "startup script" einmal im Text auf. Lochkartenst.'s Gedanke/Wissen war doch, dass man es mit einem loginskript lösen könnte, welches auf Computerkonten angewendet werden kann. Da ich aber mit dem Sambakram keine Erfahrungen habve, will ich dazu nichts sagen, habe es aber so verstanden (und kann es mir auch vorstellen), dass man an Stelle der Nutzernamen hier den rechnernamen$ (PC1$, PC2$, ...) einträgt.
Mein letztes Angebot hier:
Wenn Du die rechner nicht alle einschalten kannst, weil außer haus, dann nimm das Startskript. Auch dazu müssen Sie zur einmaligen Einrichtung EINMAL an sein, ja klar.
Ist das zu aufwendig, lies nochmal bei Oreilly nach - dort taucht der Begriff "startup script" einmal im Text auf. Lochkartenst.'s Gedanke/Wissen war doch, dass man es mit einem loginskript lösen könnte, welches auf Computerkonten angewendet werden kann. Da ich aber mit dem Sambakram keine Erfahrungen habve, will ich dazu nichts sagen, habe es aber so verstanden (und kann es mir auch vorstellen), dass man an Stelle der Nutzernamen hier den rechnernamen$ (PC1$, PC2$, ...) einträgt.
Nachtrag: Mit dem Schalter -e läuft psexec um einiges schneller, da das Profil nicht geladen wird. In CPAU entspricht es quasi dem Schalter -lwop
Grüße,
Pangu.
Grüße,
Pangu.
Zusatzinfos für diejenigen, die mit demselben Problem konfrontiert wurden:
http://riosec.com/Windows-UAC-PsExec
Das Problem bei der ganzen Angelegenheit ist, daß seit Vista und der UAC das System ein eingeschränktes Token an den zu startenden Prozess vergibt. Sobald man in dem psexec.exe irgendein Username verwendet, um sich zu authentifizieren schlägt das Ganze fehl (sofern UAC auf dem System installiert ist). Würde man UAC gänzlich ausschalten, funktionierts natürlich, aber das ist ja auch nicht unbedingt Sinn der Sache. Auch rechtsklick und ausführen als "Administrator" würde genügen, aber das kann man ja nicht aus einem Loginskript erreichen.
Ich kann problemlos von einem x-beliebigen Clients aus (sofern ich die Berechtigung habe) Kommandos auf den remote-Clients ausführen lassen. Aber ich kann dieselben Befehle nicht direkt am Client nutzen. Würde man diese dort eingeben (mit UAC aktiviert und kein ADmin-DOS-Fenster) schlägt das fehl, ganz egal welchen Admin-Useraccount man angibt. Sobald -u verwendet wird, wird ein beschnittenes/eingeschränktes Zugriffstoken weitergegegen.
Hier noch ein Link vom Blog des Entwicklers PSEXEC --> http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.as ...
Und hier wird der Unterschied zwischen IMPLICIT und EXPLICIT Logins erklärt --> http://forum.sysinternals.com/topic5072_page1.html
http://riosec.com/Windows-UAC-PsExec
Das Problem bei der ganzen Angelegenheit ist, daß seit Vista und der UAC das System ein eingeschränktes Token an den zu startenden Prozess vergibt. Sobald man in dem psexec.exe irgendein Username verwendet, um sich zu authentifizieren schlägt das Ganze fehl (sofern UAC auf dem System installiert ist). Würde man UAC gänzlich ausschalten, funktionierts natürlich, aber das ist ja auch nicht unbedingt Sinn der Sache. Auch rechtsklick und ausführen als "Administrator" würde genügen, aber das kann man ja nicht aus einem Loginskript erreichen.
Ich kann problemlos von einem x-beliebigen Clients aus (sofern ich die Berechtigung habe) Kommandos auf den remote-Clients ausführen lassen. Aber ich kann dieselben Befehle nicht direkt am Client nutzen. Würde man diese dort eingeben (mit UAC aktiviert und kein ADmin-DOS-Fenster) schlägt das fehl, ganz egal welchen Admin-Useraccount man angibt. Sobald -u verwendet wird, wird ein beschnittenes/eingeschränktes Zugriffstoken weitergegegen.
Hier noch ein Link vom Blog des Entwicklers PSEXEC --> http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.as ...
Und hier wird der Unterschied zwischen IMPLICIT und EXPLICIT Logins erklärt --> http://forum.sysinternals.com/topic5072_page1.html
