RunAs in Batch

[stickagum]

Hey everybody... first post here.

I'm not a programmer but I'm trying to figure out a way to run a batch file that can start .exe's as a domain administrator from a restricted user account. Basically, users will be logged in with restricted domain accounts and will need to run a program daily with domain admin credentials. I think I can set the batch file to run on logon and then just hide the batch file in a hidden drive to protect the credentials. I was told it AutoIt could be used for this sort of thing. Does anyone know if this has been done already?

Thank you in advance.

Edited January 24, 2011 by stickagum

[willichan]

Just a little curious as to what you have that needs domain admin credentials. Perhaps there is a better solution. The method you are suggesting will create a gaping wide security holes on your network.

[stickagum]

Just a little curious as to what you have that needs domain admin credentials. Perhaps there is a better solution. The method you are suggesting will create a gaping wide security holes on your network.

Hey... thanks for responding so quickly.

It's a soft phone. I was under the impression this would be a pretty good way to do it...? The restricted user accounts that would be running the batch file don't even have visibility to any of the drives. They're locked down. My thought was that I could just hide the .bat somewhere and that would do the trick...

Is that not wise?

[willichan]

You could use RunAs to execute a program as a domain admin, but there are two reasons you may want to avoid it.

1. You would be embedding the domain admin user and password in the script, where either someone could hack it to get the password, or you would have to recompile the script every time you change the password.

2. The application you run could open the possibility of other processes being launched, and those would have the same domain access rights.

A soft-phone app should not require domain admin rights anyway. You could create an account with local "Power Users" access rather than domain access. That way, you limit security breaches to the local machine. The domain admin account will give access to everything.

I even have a separate, limited account set up for myself. I only use the domain admin account if I REALLY need it.

[stickagum]

You could use RunAs to execute a program as a domain admin, but there are two reasons you may want to avoid it.

1. You would be embedding the domain admin user and password in the script, where either someone could hack it to get the password, or you would have to recompile the script every time you change the password.

2. The application you run could open the possibility of other processes being launched, and those would have the same domain access rights.

A soft-phone app should not require domain admin rights anyway. You could create an account with local "Power Users" access rather than domain access. That way, you limit security breaches to the local machine. The domain admin account will give access to everything.

I even have a separate, limited account set up for myself. I only use the domain admin account if I REALLY need it.

Hey willichan--

Thanks for the update. Again, I also don't want to embed the UN and pass anywhere, but the machines are completely locked down. The drive visibility is completely nonexistent for these users so there wouldn't be any access to the script anyway. It would run at logon as a scheduled task.

Next, the program itself does not need to be run as an admin. The admin rights are needed because the browsing policy seems to be blocking the program from validating against its license servers. And unfortunately, this can't be changed easily.

Thanks again...

[willichan]

Hey willichan--

Thanks for the update. Again, I also don't want to embed the UN and pass anywhere, but the machines are completely locked down. The drive visibility is completely nonexistent for these users so there wouldn't be any access to the script anyway. It would run at logon as a scheduled task.

Next, the program itself does not need to be run as an admin. The admin rights are needed because the browsing policy seems to be blocking the program from validating against its license servers. And unfortunately, this can't be changed easily.

Thanks again...

If the machine can run the script, then the user can (if they have slight knowledge of how domains and login scripts work) get access to the script file.

I don't see any way that you can do this without embedding the UN and pass. AutoIt does not bypass Windows security. If you don't provide alternate credentials, it will only operate at the level of the currently logged in user.

Even if you run it as a scheduled task, with the credentials in the task, you are still open to having the task file hacked to get the domain credentials.

By browsing policy, are you referring to a proxy server? You may want to get together with your firewall/proxy server admin, and discuss adding exceptions for the license servers.