Processus a chaque ouverture de connexion

Bonjour,

   Voila je fais un prog (visual C++ en MFC) qui va deconnecter l'utilisateur au bout d'un certain temps.
Je mets un compteur a jour toutes les sec ds la base de reg et je delogue l'utilisateur une fois que celui ai attenint sa limite.
Mon souci c que l'utilisateur n'a qu'a faire un ctrl alt suppr et killer l'appli
Je pourrais tjrs la cacher mais avec avec d'autres outils du style process explorer, ca ne marchera pas.
Est ce qu'il existe un moyen de le lancer en admin par exemple ou le proteger a chque ouverture de session ?

J'avais penser à modifier des cles runservices ds hklm ds la BDR mais ca n'a rien donné, le prog ne se lance si l'utilisateur n'a pas les droits sur ce prog (de tte facon je ne veux pas qu'il puisse y acceder)
Sinon les services windows mais le pb c ke l'appli tournera tous le temps ...

tu met dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system un cle DWORD DisableTaskMgr a 1 et donc tu utilisateur ne peux plus ouvrir Ctrl Alt Supp

Solution mutlithread:
explication :
- main crée un Thread pour l'utilisateur (Thread One)
- Le Thread utilisateur crée son propre Thread "Timer" (Thread Two) en lui passant une copie de son handle
ThreadOne tourne (en rond)...Thread Two compte...
Quand Thread Two a fini de compter, il termine le Thread One...

// TwoStopOne.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <windows.h>
#include <windows.h>

void Erreur (char *Msg) {

    fprintf(stderr, Msg);
    ExitProcess (1);
}

DWORD WINAPI ThreadTwo (LPVOID lpvThreadParam) {

    DWORD  dwResult = 0;
    printf("Dans le thread two\n");
    Sleep(2000); // Timer
    TerminateThread((HANDLE)lpvThreadParam , dwResult); // Terminer le Thread One
    printf("Thread two fini\n");
    return dwResult;
}


DWORD WINAPI ThreadOne (LPVOID lpvThreahParam) {

    DWORD  dwResult = 0, dwThreadId;
    HANDLE hThread, hThreadOne;
    printf("Dans le thread one\n");
    DuplicateHandle(
        GetCurrentProcess(),
        GetCurrentThread(),
        GetCurrentProcess(),
        &hThreadOne, 0, FALSE, DUPLICATE_SAME_ACCESS);
    hThread = CreateThread(NULL,0,ThreadTwo, (LPVOID)&hThreadOne, 0, &dwThreadId);
    if ( hThread == NULL ) Erreur ("CreateThread(Two)");
    CloseHandle(hThread);
    while(1);
}


int main(int argc, char* argv[])
{
    HANDLE hThread;
    DWORD dwThreadId;
    hThread = CreateThread(NULL,0,ThreadOne, NULL,0, &dwThreadId);
    if ( hThread == NULL ) Erreur ("CreateThread(One)");
    CloseHandle(hThread);
    Sleep(5000);
    return 0;
}

Les deux threads étant inclus dans le même processus. L'utilisateur ne peut distinguer le Thread "Timer", il ne peut pas le stopper. (dans la fenetre CTRLALTSUPPR, il ne peut faire qu'une chose terminer le processus en entier)

Je sais pas si ça peut répondre à ta question.

Merci pr les reponses mais ca ne resoud pas mn pb du moins en partie :
pr la premiere reponse je l'avais deja mis en place par les groupes policies.
pr la deuxieme reponse l'idee d'avoir deux thread est bien mais le souci c'est qu'il suffit de terminer le process pere pr arreter le prog...
Il faudrait qu'il y ait deux proccess qui verifient chqe ms la presence des 2 mais là je suis depassé !!!

Si tu veux empêcher le père (threadone, le thread utilisateur) de se terminer avant que le fils (threadtwo) n'ai fini de compter, ca veut dire que tu veux empêcher l'utilisateur de terminer sa connexion avant que toi (threadtwo) l'ai décidé. Tu dois pouvoir laisser l'utilisateur se deconnecter quand il le souhaite, même si le compteur n'est pas fini.

A mon avis un programme qui empêche l'utilisateur de terminer quand lui a envie (ou qui ne s'arrête que quand le concepteur le décide, c'est pareil) ne fera pas une longue carrière.

Entierement d'accord avec toi, je voudrais que l'utilisateur ne puisse l'arreter mais lors d'une fermeture de session qu'il n'y ait pas de pb.
Dc du coup je pense laisser tomber cette solutioin, en fait j'ai mis mon exe en service lancé par le cpte admin local de la machine.
Celui ci doit verifier si qqun et connecté lire la base de registre et declecncher le compteur.
Le souci est que lors du lancement de l'exe à la main pas de pb, il voit bien ds le registre un utilisateur (clé logon user name ds HKLM) et le cpteur peut se lancer. (le but c de verifier a chaque sec si cette clé logon existe pr savoir si un utilisateur est logué ou pas)
Par contre des qu'il se lance par le service ca plante...
Il ne reconnait pas cette clé.
Je pense qu'il doit y avoir un pb de droit mais la je ne vois pas.

ps : j'ai essayé de le lancer avec le cpte local, ca ne marche pas non plus (de tte facon, je pense que l'utilisateur pourrait larreter apres ...)

Je ne sais pas si l'utilisation de la base de registres est legitime dans ton cas. Là ça va, tu n'a qu'un seul utilisateur test. Mais dans un vrai environnement multi-utilisateurs, tu vas encombrer ta base de registres avec une multitude de petits compteurs. Tu risques d'avoir de graves problèmes de perfomances (sauf son ton appli tourne juste pour une personne) en lisant toutes les secondes ce gros pavé de windows. La base de registres sert plus pour stocker des informations systèmes, que des données de programmes.

D'autre part, si tu lances un service en arrière plan de "surveillance de visiteurs" il faut faire attention à ne pas inverser les rôles, à savoir, si ton service va régulièrement interroger quelquechose pour savoir si quelqu'un est là, il peut mobiliser des ressources inutilement. Tandis que s'il est réveillé uniquement quand quelqu'un "frappe à la porte", c'est mieux.
Soit tu fais un processus "écouteur" qui toutes les secondes se réveille pour fouiller la base de registres ou autre chose et voir s'il y a quelqu'un et qui en plus décompte les secondes pour ceux qui sont déjà connectés (coûte cher).
Soit tu fais un  processus "écouteur", disons endormi, prêt à créer une connexion et un compteur chaque fois qu'il reçoit une demande d'ouverture de session (coûte moins cher, je pense).

L'idée avec le multithread est que chaque utilisateur dispose de son propre compteur, libérant ainsi, main (le processus ecouteur) de travail inutile (decompter le temps pour les utlisateurs deja connectés). Et d'autre part, comme chaque compteur est intégré dans le processus maitre, l'utilisateur n'a aucun accès, ni aucun contrôle dessus.

Quant à tes problèmes de droits d'accès, ça peut venir du fait que la base ou une partie n'est pas accessible à ton process. je sais pas..