3

I want to run an application under another user account's (non-elevated) credentials while that user is already logged-in. Specifically, I want my application's installer (which runs under any administrator account) to spawn processes into each logged-in user's desktop session. These processes communicate with a service and display windows on the desktop for the user to interact with.

Ordinarily, from a service running as LocalSystem, the approach is WTSQueryUserToken -> CreateProcessAsUser. However, WTSQueryUserToken won't run outside of the LocalSystem account (with SE_TCB_NAME privilege), which makes that approach fail here.

If the user weren't logged in already, I could just register the application to run under HKLM\...\Run, so that any logged-in user will get a copy of the application when they log in. But if the user's already logged-in, that doesn't work either (at least, not until they log out and log back in again).

I can see two possible answers:

  1. You can't do this. Sorry.

  2. You can get a token from somewhere else (maybe enumerate explorer.exe processes and pull the access token from each one?), call DuplicateTokenEx, then pass to CreateProcessAsUser. I tried this approach and consistently received "access denied" when trying to OpenProcessToken on a process running under another user session, even with the debug privilege enabled and the process opened with PROCESS_ALL_ACCESS.

What do you think?

If the answer is #1 ("you can't do this"), then what is the recommended best practice for spawning non-elevated processes to mediate between a service and the user? Is it best practice for the service to spawn these processes into each session via CreateProcessAsUser? Or is it best practice for the non-elevated processes to be run separately (e.g. via HKLM\...\Run or HKCU\...\Run)?

DSII
  • 429
  • 6
  • 15
  • One obvious workaround is to install and start a service on the fly so that you can call WTSQueryUserToken from SYSTEM context. You could delete the service again once your work is done. – Harry Johnston Mar 13 '12 at 04:11
  • Yes, that is indeed the simplest workaround, if (A) there's no way to do this from a non-service caller (e.g. an installer), and (B) it isn't bad practice to do it this way! – DSII Mar 13 '12 at 18:31
  • (A) I'm not sure why you're getting access denied opening the process tokens, but enumerating processes is an awkward approach at best so personally I'd suggest sticking with WTSQueryUserToken which is documented to only work when you are SYSTEM. – Harry Johnston Mar 13 '12 at 20:08
  • (B) There's precedent; Microsoft software such as psexec and Process Monitor work by installing services on the fly. – Harry Johnston Mar 13 '12 at 20:12
  • I'm more concerned that it might be bad practice to run applications this way at all; that it might be better practice from a Vista Session 0 Isolation perspective to register them to run from HKLM\...\Run rather than spawning them from a service at all. – DSII Mar 14 '12 at 13:41

0 Answers0