RunAs admin needs to be run as Admin to work :P

[cowsmanaut]

So, it's been a few years since I posted here, I've not had to use Autoit the past few years.. and I'm a bit sluggish getting back into it.

I've searched and found people trying to do something similar to what I'm doing here, but I'm loath to do anything I'm not certain of. I've tested this icalcs from CMD locally and it works for me as admin but when I try to get autoit to RunAs me it fails..that is unless I try to right click 'run as admin'.. which defeats the purpose of the script trying to elevate the user.

The goal is to elevate permissions by using my login, for the temporary purpose of unlocking the permissions of this folder, however my intent is to use it for other things such as running updates for software we've authorised. This way the user can run the updates we allow, but still cannot install anything else.

 

; Run with elevated permissions to allow all users access to autodesk 
folderRunAs("USERNAME", @ComputerName, "PASSWORD", 2, @ComSpec & " /c " 
& 'icacls.exe "C:\Program Files\Autodesk" /grant users:(OI)(CI)F', 
@DesktopDir, @SW_SHOW)

So, again it runs just fine if I run as admin via right click in windows.. but the point is to avoid that.. anyone have any ideas? I'd changed from @SystemDir to @DesktopDir because it said the working dir had to be something they had access to.. and they don't have access to anything but D:/ and I figured at the least they would have access to their own desktop..
 

[BrewManNH]

How is it failing, what error message are you getting when you run it, that is if it's running at all of course?

[cowsmanaut]

it gives no error, the CMD pops up and then goes away instantly, I know it's failing because the rights to the folder are not changed. Also when I right click the script to run as admin, the CMD pops up and runs it's function which takes a fair bit of time (there are a lot of files and folders in there) and then when it's done the rights are alterd.

