[Solved] Run script without elevation/admin and launch program that requires elevation/admin

[SleeperSec]

I've tossed this issue around several times and Googled it, coming up with the following as the most relevant result:

http://www.autohotkey.com/board/topic/9 ... -as-admin/

However, the solutions presented do not fit my criteria. I deal with break-fix repairs in IT and therefore run my script on any number of platforms from XP to W10, with and without UAC, and of course different usernames and passwords.

I need to:
Run the main script without admin privilege, on a system with or without UAC enabled. edit: While logged in as an administrator account.
Launch a program with admin privilege from within that script. Specifically, command prompt with elevated permissions. The script should present a UAC prompt for elevation of the command prompt.

Restrictions:
Must run without AHK installed, as a compiled script.
Main script must run without elevation.
Usernames and passwords vary, so hardcoding isn't an option.
Prompting for username and password is tedious and undesired.
Creating a new admin account with a set password is undesired.
Running programs through task scheduler is undesired.

Expected behavior:
I would like to have the option to run command prompt with elevation and without. My main script presents two options- "Command Prompt" and "Command Prompt (Admin)". One should open without elevation and the other should present a UAC prompt for elevation. This is identical to the behavior of the Quick Access Menu (Win+X) present in Windows 8 and up.

[tank]

EXACTLY HOW ARE YOU PLANNING ON RUNNING AS ADMIN WITHOUT ADMIN CREDENTIALS?

[SleeperSec]

THE SAME WAY EVERY OTHER PROGRAM RUNS AS ADMIN WHILE LOGGED IN AS ADMIN. Do we really have to yell?

I guess I wasn't clear- I am always on an administrator account, without exception. Therefore, all I need is a UAC prompt with a simple Yes/No to elevate a program.

[megnatar]

To start a program with alleviated privileges using AHK, use code.

Code: Select all

Run *runas cmd

Or the current script:

Code: Select all

Run *runas "%A_ScriptFullPath%"

AHK is very well documented. This code above is explained in the manual

It's also possible to create a registry key to accomplish this, This will be the context menu when right clicking a directory, but you can apply this to whatever object you need. The key "RunAs" will initiate the alleviated privileges. No need for %*

Code: Select all

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Classes\Directory\shell\runas]
@="Run CMD as Admin"
"icon"="\"%Systemroot%\\System32\\cmd.exe\""

[HKEY_CURRENT_USER\SOFTWARE\Classes\Directory\shell\runas\command]
@="cmd.exe /s /k pushd \"%V\""

How UAC works is determined by how you setup group policy's in you're domain or local machine. They are eventually written to the registry.

User:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy
Machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy

You could use AHK's RegWrite command to change these settings to you're likings.

I think this should get you going.

Greets,
Megnatar

[tank]

you cannot run as administrator unless the current user is administrator. Elevation like you cited only works if the actual current thread owner is in fact an administrator

[megnatar]

No not really true, you can use runas as if it was su or sudo, but you need a password. Unless you're admin blocked the execution of runas as a user...

Anyway, you can specify this password in you're script. Once compiled and compressed it will be stored securely in the .exe.

See start->run
cmd /K runas /?

I used this method all the time when helping some user with no privileges in a windows environment.

[lexikos]

Run the main script without admin privilege, on a system with or without UAC enabled.

That seems to imply you're not logged in as an administrator. It is not trivial and generally not sensible to run a script without admin privileges while logged in as an administrator on a system where everything runs with admin privileges by default.

Usernames and passwords vary, so hardcoding isn't an option.
Prompting for username and password is tedious and undesired.

If you're logged in as an administrator, Run *RunAs will elevate with only a confirmation prompt on most systems with UAC enabled. If you're already running as admin (as you would be if logged in as administrator on Windows XP), you can just avoid calling Run *RunAs.

However, the solutions presented do not fit my criteria.

How so? Specifically the DllCall(ShellExecute, ...) part, which is equivalent to Run *RunAs.

Once compiled and compressed it will be stored securely in the .exe.

I wouldn't call that "secure". It will merely add the need to decompress the exe before inspecting the password.

[SleeperSec]

Ha. I missed the glaring version requirement on the runas verb.

Updated AHK and now basics like Run *runas cmd work. I was previously on 1.048 or some such.

Now, about parameters.

Running cmd by itself is fine.

But something like

Code: Select all

HibernateOff:
	Run, *runas powercfg -h off
return

produces

Code: Select all

---------------------------
Script.exe
---------------------------
Error:  Failed attempt to launch program or document:
Action: <powercfg -h off>
Verb: <runas>
Params: <>

Specifically: The system cannot find the file specified.



	Line#
--->	213: Run,*runas powercfg -h off

The current thread will exit.
---------------------------
OK   
---------------------------

I've seen this issue in another thread.. let me search for it.

This is what I was thinking of: http://www.autohotkey.com/board/topic/9 ... -as-admin/

Anyway, you can specify this password in you're script. Once compiled and compressed it will be stored securely in the .exe.

Not an option, usernames and passwords vary per computer.

