(also die Session mit der ich das Testprogramm auch tatsächlich starte)
Er will aber den lokal angemeldeten Benutzer und nicht den Benutzer der das Programm ausführt.
Genau das ermöglicht die Funktion. Ich glaube da haben wir uns missverstanden: Die Session unter der ich das Programm starte ist nicht gleichzusetzen mit den Benutzerkontext unter dem das Programm läuft.
Die Session ist fest an den Benutzeraccount gebunden, mit dem du dich einloggst (egal ob lokal oder remote). Sagen wir du loggst dich mit einem eingeschränkten Account "Luckie" ein und bekommst dabei die SessionId 1. Wenn du jetzt einen Prozess startest, läuft dieser standardmäßig auch unter Session 1 und bekommt zudem das Token deines eingeschränkten Accounts zugewiesen - Benutzerkontext wäre also ebenfalls "Luckie". Startest du den selben Prozess mit "Ausführen als" und wählst dort den Account "Admin", dann hat der Prozess zwar das Token vom "Admin" Account, aber dennoch wird es in Session 1 ausgeführt, weshalb die RDP
API entsprechend wieder "Luckie" als "Besitzer" der Session ermitteln kann.
Nja, aber dein Service, von dem vorhin auch noch geredet wurde, der wurde von meinem Benutzer gestartet.
Seit Vista werden SYSTEM-Services aus Sicherheitsgründen in einer eigenen Session gestartet, welche komplett isoliert ist (Session 0 Isolation). Die Session-Id und das dazugehörige Token des aktuell angemeldeten Benutzers benötigte mein Service, um einen Prozess auf dem Desktop des Benutzers zu starten. Praktisch eine Emulation des "interaktiven Services" (nur dass der Prozess auch nicht im SYSTEM Kontext lief), welcher im Rahmen der Session 0 Isolation abgeschafft wurde.