Question

J'ai un héritage et l'application de service (donné naissance) serveur Windows qui fonctionne très bien dans XP-64 et W2K3, mais échoue sur W2K8. Je crois qu'il est à cause de la nouvelle « Session 0 isolement » caractéristique.

Par conséquent, je suis à la recherche d'exemples de code / paramètres de sécurité mojo qui vous permettent de créer un nouveau processus à partir d'un service Windows pour Windows Server 2008 tel que je peux restaurer (et peut-être dépasser) le comportement précédent. J'ai besoin d'une solution:

  1. crée le nouveau processus dans une session non nulle pour contourner la session-0 restrictions d'isolement (pas d'accès à matériel graphique de la session 0) - la ligne officielle de MS sur ce point est:
  

Parce que la session 0 n'est plus un utilisateur   session, les services qui sont en cours d'exécution en   Session 0 n'a pas accès à la   pilote vidéo. Cela signifie que tout   tenter qu'un service fait de rendre   échoue graphiques. Interrogation l'affichage   résolution et profondeur de couleur en session   0 rapports les résultats corrects pour la   système jusqu'à un maximum de 1920x1200 à   32 bits par pixel.

  1. Le nouveau processus devient une station windows / bureau (par exemple winsta0 / default) qui peut être utilisé pour créer des fenêtres contrôleurs de domaine. J'ai trouvé une solution (qui lance OK dans une session interactive) pour cette ici: Démarrage d'un processus client interactif en C ++

  2. Les fenêtres DC, lorsqu'il est utilisé comme base pour un OpenGL DescribePixelFormat énumération, est en mesure de trouver et d'utiliser le format accélération matérielle (sur un système correctement équipé du matériel OpenGL.) Notez que notre solution actuelle fonctionne bien sur XP-64 et W2K3, sauf si une session de services terminaux est en cours d'exécution (VNC fonctionne très bien.) une solution qui a également permis au processus de travail (c.-à-fonctionner avec l'accélération matérielle OpenGL même lors d'une session de services terminaux est ouverte) serait fanastic, mais pas nécessaire.

Je suis bloqué au point 1 actuellement, et même si il y a des messages similaires qui traitent de cette (comme cette et ce - ils ne sont pas des solutions appropriées, car il n'y a aucune garantie d'une session utilisateur connecté déjà" prendre » un identifiant de session à partir, et je ne suis en cours d'exécution d'un compte LocalSystem (je suis en cours d'exécution à partir d'un compte de domaine pour le service, pour lequel je peux régler les privilèges, dans la raison, bien que je préférerais ne pas avoir à grimper les priorités à inclure SeTcbPrivileges.)

Par exemple - voici un bout que je pense devrait fonctionner, mais renvoie toujours une erreur 1314 sur l'appel SetTokenInformation (même si les AdjustTokenPrivileges retournés aucune erreur) Je l'ai utilisé certaines stratégies alternatives impliquant « LogonUser » aussi bien (au lieu de ouverture du jeton de processus existant), mais je ne peux pas sembler permuter l'identifiant de session.

Je suis aussi douteuse sur l'utilisation du WTSActiveConsoleSessionId dans tous les cas (par exemple, si aucun utilisateur interactif est connecté) - même si un test rapide du service en cours d'exécution sans sessions connectés semblait renvoyer une valeur de session raisonnable (1 ).

J'ai retiré une erreur de manipulation pour faciliter la lecture (encore un peu en désordre - excuses)

    //Also tried using LogonUser(..) here
OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY
                         | TOKEN_ADJUST_PRIVILEGES | TOKEN_ADJUST_SESSIONID
                         | TOKEN_ADJUST_DEFAULT | TOKEN_ASSIGN_PRIMARY
                         | TOKEN_DUPLICATE, &hToken)

GetTokenInformation( hToken, TokenSessionId, &logonSessionId, sizeof(DWORD), &dwTokenLength )

DWORD consoleSessionId = WTSGetActiveConsoleSessionId();

/* Can't use this - requires very elevated privileges (LOCAL only, SeTcbPrivileges as well)   
   if( !WTSQueryUserToken(consoleSessionId, &hToken))
...
   */

DuplicateTokenEx(hToken, (TOKEN_QUERY | TOKEN_ADJUST_PRIVILEGES | TOKEN_ADJUST_SESSIONID | TOKEN_ADJUST_DEFAULT | TOKEN_ASSIGN_PRIMARY | TOKEN_DUPLICATE), NULL, SecurityIdentification, TokenPrimary, &hDupToken))


    // Look up the LUID for the TCB Name privilege.
LookupPrivilegeValue(NULL, SE_TCB_NAME, &tp.Privileges[0].Luid))

    // Enable the TCB Name privilege in the token.
tp.PrivilegeCount = 1;
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

    if (!AdjustTokenPrivileges(hDupToken, FALSE, &tp, sizeof(TOKEN_PRIVILEGES), NULL, 0))
    {
        DisplayError("AdjustTokenPrivileges");
           ...
    }

    if (GetLastError() == ERROR_NOT_ALL_ASSIGNED)
    {
        DEBUG( "Token does not have the necessary privilege.\n");
    } else {
        DEBUG( "No error reported from AdjustTokenPrivileges!\n");
    }                                                                                                                                                                                        // Never errors here

   DEBUG(LM_INFO, "Attempting setting of sessionId to: %d\n", consoleSessionId );

   if (!SetTokenInformation(hDupToken, TokenSessionId, &consoleSessionId, sizeof(DWORD)))
           *** ALWAYS FAILS WITH 1314 HERE ***

