Run as Elevated Admin from Standard User Account

[AmbientMike]

AmbientMike. Are you in a domain environment trying to run an application on an end users machine as an admin?

Yes, however I don't really have a lot of access to the domain stuff but work reasonably closely with the team that do...

[jazzyjeff]

Ok, so I have a script that is basically an internal App Store for our School. The first script runs the 2nd script as another user, then the 2nd script has a #RequireAdmin tag at the top to have the script run elevated. The user that is specified to run the script has to have local admin rights for the elevated privileges to work on the second script.

Along with this, you will need to have the registry modified. This is where there could be some manual intervention on the end users machine.

HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableInstallerDetection. Make sure this key is set to 0.

here is some info about that key:

http://msdn.microsoft.com/en-us/library/cc232763.aspx

Modifying this key will require admin rights.

Once this key is set, anything you run as an admin will run elevated for even a standard user.

Here is an example:

Create password key:

#include <Crypt.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
_Crypt_Startup()
$password = InputBox("Password", "Please enter the password you would like to encrypt to a key", "", "*")
$encrypted = _Encrypt("password", $password) ; DO NOT FORGET TO REMOVE THIS LINE
_Crypt_Shutdown()
#region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Encrypted Password", 507, 61, 192, 124)
$Input1 = GUICtrlCreateInput($encrypted, 8, 32, 489, 21)
$label = GUICtrlCreateLabel("Encrypted Password:", 8, 8, 104, 17)
GUISetState(@SW_SHOW)
#endregion ### END Koda GUI section ###
While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd
Func _Encrypt($sKey, $sData)
Local $hKey = _Crypt_DeriveKey($sKey, $CALG_AES_256)
Local $bEncrypted = _Crypt_EncryptData($sData, $hKey, $CALG_USERKEY)
_Crypt_DestroyKey($hKey)
Return $bEncrypted
EndFunc ;==>_Encrypt

Script 1:

#include <Crypt.au3>
_DecryptPW1()
RunAs("username","Domain.com",$sPW,0,"C:\Script2.exe")
Func _DecryptPW1()
_Crypt_Startup()
Global $sPasswordCT = '0x12345678901234567890' ;Enter password here
Global $sPW = ''
$sPW = _Decrypt("password", $sPasswordCT)
_Crypt_Shutdown()
EndFunc ;==>_DecryptPW1
Func _Decrypt($sKey, $sData)
Local $hKey = _Crypt_DeriveKey($sKey, $CALG_AES_256)
Local $sDecrypted = BinaryToString(_Crypt_DecryptData(Binary($sData), $hKey, $CALG_USERKEY))
_Crypt_DestroyKey($hKey)
Return $sDecrypted
EndFunc ;==>_Decrypt

Script 2:

#RequireAdmin
Run("C:\ElevatedScript.exe")

Now the encrypted key password is not going to be crack proof, but it was more for preventing someone else from casually seeing the password.

I have Robjong to thank for getting that function:

So without that registry setting set to 0, I was still being prompted for the UAC controls. Microsoft recommend that it is set to 0 in a domain environment.

I hope this helps and/or makes sense.

Edited January 18, 2013 by jazzyjeff

[AmbientMike]

So ignoring all the encrypted password stuff all it is really doing is RunAs() and #RequireAdmin but the key is to set the reg key to 0 of the following key...

HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableInstallerDetection

And what is the status of the following reg key on your systems? 0 or 1?

HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA

The Microsoft link you gave states that it is for package installation. Does this work for running batch files, scripts etc or just for installer packages?

Edited January 18, 2013 by AmbientMike

[jazzyjeff]

The default value on Windows 7 is 1. When in a domain environment it is recommended to set that value to 0. This doesn't turn off UAC.

Oh I forgot. I also change this reg key too, to suppress UAC prompts for Admins only.

HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemConsentPromptBehaviorAdmin

The status of EnableLUA is 1, so UAC is enabled.

This works for batch files, VBS scripts, exe, msi. Anything!

Edited January 18, 2013 by jazzyjeff

[AmbientMike]

Cheers - I will take a look and see if that works for me in WIndows 8. I suspect that for my purposes running these 2 small objects as SYSTEM may actually be safer than using encrypted admin passwords where the hash can be found through decompilation. Our admin password is pretty insane so would take a looooong time to decypher it though.

[marg]

Hi AmbientMike, did you find the solution?

I have similar problem: different behavior on Win 7 / Win 8.

