Service not running for Impersonated user with CreateProcessAsUser [C#]

S

Shaitan00

Junior Contributor
Joined
Aug 11, 2003
Messages
358
Location
Hell
There is a LocalSystem Service (Job.exe) which performs a certain absolutly required task (for example: file system watching), this service is run for all users (at least when they logon).
There is another LocalSystem Service (Serv.exe) which uses CreateProcessAsUser(...) to launch a process as a different (admin) user.
There are 2 accounts, USER (which is the one logged-on) and ADMIN.

So this is the scenario ...
User logs in to USER account (non-admin) and both LocalSystem Services (Job.exe & Serv.exe) start and work without any problems... Then at a certain point Serv.exe calls CreateProcessAsUser() using the ADMIN account in order to launch an administrative task (note that USER is currently logged in).

So far everything is fine - but now a problem happens - the process run by CreateProcessAsUser(...) under the ADMIN is not subject to the LocalSystem service JOB.exe - for example if JOB.exe monitors file-system changes and logs them if I launch a task with CreateProcessAsUser(...) under ADMIN that changes files I would assume JOB.exe would log these - but it does NOT ...

So it looks like JOB.exe is NOT running in the context of the ADMIN account when launched using CreateProcessAsUser(...), this is a big deal for me - I need to ensure JOB.exe LocalSystem service is absolutly always running - even when CreateProcessAsUser(...) is used...

Is there anything I can do to solve this problem? any help would be much appreciated.
Can I load the environment? profile? something to kick-in JOB.exe so that it actually works?

Thanks,
 
Is the task being launched as Admin actually running and making the changes you are expecting?

Does the system monitoring the file system detect changes made by the logged on user? If you log on as Admin and modify the same files are the changes detected then?
 
Yes the task being launched under the ADMIN account is actually making the changes I am expecting. Yes JOB.exe succesfully monitors the logged on user, and if I logon as admin it works then also.
 
That does sound odd, if the job can spot the changes when they are performed as either a logged on Admin or User then it should also detect them using the instance spawned by CreateProcessAsUser...

What is the JOB.exe actually doing and how is it detecting the file changes?
 
JOB.exe is legacy software that monitors registry and file system changes - sadly I don't have the source code available to show exactly how it works but ... it works fine for the logged-in user.

Do I maybe have to do something special to my CreateProcessAsUser() to load the environment? Profile? etc... I also noticed that accessing HKEY_CURRENT_USER doesn't seem to work ...
 
Without knowing how it works it is hard to guess what is possibly going wrong, for security reasons services and anything they launch run on a separate desktop to a logged in user - if the application is hooking something at the user session level then it is possibly a non-starter.

If the application is monitoring access at a lower level (kernal mode for example) then it should work regardless.
 
I would have assumed JOB.exe being a LocalSystem Service would apply to all cases, logged-in user or impersonated ... could it be that I need to load some kind of context?
 
It really depends on how they are monitoring things, if they are using the API (where it exists) then it should be fine, they may however be doing something that hooks activities at the user level and this will not work when the users are under different contexts.

If you bring up the service properties there should be an option with a name something like 'allow service to interact with desktop' - try enabling that and see if it helps.

If that does fix the problem then it probably indicates the job.exe is doing things in an unorthodox way...
 
I made the change and it didn't help ...
Is it possible I may need to load the ADMIN account profile somehow?
Or use ImpersonateLoggedOnUser but pass the Token for the ADMIN account?
 
I have a feeling this is down to windows security - it looks like the job.exe is using a technique which isn't going to work when run under a different desktop to the user making the changes.

Without knowing how it is monitoring things (what techniques / Apis etc) then it will be very difficult to troubleshoot.
 
Back
Top