Discussion :

[sinfoni]

Bonjour,

Voici ma problématique:
J'ai un service qui tourne sous le compte SYSTEM. Ce process effectue différentes tâches, et notamment lance d'autres process. Certains de ces process doivent être lancés même si ma session windows n'est pas ouverte, ce cas ne pose aucun problème. Pour rendre compte à l'utilisateur de la bonne fin de certaines tâches, mon service doit cependant aussi être capable de:

1. Vérifier qu'une session windows est ouverte.
2. Si c'est le cas: Lancer un process qui doit lui interagir avec le bureau de la session ouverte.

Sur XP, pas de souci. Mon service a l'autorisation d'interagir avec le bureau, et si une session est ouverte, le process lancé par le service s'affiche.

Sur Vista et Seven, autre histoire: Car le process qui doit s'afficher est lancé par le compte SYSTEM, et il n'interagit pas avec le bureau de l'utilisateur qui a ouvert la session.

Idée: Récupérer simplement le nom du compte de la session ouverte (je cherche explorer.exe dans la liste des process et je récupère le owner du processus, ça, ça marche). Mais si je veux lancer mon process censé s'afficher sur le bureau avec le compte ainsi récupérer, il semble que le mot de passe de session soit requis, or je ne possède pas ce mot de passe.

Bref, y-a-il un moyen simple et élégant de faire lancer par un service windows un process capable d'interagir avec la session du user loggé, et ce sans avoir besoin de fournir le mot de passe de son compte ???

Merci

[khena]

A chaud, comme ça, ça me semble difficile. En plus, tu pars du principe qu'on ne peut ouvrir qu'une seule session sur un poste, ce qui me semble faux. Tu peux avoir plusieurs sessions simultanées sur un serveur, avec du TSE, ou même deux sessions ouvertes "switchables" sur un même poste.

J'ai pas tout à fait la même problématique mais j'ai déjà fait un truc de ce style :
- tu rajoutes un serveur TCP ou UDP à ton service, qui se lance "avant toute chose" (un Indy TCP Serveur)
- tu balances un raccourci d'un petit .Exe client dans le All Users > Démarrage
- Le petit exe n'est qu'un simple client TCP/UDP du serveur, il s'y connecte dès le début (avec le Indy TCP Client)
- lorsque le serveur veut lancer des applis sur les bureaux, il envoie une commande à tous les clients connectés (les petits exe), qui lanceront eux même les applis.

Bon après, y a toute une gestion au niveau de la sécurité, etc. à avoir.

C'est vraiment qu'une idée comme ça, c'est pas super simple non plus...

[Jipété]

Salut.

Mon grain de sel...

Une autre idée, simple (simpliste ?) :
un petit exe lancé en tâche de fond à l'ouverture de la session, et qui va chercher un fichier "flag", fichier qui serait créé par le service avec les données à afficher ; si ce "flag" existe, le petit exe affiche une IHM avec le contenu du fichier.

[sinfoni]

Pour le multi-sessions, ce n'est pas vraiment un souci, d'abord par que le soft n'est pas destiné à des serveurs, ensuite pour les sessions switchables sur PC, je peux afficher l'info sur toutes les sessions disponibles, ce n'est pas vraiment grave.

J'avais bien pensé aussi au coup du programme au démarrage de session et qui communique avec le service, mais je voulais juste faire "propre" et ne pas avoir à ajouter un process "service helper" qui au final la plupart du temps tourne pour rien... Mais effectivement s'il n'y a pas d'autre solution, j'en passerai par là...

En attendant, je reste ouvert à toute suggestion

[Jipété]

(...) mais je voulais juste faire "propre" et ne pas avoir à ajouter un process "service helper" qui au final la plupart du temps tourne pour rien... (...)

Si ton service est capable de lancer un exe, il le lancerait si un user est loggué et qu'il a besoin de lui dire qqchse ; ensuite, les deux processus pourront communiquer de 36 manières possibles, je pense : échange de fichier, named pipes, mailslots, client/serveur en TCP, etc.

Nan ?

[sinfoni]

Oui, mais on tourne en rond, parce que si c'est le service qui lance l'exe, cet exe est lancé sous le compte SYSTEM, et Vista/Seven n'aiment pas visiblement.... Il faut donc que l'exe soit lancé par le démarrage de la session.

Ce que je ne comprends au final, c'est qu'on donne au service l'autorisation d'interagir avec le bureau, mais que malgré cela, il ne peut par lancer de programme interactif. Etrange...

[sinfoni]

Juste une idée peut-être: Est-il possible de récupérer le Token d'un Process existant ? Si oui, si je récupère le token du process explorer.exe, et que je lance mon programme avec une fonction CreateProcessAsUser en passant ce token, l je n'ai plus besoin du ot de passe non ?

[Andnotor]

Sous XP, les services et le premier utilisateur logué tournent sous la session 0.

Depuis Vista, les services tournent toujours sous la session 0, mais les utilisateurs, sous 1 et plus. Les bureaux ne sont donc plus accessibles dû à l'isolation des sessions.

Je m'étonne même (mais n'ai pas testé) que tu puisse lancer sous XP une application sur le bureau du 2ème utilisateur logué (dans le cas où Fast User Switching est activé) puisque les services et l'utilisateur tourneront dans des sessions différentes .

...mais je voulais juste faire "propre"...

Lancer un exe avec des droits SYSTEM sur le bureau n'est pas vraiment ce que j'appellerais "propre" ! Un petit hook malveillant et hop, n'importe quelle application a un accès total au système

[sinfoni]

Alors je reviens ma problématique et cela semble fonctionner très bien via l'utilisation des fonctions WTSGetActiveConsoleSessionId et WTSQueryUserToken...

Que les services "remote" tournent ou pas, il est possible d'appeler WTSGetActiveConsoleSessionId. Sur un PC XP, VISTA, Seven, ça renvoie la session actuellement active, c'est à dire celle qui utilise le clavier et l'écran. Donc, ça fonctionne très bien si le fast user switching activé sous XP.

Cette fonction ne peut être appelée que par SYSTEM.

On récupère donc le Token de la session active, et on utilise CreateProcessAsUser... Résultat :
Le process se lance bien sous la session active, avec le compte qui a ouvert cette session et par conséquent, ma fenêtre s'affiche

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
 
function WTSGetActiveConsoleSessionId:LongWord; stdcall; external 'kernel32.dll';
function WTSQueryUserToken(SessionId: LongWord; out  phToken : LongWord): boolean; stdcall; external	'Wtsapi32.dll';
 
...
 
function RunInteractive(prog: String): boolean;
var hToken: THandle;
  si: _STARTUPINFOA;
  pi: _PROCESS_INFORMATION;
var  Ret: Cardinal;
  sTitle: string;
  sMsg: string;
begin
  ZeroMemory(@si, SizeOf(si));
  si.cb := SizeOf(si);
  si.lpDesktop := nil;
 
  if WTSQueryUserToken(WtsGetActiveConsoleSessionID, hToken) then begin
    if CreateProcessAsUser(hToken, nil, PChar(prog), nil, nil, False, 0, nil, nil, si, pi) then begin
      result := true;
    end
    else begin
      result := false;
    end;
  end
  else Begin
    result := false;
  End;
  CloseHandle(hToken);
end;

[kassimsarr]

Bizarre, sous seven, j'utilise aussi cette fonction qui focntionne bien apres une ouverture de session sauf lors d'un fast user switching (syseme error code 5, access denied). Auriez vous une idée?