views:

1874

answers:

5

I have a Windows executable that is launched from within a service by calling CreateProcessWithLogonW() with a set of specfied user details.

This works fine and the process starts as expected. However, when this process tries to launch other processes itself, currently just using CreateProcess() these start then die straight away - they are executables that require desktop access.

After reading up on Microsoft's article on CreateProcess() - http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

I think can see why this is happening and it makes sense to an extent. CreateProcess() knows the calling process is impersonating a user so it uses it's parent process, which in this case is the Local System account. But of course anything run in the local system account doesn't have the access we need, so the launched process dies.

Oddly when I was previously using LogonUser() and CreateProcessAsUser() to launch the initial executable within the service, it worked fine. But I had to change this to CreateProcessWithLogonW() due to problems with not having the correct privileges.

Does anybody know of a solution to this? I've seen talk about this elsewhere on the web but not with any definite solution. It seems like I possibly need the token of the user i'm logging on with in CreateProcessWithLogonW() with so I can use it to launch the other processes later? But I have no way of getting hold of this token, can this be retreived for the current user in any way?

Any help would be greatly appreciated, thanks :)

A: 

Isn't there an option for services to allow them to interact with the desktop? If setting that option for your service is a possibility, that would probably be the simplest solution.

Eric Petroelje
That option is already set, it's not the service itself that's the problem, it is launching the executable fine under the correct user, it's further processes which that executable attempts to start that cause issues...
Adam Cobb
Interesting. I would have thought that permission would be inherited by child processes.
Eric Petroelje
+1  A: 

Do you own the code launched using CreateProcessWithLogonW (and which in turn calls CreateProcess)? If you do not then you might need to perform IAT (or API) hooking on it (i.e. at run-time), as to substitute any calls to CreateProcess with an appropriate procedure that also uses CreateProcessWithLogonW or CreateProcessWithTokenW. See APIHijack, Detours.

After this is done, the child process may require access to HKCU. If you are not already doing this, you should load the profile of each impersonated user, once per user, before calling CreateProcessWithLogonW.

By default, CreateProcessWithLogonW does not load the specified user profile into the HKEY_USERS registry key. This means that access to information in the HKEY_CURRENT_USER registry key may not produce results that are consistent with a normal interactive logon. It is your responsibility to load the user registry hive into HKEY_USERS before calling CreateProcessWithLogonW, by using LOGON_WITH_PROFILE, or by calling the LoadUserProfile function.

Cheers, V.

vladr
A: 

We solved the problem using some code that I found long-ago. The "copyright" section of one of the source modules contains the following:

/////////////////////////////////////////////////////////////
// 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
//
/////////////////////////////////////////////////////////////

Perhaps this information will yield hits within your Google searches - I attempted a few quick attempts but came up empty-handed. We decomposed the internals into a set of API that yielded the results we needed.

SAMills
A: 

Can you post the arguments you're using for CreateProcessAsLogonW?

Tristank
CreateProcessWithLogonW( swUsername, swDomain, swPassword, LOGON_WITH_PROFILE, NULL, swCommandLine, NORMAL_PRIORITY_CLASS, NULL, swWorkingDir, (LPSTARTUPINFOW)
Adam Cobb
Sorry it seemed to miss my new line. Just to make it clearer, i've pasted the STARTUPINFO structure below the CreateProcessWithLogonW definition.
Adam Cobb
A: 

I'm assuming that this process is a service; that isn't specified in the question, but seems logical given that it is running as Local System account.

Where you're getting stuck isn't in CreateProcess, It's in CreateService. If you want your service to be able to interact with the desktop, you have to specify SERVICE_INTERACTIVE_PROCESS as one of the flags to the argument dwServiceType. This setting is inherited by child processes of the service.

You can also modify an existing service's setting by using the Services tool, select Properties for the service, click on the "Log On" tab, and select the check box "Allow service to interact with desktop".

Jared Oberhaus
Oops, I see from the above comments to another question that this has already been ruled out.
Jared Oberhaus