Is AutoIt of any use to me anymore??

[vrocco]

For a long time my organization was behind the times. We were using Windows XP right through the whole Vista phase. Now we just migrated to a new Windows 7 load for all our machines. Being in a government environment, the machines are heavily locked down, GPO enforced, UAC fully on, etc, etc.

I just can't see how to make AutoIt do anything in this environment. The biggest benefit to me of AutoIt in XP was that I could write a script that would run with admin rights. This allowed the user to download a script and run it to get something accomplished without me having to log into every box as admin. I could even present them with a GUI that gave them choices if that was necessary. There doesn't seem to be any way to do this in AutoIt (running the script as admin from normal user account). Not from what I have found searching these forums anyway.

If I am wrong about this, can someone give me an example of a script that performs an admin function (edit HKLM, create admin group user, etc) that be run by an unprivileged user. I need to not have UAC interfere at all. This means either shut it off temporarily until the script finishes, or bypass it somehow.

Or is it time to abandon AutoIt and try to find something else? What other options are there?

Please realize I am not trying to start a flame war, just honestly asking for guidance on this.

[MariusN]

For a long time my organization was behind the times. We were using Windows XP right through the whole Vista phase. Now we just migrated to a new Windows 7 load for all our machines. Being in a government environment, the machines are heavily locked down, GPO enforced, UAC fully on, etc, etc.

I just can't see how to make AutoIt do anything in this environment. The biggest benefit to me of AutoIt in XP was that I could write a script that would run with admin rights. This allowed the user to download a script and run it to get something accomplished without me having to log into every box as admin. I could even present them with a GUI that gave them choices if that was necessary. There doesn't seem to be any way to do this in AutoIt (running the script as admin from normal user account). Not from what I have found searching these forums anyway.

If I am wrong about this, can someone give me an example of a script that performs an admin function (edit HKLM, create admin group user, etc) that be run by an unprivileged user. I need to not have UAC interfere at all. This means either shut it off temporarily until the script finishes, or bypass it somehow.

Or is it time to abandon AutoIt and try to find something else? What other options are there?

Please realize I am not trying to start a flame war, just honestly asking for guidance on this.

Just a reminder...UAC cant be turned of "temp"....i'ts either on...or off....via a re-boot...Thats Win7 for you...

[iamtheky]

Being in a governement environement

If you are of the DOIM/NEC ilk you should be able to push what you need through GPO. If you are on the receiving end (as it seems), and/or you do not have the proper credentials when UAC pops currently; I dont think they are going to appreciate any circumvention of existing security and I imagine attempts to do so will throw many flags.

If you have the credentials, and are thinking of maybe embedding these in your script.....i cant recommend that at all.

[Zedna]

If I am wrong about this, can someone give me an example of a script that performs an admin function (edit HKLM, create admin group user, etc) that be run by an unprivileged user. I need to not have UAC interfere at all. This means either shut it off temporarily until the script finishes, or bypass it somehow.

Or is it time to abandon AutoIt and try to find something else? What other options are there?

In this case it's limitation of Operation System not limitation of Autoit.

So you can't do this neither with Autoit nor with other software I think.

Edited December 1, 2011 by Zedna

[MilesAhead]

Back when I was using NT4 Server there was a freeware Windows implementation of su that allowed you to run a command as administrator. It had a facility to create a shortcut for a specific task with an encrypted admin password. After that you could just double click the icon. It used the info in the shortcut as part of the encryption scheme so that you could not just change the icon target to run something else.

Maybe someone has come up with something similar for UAC by now.

Edited December 1, 2011 by MilesAhead

[spudw2k]

If you're an administrator and disabling UAC is not an option you can set a registry key to bypass the UAC prompt (for admins only). Yes the key must be set ahead of time else you'll be prompted all the same.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem]

"ConsentPromptBehaviorAdmin"=dword:00000000

There is a separate key for non admin users but I wouldn't recommend changing that one.

Edited December 1, 2011 by spudw2k

[ghetek]

You may want to look into compatibility shims for your autoit projects

http://technet.microsoft.com/en-us/library/dd837644%28WS.10%29.aspx

[iamtheky]

you cannot use shims to bypass any security mechanisms present in Windows. For example, no shim is available to bypass the Windows 7 User Account Control (UAC) prompts while still running the application with elevated permissions.

[jchd]

Zapping here, my opinion is that your issue just can't be solved the way you put it. It isn't the question of AutoIt or anything else, it is a question of edicted policies that simply don't give room for achievement of the tasks at hand.

This issue should be debated with your hierarchy, weighting the goods and odds of the rules they have put in place without thinking twice. If they decide that your job now has to be done "by hand" because strict policies govern above all, then they must accept the burden of their option.

Prove your point about allowing elevated controlled runs of [AutoIt or anything else] scripts _you_ manage by comparing time wasted and potential errors vs. effectiveness of your previous solution. Let them decide but tell them clearly that _they_ now carry the burden of slow deployment, slow upgrade, slow setups and park inconsistencies leading to more wasted time and energy within your organization.

Ask them to put their decision in writing as a note that you can exhibit every time something "should have been done yesterday" but requires more time to be done. Push back the pressure to them, don't even think to accept it. Practice Aïkido in IT dept.

Edit: BTW I'm not in a good position to tell you that what you expect can or cannot be done, the above is just a non-tech opinion. Seasonned admins here might have a magic wand for you.

Edited December 2, 2011 by jchd

[Chimaera]

This issue should be debated with your hierarchy, weighting the goods and odds of the rules they have put in place without thinking twice. If they decide that your job now has to be done "by hand" because strict policies govern above all, then they must accept the burden of their option.

Prove your point about allowing elevated controlled runs of [AutoIt or anything else] scripts _you_ manage by comparing time wasted and potential errors vs. effectiveness of your previous solution. Let them decide but tell them clearly that _they_ now carry the burden of slow deployment, slow upgrade, slow setups and park inconsistencies leading to more wasted time and energy within your organization.

Ask them to put their decision in writing as a note that you can exhibit every time something "should have been done yesterday" but requires more time to be done. Push back the pressure to them, don't even think to accept it. Practice Aïkido in IT dept.

Every time i try this i get the boot from the company, but maybe im a little to insistent about it.

[skylang]

Check out SetACL. You should be able to invoke it with AutoIt

Edited December 17, 2011 by skylang