Welcome PowerShell User! This recipe is just one of the hundreds of useful resources contained in the PowerShell Cookbook.
If you own the book already, login here to get free, online, searchable access to the entire book's content.
If not, the Windows PowerShell Cookbook is available at Amazon, or any of your other favourite book retailers. If you want to see what the PowerShell Cookbook has to offer, enjoy this free 90 page e-book sample: "The Windows PowerShell Interactive Shell".
You want to control PowerShell’s security features in an enterprise setting.
You have two ways to manage PowerShell’s security features enterprise-wide:
Apply PowerShell’s Group Policy templates to control PowerShell’s execution policy through Group Policy.
Deploy Microsoft Certificate Services to automatically generate Authenticode code-signing certificates for domain accounts.
Either separately or together, these features let you customize your PowerShell environment across your entire domain.
The administrative templates for Windows PowerShell let you override the machine’s local execution policy preference at both the machine and per-user level.
Administrative templates for Windows PowerShell are included in Windows by default. You can find the administrative templates for PowerShell Core in its $PSHome installation directory. To use them, copy the ADMX file into C:\Windows\PolicyDefinitions and the ADML file into C:\Windows\PolicyDefinitions\en-US, or use the InstallPSCorePolicyDefinitions.ps1 script to do this for you.
Although Group Policy settings override local preferences, PowerShell’s execution policy shouldn’t be considered a security measure that protects the system from the user. It’s a security measure that helps prevent untrusted scripts from running on the system. As mentioned in Recipe 18.1, PowerShell is only a vehicle that allows users to do what they already have the Windows permissions to do.
To edit the Group Policy settings, launch the Group Policy Object Editor MMC snap-in. The Group Policy Editor MMC snap-in provides PowerShell as an option under its Administrative Templates node, as shown in Figure 18-3. You can find PowerShell Core in the root of the Administrative Templates tree, and Windows PowerShell under Windows Components.
The default state is Not Configured. In this state, PowerShell takes its settings from the machine’s local preference (as described in Recipe 18.1). If you change the state to one of the Enabled options (or Disabled), PowerShell uses this configuration instead of the machine’s local preference.
PowerShell respects these Group Policy settings no matter what. This includes settings that the machine’s administrator may consider to reduce security—such as an Unrestricted group policy overriding an AllSigned local preference.
Per-user Group Policy settings override the machine’s local preference, whereas per-machine Group Policy settings override per-user settings.
Although outside the scope of this book, Microsoft Certificate Services lets you automatically deploy code-signing certificates to any or all domain users. This provides a significant benefit, as it helps protect users from accidental or malicious script tampering.
For an introduction to this topic, visit the Miscrosoft documentation site and search for “Enterprise Design for Certificate Services.” For more information about script signing, see Recipe 18.4.
Recipe 18.1, “Enable Scripting Through an Execution Policy”
Recipe 18.4, “Sign a PowerShell Script, Module, or Formatting File”