The directive was simple: Build some sort of tool that could perform an installation similar to what ‘sudo’ does on Linux in a limited user session. There is literally nothing like this for Windows that performs in any sort of automated fashion. also, given I know the administrative password of the local machine, there should be a way to give a user an installer that perform an installation I need?

Here’s a simple example:

I want to automate the installation of the latest ConnectWise Control / Screenconnect tool in a limited user context. For this I use two tools primarily. You’ll need to download the great Sysinternals tool pesexec64 and the Nullsoft Install System for 64bit. In my case, I want to stay native 64bit, but you could do all this with 32bit tools too. I use psexec to launch with admin credentials and I use NSIS to wrap the process and potentially include installer files if needed. Naturally, create an installer for ConnectWise Control and save that too.

I then setup a basic folder structure:
\Work
— \Runadmin
— \Root

In the ‘Work’ folder, I’ll place my NSIS script. Just create a basic text file and set its extension to .nsi. In my example I’ll call it runadmin.nsi. Next, place the psexec64.exe and Connectwise.Control.exe (which I’ve renamed to rds.exe for ease of use). files in the ‘Root’ folder. Great, that’s the basic structure.

The following is my .nsi script. Change the adminuser and adminpassword to suit your needs:

!include "MUI2.nsh"

!define OutFileName "example.exe"
!define ProgramName "Runadmin"

Name "Runadmin x64"
OutFile example.exe
CRCCheck off

!insertmacro MUI_PAGE_COMPONENTS
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE "English"

!insertmacro MUI_UNPAGE_CONFIRM
!insertmacro MUI_UNPAGE_INSTFILES

ComponentText "This will install the Application on your computer."
DirText "Please select a location to install Runadmin (or use the default). The install directly will be deleted so backup important files or scripts!"
AutoCloseWindow True 

InstallDir C:\runadmin
RequestExecutionLevel user

Section "Program Files (required)"
SectionIn 1
SetOutPath $INSTDIR

File /r root\*.*  

Exec "reg.exe ADD HKCU\Software\Sysinternals /v EulaAccepted /t REG_DWORD /d 1 /f"
Exec "reg.exe ADD HKU\.DEFAULT\Software\Sysinternals /v EulaAccepted /t REG_DWORD /d 1 /f"
Exec "$INSTDIR\psexec64 -accepteula -d -u AdminUser -p AdminPassword $INSTDIR\rds.exe"
sleep "500"
SectionEnd

Section Uninstall

SectionEnd

Most of those directives are what’s needed to build a basic installer, but there are a few important statements to note.

InstallDir C:\runadmin is a result of compromising on file access issues (I’ll get into that more later)

RequestExecutionLevel user is crucial for making the installer run int he context of a cureent lmitded user. Without this, NSIS will expect to be elevated and fail.

Exec “$INSTDIR\psexec64 -accepteula -d -u AdminUser -p AdminPassword $INSTDIR\rds.exe”

This is where everything happens. Psexec will launch the rds.exe process in the context of your provided administrator user. You’ll notice also that a pause is added (sleep “500”). You might think it’s possible to add multiple of these statements if you’re unsure of the exact admin password combination and you’d be right. I’ve used up to four Exec statements and when the right password hits, the command runs.

File Access

So psexec64 is working for me with the built-in administrator account, but for some reason when I’ve created a second administrative account, running psexec64 yields an “Access is denied” error. This stumped me for some time. I started thinking, this might be some sort of user right assignment? There’s somethin special in that administrator account? Well, it turns out this was far simpler. When the limited user downloads to her “Downloads” folder, that folder is not accessible to newly created administrator accounts by default. My solution to this? Create a folder in the context both accounts can access. Thus, I run the install and drop the files needed to c:\runadmin

What could you do with this?

Of course, the intention of this is not for hacking. Yes, you do need a domain or local administrator password. This isn’t going to circumvent that. But in environments were prepackaged machines need to have software installed, yet you as the admin cannot provide the administrative password; this tool can be provided to the user and that software installed in an automated manner.

Security, Security.

So, if you’ve read this far, your eyeballs are probably burning. You’re thinking “Hardcode the administrative password, are you nuts? Talk about giving it all away?!” In all these respects, you are correct. While this is nothing more than a proof of concept and the NSIS-complied installer does not have the password stored in plain-text, this does not mean it is safe for production use. To use this in your environment, I’d suggest further encrypting the password in the script while also self-signing the installer itself.