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

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,

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

You need Job.exe to be run for LocalSystem account or as Admin account? You cannot run the same process in both accounts.

For performing some tasks in other user's context you can use ImpersonateLoggedOnUser while the process (service) is running.

I need JOB.exe (the LocalSystem Service) to work for the user who is logged on as well as the ADMIN user which as created by Serv.exe using CreateProcessAsUser(...).

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?

LocalSystem account has the highest access, that's true! Then why do you need to run the same process (or impersonate) in Admin account? Do you need to access the local profile of Admin user?

Quote:

---

I would have assumed JOB.exe being a LocalSystem Service would apply to all cases, logged-in user or impersonated

---

Did I misinterpreted it??

Sadly it looks like I do - my Serv.exe LocalSystem service needs to install software - for that I need to be logged on as the administrator so that JOB.exe can take effect (I need to monitor the changes the software install does) as well as because I need HKEY_CURRENT_USER of the ADMIN accout.

If I install directly as LocalSystem JOB.exe doesn't track it (only the logged-on user) and HKEY_CURRENT_USER is that of the LocalSystem itself not the ADMIN user.

So I impersonate the ADMIN user to be able to install as-it ... but i that case JOB.exe isn't doing its task.

Simple! You use LogonUser, followed by ImpersonateLoggedOnUser (specify the Logon'ed user token). Then your process (service), performs the Admin task, and then you revert to LocalSystem account with RevertToSelf .

• It is better if you put above code in separate thread, since in Impersonate-Revert period the current thread would be running in context of specified user-token.
• What about Administrator password? Doesn't it change? Do you ask user for credentials?

That is a great idea ... I've gotta run for 4-5 hours but the second I get back I'll test and post the results here ... Thanks !

Didn't work - gives the same behavior ...

Did you verify with user information retrieval function like GetUserName, GetCurrentDirectory etc. that Admin is logged in at some stage?

Ya - it is logged-on as ADMIN (verified) - from what I can see I still can't even access HKEY_CURRENT_USER so I think I need to use LoadUserProfile(...) to load-in all that information ... playing with that now.