From regular user to elevated administrator...

• PowerShell Studio
• HowTo
• PrimalScript
• Windows PowerShell

User Rating: 5 / 5

This is a question that comes up fairly often in our support forums, so I thought I would post a quick overview. The scenario is that an admin wants to package his script as an executable to allow regular users to accomplish some type of task, which requires full administrative privileges.

Since Windows Vista, the administrator security token is split, meaning that you cannot just logon as admin and do what you need to do. An admin must elevate in order to accomplish certain tasks.
This was done because many users logged on as administrators on their local machine, leaving it vulnerable to any malware they ran by accident. Now you need to verify elevation to full admin rights when accessing or modifying certain system areas. What does this mean for packaging executables? PowerShell Studio and PrimalScript have a number of options when packaging a script as an executable, including RunAs, Impersonation and Elevation. Many users simply think to enter credentials and select “RunAs” in addition to using a manifest with elevation.

Unfortunately it does not work that way. You cannot successfully use both options at the same time.

Bonus question: What is the difference between RunAs and Impersonation?

Impersonation changes the security token of the current process to that of another user while leaving the environment of the current user intact. RunAs acts as if the specified user logged on and will load the complete environment for that user.

Now back to the main question. In order to understand why RunAs or Impersonation and Elevation cannot be used at the same time, we need to examine how they work.

When selecting RunAs or Impersonation, the specified credentials are stored inside the packaged executable. They are of course stored encrypted. When the executable is launched it will use certain API calls to create a new security token or run itself with the specified credentials. The important part here is that the executable needs to be loaded and run for this to happen. When you select a manifest with elevation, the manifest is embedded in the executable as well. Unencrypted by the way, since Windows needs to read this information. The difference is, Windows will load and evaluate this manifest before any code is executed. If you run this from a regular user, you will be prompted for admin credentials and to verify elevation. The credentials stored inside the package have no effect at this point because they would only be applied after the fact.

So, the important part is, due to the way Windows evaluates manifests, elevation happens before RunAs. But you want it the other way around to avoid prompts and giving regular users admin credentials.
In order to accomplish this you need a two step process:

1. Use a little script packaged as an executable that we call “starter.exe”. We add credentials and RunAs or impersonation to that. What is in the script you package there? Nothing else but an instruction to launch your actual application.
2. Your actual script packaged as an executable with a manifest for elevation.

So, step 1, starter.exe is launched and uses the admin credentials you provided. Step 2 then is your application with elevation. Depending on your local settings you may get a prompt to allow your app to modify your system, but it will not prompt you for actual credentials.

• Prev
• Next