Scott Burrell shows how execution policies are used to allow and restrict PowerShell scripts for a computer or user based on where the script originated.
- [Narrator] In this course, we will be writing and running several of our own PowerShell scripts. There is something that we need to do however before we get started. We need to make sure that our scripts will be allowed to run. PowerShell scripts can access of modify the functionality of the operating system and several types of applications. For this reason, Windows includes policies that let you specify what types of scripts you want to allow or block.
Execution policies are set to identify where a script originated and whether that location requires a digital signature. There are really only two important location options when it comes to where the script originated. The script either came from the internet or it came from some place local. You may be more likely to trust a script that originated locally than one that was downloaded from the internet. Including those that were attached to email or Messenger applications.
Scripts that come from the internet are considered remote scripts. If however, your users have the ability to insert USB drives or other types of removable storage, you may also need to consider the possibility of threats that don't come from the internet. Once you decide which points of origin constitutes threats, you can specify whether to require recognize digital signatures on your scripts. In all, there's six policies that you can choose from.
Scripts can be restricted, meaning no scripts will be allowed to run. Or the policy could be set to AllSigned, which requires scripts to be digitally signed to run no matter where they come from. If the policy is set to RemoteSigned, scripts from the internet will require a trusted digital signature. But all scripts originating locally will be allowed without any additional requirements. If you want to allow all scripts to run, you could set the policy to Unrestricted.
This policy will warn the user when running remote scripts but it won't block them. Finally, Bypass allows any script to run without warning, without caution. It should go without saying that there aren't very many situations that would merit this type of policy. Off the top of head, I can't think of any. Each of these policies can be applied and they can be applied to a different scope. If no policy has been set, then it's going to be undefined and we'll talk later about what that means.
Now each of these policies can be applied to a different scope. A policy can be applied to the LocalMachine and any user that may log into it. Or it could apply to a specific user taking advantage of the CurrentUser hive in the registry. And there's also an option to set an execution policy for the PowerShell process or that individual PowerShell session. This is a good way to test policies to see how they'll affect your scripts.
In PowerShell, you can check to see the policies that are currently set on your machine. Here I have a Windows 2016 server, it's right now a standalone server that's not joined to any domain and it's getting its IP address dynamically. So there's nothing special about the configuration of this box. And I have it installed with PowerShell Core as well as Windows PowerShell. I'm going to run PowerShell Core or PowerShell version six.
And more specifically, I'm going to right-click it and under More, chose Run as Administrator so that I'll have the permissions and access necessary to not only view but make changes to the execution policies. The commandlet to take a look at your current execution policies is Get-ExecutionPolicy. And I'm going to add the list parameter so that we can see all of the policies that currently apply.
Here you can see the scopes that we talked about, the LocalMachine, CurrentUser, and the Process as well as two other policies that can't be set by group policy in an active directory domain. The others are set using the Set-ExecutionPolicy commandlet. You'll notice here that most of these are undefined. And this is a default setting. If all of the policies were set as undefined, the resulting policy would be restricted, meaning if you set the LocalMachine policy to undefined and there is nothing granting scripts permission to run, all scripts will be blocked.
Otherwise, these policies will start at the top and go down adding restrictions as they go. Placing a less secure policy down here at CurrentUser isn't going to reduce the restrictions. The only exception to that is LocalMachine. The LocalMachine policy will trump CurrentUser and Process even if it's a more lenient policy. Coming up, we're going to take a look at setting these policies so that we can set up our system to allow and block the scripts that we want to run.
- Creating a PowerShell script
- Creating scripts in IDE or Visual Studio Code
- Working with files
- Loading modules
- Using functions
- Managing servers with WMI
- Adding users to a domain