In the dynamic world of systems administration, proactive management is key to ensuring the security, stability, and performance of IT environments. One of the most powerful tools available to administrators is PowerShell, a scripting language and command-line environment that automates numerous tasks on Windows systems. Every week, every administrator should run a specific PowerShell script; this is a simple yet extremely effective tool for ensuring the smooth running of IT operations. This script, in particular, focuses on managing PowerShell script execution policies, a crucial and often overlooked aspect. This article explores this essential feature in depth.
Understanding PowerShell Script Execution Policy
The execution policy in PowerShell determines which commands and scripts can be executed on a system. It is a security feature that protects the user from the execution of malicious scripts. Understanding this policy and knowing how to configure it is essential for every administrator wishing to maintain a secure and efficient Windows environment. There are several levels of
execution policies, each with its own implications and security levels. Here’s an overview of the main policies available: Restricted:Blocks all scripts, allowing only interactive commands to be executed in the console.
- AllSigned: Only allows the execution of scripts signed by a trusted publisher.
- RemoteSigned: Allows the execution of unsigned local scripts, but blocks those originating from the internet unless they are signed.
- Unrestricted: Allows the execution of all scripts, but displays alerts for those originating from the internet.
- Bypass: Applies no restrictions, allowing all scripts to run without warning the user.
- Undefined: Indicates that the policy is not set, letting the top-level policy apply.
- For enterprise environments, the strategy AllSigned
is generally the most recommended, because it ensures a high level of security while still allowing the necessary execution of scripts. However, depending on the needs, other policies can be applied depending on the execution context. Exploring execution strategies To see what policy is currently applied on your system, the cmdlet
Get-ExecutionPolicy
can be used: Get-ExecutionPolicy To get a more detailed view of the execution policies on each scope, it is possible to use:
<!– wp:code {"content":"Get-ExecutionPolicyGet-ExecutionPolicy-List
This will display the policies applied to each scope, including for
<!– wp:code {"content":"Get-ExecutionPolicy -ListProcess
, CurrentUserAnd LocalMachine . ExtentExecution policy
| Process | policy applied to current PowerShell session |
|---|---|
| CurrentUser | policy applied to logged in user |
| LocalMachine | strategy applied to the entire machine |
| It’s a good idea to regularly review these configurations to ensure they still meet the organization’s security needs. | How to change the execution policy |
Changing the execution policy is a fairly simple process, but requires administrator privileges. Use the cmdlet
Set-ExecutionPolicy
allows you to define a new strategy. For example, to define a policy on AllSigned , the following command must be executed: Set-ExecutionPolicy -ExecutionPolicy AllSignedIt is also possible to specify the scope of application of this policy:
<!– wp:code {"content":"Set-ExecutionPolicy -ExecutionPolicy AllSignedSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
This command applies the policy only to the current user, which can be useful in a multi-user environment.
<!– wp:code {"content":"Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserIn an organization, it may be wise to set strict execution policies for all users to reduce the risks associated with running unverified scripts. Here are some best practices to consider:
Promote the use of the AllSigned policy to ensure that only verified scripts are executed.
Educate users about the risks associated with running downloaded scripts.
- Implement regular checks to verify compliance with execution policy settings. Documenting execution policies and the reasons behind their selection helps raise awareness and train administrative staff. Automate execution policy verification
- A good system administrator knows that proactive monitoring can save valuable time. Writing a small PowerShell script dedicated to checking the execution policy and sending alerts when changes are made can help maintain ongoing compliance.
- $executionPolicy = Get-ExecutionPolicy -List
if ($executionPolicy.CurrentUser -ne “AllSigned”) {
Send-MailMessage -To “[email protected]” -From “[email protected]” -Subject “Execution Policy Alert” -Body “User’s execution policy has changed.” -SmtpServer “smtp.example.com”
}
<!– wp:code {"content":"n$executionPolicy = Get-ExecutionPolicy -Listnif ($executionPolicy.CurrentUser -ne "AllSigned") {n Send-MailMessage -To "[email protected]" -From "[email protected]" -Subject "Alerte sur stratu00e9gie d'exu00e9cution" -Body "La politique d'exu00e9cution de l'utilisateur a changu00e9." -SmtpServer "smtp.example.com"n}nThis script sends an email to the appropriate administrator if the current execution policy does not meet the expected standard. This helps keep an eye out for unexpected and potentially dangerous changes. Here are some suggestions for improving your audit automation processes: Integrate checks for other security settings to complement execution policies. Schedule this script to run at defined intervals, for example, weekly.
Use configuration management tools such as Chef, Puppet, or SolarWinds to maintain the integrity of system configurations.
Reducing human risk by automating these checks allows you to focus on other critical aspects of IT management.
- Unblock a Secured PowerShell Script
- When scripts are downloaded from the internet, they can be marked as untrusted, preventing their execution by default as part of Windows security. To run them, they must be “unblocked” with the Unblock-File cmdlet.
- Unblock-File “C:TEMPscript.ps1” This command removes the security protection associated with the downloaded file. It is recommended to only use this command for files from trusted sources. Administrators should be careful when unblocking files and remember the following:Verify the integrity and source of the script before unblocking it. Document unblocked scripts to maintain inventory and traceability. Assess potential risks before giving the green light to run a sensitive script. Properly managing downloaded scripts can make a big difference in a system’s security posture. Administrative Execution of PowerShell Scripts
In many situations, running scripts requires administrative privileges to access certain system resources or apply critical changes. Here’s how an administrator can easily run a script with elevated privileges:
Start-Process powershell -Verb RunAs -ArgumentList “-File C:TEMPscript.ps1”
This launches a new PowerShell process with administrator privileges to run the specified script. Ensure users are trained on this method to avoid potential errors. It’s also possible to write a self-elevation script to automate this process:Start-Process PowerShell -Verb RunAs -ArgumentList “-NoProfile -ExecutionPolicy Bypass -File `$PSCommandPath”
<!– wp:code {"content":"Unblock-File "C:TEMPscript.ps1"Exit
}
With this approach, if a user tries to run the script without administrator privileges, the script will automatically restart with the required permissions. This is a secure method that simplifies the permissions management process.
- https://www.youtube.com/watch?v=ckiW2RKsrAc
Start-Process powershell -Verb RunAs -ArgumentList "-File C:TEMPscript.ps1"<!– wp:code {"content":"
nif (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {n Start-Process PowerShell -Verb RunAs -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File `$PSCommandPath"n Exitn}n