Tous les résultats de débogage semble bien jusqu'à l'appel SetTokenInformation - Je vois la session 0 est ma session en cours de processus, et dans mon cas, il essaie de régler la session 1 (le résultat de la WTSGetActiveConsoleSessionId). (Notez que je suis connecté dans la zone de W2K8 via VNC, non RDC)

Alors - une des questions suivantes:

  1. Cette approche est valable, ou sont tous les processus initiés services restreints à la session 0 intentionnellement?
  2. Y at-il une meilleure approche (peu de « lancement ouverture de session » et ouverture de session automatique pour les serveurs?)
  3. Y at-il quelque chose de mal avec ce code, ou une autre façon de créer un jeton de processus où I peut swap sur l'identifiant de session pour indiquer que je veux reproduire le processus dans une nouvelle session? J'ai essayé en utilisant LogonUser au lieu de OpenProcessToken, mais cela ne fonctionne pas non plus. (Je ne me soucie pas si tous les processus donné naissance à partager la même session ou non non nul à ce point.)

Toute aide très appréciée - merci

Était-ce utile?

La solution

Pour toute personne intéressée par la résolution de cette question:

Je discuté de cette question avec MS soutien à l'équipe LogonSDK. Il semble qu'il ne soit pas possible d'usurper l'identité d'un utilisateur entièrement interactif programatically, de sorte que vous obtenez une console physique et des constructions de GDI associés, et nous avons essentiellement été « chanceux » que cela a fonctionné jusqu'à présent. Ils ont confirmé que la session 0 isolement était la cause de la régression.

Leur recommandation est de permettre l'ouverture de session-automatique à une session interactive et factoriser le service de parler à un nouveau composant client dans la session interactive. Pour remédier à l'inconvénient de sécurité, ils recommandent la mise en œuvre d'un remplacement du shell pour mettre le serveur en mode « Kiosk » ouverture de session (par exemple pas d'accès Explorer sans informations d'identification appropriées, etc.)

Sur le haut côté, cela devrait résoudre les problèmes que nous avons avec des séances de rencontrons services de terminal tuer notre accélération matérielle.

Je vais soumettre une demande à MS considérer ce genre de « rendre ferme » cas d'utilisation pour le soutien « session utilisateur proxy » dans les versions ultérieures, de sorte qu'un serveur peut engendrer des processus accélération matérielle sans compromis de sécurité d'exiger un existant processus d'utilisateur du client pour être connecté à la console.

Autres conseils

Je ne l'ai pas suivi le cours de formation, mais je l'ai trouvé un tutoriel « Session 0 solution d'isolement » sur le site Microsoft MSDN:

http://msdn.microsoft.com/en-us/windows7trainingcourse_sessionisolation_unit.aspx

J'ai le même problème session 0 isolement manifesté dans une tâche planifiée.

farmComm lancera l'application (s) de votre choix dans la session 0, sans interface graphique visible, mais avec un accès au matériel graphique, si les utilisateurs sont connectés ou non. Elle répond également à l'activité de l'utilisateur quelle que soit la session est active (y compris la session 0 ou le « bureau sécurisé » quand cela est la session active). Il est conçu pour lancer des applications ainsi lorsque les utilisateurs sont inactifs, et les mettre fin à la reprise de l'utilisateur du ralenti, mais ces conditions pourraient exécuter facilement être modifiée dans les scripts AutoHotkey source.

https://github.com/r-alex-hall/farmComm

Il génère des applications dans la session 0 « invisiblement », mais il peut très facilement être modifié (changer une variable avec la valeur « cacher » pour « montrer ») d'avoir les interfaces graphiques des processus donné naissance visibles (si elles ont une interface graphique) . Si elles sont visibles, mais ils peuvent soit déclencher de Windows bourrins pour voir « messages » en session 0, et / ou être visibles de la session 0 (qui, paraît-il, comprend tout moment le « bureau sécurisé » est visible - pour par exemple lorsqu'un poste de travail est verrouillé ou déconnecté de sessions utilisateur, ou pas d'utilisateurs connectés).

À ce jour, si une session de bureau (RDP) est commencé alors que les processus engendrés par l'exécution farmComm, farmComm mettra fin à ces processus et tenter de les relancer pour répondre à la session RDP, qui, si elles sont des applications qui tenter d'accéder au matériel graphique, peut les amener à planter (car RDP restreint l'accès au matériel graphique). Probablement ce problème RDP pourrait être contournée, aussi. . . ou vous pouvez modifier la source de mettre fin à jamais les processus, ou jamais migrer vers d'autres sessions. (REMARQUE: un éventuel changement prévu est de vous permettre de scripter si et quand farmComm se termine, ne se termine pas, suspend ou reprend processus - ou pour cette matière, le script à exécuter des processus entièrement différents lorsque les utilisateurs reprennent du ralenti) <. / p>

Les scripts peuvent être compilés à executables, qui dans ma distribution, ils sont.

Les chevilles ouvrières de ce jeu d'outils sont une version particulière de paexec (qui lance des applications dans la session 0), et des réponses très fiables à l'activité des utilisateurs de AutoHotkey (ou l'absence de celui-ci), et la récupération des informations système sur une session. L'option de lancer des processus "cachée" (sans interface visible) est également via AutoHotkey.

Divulgation: Je scripté (ou codé) farmComm et publié dans le domaine public

.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top