views:

342

answers:

1

I've read all the posts on Stack Overflow about CreateProcessAsUser and there are very few resolved questions, so I'm not holding my breath on this one. But it seems like I'm definitely missing something, so it might be easy.

The target OS is Windows XP. I have a service running as "Local System" from which I want to create a process running as a different user. For that user, I have the username and password, so LogonUser goes fine and I get a token for the user (in this case, an Administrator account.) I then try to use that token to call CreateProcessAsUser, but it fails because that token does not come with SeAssignPrimaryTokenPrivilege - however, it does have SeIncreaseQuotaPrivilege. (I used GetTokenInformation to dump all the privileges associated with that token.) According to the MSDN page for CreateProcessAsUser, you need both privileges in order to call CreateProcessAsUser successfully.

It also says you don't need the SeAssignPrimaryTokenPrivilege if the token you pass in to CreateProcessAsUser() is a "restricted version of the calling process' primary token", which I can create with CreateRestrictedToken(), but then it will be associated with the Local System user and not the target user I'm trying to run the process as.

So how would I create a logon token that is both a restricted version of the calling process' primary token, AND is associated with a different user? Thanks!

Note that there is no need for user interaction in here - it's all unattended - so there's no need to do stuff like grabbing WINSTA0, etc.

+2  A: 

SE_ASSIGNPRIMARYTOKEN_NAME is a privilege you can enable in your process/thread with OpenProcessToken/OpenThreadToken+LookupPrivilegeValue+AdjustTokenPrivileges (It is easy to confuse this with TOKEN_ASSIGN_PRIMARY, and MSDN says you need both to attach a primary token to a process)

On this XP:SP2 machine, just calling LogonUser(...,LOGON32_LOGON_INTERACTIVE,...)+CreateProcessAsUser works just fine without messing with any privileges (Using a fake cmd.exe service, but that should not matter)

This quote on MSDN:

If the necessary privileges are not already enabled, CreateProcessAsUser enables them for the duration of the call

and the fact that you are running as SYSTEM and should be able to enable any privilege leads me to believe that this assign primary stuff is not the problem.

Anders
You're right, it turned out to be a red herring. This is useful knowledge for later though. Thank you.
Josh K