PowerShell Execution Policy
You have just found the perfect script online to take care of that weird, overly complex thing your boss asked you to do. You have combed through the code to make sure nothing dodgy is hidden in there and modified it to fit your environment. You launch the PowerShell command shell and run the script only to be greeted with some lovely red lettering informing you that your script is not digitally signed.
This is the PowerShell execution policy at work. From a security stand point its fantastic. It prevents people from running malicious scripts they find on the internet. A security measure sorely lacking with VBScripts and batch files.
From an IT admins standpoint it's a pain in the ass because it's standing between you and the completion of an annoying task that needs to go away so you can move onto the next project\fire\lunch.
For those of you in a rush here is the quick and dirty way around this.
This is the PowerShell execution policy at work. From a security stand point its fantastic. It prevents people from running malicious scripts they find on the internet. A security measure sorely lacking with VBScripts and batch files.
From an IT admins standpoint it's a pain in the ass because it's standing between you and the completion of an annoying task that needs to go away so you can move onto the next project\fire\lunch.
For those of you in a rush here is the quick and dirty way around this.
- Open PowerShell as an administrator (The old right click and run as administrator).
- Enter "Set-ExecutionPolicy Unrestricted."
- Say "Yes" when asked if your sure.
- Now you can run your script all day long.
To check the settings took, perform the following.
- Launch the PowerShell console.
- Enter "Get-ExecutionPolicy -list."
This is most definitely a work-around and not something that should be considered the best way to solve this issue.
Now for those with a little more time on their hands, let's look at a nice way of taming this feisty little restriction.
PowerShell will let you choose between 6 different execution modes.
- Restricted - This lets you run nothing.
- AllSigned - If its been signed with a certificate it will run. Anything not signed will not run
- RemoteSigned - If it's from the internet it must be signed, otherwise it won't run. If you write it in your editor of choice and save it, then it will run.
- Unrestricted - Runs everything but will ask for confirmation if the script was downloaded from the internet.
- Bypass - No restrictions or warnings. Like the Vegas of PowerShell restrictions. Anything goes.
- Undefined - This just puts the execution policy into a limbo state.
I personally like remote signed option. It gives the freedom of being able to write and run your own stuff with the protection of not allowing random people to download a script called "RunMeAndBeRich.ps1" from the internet and screw up your day.
But how do I configure my hundreds of machines I hear you ask. Well, for that, we turn to our old friend group policy. Using a GPO, we can configure the execution policy on a mass scale.
You will want to modify what ever policy controls all your workstations and the policy that controls all your servers....assuming you want this rolled out on a large scale of course.
- Right click on your policy and click Edit.
- Expand Computer Configuration\Administrative Templates\Windows Components.
- Select the Windows PowerShell folder.
- In the right pane Double Click "Turn on Script Execution."
- Select Enable.
- Select one of the options from the Execution Policy drop down list. See table below of explanation of the options.
- Click on and close the Group Policy Management Editor
GPO Drop Down | Execution Policy |
---|---|
Allow only signed scripts | AllSigned |
Allow local scripts and remote signed scripts | RemoteSigned |
Allow all scripts | Unrestricted |
Job done. All your machines are now protected from PowerShell internet nasties while still allowing you to take care of business with your masterfully written scripts.
Taking all of the above into account, I would still recommend signed scripts with a code signing certificate. But that's for another day.
Taking all of the above into account, I would still recommend signed scripts with a code signing certificate. But that's for another day.
Comments
Post a Comment