Set PowerShell Execution Policy For Non-Admin Users

Dec 24, 2025 by Andrew McMorgan 52 views

Hey guys, ever run into that frustrating roadblock in PowerShell where you need to change the execution policy for a non-admin user, but you're logged in as admin? It's a common pickle, especially in managed environments. You type Set-ExecutionPolicy, maybe try -Scope CurrentUser or LocalMachine, and bam! You hit a wall. This article is your guide to smashing through that wall, understanding why it happens, and how to effectively manage PowerShell execution policies for all your users, not just the admins. We'll dive deep into the nuances of scopes, explore the Windows Registry and Group Policy, and equip you with the knowledge to make this happen smoothly.

Understanding PowerShell Execution Policies and Scopes

Alright, let's kick things off by getting crystal clear on what PowerShell execution policies actually are and why they matter. Think of them as the security guards for your PowerShell scripts. By default, PowerShell might not run any scripts at all to protect your system from potentially malicious code. The execution policy defines which scripts, if any, you're allowed to run. This is a crucial security feature, folks! Now, when we talk about setting these policies, the Set-ExecutionPolicy cmdlet comes into play. It has a -Scope parameter, and this is where things get interesting. The default scopes like MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine are great, but they don't always cover the scenario where an admin needs to set a policy for a different non-admin user. LocalMachine affects everyone on the machine, CurrentUser only affects the user currently logged in, and Process is temporary. MachinePolicy and UserPolicy are usually managed by Group Policy, which we'll get to.

The core issue is that when you're an administrator, you can set policies at the LocalMachine scope, which affects all users. However, if you want to set a policy specifically for another user (who isn't you and isn't an admin), simply using Set-ExecutionPolicy -Scope CurrentUser won't work directly because you're not logged in as that user. You need a way to apply the policy to their specific user context without having to log in as them. This is where understanding the underlying mechanisms, particularly the Windows Registry and Group Policy, becomes essential. We're not just looking for a quick command; we're looking for a robust solution that respects user permissions and system security.

The Windows Registry: Where Policies Live

So, where does PowerShell actually store these execution policy settings? The answer, my friends, lies deep within the Windows Registry. This is the central database for configuration settings on Windows, and PowerShell leans on it heavily. Understanding the registry keys involved is key to manipulating policies, especially when you need to set them for other users. The primary locations we're interested in are within HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. Specifically, PowerShell looks for policy settings under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerShell
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerShell

When you use Set-ExecutionPolicy -Scope LocalMachine, you're essentially writing to the HKEY_LOCAL_MACHINE path. This policy then overrides any policy set at the CurrentUser scope for all users on that machine. Conversely, when you use Set-ExecutionPolicy -Scope CurrentUser, you're writing to the HKEY_CURRENT_USER path, affecting only the currently logged-in user. The magic, or rather the challenge, for setting a policy for another non-admin user when you're an admin is that you can't directly use Set-ExecutionPolicy -Scope CurrentUser for that other user because you're not operating within their user context.

However, the registry offers a workaround. As an administrator, you can directly manipulate the registry keys for other users if you know their Security Identifier (SID). This involves navigating to the HKEY_USERS hive, which contains the registry settings for all loaded user profiles. Under HKEY_USERS, you'll find subkeys named after the SIDs of various users on the machine. For the user you want to target, you would look for their SID, and then navigate to HKEY_USERS\<UserSID>\SOFTWARE\Policies\Microsoft\PowerShell. By creating or modifying the ExecutionPolicy DWORD value within this key, you can effectively set the execution policy for that specific user. This is a powerful technique, but it requires care and precision. You need to ensure you have the correct SID and that you're making changes in the right place. Remember, the LocalMachine policy (under HKEY_LOCAL_MACHINE) will always take precedence over a CurrentUser policy, including one set via HKEY_USERS\<UserSID>. Therefore, if a LocalMachine policy is in place, your CurrentUser or HKEY_USERS setting might not have the intended effect.

Group Policy: The Enterprise Solution

For managing execution policies across multiple machines or for many users in an organization, Group Policy is the go-to solution. It's the robust, scalable way to enforce settings, including PowerShell execution policies, without needing to touch individual machines or registries directly. Group Policy Objects (GPOs) allow administrators to define a wide range of configurations that are then applied to users and computers within an Active Directory domain or even on standalone machines using Local Group Policy Editor (gpedit.msc).

