psexec: "Access denied" auf remote PC trotz lokaler Admin

[Stibo 17]

Guten Morgen zusammen,

 

erst kurz der Hintergrund zu diesem Thema: es gibt zwei Standorte, A (Hauptsitz) und B (Remote Office), die per VPN zweier Sonicwalls dauerhaft verbunden sind (alles eine Domäne). Nun gibt es die Anforderung, dass bestimmte Mitarbeiter von Standort B ihre Rechner auch spätabends bzw. am Wochenende benutzen können möchten. Alle normalen Clients fahren abends um 22:00 Uhr nach einem Virenscan herunter, daher brauchen wir hier eine WoL-Lösung.

 

Da wir RemoteApps an Standort A einsetzen kam mir die Idee, dass ich das ganze damit realisiere: Der Mitarbeiter meldet sich per Browser bei den RemoteApps an, startet hier ein bereitgestelltes Programm (psexec von Sysinternals), die wiederum den WoL-Befehl auf einem Server an Standort B sendet. Den Umweg muss ich leider gehen, da der Befehl von Standort A nicht an Standort B weitergebeben wird (evtl. muss da noch etwas in der Sonicwall angepasst werden, keine Ahnung).

 

Ist das Ziel soweit verständlich? Ich bekomme beim Testen ein "Access Denied" von psexec am Remoteclient. Das Programm wird mit allen benötigten Parametern aufgerufen, also auch Benutzername und Passwort werden mitgegeben. Der Benutzer ist lokaler Admin auf dem Server in Standort B, trotzdem wird das Programm nicht gestartet.

 

Kann mir hier jemand weiterhelfen oder habe ich etwas Essentielles vergessen? Ich stehe hier momentan mächtig auf dem Schlauch... achja, falls das Ganze als Text nicht verständlich ist, versuche ich gerne mal, das ganze in Visio zu visualisieren.

 

Vielen dank schon mal im Voraus und ein schönes Wochenende!

 

Stibo

[Sunny61 773]

Pack den Aufruf in eine Batch, ich glaube nur so funktioniert das dann.

[Stibo 17]

Hmm, irgendwie klappt das nicht so recht. Aufbau ist wie folgt:

 

Batch per RemoteApp gestartet, in dieser Batch steht (mit echo on und pause am Schluss, damit ich sehe, was passiert), pseexec liegt auf D:\Management\PSTools

 

@echo on

D:
cd Management
cd PSTools

psexec.exe \\Remoteserver -u Remoteserver\user -p passwort "wolcmd.exe MAC-Adresse IP Subnetz" Remoteserver

pause

 

 

wolcmd.exe liegt auf dem Remoteserver unter C:\Windows\system32\, der User hat explizit Schreibrechte auf diese Datei.

 

Leider immer noch ein "Access Denied". Mir scheint, als dürfe der lokal angelegte Benutzer nichts auf dem Remoteserver machen...

 

[Edit] Mal testweise einen Aufruf mit meinem Domainadmin gemacht, da funktioniert zumindest psexec und ich konnte eine CMD-Shell starten. Teste das jetzt mal mit dem WoL-Tool.

 

[Edit2] Beim Aufruf von wolcmd.exe kriege ich jetzt die Meldung, dass das System die angegebene Datei nicht finden kann. Ich hatte jetzt noch eine Idee, die Datei mittels -c als Parameter zu kopieren, allerdings weiß ich nicht, ob man dann nochmals Parameter für eine Datei bei psexec mitgeben kann.

bearbeitet 14. Juni 2013 von Stibo

[Sunny61 773]

 

 

@echo on

D:
cd Management
cd PSTools

psexec.exe \\Remoteserver -u Remoteserver\user -p passwort "wolcmd.exe MAC-Adresse IP Subnetz" Remoteserver

pause

 