Check this script:

RunAs($AccountLocalName, $AccountLocalDomain,  $AccountLocalPassword, 0, @ComSpec & " /k")

on Win7: Elevated (Administratror) command promt is opened
on Win8: NOT-elevated command promt is opened

How can I easily (without changing any registry/system settings) run elevated command prompt on Win8?
Thank you.
 

Edited July 23, 2013 by marg

[AmbientMike]

Sorry for dredging up my old topic but as I'm re-building my Windows 8 image from scratch using a Windows 8.1 Enterprise base I thought I'd let you know that I've managed to simplify things a bit this year managing to let users run a couple of commands as admin (well SYSTEM actually!).

One thing I noticed over the last year is that Microsoft tend to use Scheduled Tasks more often than just putting a shortcut into the startup folder these days it seems.  And last year for some reason I completely forgot about the great tool that is PSEXEC.  PSExec.exe needs to be in the Windows dir for this one...

So what I do is have an autoit script running as SYSTEM at PC startup via a scheduled task with "Run with highest privileges" enabled awaiting for two particular files to exist using the following little bit of script...

While 1

If FileExists ("C:\Temp\Reg") Then
    FileDelete ("C:\Temp\Reg")
    ShellExecute ( "C:\Windows\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c reg add 'HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' /v ExecutionPolicy /t REG_SZ /d RemoteSigned /f" )
    ShellExecute ( "C:\Windows\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start /min powershell.exe -windowstyle hidden C:\Windows\VS2012Configs\RegAccount.ps1" )
EndIf

If FileExists ("C:\Temp\UnReg") Then
    FileDelete ("C:\Temp\UnReg")
    ShellExecute ( "C:\Windows\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c reg add 'HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' /v ExecutionPolicy /t REG_SZ /d RemoteSigned /f" )
    ShellExecute ( "C:\Windows\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start /min powershell.exe -windowstyle hidden C:\Windows\VS2012Configs\UnReg.ps1" )
EndIf

sleep(10)

WEnd

Then I have two simple, one line scripts that can be run by someone with just user rights (everyone has modify rights to C:Temp)...

filewrite("c:\temp\Reg", " ")

filewrite("c:\temp\UnReg", " ")

Then for all intents and purposes the user has admin rights to run those two commands and those two only because PSExec is being called from System with the -d -e -i -s switches

-d  Don't wait for process to finish

-e  Don't load user profile

-i  Interacts with desktop

-s  Run as System account

No UAC, just "happy" users being able to do what they need to do as admin (and nothing more).

Edited April 1, 2014 by AmbientMike

[MyEarth]

Sorry but there is something i don't understand or you miss to write.

On a Stardard User, this script:

ShellExecute("C:\Windows\psexec.exe", "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start notepad")

Give me "Can't access to 127.0.0.1 - Access Denied"

This instead:

#RequireAdmin
ShellExecute("C:\Windows\psexec.exe", "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start notepad")

Work without any problem but using #RequireAdmin give me the UAC prompt. So if PsExec need admin right to work where is the "No UAC" solution?

Edited April 1, 2014 by MyEarth

[AmbientMike]

Sorry but there is something i don't understand or you miss to write.

On a Stardard User, this script:

ShellExecute("C:\Windows\psexec.exe", "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start notepad")

Give me "Can't access to 127.0.0.1 - Access Denied"

This instead:

#RequireAdmin
ShellExecute("C:\Windows\psexec.exe", "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start notepad")

Work without any problem but using #RequireAdmin give me the UAC prompt. So if PsExec need admin right to work where is the "No UAC" solution?

Well, in your script you're opening notepad - which all users can do.

The commands that I need to run will only work correctly as admin - they will launch as a user but will fail to make amendments to the computer as required.

Just putting #RequireAdmin at the top of a script and getting a non-admin user to run it will NOT grant them admin rights - it will just prompt for admin credentials which you're aware of.

Also I think you have misunderstood - I don't run the PSEXEC command as the user - it is run as SYSTEM (so I probably don't need the "-s" switch in there really) but is watching for a file to be dropped in a certain location by a non-admin user to run the command.  In the scheduled task that starts the main loop as SYSTEM it's set to run with highest privileges.

All the non-admin accounts are actually doing is creating a file in a location that the SYSTEM script is looking for and then running commands as required but visible to the logged in user.

Edited April 1, 2014 by AmbientMike

[MyEarth]

Notepad was only an example but i really miss the point.

