Run as local admin

[Niclas]

Hi there,

I've already searched this and other forums but couldn't find a solution. So I opened this thread. Please excuse me if a similar one already exists.

I'm working with AutoIT 3.1.1.0 since yesterday and now trying to create some scripts.

For our users in our Windows network, including AD, I'd like to edit some scripts which enable them to run/install applications which need administrator privileges to be installed.

To do this I'm using the "RunAsSet()"-command but always receive an error that the account oder username doesn't exist.

As further description:

- users are domain users with restricted right

- the administrator account to enable an installation is a local account which exists on all machines and has the same password everywhere

Now I'd like the user to run the AutoIT-script which should install an application using admin rights, compared to the "Run As..." feature when right clicking applications in the explorer.

My script therefore contains:

RunAsSet ("administrator", "localhost", "XXXXXXX",2)
Run ("fp9.exe")

I'm using "localhost" since the admin account is no domain account. I also tried the switch "0" with no result.

What's wrong and how can I get it running ? I also left out the domain "localhost" and received the error that the path to the application cannot be found although it's located in the same directory. Also "127.0.0.1" - which in fact is localhost - doesn't work.

Thanks in advance for some helpful hints.

With kind regards,

Niclas

[MHz]

Since you are not using a path to the file, then you may want to check your working directory.

RunAsSet ("administrator", "localhost", "XXXXXXX", 2)
MsgBox(0x40000, 'WorkingDir', @WorkingDir)
If Not FileExists("fp9.exe") And FileExists(@ScriptDir & "\fp9.exe") Then
    FileChangeDir(@ScriptDir)
EndIf
Run ("fp9.exe")

[Niclas]

Hi MHZ and thanks for the fast reply !

I just changed my script and receive the message box which shows the working dir.

But after clicking "OK" I again receive an error message:

Run ("fp9.exe")

Error: Unable to execute the external program.

Das System kann den angegebenen Pfad nicht finden*

*The system cannot find the given path

Still both files are located in the same folder.

[MHz]

Niclas, If you are executing this on a locally, then you may wish to try @Computername for the domain oarameter of RunAsSet. I am not sure if LocalHost is valid for use or not. This change may influence the Run function.

[Niclas]

Hmm.....same error message.

My RunAsSet line now looks like:

RunAsSet ("administrator", "@ComputerName", "XXXXXXX")

I guess "@ComputerName" is wrong in there.

Sorry, but I don't know all switches, variables and so on yet. :">

But generally adding the computername into the RunAsSet command (tried this also) is a problem since I don't know which user with which computer(-name) is running the file.

Edited December 7, 2006 by Niclas

[MHz]

Macros do not belong as being strings so loose the quotes,

RunAsSet ("administrator", @ComputerName, "XXXXXXX")oÝ÷ ØGbµ8^vzZ­©µêâ²mÚÊ2¢éÉ·nW­¢ëjw¦¦Ü¬¶¸§«¨¶«¨µ«­¢+ÙIÕ¹ÍMÐ ÅÕ½Ðíµ¥¹¥ÍÑÉѽÈÅÕ½Ðì°ÅÕ½ÐìÅÕ½Ðì°ÅÕ½Ðíaaaaaa`ÅÕ½Ðì¤

Edited December 7, 2006 by MHz

[Niclas]

No, still doesn't work. Same error message.

I also left out the domain already. Same effect.

; Script Start - Add your code below here
RunAsSet ("administrator", "", "XXXXXXXX", 0)
MsgBox(0x40000, 'WorkingDir', @WorkingDir)
If Not FileExists("fp9.exe") And FileExists(@ScriptDir & "\fp9.exe") Then
    FileChangeDir(@ScriptDir)
EndIf
Run ("fp9.exe")oÝ÷ Ù«­¢+ØìMÉ¥ÁÐMÑÉдå½ÕȽ±½Ü¡É)IÕ¹ÍMÐ ÅÕ½Ðíµ¥¹¥ÍÑÉѽÈÅÕ½Ðì°
½µÁÕÑÉ9µ°ÅÕ½Ðíaaaaaaa`ÅÕ½Ðì°À¤)5Í ½à ÁàÐÀÀÀÀ°Ìäí]½É­¥¹¥ÈÌäì°]½É­¥¹¥È¤)%9½Ð¥±á¥ÍÑÌ ÅÕ½ÐíÀä¹áÅÕ½Ð줹¥±á¥ÍÑÌ¡MÉ¥ÁѥȵÀìÅÕ½ÐìÀäÈíÀä¹áÅÕ½Ðì¤Q¡¸(¥±
¡¹¥È¡MÉ¥ÁѥȤ)¹%)IÕ¸ ÅÕ½ÐíÀä¹áÅÕ½Ðì¤

