Windows + UAC + RunAS

[colombeen]

Hi guys

has anyone here had this problem : UAC is enabled on your Win7 machine, you need to run an application as a different user, but since UAC is enabled the popup for elevation doesn't appear and so... nothing happens... I'm wondering if it could be fixed with autoit script (instead of just using runas.exe from MS)

 

I'd like to create a script that uses startup params (passthrough) so that I could provide user, pass, app and make it start elevated.

anyone who has made something like this already? is it even possible? like say starting a HTA file under a different account but also elevated (without the right click, run as different user)

 

thx

colombeen

 

with other words, i'd like to make a working replacement for Microsoft their RunAs.exe app

Edited May 3, 2016 by colombeen

[JLogan3o13]

@colombeen If you need to pass params at launch, you can always do the two-script hop, something like this:

 

expandcollapse popup

#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <MsgBoxConstants.au3>

    $hGUI = GUICreate("Run External App as Different Users", 600, 370)
        GUISetState(@SW_SHOW)
        GUISetFont(14, 400, Default, "Arial")

    $lblUser = GUICtrlCreateLabel("UserName", 10, 5, 100, 20)
        GUICtrlSetFont($lblUser, 11, 600, Default, "Arial")
    $inpUser = GUICtrlCreateInput("", 10, 25, 580, 40)

    $lblDomain = GUICtrlCreateLabel("Domain", 10, 85, 100, 20)
        GUICtrlSetFont($lblDomain, 11, 600, Default, "Arial")
    $inpDomain = GUICtrlCreateInput(@LogonDomain, 10, 105, 580, 40)

    $lblPassword = GUICtrlCreateLabel("Password", 10, 165, 100, 20)
        GUICtrlSetFont($lblPassword, 11, 600, Default, "Arial")
    $inpPass = GUICtrlCreateInput("", 10, 180, 580, 40, $ES_PASSWORD)

    $lblFile = GUICtrlCreateLabel("Choose file to run", 10, 245, 180, 20)
        GUICtrlSetFont($lblFile, 11, 600, Default, "Arial")
    $inpFile = GUICtrlCreateInput("", 10, 260, 580, 40)

    $btnLaunch = GUICtrlCreateButton("Browse", 10, 320, 80, 40)
    $btnGo = GUICtrlCreateButton("Run", 510, 320, 80, 40)

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                Exit
            Case $btnLaunch
                $sFile = FileOpenDialog("Browse for File", @ScriptDir, "Exe (*.exe)")
                GUICtrlSetData($inpFile, $sFile)
            Case $btnGo
                If $inpFile <> "" Then
                    RunAs(GUICtrlRead($inpUser), GUICtrlRead($inpDomain), GUICtrlRead($inpPass), 0, GUICtrlRead($inpFile))
                Else
                    MsgBox($MB_SYSTEMMODAL, "Run External App", "Please specify the file first")
                EndIf
        EndSwitch
    WEnd

 

[colombeen]

22 minutes ago, JLogan3o13 said:

@colombeen If you need to pass params at launch, you can always do the two-script hop, something like this:

 

expandcollapsepopup

expandcollapse popup

#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <MsgBoxConstants.au3>

    $hGUI = GUICreate("Run External App as Different Users", 600, 370)
        GUISetState(@SW_SHOW)
        GUISetFont(14, 400, Default, "Arial")

    $lblUser = GUICtrlCreateLabel("UserName", 10, 5, 100, 20)
        GUICtrlSetFont($lblUser, 11, 600, Default, "Arial")
    $inpUser = GUICtrlCreateInput("", 10, 25, 580, 40)

    $lblDomain = GUICtrlCreateLabel("Domain", 10, 85, 100, 20)
        GUICtrlSetFont($lblDomain, 11, 600, Default, "Arial")
    $inpDomain = GUICtrlCreateInput(@LogonDomain, 10, 105, 580, 40)

    $lblPassword = GUICtrlCreateLabel("Password", 10, 165, 100, 20)
        GUICtrlSetFont($lblPassword, 11, 600, Default, "Arial")
    $inpPass = GUICtrlCreateInput("", 10, 180, 580, 40, $ES_PASSWORD)

    $lblFile = GUICtrlCreateLabel("Choose file to run", 10, 245, 180, 20)
        GUICtrlSetFont($lblFile, 11, 600, Default, "Arial")
    $inpFile = GUICtrlCreateInput("", 10, 260, 580, 40)

    $btnLaunch = GUICtrlCreateButton("Browse", 10, 320, 80, 40)
    $btnGo = GUICtrlCreateButton("Run", 510, 320, 80, 40)

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                Exit
            Case $btnLaunch
                $sFile = FileOpenDialog("Browse for File", @ScriptDir, "Exe (*.exe)")
                GUICtrlSetData($inpFile, $sFile)
            Case $btnGo
                If $inpFile <> "" Then
                    RunAs(GUICtrlRead($inpUser), GUICtrlRead($inpDomain), GUICtrlRead($inpPass), 0, GUICtrlRead($inpFile))
                Else
                    MsgBox($MB_SYSTEMMODAL, "Run External App", "Please specify the file first")
                EndIf
        EndSwitch
    WEnd

 

And will this work when the app you try to run requires elevation (=> UAC is enabled and needs to stay enabled)?

[AdamUL]

Does the user that you are trying to run the application under have permissions to request elevation (Admin Token) e.g in the local Administrations group?  If not, this would not be possible without doing some workaround, such as:  Add the user to the local Admin group, run the application requesting the Admin Token as the user, remove the user from the local Admin group when the application is closed.  To do all this, would require an Admin account to initially run the script.  A local Admin account would be the preferred method.  