So my issues now:

Request elevation on programs with parameters. Such as [/b]Run, *runas powercfg -h off[/b]. I see that the parameters aren't properly getting processed into the "Params" section on the error message, instead bundling the params with the action. I've tried double quotes on powercfg and parameters and double quotes just on the parameters, no dice.

Even when I run a command prompt with elevation (Run *runas cmd.exe), I am not able to start sfc /scannow from the elevated console. I get "Windows Resource Protection could not start the repair service." Yet if I go to explorer and start an elevated command prompt, I can start the scan without a hitch. Interesting.

[lexikos]

AutoHotkey v1.1 splits the executable name and parameters like this:

• If there is a known verb (properties, print, etc.) or custom verb (*something), exclude it from the logic below.
• If the command begins with a double-quote ("), use everything up to the next double-quote as the executable name. Otherwise:
• Look for a known executable extension, such as .exe. For instance, Run *Runas cmd /k echo .exe foo will try to use cmd /k echo .exe as the executable name.
• Try each substring from the beginning of the command to each space, until a file is found in the working directory. This does not search the directories specified by the PATH env var.

Run cmd /k echo .exe and similar will work because they pass the entire command line to the CreateProcess() system function. When you specify a custom shell verb such as *RunAs, AutoHotkey has to split up the command line and pass the command and parameters separately to ShellExecuteEx(). Therefore, you must write the command line in a way that allows AutoHotkey to recognize where the command ends and the parameters begin.

Code: Select all

Run, *runas powercfg.exe -h off

AutoHotkey v1.0.48 is less smart about the command line; iirc, it ignores quote marks and just looks for known extensions, such as .exe and .bat.

[SleeperSec]

Thanks for the breakdown.

So all I was missing was the exe. Lazy coding strikes again! I'll try again tomorrow.

Even when I run a command prompt with elevation (Run *runas cmd.exe), I am not able to start sfc /scannow from the elevated console. I get "Windows Resource Protection could not start the repair service." Yet if I go to explorer and start an elevated command prompt, I can start the scan without a hitch. Interesting.

Any idea on this? Elevated yet.. not?

[lexikos]

No. Works just fine for me.

[SleeperSec]

Seems my issue is 32 vs 64 bit versions of the command prompt.

Command prompt via AHK opens the cmd located in C:\Windows\SysWOW64\cmd.exe...

Whereas manually opening an elevated command prompt uses the expected C:\Windows\System32\cmd.exe.

Even explicitly stating to use %windir%\system32\cmd.exe opens the SysWOW64 version. I suppose it has something to do with my compiled script running as a 32 bit program?

Here (http://www.autohotkey.com/board/topic/3 ... utohotkey/) lexikos recommends to use Sysnative. Reading the documentation he linked to (https://msdn.microsoft.com/en-us/library/aa384187.aspx) states If the access causes the system to display the UAC prompt, redirection does not occur. Instead, the 64-bit version of the requested file is launched. This is not the behavior I am experiencing. I receive a UAC prompt but am still redirected to the SySWOW64 version.

Following that thread a bit farther down, using another of lexikos' examples lets me run the proper cmd:

Code: Select all

	DllCall("Wow64DisableWow64FsRedirection", "uint*", OldValue)
	Run, *runas %windir%\system32\cmd.exe
	DllCall("Wow64RevertWow64FsRedirection", "uint", OldValue)

[lexikos]

I can confirm that on Windows 10 with AutoHotkey 32-bit, Run *RunAs cmd.exe and Run *RunAs %A_WinDir%\System32\cmd.exe both launch the 32-bit cmd.exe. Unfortunately, the "redirection does not occur" part does seem to apply to SysNative; i.e. it doesn't work.

[SleeperSec]

Good to have the confirmation.

It's not as elegant as I'd like, but the Dllcall posted above fixed the issue for me on all platforms vista and newer. I am now running all admin actions without issue. Thanks for the assistance.

[Zask3333]

Would it be technically possible to make the remote administration tool by automatically clicking the mouse coordinates of the run button when regularly requesting
for administration?

[eladkarako]

My program was Locate32, which refused to write the DB files,
unless was either started on-startup (automatically by explorer.exe),
or by right-clicking, run as admin.

I have problems running exes through AutoHotKeys,
I've tried a lot of stuff, embedding a manifest that says to run it as admin,
and even the *RunAs as explained above. I even null'ified the permissions an ownership for all the files in the systems to have full execute/read/write/taking ownership to 'everyone' user. I even wrote a small VB6 application that uses shell command inside. Nothing worked.

Finally I've wrote a Locate32.cmd with this content below, and placed it in my Locate32 program-folder,

Code: Select all

@echo off
chcp 65001 2>nul >nul
pushd "%~sdp0"
start /B /MAX /ABOVENORMAL "cmd /c "call locate32.exe
exit /b 0

I have a program called WinKey (named after a legacy program I've used to had),
and added the following line:

Code: Select all

#+l::         Run   D:\Software\Locate32\locate32.cmd

it seems to be working well.