[MHz]

If RunAsSet fails, then so will the rest. If this is the default Administrator account, then does it not start with a upper case "A" instead of lower case "a"? I have an account named "Administrator".

[TheSaint]

Hi Niclas

I've written a nifty little program, that allows users to run programs they right-click on, without knowing the Admin password - which you store in the program itself - encrypted!

You might find it usefull as is or maybe modify it ... put in a time limit, etc.

Only the Administrator can enable/disable/change the password.

Here's where you can download it - Admin Rights & Shortcuts For All

[Niclas]

@MHz: Do you think it's important whether to use capital or miniscule letters for a username ? Thought it's only important for passwords. But I will try it. Thanks.

@TheSaint: Thanks for the hint ! I'll try it ! Is "Admin_Right.au3" the one which is going to suit my needs ?

Downloaded both and will check 'em.

[Niclas]

Checked it again.

If user is local admin the script works. If not it doesn't.

If IsAdmin() Then
    Run("fp9.exe")
Else
    RunAsSet ("administrator", @ComputerName, "XXXXXXX")
    Run("fp9.exe")
    IsAdmin()
EndIf

As soon as the user no more member of the local admin group an error message pops up that the path to the application cannot be found (see above).

Edited December 7, 2006 by Niclas

[TheSaint]

Run("fp9.exe")

I think this may need to be RunWait("fp9.exe")

IsAdmin()

Not having access to helpfile at moment, I can't check much, but did you mean to use RunAsSet() instead of the second IsAdmin(). My memory says that if the script quits, so does Administrator privileges - that's why I used RunWait, then an explicit termination of Administrator privileges, by using RunAsSet().

[Niclas]

@TheSaint: I just tested your program, but cannot find anything in "Send To..." concerning both programs. So I dragged the file onto your script which opened the dialogue in which I set the admin password. But running the program via the button in you application fails with the message that the password's wrong.

[Niclas]

that's why I used RunWait, then an explicit termination of Administrator privileges, by using RunAsSet().

Ups, you're right. Mistyped it. :"> It is RunAsSet() - correct.

Modified Run("fp9.exe") to RunWait("fp9.exe") and checking it again.

Edited December 7, 2006 by Niclas

[TheSaint]

As stated on the page you downloaded from - Both programs need a shortcut in your 'SendTo' folder. This is on XP - C:\Documents and Settings\%username goes here%\SendTo (the SendTo folder usually being hidden, so you may need to change your folder view settings to get to it ... or just type it in the address bar and hit return). On 98 or ME the SendTo folder is hidden in the Windows folder.

YOU HAVE TO MANUALLY CREATE THE SHORTCUT AND THEN PASTE IT IN THE SENDTO FOLDER!

When you first start the "Admin Rights" program, you need to click on the Create/Edit button and enter your Administrator password, it is then encrypted and stored, and the program is now ready for using!

Right-click on an .exe file or a shortcut to an .exe ... then when the "Admin Rights" program appears, click on the "Run As Admin" button, then all should work as hoped for.

[TheSaint]

ADDENDUM:

Leave the "Admin Rights" program running in the background, until you've finished with the file you right-clicked on!

[Niclas]

Ah, you're right. Damn lack off time. Made me fly over the text.

But "Send to..." works like the dragging the file onto the "Admin_Rights".

After having sent the "f9p.exe" to "Admin_Rights" I entered the admin password and chose "RUN as ADMIN" which resulted in the following error message: "Operation failed - possibly due to incorrect password!"

Yes, I've checked the password. It's correct.

Edited December 7, 2006 by Niclas

[TheSaint]

The error checking for RunAsSet is pretty basic - read the helpfile, so I'm not sure what is wrong, but as Mhz said check the path of "f9p.exe", you may need to use @Scriptdir if it is in the same folder as my program - don't forget the backslash \ i.e. @Scriptdir & "\f9p.exe". If it's elsewhere you may need to explicitly use that path!

[TheSaint]

But really, if you are right-clicking on "f9p.exe", then you shouldn't need to worry about path, as my program does all that!

[TheSaint]

I'm not sure in your case, but sometimes file ownership can really put a spanner in the works ... this is why I always have a fat32 partition, to swap files in and out of, to get rid of that nasty little feature - need to be logged in as Admin to do this - don't open/run certain files as Admin on a NTFS root, as Admin may gain sole ownership - I've often run into this dilemma ... that's why I use the fat32 trick. If you haven't fat32 then copy and delete the original while logged in as admin, may work ... can't remember?