Question: I am having an issue with UAC and executing a non interactive process as a different user (APIs such as CreateProcessAsUser or CreateProcessWithLogonW).

My program is intended to do the following:

1) Create a new windows user account (check, works correctly)

2) Create a non interactive child process as new user account (fails when UAC is enabled)

My application includes a administrator manifest, and elevates correct when UAC is enabled in order to complete step 1. 

But step 2 is failing to execute correctly. I suspect this is because the child process which executes as another user is not inheriting the elevated rights of my main process (which executes as the interactive user).

I would like to know how to resolve this issue. When UAC is off my program works correctly. How can I deal with UAC or required elevated rights in this situation?

If it helps any, the child process needs to run as another user in order to setup file encryption for the new user account.

Answer: 
The reason why the spawned process has no admin rights when using CreateProcessWithLogon and CreateProcessAsUser is explained in this blog post:

<http://blogs.msdn.com/cjacks/archive/2010/02/01/why-can-t-i-elevate-my-application-to-run-as-administrator-while-using-createprocesswithlogonw.aspx>

Long story short: CreateProcess is such a low layer in windows it doesn't know about elevation. ShellExecute(Ex) does. So you have to create and start a bootstrapper application with CreateProcessWithLogon/CreateProcessAsUser which in turn (now acting as the other user) starts your final application with ShellExecute(Ex) which will ask for admin rights (if you specify "runas" as lpVerb or provide a manifest for your app). And because this is such an easy and fun task to do there is no ShellExecuteWithLogon function provided by Windows.

Hope this helps.
Just faced a similar issue on Windows 7 under maxed UAC.

When UAC is turned ON, CreateProcessWithLogon creates a restricted token, just like LogonUser with LOGON32\_LOGON\_INTERACTIVE would do. This token prevents elevation.

Solution is to first call LogonUser with LOGON32\_LOGON\_BATCH, which returns a full-access token. Once obtained, just call CreateProcessWithToken.