The title of the thread is "Run as Elevated Admin from Standard User Account without prompt", if you have "solved" can you provide a working script, run example powercfg -setactive 123456789, that require admin rights, without any UAC prompt, from an standard account? The complete procedure please, including the scheduler task if is a part of the procedure.

Thanks

[AmbientMike]

I have provided my full scripts...

I'll try to flesh it out a bit more.  This is more of a way to leverage the power of PSExec rather than show the power of AutoIt.

PSExec is stored in my C:Windows directory

http://technet.microsoft.com/en-gb/sysinternals/bb897553.aspx

This script is run as a scheduled task "At startup" as the "SYSTEM" user, "Run whether user is logged on or not" and "Run with highest privileges" and not "Hidden"...

While 1

If FileExists ("C:\Temp\Reg") Then
    FileDelete ("C:\Temp\Reg")
    ShellExecute ( @WindowsDir & "\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start 'PUT YOUR 1ST COMMAND HERE'" )
EndIf

If FileExists ("C:\Temp\UnReg") Then
    FileDelete ("C:\Temp\UnReg")
    ShellExecute ( @WindowsDir & "\psexec.exe" , "-accepteula \\127.0.0.1 -d -e -i -s cmd /c start 'PUT YOUR 2ND COMMAND HERE'" )
EndIf

sleep(10)

WEnd

So this just sits looping in the background basically looking for one or either file to exist... C:TempReg or C:TempUnReg

I chose that location as I know that's a world-writeable scratch area we use but feel free to use any other directory as long as everyone has at least modify rights to it.

I have this script looking for two files as I need to only run two commands but you could have it look for any file and any number of items or look for one file but vary the contents and do a FileReadLine if desired.

Then I give the users their own scripts (doesn't even need to be an AutoIt script - a simple batch file will suffice but in my case I use two AutoIt scripts, each with one line in them...

filewrite("c:\temp\Reg", " ")

filewrite("c:\temp\UnReg", " ")

So the user simply creates a file in an area they have rights to and the script running as SYSTEM catches the existence of that file and runs a PSExec command as required.  In my case it runs a couple of PowerShell scripts that only work as an admin.

I hope that makes it a little more clear.

In truth, in writing this I think I've just figured out a way to do this with only Scheduled Tasks and cutting out AutoIt but it's too late to start thinking about that now.

Bear in mind that this DOES NOT run the command as the user (there is simply no way to run commands elevated to administrator by a standard user account as Windows cannot do it) instead it runs it as SYSTEM but visible to the user so anything that relies on modifying the user's profile files or registry then you will need to do a little more to check for the console user - but these commands can normally be run as the user anyway).  I don't recall if powercfg is per user or per computer but I'd presume it's per computer as you can only run one power profile at any one time so this should work without any modification as far as I'm aware.

Edited April 2, 2014 by AmbientMike

[MyEarth]

Ok, i have understood now. Thanks

[Tlem]

@AmbientMike

For my knowledge, when you launch the script with a right clic on it an you chose launch with admin right  what's going on?

Did he run correctly?

[AmbientMike]

@AmbientMike

For my knowledge, when you launch the script with a right clic on it an you chose launch with admin right  what's going on?

Did he run correctly?

 

A user in the admin group gets a UAC prompt and can continue with a click of a button but a non-admin user gets a UAC prompt with a username / password box that they don't know the details for.

[Tlem]

On the second case, if you put the Admin username / password on the box, the script run exactly like on a admin session?

[iamtheky]

1) our students CANNOT have admin rights as our ISP demands it.

2) We also have to have UAC enabled 

 

What about solving 1 instead of 2?  Being a limited user would suck in powershell, cant imagine the pain it will cause in VS2012.  In your solution you solve for one circumstance, when I can only imagine there would be tens if not hundreds of issues with UAC in a coding class?

How about log into the host as a limited user, log into VMs that they have admin rights on?

Suppose your ISP can actually detect level of access (and is small enough to have the time to be concerned); segment your class with a router with a ridiculous large NAT pool and set the leases low so they change with great frequency, or drop a NAC like packetfence and dont allow any queries in.  Or KonBoot those machines and let whoever reads those logs try and figure out that authentication.

Edited April 3, 2014 by boththose

[DigitalFacade82]

Seeming this thread is fairly recent I am going to reply. After reading the title straight away I realised that this is exactly what I have been looking for. Reading further through the thread I definitely know this is what I am looking for! Great topic.

