Possible to RunAs currentuser and AsAdmin true?

[jriv]

I need to run an executable as the current user but elevated with admin privileges (our users are not admins). The executable will get the currently logged in username and check an online service if the username exists. I’ve been trying to figure out the correct usage of RunAs but can’t seem to get it right.

If I use:

override wait 
runas=currentuser 
completion=job 
hidden=true 

The app asks for admin credentials.

If I use:

override wait 
runas=localuser 
completion=job 
asAdmin=true 
password=required 
user=.\localadmin

The app reports that the current user is .\localadmin (instead of the current user).

I also tried:

override wait 
runas=currentuser 
completion=job 
asAdmin=true 

But the command failed with: “The keyword ‘AsAdmin=true’ can be used when both RunAs=localuser and Password=required are specified.”

Locally, if I open a command prompt as admin but authenticate with the local (non-admin) user’s credentials, then run the app, it produces the desired output. I’m still not quite sure how I’m able to authenticate with a standard user’s credentials here so that just adds to my confusion.

Is it possible to do what I need to do and how? Thanks in advance!

[akira]

As the message indicated, you cannot use RunAs=CurrentUser and AsAdmin=true in the same override.
To run a command in the context of an user who is not a member of local Adimistrators group yet with elevated Admin privileges, you could do:

override wait 
runas=localuser 
asadmin=true 
password=required 
user=(userid you want to run the command with)

You need to have the password of that user to submit action.

[jriv]

I see. So since I am planning to run this on all of my user endpoints, it does not seem like it will be possible. Thank you, @akira.

[JasonWalker]

Yes, that’s pretty central to the Windows security model.
We can run things as LocalSystem (our default), or we can run as the logged-on user using their existing security token, but in order to elevate them we have to build a new logon token for them - which requires their password.

We can also run in LocalSystem context but display the user interface on their desktop - which has obvious security implications and should be avoided.

You may be able to refactor your operation into separate steps - part of the action would run in user context (non-elevated) to retrieve the user info pieces and store the result, and another command running in the default LocalSystem context to read the results and update whatever needs to change on the machine.

[JonL]

There can also be some creative ways to side-step an issue like this such as creating a scheduled task on your endpoint where you can specify alternative credentials in a task template. The credentials would be stored in Windows Credential Manager for the scheduled task to leverage. We’ve used this approach in some situations with success.

Another creative way is elevating with something like PSexec utility.

In either case, proper transmission, handling, and disposal of sensitive password data is crucial. There are many other posts that detail both mainstream and alternative approaches to that part.