problèmes CreateProcessWithLogonW () - Nécessité de lancer des sous-processus avec le même utilisateur

Question

J'ai un exécutable Windows qui est lancé à partir d'un service en appelant CreateProcessWithLogonW () avec un ensemble de données d'utilisateur specfied.

Cela fonctionne bien et le processus commence comme prévu. Toutefois, lorsque ce processus tente de lancer d'autres processus lui-même, en utilisant simplement CreateProcess () ces droites commencent à mourir alors loin -. Ils sont executables qui nécessitent un accès de bureau

Après avoir lu sur l'article de Microsoft sur CreateProcess () - http://msdn.microsoft.com/en-us/library/ms682425 (VS.85) .aspx

Je pense peut voir pourquoi cela se passe et il est logique dans une certaine mesure. CreateProcess () connaît le processus d'appel est un utilisateur pour usurper l'identité qu'il utilise son processus parent, qui dans ce cas est le compte système local. Mais bien sûr, quoi que ce soit exécuté sur le compte du système local ne dispose pas de l'accès dont nous avons besoin, de sorte que le processus lancé meurt.

Curieusement quand je précédemment en utilisant LogonUser () et CreateProcessAsUser () pour lancer l'exécutable initial au sein du service, il a bien fonctionné. Mais je devais changer cela CreateProcessWithLogonW () en raison de problèmes de ne pas avoir les privilèges appropriés.

Quelqu'un sait-il d'une solution à cela? Je l'ai vu parler de cela ailleurs sur le web, mais pas avec une solution définitive. Il semble que je dois peut-être le signe de l'utilisateur je suis en connexion avec CreateProcessWithLogonW () avec donc je peux l'utiliser pour lancer les autres processus plus tard? Mais je n'ai aucun moyen de mettre la main sur ce jeton, cela peut être retreived pour l'utilisateur actuel de quelque façon?

Toute aide serait grandement appréciée, merci:)

Answer 1

Possédez-vous le code lancé en utilisant CreateProcessWithLogonW (et qui à son tour appelle CreateProcess)? Si vous ne vous pourriez donc pas besoin d'effectuer IAT (ou API) crochetage (ie à l'exécution), à remplacer tous les appels à CreateProcess une procédure appropriée qui utilise également CreateProcessWithLogonW ou CreateProcessWithTokenW. Voir APIHijack , Detours.

Après cela, le processus de l'enfant peut nécessiter un accès à HKCU. Si vous faites pas déjà, vous devez charger le profil de chaque utilisateur personnifié, une fois par utilisateur, avant d'appeler CreateProcessWithLogonW.

  

Par défaut, CreateProcessWithLogonW   ne charge pas l'utilisateur spécifié   profil dans le registre HKEY_USERS   clé. Cela signifie que l'accès à   informations dans le HKEY_CURRENT_USER   clé de Registre peut ne pas produire des résultats   qui sont compatibles avec une normale   ouverture de session interactive. C'est ton   la responsabilité de charger l'utilisateur   ruche de Registre dans HKEY_USERS avant   appelant CreateProcessWithLogonW, par   en utilisant LOGON_WITH_PROFILE, ou par   appelant la fonction LoadUserProfile.

Answer 2

Nous avons résolu le problème en utilisant un code que j'ai trouvé il y a longtemps. La section "copyright" de l'un des modules de source contient le texte suivant:

/////////////////////////////////////////////////////////////
// CreateProcessAsUser.cpp
// 
// Written by Valery Pryamikov (1999)
// 
// Command line utility that executes a command under specified user identity 
// by temporarily installing itself as a service.
//
// Based on Keith Brown's AsLocalSystem utility (http://www.develop.com/kbrown)
// Uses some code from Mike Nelson's dcomperm sample utility 
//   and from tlist sample (Microsoft Source Code Samples)
//
// Use:
//  CreateProcessAsUser.exe [-i[nteractive]]|[-s[ystem]]|
//       [-u"UserName" -d"DomainName" -p"Password"]|[-a"AppID"] command
//  Command must begin with the process (path to the exe file) to launch
//  -i        process will be launched under credentials of the 
//            "Interactive User" (retrieved from winlogon\shell process)
//  -a        process will be launched under credentials of the user 
//            specified in "RunAs" parameter of AppID.
//  -s        process will be launched as local system
//  -u -d -p  process will be launched on the result token of the 
//            LogonUser(userName,domainName,password,LOGON32_LOGON_BATCH...)
//
// either (-s) or (-i) or (-a) or (-u -d -p) parameters must supplied
// 
// Examples:
// CreateProcessAsUser -s cmd.exe
// CreateProcessAsUser -a"{731A63AF-2990-11D1-B12E-00C04FC2F56F}" winfile.exe
//
/////////////////////////////////////////////////////////////

Peut-être que cette information donnera vos recherches dans les succès de Google - J'ai essayé quelques tentatives rapides mais il est venu les mains vides. Nous décomposons les entrailles dans un ensemble de l'API qui a donné les résultats que nous avions besoin.

Answer 3

est pas là une option pour les services pour leur permettre d'interagir avec le bureau? Si cette option pour la mise en service est votre possibilité, ce serait sans doute la solution la plus simple.

Answer 4

Je suppose que ce processus est un service; qui n'est pas précisé dans la question, mais semble logique étant donné qu'il est en cours d'exécution en tant que compte système local.

Si vous obtenez coincé est pas CreateProcess, il est dans CreateService . Si vous voulez que votre service soit en mesure d'interagir avec le bureau, vous devez spécifier SERVICE_INTERACTIVE_PROCESS comme l'un des drapeaux au dwServiceType argument. Ce paramètre est hérité par les processus enfants du service.

Vous pouvez également modifier un paramètre de service existant à l'aide de l'outil Services, sélectionnez Propriétés pour le service, cliquez sur le « Connexion » onglet et activez la case à cocher « Autoriser le service à interagir avec le bureau ».