[Edit2] Beim Aufruf von wolcmd.exe kriege ich jetzt die Meldung, dass das System die angegebene Datei nicht finden kann. Ich hatte jetzt noch eine Idee, die Datei mittels -c als Parameter zu kopieren, allerdings weiß ich nicht, ob man dann nochmals Parameter für eine Datei bei psexec mitgeben kann.

 

 

 

Schreib den exakten Pfad zur wolcmd.exe in das Script.

[Stibo 17]

Schreib den exakten Pfad zur wolcmd.exe in das Script.

 

Hilft leider nicht, immer noch "The system cannot find the file specified."

 

[Edit] Ohne Anführungszeichen beim Programm hat's, zumindest per Domainadmin, funktioniert. Probiere das nun nochmals über die Batch.

 

[Edit2] Narf, mit dem lokalen Administrator funktioniert es immer noch nicht, weiterhin "Access is denied"... also liegt's definitiv an den Berechtigungen des lokalen Admins. Stellt sich mir die Frage: was vergesse ich hier...? :/

 

Update: Booya! :cool: Die Sonicwall bietet eine Option, "WoL-Pakete durchlassen". Nachdem diese konfiguriert und aktiviert wurde gehen die Magic Packets nun ohne Murren über die VPN-Verbindung drüber und wecken auch Rechner in anderen Netzwerksegmenten. :)

 

Wieso der lokale Admin allerdings weniger Rechte hat ein Programm zu starten als ein Domainadmin, ist mir bis jetzt leider nicht klar. Wenn mir hier noch jemand eine Antwort geben könnte, wäre ich sehr verbunden.

Ansonsten Euch allen ein schönes Wochenende!

bearbeitet 14. Juni 2013 von Stibo

[Sunny61 773]

Melde dich als lokaler Admin und starte die Batch genauso so, wie bisher durch psexec. Evtl. kannst Du auch den ProcessMonitor mitlaufen lassen und zu sehen wo es hakt.

 

Danke trotzdem für die Rückmeldung. ;)

[blub 115]

Stibo, ist dir bewusst, dass psexec das Passwort im Klartext übers Netz schickt?

 

blub

[lefg 276]

Hallo,

 

ich empfehle, das Konzept zu überdenken.

 

Ist es zwingend, dass die Mitarbeiter den (eigenen?) PC benutzen? Ob es möglich, die Mitarbeiter auf einem RDP-Server arbeiten?

bearbeitet 16. Juni 2013 von lefg

[schtebo 10]

funktioniert denn:

 

psexec.exe \\Remoteserver -u Remoteserver\user -p password cmd

 

?

[lefg 276]

Hallo,

 

wozu überhaupt psexec, was für OS auf Server und Clients sind denn das?

bearbeitet 16. Juni 2013 von lefg

[Stibo 17]

Stibo, ist dir bewusst, dass psexec das Passwort im Klartext übers Netz schickt?

 

blub

 

Nein, das war mir nicht bewusst - allerdings wir das Programm ja nun nicht mehr verwendet. Wieder was gelernt, danke!

 

 

Hallo,

 

ich empfehle, das Konzept zu überdenken.

 

Ist es zwingend, dass die Mitarbeiter den (eigenen?) PC benutzen? Ob es möglich, die Mitarbeiter auf einem RDP-Server arbeiten?

 

Das komplette Konzept habe ich bereits selber in Frage gestellt, allerdings habe ich hierzu noch keine Rückmeldung erhalten. Ob es zwingend notwendig ist, dass die eigenen Rechner benutzt werden müssen, vermag ich nicht zu sagen.

 

Hallo,

 

wozu überhaupt psexec, was für OS auf Server und Clients sind denn das?

 

psexec war quasi mein letzter Strohalm, um ein WoL-Tool im anderen Netzwerksegment zu starten, da durch die Sonicwall das WoL-Paket nicht weitergeleitet wurde. Server OS = 2008 R2, Client OS = Win 7 Prof. x64.