Seeming as though (as the saying goes) 'many ways to skin a cat' I am posting to ask what best way to solve my issue would be if I play out the scenario. Although I think this would seem off topic to the OP and possibly AutoIT (depending on the response I guess?) I think it is relevant to others who are seeking solutions to similar problems.

Essentially for me it is to save problems of mounting "free work" as in those annoying fixes I need to do to PCs I have already built in the past due to the users having admin privileges and discovering after some period of time that the cause was likely a dodgy download or what ever, but had the ployed with the sympathy card.....to me.....to come fix the broken computer.......and it winding up with me wearing the cost as my time.....along with the post arguments of 'Well you didn't quote me that, I am not paying that but here is just a few bucks just to keep you happy'

What I am getting at is this: 1) My challenge is that removing administrator rights from users of their own PCs is not a viable solution due to the shoddy development of application developers Take for instance photoshop requiring admin privillages (negating if the user is doing full 3D rendering in like OpenGL or something like that - to which case they should be smart enough not to screw their own PC in the first place) then they don't bloody need it! Screw you developers! Yeah along with a crap applications writing huge packets of data to the program files directory....I could go on with the list of pet hates that will likely never be solved no matter how much I bitch or whinge to the companies that make these applications /END RANT
2) I would technically not be profiting of this directly only saving my self huge amounts of cost and lost time and many arguments.

Put simply at times I have learned to just shut my trap and "wear it" so to speak for the sake of keeping business. Sometimes I don't know what's worse for welbeing? Keeping in bottled up rage or actually expending the argument (proving I am right - which I hate doing but they push me there, they think I am not going to find out what user did what when..huh! watch me!) to the point of severing relationships in a big hot molten firey ball of mess.

Edited May 5, 2014 by DigitalFacade82

[bobmcrae]

It seems I have struggled with this topic for as long as this thread has been alive.  While I have been successful at elevating from a standard user without prompting for the admin password (I know that password) using a technique very similar to what jazzyjeff describes in post #22, I have found that this approach is entirely dependent on the version of AutoIT the elevating script is compiled with.  I have found that compiling with AutoIT v3.3.8.1 the elevating script properly elevates, but does NOT elevate when the exact script is compiled with AutoIT v3.3.14.1.  I would LOVE to understand why the same VERY SIMPLE code works in the earlier version of AutoIT.  Below is an example of what I am doing:

Standard User Script:

#include <File.au3>
#include <dependentFiles\SystemInfo.au3>    ; this is where $pw comes from

Global $pw, $reEXE = @DocumentsCommonDir & '\runElevated.exe'

FileInstall('dependentFiles\runElevated.exe', $reEXE, 1)
$CMD = 'time ' & @HOUR +1 & ':' & @MIN  ; set the clock forward an hour
runElevated($CMD)
Sleep(3000)
$CMD = 'time ' & @HOUR -1 & ':' & @MIN  ; set the clock back an hour
runElevated($CMD)



Func runElevated($CMD, $wait=False)
    Local $tmpBAT = _TempFile(@DocumentsCommonDir, Default, '.bat')

    ;~ A batch file is necesary in order to fully elevate (e.g., move command)
    FileWrite($tmpBAT,$CMD)
    If $pw = '' Then $pw = getPW()
    $pid = RunAs('Admin', @ComputerName, $pw, 0, $reEXE & ' ' & $tmpBAT, @SystemDir, @SW_SHOW, 8)

EndFunc ; runElevated()

Elevating Script (runElevated.au3):

#RequireAdmin
#NoTrayIcon
RunWait(@ComSpec & ' /c ' & $CmdLineRaw,@SystemDir,@SW_HIDE)

System details: Win7 HP; AUC: ConsentPromptBehaviorAdmin=0, ConsentPromptBehaviorUser=3 [I see that this should be =1, but that is mute]

 

Edited December 24, 2015 by bobmcrae

[TheAppleFreak]

While I don't have a native AutoIT answer to this question, someone pointed me to a third party utility aptly called elevate, which accepts a command and runs it with full administrative permissions. From my (limited) testing with the application, it seems to work exactly as described.

[iamtheky]

I cant imagine a case where I would want a normal user to have the ability to elevate themselves with stored credentials.  What problem do you believe you are solving, that you are not also making larger with the solution?  

Essentially:

You dont want to give them their own key to the door. So you bust a hole in the wall, so they can go in and get your key, and then you make them go back out that big hole in the wall, and use your key to come in the door.