3

Overview

The Process

exe/dll compiled in C++ to be run

Scenario

  1. Log in (win 7) to a standard user account (no admin)
  2. run The Process as admin
  3. The Process opens some app (exe) using ShellExecute

Problem

The app is opened in the scope of the admin user

Expecting

The app is opened in the scope of the standard user


Solutions

1. CreateProcessAsUser

Use CreateProcessAsUser (Assuming I managed to get hToken right that should have solved the issue).

However, I get the call failed with error code 1314 - ERROR_PRIVILEGE_NOT_HELD. Going back to the documentation tells me:

If this function fails with ERROR_PRIVILEGE_NOT_HELD (1314), use the CreateProcessWithLogonW function instead

So I digged in and found this CreateProcessAsUser Error 1314 which wasn't very helpful.

2. ImpersonateLoggedOnUser

using ImpersonateLoggedOnUser generated the same error code: 1314 - ERROR_PRIVILEGE_NOT_HELD.

3. CreateProcessWithLogonW

CreateProcessWithLogonW requires lpPassword which naturally I don't have


The Question

How can an admin process open an application in the logged in user?

idanshmu
  • 5,061
  • 6
  • 46
  • 92
  • You want to run an admin process as a user that has no admin rights? Perhaps it might help if you described why you want to do this and what specific aspect of the user you need access to? – Component 10 Nov 05 '15 at 09:12
  • Imagine `The Process` is making changes in files of the standard user. Now, the app that `The Process` activates, is using these files. If the app is opened in the scope of the admin user, then the changes made by `The Process` are not "seen". – idanshmu Nov 05 '15 at 09:24
  • 1
    Understood, though it seems from the various references that this is not possible without the caveats mentioned (i.e. password etc.) possible the most pragmatic approach is to run all from an un-elevated launcher [as described here](http://blogs.msdn.com/b/jamesfi/archive/2007/04/11/how-to-launch-an-un-elevated-process-from-an-elevated-process.aspx) – Component 10 Nov 05 '15 at 10:08
  • See [this answer](http://stackoverflow.com/a/7880040/886887). – Harry Johnston Nov 05 '15 at 22:16
  • A privilege is not a right! (Pun intended.) Privileges must be bestowed upon you and in many cases you have to also enable them. A token is not a privilege either. – conio Nov 08 '15 at 03:02

2 Answers2

1

Have you tried using CreateProcessWithTokenW which is mentioned in the CreateProcessWithLogonW documentation? It seems to require a much weaker privilege than CreateProcessAsUser, one you should posses (SE_IMPERSONATE_NAME rather than SE_ASSIGNPRIMARYTOKEN_NAME).

You said you already have a token for the interactive user so I won't go into it.

(Note: Strange bugs have been reported with all of this, including CreateProcessWithTokenW. Don't give up on the first attempt. A bug and a fix for example: why is CreateProcessWithTokenW failing with ERROR_ACCESS_DENIED )


hToken is not a "right". It's a token. What the error says is that you lack a privilege.

Holding a privilege is not a fundamental right! Some privileges are given to certain users by default. Others need to be given through the Local Security Policy (in the "User Right Assignment" node in the MMC snap-in or with LsaAddAccountRights - all of which is documented in the page Assigning Privileges to an Account).

Besides that you sometimes have to enable privileges using AdjustTokenPrivileges. This is documented in the sibling page Changing Privileges in a Token.

Some APIs enable them if you hold them. Others don't and require you to do so yourself. The obvious way to go is to enable a privilege before calling and API that's documented to require it.

The MS Forum link may not have been but the error message is quite clear. MSDN says about the function:

Typically, the process that calls the CreateProcessAsUser function must have the SE_INCREASE_QUOTA_NAME privilege and may require the SE_ASSIGNPRIMARYTOKEN_NAME privilege if the token is not assignable.

and the error is (from the page you linked to!):

ERROR_PRIVILEGE_NOT_HELD
  1314 (0x522)
  A required privilege is not held by the client.

Community
  • 1
  • 1
conio
  • 3,681
  • 1
  • 20
  • 34
0

This is actually a very tricky Task you want to accomplish. There are very strict security policies which make it very difficult.

As far as I know you can do it with psexec. It has a commandline Switch which enables user interaction but running the process as admin. I think your command should look like the following:

psexec \\target-computer -i -s [your command]

Another way to do it is using WMI. But for this you Need to Change the security Settings of the target machine (probably using GPO's). You Need to connect to the target machine using impersonation Level deletgate see here. Additionally as said before, you Need to Change the security Settings. See here

Thomas Sparber
  • 2,827
  • 2
  • 18
  • 34