Again, the whole point is to elevate the rights of the regular user for the purpose of the scripts internal tasks. This, I thought, was the point of "RunAs".. I've now tried it with every flag.. I even invented one, as I hadn't noticed there was no "3" just 0,1,2,4  .. No change.. it only seems to run with flag 2 when run as admin as well. it's possible that they don't have access to the desktop folder as it's viewed by windows, as I've noticed that sometimes when I try to go to the my documents folder from within the windows explorer rather than just clicking on shortcut it says I need admin rights.. so what would be the syntax for telling it to use the D: drive rather than using one of these @(####)dir functions..? I tried just writing D:/ but it didn't work.

[AdamUL]

I had a similar issue as you, but here is how I resolved it.  It requires restarting of the whole script twice.  The first step is to restart the script to run under the admin account, then restart it again to request the admin token.  Take a look a this example.  

 

Global $sAdminUser = "USERNAME"
Global $sAdminPassword = "PASSWORD"
Global $sDomain = @ComputerName
;~ Global $sDomain = "ad.domain.edu"
Global $iLogOnFlag = 0
Global $sParameters = ""

;Elevate with the Admin account.
If @UserName <> $sAdminUser And Not IsAdmin() Then
    $sParameters = ""
    If Not @Compiled Then
        $sParameters = ' "' & @ScriptFullPath & '"'
    EndIf

    If RunAs($sAdminUser, $sDomain, $sAdminPassword, $iLogOnFlag, @AutoItExe & $sParameters) Then
        Exit
    Else
        Exit MsgBox(16 + 262144, "ERROR!", "Unable to run under administrator account.")
    EndIf
EndIf

;Run with Admin Token in Windows Vista and Higher.
If @UserName = $sAdminUser And Not IsAdmin() And Not StringRegExp(@OSVersion, "_(XP|200(0|3))") Then
    $sParameters = ""
    If Not @Compiled Then
        $sParameters = '"' & @ScriptFullPath & '"'
    EndIf

    If ShellExecute(@AutoItExe, $sParameters, "", "runas") Then
        Exit
    Else
        Exit MsgBox(16 + 262144, "ERROR!", "Unable to elevate to Admin due to UAC.")
   EndIf
EndIf

MsgBox(16, "Test", IsAdmin()) ;Example

The main issue I can see is storing you credential in plain text in the script.  For my project, I found a way around that.  

 

 

Adam

Edited November 4, 2013 by AdamUL

[cowsmanaut]

Thanks! so, it runs with the attempt at setting admin rights, then tries to run itself a second time with those adminrights?

I'm trying to grasp the usage, I've been out of this scripting language so many years now that my brain is starting to hurt as I get back into it.

just a bit lost as the reasons for $sparameters value. this is to get it to run at the script path if it's not compiled, but run in the systemdir if it IS compiled?

I'm guessing line 33 where the message comes in, is the final use of this script, in my case running the CMD command fo icalcs?

[cowsmanaut]

I just tested it... no love.. "unable to run under admin account"

Though it works wonderfully under my account

[AdamUL]

Are you trying to use a local Admin account or a domain admin account?

[AdamUL]

To explain the script further, the script re-runs the first time with the LOCAL admin account entered in $sAdminUser with password $sAdminPassword.  This account has to be in the Administrators group on the local computer. This gets the script to run under an admin account, but it still does not have the "admin token" to preform restricted actions.  The second re-run of the script requests the admin token, which gives the scripts full admin rights.  

The $sParameters is used so the script will work if it is compiled or not.  You do not need to change this value.  The script does not need to be in the @SystemDir, it can be located anywhere you choose.  

Yes, you would put the rest of your script where the example message box is located.  

To test the script I posted:

-Enter the admin account information in $sAdminUser and $sAdminPassword

-Compile it

-Shift click, "Run as a different user"

-Enter in a NON-ADMIN account user information.

-Check the results.  

The message box should have a title "Test" and show "1."

[cowsmanaut]

we're using a domain login under windows 7.

So it sounds like I understood the essential actions of your script.. Again, when run while I'm logged on, it functions and gives the test 1 values, when run on a students computer with their login it returns the error that it can not be run under the administrator rights found in the first portion of the script.

[cowsmanaut]

tried copying over the @ComputerName with "our.domain.ca" with the quotes to see if this altered the result, it did not.. unless I'm getting the domain syntax incorrect?

[AdamUL]

If your domain is an Active Directory?  You could try "AD" for the domain.  Our domain is ad.domain.edu, and we just use AD.  

When testing with your account, are you putting your user name and password for $sAdminUser and $sAdminPassword, and then running it under your account as well, or are you using a different admin account?  

When you are running it under the student account, are you using your account, or a different admin account?

[cowsmanaut]

I'm running it under my account in the initial test.. then I run it under their account.. but the login information is my own account. When we try to install apps here under a student account we end up with it asking for the credentilals and mine work just fine in that case, I assumed it would be true here as well.

[AdamUL]

That's what I thought you were doing, and just wanted to be sure.  Yes, it would be true with this script as well.  I believe that the domain on the RunAs command is what causing the issue.  Do you have a local admin account on the PCs that you could use?  

[cowsmanaut]

nope, our it dept removed that.. I'm lucky to have admin rights as it is 0_0

[AdamUL]

Try changing the the RunAs domain parameter to "AD" and the logon flag to 2, and running it under the student account.  

 

I'm currently not able test with my test box, so I cannot test it with a domain account at the moment.  When i get back to work tomorrow, I'll do some additional testing using a domain account.  

Edited October 31, 2013 by AdamUL

[AdamUL]

OK, I did some testing to try to reproduce what you are reporting.  Where are you running the script from during testing, is it stored in a folder under the non-admin user profile, such as the user's desktop?  In my testing, I tried running it from a non-admin user's desktop, and running it from the Public desktop.  It would fail when run from the non-admin user's desktop, but it would run correctly from the Public desktop.  It seems that the admin user account did not have permission to access the script path under the non-admin account without the admin token.  The script would need to be stored where both accounts can access it. A folder under ProgramData would be a good location.  Also, I ran it with the logon flag set to 0, and the domain set to "AD".

I also just tested with domain set to "ad.domain.edu" without issues.

Edited November 1, 2013 by AdamUL

[cowsmanaut]

yeah, from their own desktop, as well as one of them trying to run it off the shared network drive.. but they wouldn't have admin rights there either.. I tried setting my own scrip to use the D: drive which they do have access to, but I don't think I had the domain listed, so I'll try that next. Won't be able to test until monday though.. thanks

[cowsmanaut]

Thank you Adam which is funny for me to say, since it's also my name.. but anyway.. I finally got it working by using the domain, and the @scriptdir and running it from the D drive directly along with it's resources.. so it looks like this will be workable for running some updates. Thanks again!

[AdamUL]

Glad I could help.  Sorry I didn't catch the errors earlier.  Since most of the apps I use this technique with are run from a flash drive with a local admin account.  I have updated the script above to what I used during testing.  

[ajharper]

I had a similar issue as you, but here is how I resolved it.  It requires restarting of the whole script twice.  The first step is to restart the script to run under the admin account, then restart it again to request the admin token.  Take a look a this example.  

 

Global $sAdminUser = "USERNAME"
Global $sAdminPassword = "PASSWORD"
Global $sDomain = @ComputerName
;~ Global $sDomain = "ad.domain.edu"
Global $iLogOnFlag = 0
Global $sParameters = ""

;Elevate with the Admin account.
If @UserName <> $sAdminUser And Not IsAdmin() Then
    $sParameters = ""
    If Not @Compiled Then
        $sParameters = ' "' & @ScriptFullPath & '"'
    EndIf

    If RunAs($sAdminUser, $sDomain, $sAdminPassword, $iLogOnFlag, @AutoItExe & $sParameters) Then
        Exit
    Else
        Exit MsgBox(16 + 262144, "ERROR!", "Unable to run under administrator account.")
    EndIf
EndIf

;Run with Admin Token in Windows Vista and Higher.
If @UserName = $sAdminUser And Not IsAdmin() And Not StringRegExp(@OSVersion, "_(XP|200(0|3))") Then
    $sParameters = ""
    If Not @Compiled Then
        $sParameters = '"' & @ScriptFullPath & '"'
    EndIf

    If ShellExecute(@AutoItExe, $sParameters, "", "runas") Then
        Exit
    Else
        Exit MsgBox(16 + 262144, "ERROR!", "Unable to elevate to Admin due to UAC.")
   EndIf
EndIf

MsgBox(16, "Test", IsAdmin()) ;Example

The main issue I can see is storing you credential in plain text in the script.  For my project, I found a way around that.  

 

 

Adam

 

Greetings,

I am new to this forum because I need to do exactly what this script does.  I need to run a script as an admin, and then I need that to fire off the actual program.  Simply doing a Run As with admin credentials isn't enough.  Can you tell me all the parameters I need to fill in the script above other then the username/password/logon flag?  I tried and all I get is the  Unable to run under administrator account error.

What I tried to do originally was create a script that would fire off the program executable via the RunAs parameter in AutoIT with the username, password, domain, and logon flag info set.  I guess I'm not sure in the script above where I add the program executable name/path.  Any help would be appreciated.  Thanks.

Edited January 13, 2015 by ajharper