Sign in to follow this  
Followers 0
gregnottage

RunAsSet and changing local admin pw?

10 posts in this topic

Hi Guys,

I have been succesfully using RunAsSet in my scripts to elevate the permission of the running script. I distribute compiled versions of my scripts on our workstations, so that the admin credentials used for RunAsSet in the script cannot be read by the casual user. This all works fine, however if the password gets changed for the local admin account, the RunAsSet fails because the credentials are hard coded into the script.

Is there a way of reading the credentials (in an encrypted format?) for use with RunAsSet, so that my compiled exe doesn't require the credentials to be hard coded?

Thanks,

Greg

Share this post


Link to post
Share on other sites



Reading the username yes... reading the password, no. That's why programs like L0phtcrack take days to crack the local admin password.


My Additions:- RunAs AdminDeviant Fun:- Variable Sound Volume

Share this post


Link to post
Share on other sites

OK, I thought as much. Can you suggest a solution in that case? Is it just a case of working out a method to distribute an updated version of the exe, each time the local admin password changes?

Maybe I could write something in a startup script that compares the local version of the exe to a version kept on a share somewhere and overwrites the local version if it's older? What do you think?

Thanks,

Greg.

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

OK, I thought as much. Can you suggest a solution in that case? Is it just a case of working out a method to distribute an updated version of the exe, each time the local admin password changes?

Maybe I could write something in a startup script that compares the local version of the exe to a version kept on a share somewhere and overwrites the local version if it's older? What do you think?

Thanks,

Greg.

Instead of trying to determine if the password has changed why not just change it to what you want it to be?

NET USER ADMINISTRATOR <password>

will change the local administrator password. You could compile this and run it remotely via psexec or RCMD. If you have an AD domain you could even do this via group policy. Off the top of my head I cannot recall if startup scripts run as the user or under the system account. If they run as system this should work as a startup script. Startup and shutdown scripts run with local system authority so this could work for you.

Edited by ksmith247

Support bacteria; it's the only culture most people have.LxP's Learning to Script with AutoIt 3 - Excellent starting placeVolly's Links Page - Links to cool and useful scriptsAutoIt Wrappers - Valuater's AutoIt Wrappers post. Lots of good stuff.Support AutoIt - Make a donation here; I did.[size="2"]#include <Guinness.pint>[/size]

Share this post


Link to post
Share on other sites

How about a service account which never expires? I've written also a GUI which can handle a service on a specific server and this needs admin rights. I put a service account from AD to local Adminitrators group which never expires!

If you don't use AD then you have to create a local account which is also an admin (this can also created by a script).

I hope this helps.

UEZ


Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites

Yikes,

Is an executable really that secure? I haven't been around AutoIT that long. My supervisor is the one that had me use it and I loved it. Being an admin in my place of employment, I had to research the security. After a short meeting I decided that I would never put anything I wanted kept private in a script.

There was an Exe2Aut CW2K edition or something that doesnt even ask for a passphrase, whether you compile with one or not, don't know much about this.

I did see a post the other day that sort of scrambled the header files, maybe this can prevent it.

Share this post


Link to post
Share on other sites

Nope, its not secure. It has been said many times on this forum. You can use an Obfuscator to make your script more difficult read but that isn't secure either (though it is beyond my capability to de-obfuscate a script). I just answered the question that was asked.


Support bacteria; it's the only culture most people have.LxP's Learning to Script with AutoIt 3 - Excellent starting placeVolly's Links Page - Links to cool and useful scriptsAutoIt Wrappers - Valuater's AutoIt Wrappers post. Lots of good stuff.Support AutoIt - Make a donation here; I did.[size="2"]#include <Guinness.pint>[/size]

Share this post


Link to post
Share on other sites

UEZ: please can you explain a bit more about your solution? I like the sound of it, but I need to get my head around it. We are using and AD, but please can you explain it from the local admin point of view. The reason for this is that the RunAsSet app I'm using sets up some things before the machine is joined to the AD.

Thanks,

Greg.

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Feature Request - _RequirePassword() that works like _Singleton() exiting the script on fail. It would probably take a few DLL calls.

@gregnottage - You should just distribute your compiled script in such a way that it is not accessible to casual users, only to password protected users; then it seems you would not need to use RunAsSet.

For example, let us say that the user Jason must always use a password or be fired, and the user Guest is not password protected. In this case, then when you distribute, copy the .exe only to a folder listed under Jason's Documents, and put a shortcut to it only under Jason's Start Menu.

This strategy is for if you are looking for a solution to a real challenge that a real business concern has, rather than if you are just a nerd who occupies his time with experiments in how to remake the wheel.

Elsewise - this script here would probably be interesting to study.

Edited by Squirrely1

Das Häschen benutzt Radar

Share this post


Link to post
Share on other sites

UEZ: please can you explain a bit more about your solution? I like the sound of it, but I need to get my head around it. We are using and AD, but please can you explain it from the local admin point of view. The reason for this is that the RunAsSet app I'm using sets up some things before the machine is joined to the AD.

Thanks,

Greg.

Greg,

one of our department requested to be able to start / stop a service on a servcer but controlling service needs admin. rights. So I created an account in AD and put the account to a group in AD. This group is member of the local 'Administrators' group. The password of the service account in AD is set to 'never expires'.

What the GUI is doing is to control (start / stop / restart) the service on the specified server with the service account I created. Accounts that expire cannot be used because of hard coded password inside the compiled exe.

The controlling of the service is made with WMI instances because it can be started from any system remotely.

What do you mean with "...sets up some things..."?

UEZ


Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0