Also, for the admin accounts to not be prompted by a UAC login, ConsentPromptBehaviorAdmin would need to be set to $UAC_ELEVATE_WITHOUT_PROMPTING (0).  Without this being set, the script will not run correctly, and you will have a UAC prompt waiting.  Have a look at my UAC UDF for reading and changing UAC settings.  

 

Here is an example using re-execution to get a script to have the Admin Token.  I could be reworked to do what you are trying to do.  You could then add ShellExecute or Run to the end of it to start what ever you would like.  

 

 

Adam

 

 

[jdelaney]

You can use PAEXEC to start a process as the system user (with elevated permissions) and run it on the user's session.  They would not be able to interact with it though.

I recently created a little app that does what I just mentioned, and there is another non elevated app that just runs in the systray, that can communicate (file transfers) to the elevated app.  That way, the user can 'interact' with it (start jobs).  The elevate app can then still see all the handles on the users session.

Edited May 4, 2016 by jdelaney

[colombeen]

in my case i normally use a shortcut that uses runas to start our active directory (C:\Windows\System32\dsa.msc)

but ever since UAC was enabled it doesn't work anymore. i need to shift + right click on the app directly and click on run as a different user.

that's my issue with alot of apps ever since the UAC change and I was hoping that there was a fix for that

[colombeen]

On 3-5-2016 at 5:46 PM, AdamUL said:

...

 

Hi Adam, i'm just wondering... if I call a bat file from an elevated autoit script, will the bat file also be elevated of will it still need it's own UAC elevation?

Edited May 4, 2016 by colombeen

[BrewManNH]

Please don't quote the whole post, just to add one line of text. just use the "Reply to this topic" button, or reply in the editor box at the bottom. We already know what the other person wrote, so there's no need to repeat the whole thing.

[AdamUL]

The BAT file will be run under elevation of the current user, if they have the rights to request elevation, that ran the script.  Do you have an idea of what you would like to try?  

Adam

 

 

[colombeen]

23 hours ago, AdamUL said:

The BAT file will be run under elevation of the current user, ...

one of the things that I'd like to make work again is:
I created a replacement app for Active Directory that also has some extra buttons to directly access computer management, printer management, ...
The AD app requires a different account then the current logged on user, so that app is started as a different user, the app is also elevated for UAC shizzle.
When I try to start the computermanagement msc it won't start anymore ever since UAC was enabled, because it requires it's own elevation and with that other account it just can't pop-up the notification.

another one is this :

I have an autoit script that now dynamically shows scripts placed in a specific directory (network location). the app is elevated.
Most of the scripts that it shows are bat or vbs files that change settings in the registry, stop/start/restart services on the system, ... (which requires elevation as well)
I need to know how to fix that when my bat/vbs files are called they won't fail because of the UAC elevation notice not popping up.
the usage of bat files etc is so that everyone of my co-workers can add stuff to it without needing to change the GUI (autoit script that only shows the files and starts them)...
in this case no other user required

i could give more examples but i think this will suffice

Edited May 5, 2016 by colombeen

[jdelaney]

So what's the problem...you either tried it, and know it works, or you tried it and have a specific question because it didn't work.

The question posted is more a call for someone to test for you.

[colombeen]

@jdelaney: at this point I've tried fixing the second part on my last post (batch files/vbs files called from elevated autoit script) but at this point I can't find a way to elevate whatever I call that doesn't ask for elevation by itself (like a bat file)

that's the most important one at this point

[AdamUL]

Is the account that the AD tools run under in the local Administrators group on the PC that you are running them on?  If not, that is why it will not work.  Windows will not allow elevation on an account this is not a local admin.  Please read up on UAC.  

If you are just running the script under your account, and not another account.  To cause the script to be elevated, you need to have one of the following at the top of your script.  Remember any account that you want to run a process elevated, it must be in the local Administrators group on the PC, either explicitly or in a group.  

;Re-executes the script, requesting elevation on the script's first run.  Script can be compiled or not compiled. 
#RequireAdmin

;Adds a request for elevation in to the EXE manifext when the script is compiled using Aut2EXE.
#pragma compile(ExecLevel, requireAdministrator)

;Adds a request for elevation in to the EXE manifext when the script is compiled using AutoIt3Wrapper installed with SciTE4AutoIt3.
#AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator

Also, you can make a process request elevation using ShellExecute or ShellExecuteWait with the "runas" verb from a non-elevated script.  This will run under the user that started the script.  If the user is not allowed to request elevation, it will prompt for credentials.  Here's some examples.  

;Elevated Command Prompt.
ShellExecute(@SystemDir & "\CMD.exe", "/k", "", "runas", @SW_SHOW)

;Elevated ADUC.
ShellExecuteWait(@SystemDir & "\dsa.msc", "", "", "runas", @SW_SHOW)

;Elevated BAT file.
ShellExecuteWait("C:\BAT Files\File.bat", "", "", "runas", @SW_SHOW)
ShellExecute("\\server\share\BAT Files\File.bat", "", "", "runas", @SW_SHOW)

Hope that helps.

 

Adam

 

[Daymond]

I am attempting to do something similar, as I have an application that now needs to run elevated (camera software) while the users aren't permitted to have local admin on the PCs. I need to write a script that will run the application elevated (smartpss.exe), but leave UAC enabled and give only that application elevated permissions. I would have thought that I could easily write this script using the RunAs command and having that login as an administrator, but have discovered that RunAs doesn't fully elevate the app, and in my case doesn't even launch the application unless I run the script as administrator, which of course gives the user the UAC Prompt still and defeats the purpose of my script. Of course the script will be compiled and coded to prevent key/mouse input while the script is running, to prevent the user from pulling up something like Notepad to capture the login information. Any other suggestions? I will definitely look into the User Account Control (UAC) UDF created by AdamUL (Thank you Adam, this will probably come in handy for other scripts as well.)