Run part of code as other user.

[WJST]

Good day,

Since a few years I use AutoIt to create little tools for myself making the support of our it environment a bit easyer. But now I'm in a clash.

I want to create a tool, which allows users to do something they don't have the right for to do it. So I want to incorporate some kind of "run as" feature in it. This can off-course be done by using the RunAs function, however, that would meen I need to create some other exe file what'll do it for me, and I don't want that.

So is it possible, to create a script with domain user credentials and a password embedded in it to allow part of the code to be run as an "elevated rights domain user"?

In this case I use functions from services.au3 to visualize the restarting of specific services on remote applicationservers

I hope somebody knows the answer to this

Thanks.

Edited October 28, 2010 by WJST

[iamtheky]

not utilizing the services.au3 but something along these lines should allow you to stop/start remotely

runas ("DomainUser" , "Domain" , "passwor*" , 1 , "cmd /c " & "sc SERVER stop MySERVICE")
runas ("DomainUser" , "Domain" , "passwor*" , 1 , "cmd /c " & "sc SERVER start MySERVICE")

Edited October 28, 2010 by iamtheky

[PsaltyDS]

Nobody is going to like the idea of embedding domain level credentials in a script. It is not secure and should not be done. There are other options, for instance: Have the client scripts post/send a request to a server where a monitor script, running with require perms, sees the request and remotely performs that action over the network. The clients never have to get perms to do anything except send the request. The monitor script is the only one with elevated perms.

not utilizing the services.au3 but something along these lines should allow you to stop/start remotely

runas ("DomainUser" , "Domain" , "passwor*" , 1 , "cmd /c " & "sc SERVER stop MySERVICE")
runas ("DomainUser" , "Domain" , "passwor*" , 1 , "cmd /c " & "sc SERVER start MySERVICE")

@iamtheky: That doesn't answer the question of where the client gets those credentials from. Storing them in the script source is unsafe. But in the idea I posted above, the monitor script could use a simpler command line without credentials because the monitor already has the perms. Something like:

; $sTarget was parsed from the client request
Run("sc.exe " & $sTarget & " start Your_Service_Name")

Edited October 28, 2010 by PsaltyDS

[iamtheky]

"to create a script with domain user credentials and a password embedded in it"

Since the OP asked in such a way...

[WJST]

Nobody is going to like the idea of embedding domain level credentials in a script. It is not secure and should not be done. There are other options, for instance: Have the client scripts post/send a request to a server where a monitor script, running with require perms, sees the request and remotely performs that action over the network. The clients never have to get perms to do anything except send the request. The monitor script is the only one with elevated perms.

I do realise that, but that's not an issue to be honest. Utilizing a 2nd monitoring script is a good idea in some cases, however, in this case it's not possible. Hence my question

@iamtheky:

Yes, that's true and also a reasonable option, however, it's pretty limited.. It doesnt give all the options I'm looking for in this case, like being able to interact with a simple gui..

That's why I like the services.au3 options for the diagnostic options in it.