Root Cause Analysis of Local Script Execution Failure Under PowerShell RemoteSigned Execution Policy

Problem Background and Phenomenon Description

In Windows PowerShell 2.0 environments, when the execution policy is set to RemoteSigned, locally created and unsigned scripts should theoretically execute normally. However, unexpected security exceptions occur in practice. The specific error message indicates: "File cannot be loaded. The file is not digitally signed. The script will not execute on the system." This anomalous behavior contradicts the design intent of the RemoteSigned policy.

Execution Policy and Security Mechanism Analysis

PowerShell's RemoteSigned execution policy aims to balance security and convenience. According to official documentation, this policy allows running locally created scripts without digital signatures, requiring digital signature verification only for scripts from the internet. This distinction is based on the file's "zone" attribute, with Windows system using Alternate Data Streams (ADS) to mark file origins.

Under standard configurations, locally created files are typically classified into the "MyComputer" zone with FullTrust permissions. However, when custom .NET Code Access Security configurations exist in the system, this default classification mechanism can be disrupted.

Root Cause: .NET Code Access Security Configuration Interference

Through in-depth investigation, the root cause was identified as custom .NET Code Access Security (CAS) policies. Specifically, URL rules targeting network share directories were added to the Intranet code group:

Url - file://Server/Share/Directory/WindowsPowerShell/Modules/*: FullTrust

While this configuration resolved network share module loading issues, it unexpectedly altered PowerShell's file zone determination logic. When processing file paths, the CAS system might misclassify local files into the Intranet zone instead of the expected MyComputer zone.

Diagnostic and Verification Methods

To confirm whether CAS configuration issues exist, diagnose using the following steps:

& "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups

This command displays the current machine's CAS policy configuration. Normal default configuration should include:

• MyComputer zone: FullTrust permissions
• Intranet zone: LocalIntranet permissions
• Internet zone: Internet permissions

If custom URL rules are found under the Intranet zone, particularly rules targeting file:// protocol, this could be the problem source.

Solution and Implementation Steps

To resolve this issue, remove the interfering CAS rules. Specific implementation steps:

& "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.

After executing this command, the system will prompt for confirmation; enter "yes" to continue. After successful removal, the CAS configuration returns to default state, resolving the local script execution issue.

Technical Deep Dive

The essence of this problem lies in the interaction between PowerShell's security model and the .NET CAS system. PowerShell relies on CAS to determine script execution permissions, while CAS makes security decisions based on file "evidence." When custom rules alter the evidence collection logic, permission determination anomalies occur.

Notably, starting from .NET 4.0, the CAS system has been marked as obsolete, with PowerShell 3.0 and later versions based on new security models. However, in PowerShell 2.0 environments, CAS remains the core security mechanism.

Best Practice Recommendations

To avoid similar issues, recommend:

• Modify CAS policies cautiously unless there are clear business requirements
• Regularly audit system security configurations
• Consider upgrading to newer PowerShell versions for better security models
• For scenarios requiring CAS usage, ensure rule design doesn't affect normal local operations

Conclusion

This paper provides detailed analysis of the root cause behind local script execution failures under PowerShell RemoteSigned policy, revealing how .NET CAS configurations impact script execution. Through systematic diagnostics and solutions, it offers complete technical pathways for handling similar problems. This case also reminds us that in complex system environments, interactions between different security mechanisms can produce unexpected results, requiring deep understanding of each component's working principles to effectively resolve issues.