When it comes to PowerShell, Group Policy provides specific administrative templates that allow you to control the execution policy. These templates often map directly to the registry keys we discussed earlier (`HKEY_LOCAL_MACHINE

Computer Configuration: This section applies settings to the computer itself, regardless of who logs in. Policies set here often fall under the MachinePolicy scope for PowerShell and have the highest precedence. You'll find options like "Turn on Script Execution" here, which effectively controls the LocalMachine scope. This is ideal for ensuring that all machines in a certain organizational unit (OU) adhere to a specific security standard for running scripts. You can set it to "Allow local admin to choose", "Allow all scripts", "Disallow all scripts", or "Allow only signed scripts".
User Configuration: This section applies settings to users when they log in. Policies set here typically affect the UserPolicy scope for PowerShell. This is useful for enforcing specific execution policies for certain groups of users, perhaps allowing more flexibility for developers versus standard users. You can configure settings that dictate the execution policy behavior for users within their own context.

To implement this, you would typically:

Open Group Policy Management Console (GPMC) for domain environments or Local Group Policy Editor (gpedit.msc) for a single machine.
Navigate to the appropriate section (Computer Configuration or User Configuration) and then to Administrative Templates -> Windows Components -> Windows PowerShell.
Find and enable the "Turn on Script Execution" policy.
Choose the desired execution policy from the dropdown menu (e.g., RemoteSigned, Unrestricted, AllSigned, Restricted).

Crucially, Group Policy settings applied via Computer Configuration (like MachinePolicy) will always override settings applied via User Configuration (like UserPolicy) or even Set-ExecutionPolicy at the CurrentUser or LocalMachine scope. This is because Group Policy is designed for centralized, top-down administration. Therefore, if you want to ensure a specific policy is active for all users, including non-admins, configuring it under Computer Configuration is the most effective and reliable method. It ensures consistency and prevents users from bypassing the enforced setting.

Programmatic Approach: Leveraging PowerShell with Admin Privileges

While Group Policy is king for enterprise environments, you might still need a more direct, programmatic way to set the execution policy for a specific non-admin user without relying on Group Policy or logging in as that user. As an administrator, you can leverage PowerShell itself, combined with knowledge of user SIDs and registry manipulation, to achieve this. This involves running PowerShell with elevated privileges (as an administrator) and then targeting the specific user's registry hive.

Here's the breakdown of how you can approach this:

Identify the Target User's SID: You first need the Security Identifier (SID) of the user for whom you want to set the policy. You can find this using PowerShell commands like Get-LocalUser (for local users) or Get-ADUser (for domain users), and then extracting the SID property. For example, to get the SID of a local user named 'TestUser':
```
$userName = "TestUser"
$user = Get-LocalUser -Name $userName
$userSID = $user.SID.Value
Write-Host "User SID: $userSID"
```
If it's a domain user, you'd use Active Directory cmdlets.
Load the User's Registry Hive: Once you have the SID, you can load their registry hive under the HKEY_USERS root. This makes their specific registry settings accessible. You can do this using the reg command-line tool or by using PowerShell's registry provider, though directly manipulating the loaded hive is often cleaner. A common technique is to use Invoke-Command with the -Session parameter targeting a remote computer, or more practically for a local user, you can directly access their hive via HKEY_USERS\<UserSID>. PowerShell's registry provider allows you to navigate directly: HKU:\<UserSID>\SOFTWARE\Policies\Microsoft\PowerShell.

Set the Execution Policy Registry Value: Within the target user's loaded registry hive, you need to set the ExecutionPolicy DWORD value. You can use New-ItemProperty or Set-ItemProperty cmdlets for this. Ensure you are running these commands from an elevated PowerShell session.

# Example: Setting policy to RemoteSigned for a specific user SID
$targetUserSID = "S-1-5-21-..." # Replace with the actual User SID
$policyPath = "$($targetUserSID)\SOFTWARE\Policies\Microsoft\PowerShell"
$policyValueName = "ExecutionPolicy"
$policyValueData = "RemoteSigned" # Or 'AllSigned', 'Unrestricted', 'Restricted'

# Ensure the path exists, create if not
if (-not (Test-Path "Registry::HKU\$policyPath")) {
    New-Item -Path "Registry::HKU\$policyPath" -Force
}

# Set the execution policy value
Set-ItemProperty -Path "Registry::HKU\$policyPath" -Name $policyValueName -Value $policyValueData -Type String -Force
Write-Host "Execution policy set to $policyValueData for user SID $targetUserSID."

Important Note: The ExecutionPolicy registry value expects a String value representing the policy name (e.g., "RemoteSigned"), not a numeric representation. Make sure you use -Type String.

Consider Precedence: Remember, policies set under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerShell (typically via Group Policy's Computer Configuration) will always override policies set under HKEY_USERS\<UserSID>\SOFTWARE\Policies\Microsoft\PowerShell. If you want your specific user policy to be effective, ensure there isn't a conflicting MachinePolicy or LocalMachine policy that overrides it.

This method allows an administrator to precisely control execution policies for individual users without needing interactive access to their sessions or relying on Group Policy infrastructure. It's a powerful technique for custom deployments or troubleshooting specific user environments.

The `Set-ExecutionPolicy` Cmdlet and Its Limitations

Let's circle back to the Set-ExecutionPolicy cmdlet itself and really hammer home why it often falls short when trying to manage policies for other users. The cmdlet is designed primarily for the user running it, or for the entire machine. The -Scope parameter is the key here. When you use Set-ExecutionPolicy, you're operating within your current security context. If you're an administrator, you have the power to change settings that affect the whole machine (LocalMachine) or the current user (CurrentUser).

Here's a breakdown of the scopes and their implications:

MachinePolicy: This scope is read-only for the Set-ExecutionPolicy cmdlet. It's typically managed by Group Policy and dictates the execution policy for all users on the machine. As a regular user, you can't change this. Even as an admin, you usually manage this via GPO, not directly with Set-ExecutionPolicy.
UserPolicy: Similar to MachinePolicy, this scope is also read-only for Set-ExecutionPolicy. It's for policies applied to users via Group Policy and overrides CurrentUser settings. Again, managed via GPO.
Process: This scope is temporary. It applies only to the current PowerShell session and is lost when the session ends. It's useful for testing scripts within a specific session without making permanent changes.
CurrentUser: This scope affects only the user who is currently logged in. When you run Set-ExecutionPolicy -Scope CurrentUser, it modifies the registry settings under HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell. This is the most common scope for individual user settings.
LocalMachine: This scope affects all users on the computer. It modifies the registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell. This requires administrative privileges to change.

The problem arises when you, the administrator, want to set the policy for UserX (a non-admin user) without logging in as UserX. If you try Set-ExecutionPolicy -Scope CurrentUser - **For UserX**, it won't work because the cmdlet is running under your CurrentUser context, not UserX's. You could potentially use runas /user:UserX powershell.exe but that requires UserX's password, which is often impractical or undesirable. And even then, you might run into UAC prompts or permission issues.

This is precisely why understanding the registry and Group Policy becomes vital. These mechanisms allow you to set configurations that are associated with a specific user or machine, regardless of the current interactive session. The Set-ExecutionPolicy cmdlet is a convenient tool for managing your own context or the machine's global context, but for granular control over other users' environments, you need to look beyond its direct capabilities and work with the underlying system configurations.

Best Practices and Final Thoughts

So, we've covered a lot of ground, guys! We've seen how PowerShell execution policies work, explored the role of the Windows Registry and Group Policy, and discussed the limitations of the Set-ExecutionPolicy cmdlet. When it comes to setting execution policies for non-admin users as an administrator, remember these key takeaways:

Prioritize Group Policy for Scalability: If you're in an enterprise environment with Active Directory, Group Policy is your best friend. Use the administrative templates to enforce execution policies centrally. This is the cleanest, most manageable, and most secure approach, ensuring consistency across your network.
Leverage Registry for Specific Needs: If Group Policy isn't an option or you need to target a specific user on a standalone machine, direct registry manipulation using an elevated PowerShell session is the way to go. Remember to target the correct user SID under HKEY_USERS.
Understand Scope Precedence: Always keep in mind that MachinePolicy (via GPO Computer Configuration) > UserPolicy (via GPO User Configuration) > LocalMachine > CurrentUser > Process. Policies higher in this hierarchy will override lower ones. Ensure your chosen method aligns with the desired outcome and doesn't conflict with existing higher-priority policies.
Run with Elevated Privileges: Whenever you're making system-wide changes or modifying settings for other users (especially via the registry), ensure your PowerShell session is running as an administrator. Right-click -> 'Run as administrator' is your mantra!
Use RemoteSigned: For most scenarios, the RemoteSigned execution policy is a good balance between security and usability. It allows local scripts to run freely but requires scripts downloaded from the internet to be signed by a trusted publisher. Avoid Unrestricted unless you have a very specific, controlled environment.
Test Thoroughly: After making changes, always log in as the target user (or have them test) to verify that the execution policy is applied as expected. Sometimes, a reboot or a new login session is required for registry changes to take full effect.

Managing execution policies can seem complex, especially when dealing with different user contexts. By understanding the underlying mechanisms and choosing the right tool for the job – whether it's Group Policy, direct registry edits, or understanding the Set-ExecutionPolicy cmdlet's scope – you can effectively control script execution and keep your systems secure. Stay safe out there, and happy scripting!