Non-admin running VBScript HTA with admin rights

[woter324]

Hi All,

I am after some advice on the best way to accomplish a task.

I have written an HTA in VBScript to create domain users that can be given to our helpdesk. The HTA processes a form submitted by users on our intranet, leaving the helpdesk to do the bare minimum as 95% of the new user tasks are completed in the background by the HTA.

Our helpdesk staff do not have admin rights and historically have not created user accounts. The HTA has been developed to farm off the user creation task to them.

I have identified four main tasks the HTA performs that will require admin rights:

[ol]
[li]Create user using Exchange 2007 powershell command.[/li]
[li]'put' users Active Directory properties. Address, Telephone etc.[/li]
[li]Create users' home and tsprofile directory on our NAS file server using FileSystemObject [/li]
[li]Run third party tool 'setACL' to set permissions on user's home and tsprofiles directory on our NAS share.[/li]
[/ol]

What I would realy like to do is to create some kind of 'wrapper' that the HTA runs in, granting all call from the HTA with the correct rights, but I guess this will require .NET or something else far more complicated for my little brain to cope with.

A few things I have thought of:

Delegated rights: Create a script that delegates rights to the HD user at runtime, and removes them after.

Problems:
If the user crashed out of HTA, then delegated rights remain and that means the HD user can use normal AD users and computers to try and create users.

Complicated to script and I don't like the idea of keep changing AD like that.

Runas: Run the four commands with elevated rights.

Problems:
Password Not sure how to run the FSO under runas
Password has to be entered for each command unless I use something like lsrunase that will encrypt the password.

So in short, if anyone can think of a better way or something I haven't thought of, I'd be very grateful if you could point me in that direction.


Many thanks

 

[markdmac]

I've had to tackle this same issue many times and the good news is you are really close.

You have already automated much of what needs to be done, so my advice is to move your code into a classic ASP page. You can have the credentials encoded in the ASP page so the users don't need to have the rights.

For the part of adding the user mailbox in Exchange, you can use the file system object to create a PS1 file that has all your PowerShell commands to be executed. Then all you need to do is have the server launch PowerShell and pass that PS1 file as an argument to be able to create the mailbox. Once done do cleanup to remove the PS1 file.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[woter324]

Hi Mark,

Thanks for the reply. If I am not mistaken, I believe your suggestion mean 're'-writing the code to work as a web page rather than an HTA application?

I always thought using runas on the main HTA would not run spawned processes as the runas user. Well testing would prove me wrong, so I am happy to continue down this route.

I have created a dedicated domain admin user for using runas and so the Helpdesk don't use it to log on and do things they shouldn't I have use AD's "deny logon locally" and also denied Helpdesk_Users Security Group permission to modivy members of the DENY_LOGON_LOCALLY security group. All well and good, until I get the message.

1385: Logon failure: the user has not been granted the requested logon type at this computer.

.

So the question is now, is there a way to deny logon locally, but allow the account to use runas?

Many thanks

Woter

 

[markdmac]

Not that I am aware of. That is why I have suggested the route that I have.

Using the RunAs your users will be able to gain elevated priviledges. Once they know the user ID there is nothing to stop them from making a new user a member of the Domain Admins group and then doing whatever they want.

Your code is essentially almost what you need it to be to use in an ASP page, that is why I recommend you go that route. Using this method you can set the code to execute with the elevated rights (the same idea as the runas) but the users can't view the password and you control what they can do in the ASP form.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[woter324]

Hi Mark,

Thanks again. Sorry to be a pain in the butt. I am just a little scared of writting this again in ASP.

Do you think a similar aim could be achieved in old VB 6?

I'm looking at ASP and found an interesting page on [link MSDN]

http://msdn.microsoft.com/en-us/library/aa389281(VS.85).aspx

[/url] that I am trying to get to work.

If I go down the asp route, would it be possible to ask for a security example as my knowledge of ASP extends to using IIS authentication and, in my head, I will be no better off.

Thanks again.

 

[woter324]

Sorry, the MSDN link above was not correct. This is the one I meant to give.

 

[markdmac]

Here is a sample of one of the pages I wrote for managing user SMTP addresses. The Secrets.inc file that is referenced has the has the security information in it and lists user name and password.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.