So to get started, let's talk about execution policies themselves.
An execution policy is a safety feature within Windows that will
control the conditions under which PowerShell as a process will
load configuration files and run scripts.
This feature is all of designed to prevent execution of malicious scripts.
Now execution policies for Windows support setting the
execution policy within either the local computer,
the current user, or the current session.
So three different areas that we can set an execution policy.
Execution policies, when set for the local computer,
get saved into the registry of the machine.
If it's set for a session, then it's stored within memory.
Execution policies don't actually restrict any of the user actions themselves.
The users can technically bypass the policy,
for example,
by copying the contents of the PowerShell script and
pasting it directly into the command line.
Now execution policies for non‑Windows, such as a Linux machine or a Mac machine,
for example, the default execution policy is always unrestricted,
so these policies don't necessarily provide any support,
control, capabilities, etc.
within PowerShell.
PowerShell will actually display a console message
saying that it's not supported.
Unrestricted on non‑Windows platforms basically
matches bypass on a Windows platform,
which effectively means you can do whatever you need to.
Now the most important thing here is to understand that enforcement of
these policies only occurs on Windows platforms.
Now when we talk about execution policies,
there are specific values that we can set.
The first one is what's called AllSigned.
When it's set as AllSigned PowerShell scripts can run; however,
those PowerShell scripts must be signed,
whether they are configuration files or PowerShell scripts,
whether they are downloaded from the internet,
whether you created them locally, it really makes no difference,
anything that needs to execute as a PowerShell script must be signed.
If we set to the Bypass option, then nothing is blocked,
there's no warnings or prompts,
and you can effectively execute whatever you need to.
The default option is normally set to Restricted for Windows clients
and then for servers it's set to RemoteSigned.
Now RemoteSigned is the default PowerShell policy for Windows Server computers,
which means that when PowerShell scripts are executed,
for example if you downloaded it from the internet,
then it needs to be signed with a publisher certificate,
one that's trusted.
Restricted is another option.
This is the default one for the client computers,
which does block access to executing scripts.
And then we have the most common one,
which I am guilty of setting in various environments,
is Unrestricted.
And this is the default one for non‑Windows computers,
and it really just helps me execute any kind of script that I need to.
So let's compare the two together.
Let's talk about AllSigned versus RemoteSigned.
So, in AllSigned mode scripts can run.
All the scripts and configuration files need signing by a trusted publisher,
so by an SSL certificate, a code signing one.
It will prompt you before executing scripts from untrusted publishers.
So for example, if you self signed it, you would be untrusted.
And there's still the risk of running signed malicious scripts either way.
If we set it to RemoteSigned, then, again,
scripts can run,
all internet‑downloaded scripts and configuration files
need to be signed by a trusted publisher,
there's no need to sign any scripts that are written locally because we've
told it to only require remote scripts to be signed,
and we still have the same risk of executing,
well, a little bit more actually,
of executing unsigned and signed malicious scripts.
What about if we compare Restricted to Unrestricted?
Well, in that scenario Restricted supports execution of individual commands,
but doesn't allow scripts to be executed.
In fact, it prevents running of all script files,
including configuration files, which would be the ps1xml files; modules,
psm1; and then scripts, ps1 files.
If we flick that to Unrestricted, then unsigned scripts can run,
risk of running malicious scripts can run,
and then of course it does warn before executing scripts,
but only those that are not from the local intranet zone itself.
So how do we retrieve the current execution policy?
Well, there's a PowerShell command called Get‑ExecutionPolicy,
which when we execute this will simply return which of
those options it's currently set for.
We can also then ask for a list of the policies and it will then show us
which ones currently affect the session that we are in.
We can also go one step further and we can utilize what's called a scope,
so the scope of the current user, the local machine,
the process,
to determine if there are different levels of execution
policies depending on the scope that's been set.
Now it's important to understand, we just talked about scopes,
that execution policies support scopes, but what are scopes?
Well, for execution policies our first one here is a machine policy scope.
This means that the security or the configuration has been defined
within a Group Policy for all the users of that computer.
The next scope would be user policy, which is defined,
again, within a Group Policy,
but it only affects the current user of the computer.
The next scope would be process.
This only affects the current PowerShell session that you're actively in.
Then we have current user, which only affects the current user,
and then we have local machine.
So I suppose the question is,
what's the difference between a machine policy and a
user policy versus current user, local machine?
Well, machine policy and user policy come by Group Policy designation only,
whereas process, current user,
and local machine can be done ad hocly by simply using
execution policy PowerShell commands.
Now it's important to understand that execution
policy scopes work in a certain way.
So the scope values work in precedence order.
So what I mean by that is if a current user policy exists,
then it will take precedence over all other policies.
Even if you have a more restrictive policy,
set at the lower level of importance, the higher priority one will always apply,
and we'll look at this again shortly.