Rechner/Server aus Dienst neu booten

[DataCool]

Hi Leute,

ist es möglich aus einen Dienst(läuft unter dem lokalen Systemkonto ohne Interaktion mit dem Desktop),
den Rechner neu zu starten ?

Sämtliche Codes mit ExitWindows sollten damit nicht funktionieren, oder ?

Greetz DAta

[nahpets]

Hallo,

schau mal bitte, ob Du damit shutdown__reboot__logoff_windows_9xntme2000xp was anfangen kannst.

Eventuell geht es auch mit
ShellExecute(Handle,nil,'cmd.exe',('/c shutdown -t 360'),nil,1); Schau Dir dazu mal die Paramter zu ShutDown an.

[DataCool]

Hi,

das vorgehen ist mir bekannt,
aber da ich den Rechner von einem Dienst aus beenden möchte,
Dienste laufen auf einer anderen Berechtigungsebene,
ist das so leider nicht möglich(denke ich auf jeden Fall),
Shellexecute geht auf jeden Fall nicht.

Greetz Data

[Dezipaitor]

Hast du es denn mal ausprobiert?

[DataCool]

Hi,

teste es gerade es, scheint sogar zu gehen(auf meinem Testrechner).
Weiterer Test auf Win2003 Server 64 Bit folgt.

Greetz Data

P.S.: Verstehe allerdings nicht, das man sich die "fehlende" Berechtigung einfach einholen kann.

[Dezipaitor]

Welche Berechtigung fehlt denn nach deiner Meinung?

[DataCool]

^^Generell mit dem Desktop zu kommunizieren.

SendMessage, FindWindow und andere Handle bezogene Messages funktionieren z.B. nicht,
wenn nicht "Interaktion mit dem Desktop" aktiviert ist.

Teste aber gleich auf meinem Server

Dann weiß ich mehr,

Greetz Data

[Dezipaitor]

Zitat von DataCool:

SendMessage, FindWindow und andere Handle bezogene Messages funktionieren z.B. nicht,
wenn nicht "Interaktion mit dem Desktop" aktiviert ist.

Geht nicht in Vista und XP mit Fast User Switch oder Windows Terminal Server (ab 2000).
Auch nicht mit dem Haken.

[DataCool]

Ok, wenn Du das sagst glaube ich das dann mal so,
ist auch nicht mein Spezial-Gebiet.

Auch der Server-Reboot(windows Server 2003 RC2 Std. Edition 64Bit) funktioniert mit Code aus dem obrigen Link.

Mehr wollte ich auch gar nicht

Danke & Greetz Data

[Dezipaitor]

Hattest du das Problem nicht schonmal? http://www.delphipraxis.net/internal...ct.php?t=70998

Ich will dir dazu nur kurz etwas erklären:

1. http://msdn.microsoft.com/en-us/library/aa376868(VS.85).aspx

Zitat:

EWX_SHUTDOWN
...
The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.
...

Jeder Prozess hat einen Ausweiß (genannt Token), welcher Privilegien besitzt, die von einigen WinAPI Funktionen abgefragt werden.
ExitWindowsEx fragt das Privileg SE_SHUTDOWN_NAME (ist nur ein Konstante von einem String) ab. Wenn du das Privileg aktiviert hast, dann darfst du den Rechner herunterfahren. Daher sehen die ExitWindowsEx Quelltexte auch so kompliziert aus (wegen C code).
Wenn ein Benutzer sich anmeldet, bekommt er ein solches Token. Das Token wird auf jeden neuen Prozess vererbt, der gestartet wird (Explorer ist gewöhnlich der erste).
Privilegien kann man an und abschalten. Manche WinAPI Funktionen wollen ein aktives Privileg sehen. Manche reicht ein deaktiviertes (nur ganz wenige). Du kannst in keinem Fall nachträglich ein Privileg hinzufügen. Es ist nur möglich ein Privileg zu entfernen. Um mehr Privilegien zu bekommen, musst du ein neues Token bekommen (z.b. durch ein Logon, oder von einem Dienst).
Das SYSTEM-Token ist ein Spezialfall. Das Token gibt es immer und hat so gut, wie alle Privilegien. Einige wenige sind davon ausgenommen (können aber durch Policy, Registryeingriff, oder ein paar andere Tricks geändert werden).

2. Dienste und Desktop.
Windows benutzt sogenannte Sessions (Sitzungen), die WindowStations und diese wiederum Desktops enthalten (Paradebeispiele: winsta0 und default bzw. winlogon desktop).
Jede Sitzung ist von anderen Sitzungen fast vollständig getrennt. Du kannst keine Nachrichten mit SendMessage senden oder irgendwie direkt auf den Desktop dort zugreifen. Da SendMessage flach fällt, ist das Erzeugen eines Fensters damit auch nicht mehr möglich, denn CreateWindow und andere Funktionen arbeiten immer nur mit dem Desktop, der in derselben Session, wie dein Prozess läuft. Allerdings ist es nicht möglich die Session nachträglich zu ändern. Beim Erstellen des neuen Prozess muss man die Zielsitzung einmalig angeben - und das kann auch nur SYSTEM, welches das Privilege SE_TCB_NAME besitzt.
Und warum kann man in XP mit einem Dienst trotzdem Fenster erstellen? Ganz einfach, die Dienste laufen in derselben Sitzung (Nummer 0) wie der erste Benutzer in der Konsole. Beide haben dieselbe Sitzungsnummer und sind somit gegenseitig zugreifbar.
In Vista laufen Dienste in Sitzung 0. Der erste Benutzer läuft aber schon in Sitzung 1. Das nennt man seit jeher Session Isolation.
Dasselbe gilt wenn du unter XP einen Benutzer wechselst (FUS), dann wird nämlich eine komplette neue Sitzung angelegt. Du merkst das vielleicht, wenn der Bildschirm plötzlich für kurze Zeit ein Textmodusprompt anzeigt (VMs ändern dann ihre Fenstergröße auf Minimum, nur so.). Nach dem Benutzerwechsel kann dein Dienst nicht auf den aktuellen Bildschirm zugreifen. Er agiert nämlich (nur XP!) auf dem anderen Desktop. In Vista wurde dafür ein Kompatibilitätsanpassung eingeführt, die es erlaubt, die Nachricht des Dienstes zu sehen - dazu wird die Session umgeschaltet (Das ist auch die einzige Wirkung des "Allow Desktop" Flags in Vista). Es ist aber nicht sicher, wie lange das "Feature" bleibt (Win7 hat es vllt garnicht mehr - just a guess).
Warum sind Dienste so abgesichert worden?
Nun, die Absicherung wurde zu spät eingeführt. Das hätte schon so in Win 2000 und spätestens in XP sein sollen. Der Grund liegt darin, dass es möglich sein kann, dem Fenster/Dialog des Dienstes so fernzusteuern bzw. Befehle zu schicken, dass man Code in den Prozess einschleussen kann. Das nennt sich Shatter Attack (http://en.wikipedia.org/wiki/Shatter_attack).