The PowerShell execution policy prevents unintended or accidental execution of a PowerShell scripts. You can use Group Policy to set the PowerShell execution policy in your network.
Profile gravatar of Jeffery Hicks

Jeffery Hicks

Jeffery Hicks is a multi-year Microsoft MVP in Windows PowerShell, Microsoft Certified Professional and an IT veteran with 25 years of experience specializing in automation. He works today as an author, trainer and consultant.
Profile gravatar of Jeffery Hicks

In a previous article I explained about PowerShell’s execution policy and demonstrated how to set it from an elevated PowerShell session.

The default policy is Restricted so if you only need to configure a policy on a handful of machines you could run the command interactively. You could even use a remoting command.

 

But the smarter way is to use a Group Policy object. The primary benefit is that policies applied by a GPO can’t be overwritten, even by an administrator. To configure such a policy open the Group Policy Management Editor and edit or create a new GPO. Mine is called PowerShell Configuration.

Group Policy Management Editor

Group Policy Management Editor

To configure, navigate under Computer Configuration to Policies\Administrative Templates\Windows Components\Windows PowerShell. You should see a setting called Turn on Script Execution like in figure 2.

Turn on Script Execution

Turn on Script Execution

Double-click the setting. You will want to enable it and select an option from the drop down.

Enable PowerShell execution policy

Enable PowerShell execution policy

The policy descriptions correspond to AllSigned, RemoteSigned and Unrestricted. I’m going to pick the policy to allow local and remote signed scripts. Click OK to set it. The dialog suggest you need at least Windows 7 but I am pretty sure that even with PowerShell 2 running on older systems you can use this policy. I unfortunately no longer have any such legacy systems to verify that. But this setting will apply to PowerShell 2.0 and later.

I can verify my setting in the Group Policy Editor.

Group Policy Editor

Group Policy Editor

Of course the benefit is that you can apply different settings to different organizational units so servers, user desktops and admin desktops can all have different settings that will be enforced. Remember, this policy is per machine so it will apply to your administrator desktops as well.

Now, when the policy is in place, users (and administrators) can’t override your script execution policy.

PowerShell execution policy overridden

PowerShell execution policy overridden

In theory, this should also protect you from any future PowerShell-centric malware that might try alter your script execution policy.

As I mentioned before, this doesn’t prevent someone from copying and pasting the contents of a script into a PowerShell session, but at least they can’t simply run the script.

This policy also doesn’t have any effect on cmdlets, like Invoke-Command, that have a parameter to specify a script path. The machine running Invoke-Command should have a policy to allow script execution. But any remote machines can have restricted execution policies. When you specify a script from your machine, the script itself doesn’t run remotely, only the contents. Think of this as the equivalent of copying and pasting the script commands into a PowerShell session. The end result is that servers can be locked down yet you can still take advantage of PowerShell scripts.

One thing to be aware of is that if you are using a Group Policy to define a PowerShell logon, logoff or computer script, that script will disregard any execution policy set locally or through a GPO. These scripts execute with a Bypass execution policy. The assumption is that you have created the script, know what it does and have taken precautions to secure it.

I encourage you to test these Group Policy settings in a non-production environment so that you can fully understand the implications and how it might affect your PowerShell management practices.

Take part in our competition and win $100!

Share
0

Related Posts

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account