If you are running an Active Directory shop, you most probably have PowerShell scripts running in it. It’s a great way to execute tasks that are specific to your environment and automate them. However, it’s only convenient while you and your fellow admins are the only ones using them. But what if you are not? How do you properly delegate PowerShell scripts to non-administrators?

The Problem with Delegating Scripts

So, the first question you might ask could be: if you need to give a certain script to, let’s say, help desk personnel, why not simply give it to them? Actually, there are some strong reasons, why you shouldn’t do that.

• Firstly, to let help desk guys execute a script, they need to have same permissions that the script needs. It can be a lot of permissions. E.g. if a script adds users to a specific group, it means that your help desk personnel will be able to add and remove anybody (including themselves) to and from the group. That can easily lead to elevation of permissions and other consequences that you won’t be able to control.
• Secondly, by giving out a script, you can’t be sure that it won’t be modified at some point. Because of that, a script that you give out is a slow bomb that can cause a disaster at any moment. You definitely don’t want that in your environment.
• Thirdly, if you want to make changes to a script that is already given away, you can’t be sure that everybody gets the new version and won’t be using the old one.

To solve these problems, you can use version control systems, share scripts via network folders or even create your own PowerShell modules. However, this is a band-aid that can only work for some time. And none of these approaches solves the problem with permissions. To do that you need a change of paradigm.

Another Approach

With Adaxes we use a slightly different approach to delegating PowerShell scripts to non-admins. Instead of giving them actual scripts, you can give them just the ability to execute them.

Adaxes allows you to put your scripts inside Custom Commands. It is done in the Administration Console, which only admins have access to. This solves one of the problems mentioned above, as non-admin will be able to mess with the scripts’ code.

Putting a script into a Custom Command in Adaxes Administration Console (click to enlarge)

When users run a Custom Command, the script inside of it will be executed on behalf of the Adaxes Service. This means that users don’t need to have all the permissions that the script does. All they need is the permission to run the command. To provide that Adaxes has a Role-Based Access Control system that allows you to be very granular with which Custom Commands can be executed, which users can run them and which objects can those commands act on.

Configuring permissions to run Custom Commands within a Security Role (click to enlarge)

The approach Adaxes utilizes also means that your scripts have centralized management. So, if you want to change the script, there is only one place to do that and it’s instantly updated for everyone. Nobody will have older versions of it.

Providing Access to Scripts

After you assign permissions, you need to give your help desk personnel a way access those commands. With Adaxes all you need to do is to put them in a Web Interface, so the scripts will be one-click actions accessible from any browser on any machine.

Adaxes Web Interface (click to enlarge)

The whole Web UI is completely customizable, so you can give the exact commands needed to each category of users.

Even More Control

Now you know how to delegate your PowerShell scripts. But what if you have a healthy paranoia? What if you still want to be in full control? Adaxes has got you covered on that as well.

It allows you to add approval steps at any stage of the process. You can also add conditions to actions, so the approval will be required only if they are met.

To monitor execution of scripts you delegate to users, previously you had to dig the absolute mess of logs that could be scattered across different DCs, which made the task next to impossible. With Adaxes this problem goes away, as it provides you with comprehensive human-friendly logs all in one place.

Comprehensive logging in Adaxes (click to enlarge)

Final Thoughts

Having PowerShell scripts in an Active Directory environment is great. We love PowerShell! But when it comes to delegation, you need a robust solution to do that. That’s why Adaxes is there for you.

Try it yourself by downloading a free 30-day trial and see if it fits you.