为什么不允许我在本地创建的脚本在RemoteSigned执行策略下运行? [英] Why is my locally-created script not allowed to run under the RemoteSigned execution policy?
问题描述
由于此问题继续吸引了以下任一人的回答:被问题主体反驳或未解决实际问题,请阅读以下有关您需要了解的简单摘要:
- 这不是 为什么我的默认安装的PowerShell运行脚本为什么不安装?"问题.
- 这不是 为什么我的PowerShell的安装不从互联网下载?问题.
- 问题是为什么
RemoteSigned
执行策略在不应该执行的情况下阻止脚本执行. -
RemoteSigned
是我要使用的 only 执行策略.我知道可以使用其他限制较少的策略.如果这些政策是可以接受的替代品,我本来会用它们的相反,这个问题将不存在. - 已将执行策略 设置为
RemoteSigned
.将其从RemoteSigned
更改为RemoteSigned
不是解决方案. - 脚本文件已创建并存储在本地.
- 脚本文件未被阻止.脚本文件从未被阻止(请参见上一点).
- 该脚本文件无法取消阻止,因为没有任何要取消阻止的内容(请参见上一点).
- 脚本文件由管理员执行(试图执行).
-
Windows PowerShell
是唯一涉及的应用程序.不是Windows PowerShell ISE
或Command Prompt
或任何其他工具或者编辑是相关的. - 已经 已确定问题的原因(请参见已接受的答案).近8年后,我认为其他所有显而易见的问题解释(无论是否适用)也已发布.如果如果您认为否则,请阅读该问题和现有内容在添加您的答案之前,先完整地回答 .
- This is not a "Why won't my default installation of PowerShell run scripts?" question.
- This is not a "Why won't my installation of PowerShell run scripts downloaded from the internet?" question.
- The question is why the
RemoteSigned
execution policy is preventing script execution when it shouldn't. RemoteSigned
is the only execution policy I want to use. I am aware that other, less-restrictive policies are available. If those policies were acceptable substitutes I would have just used them instead and this question wouldn't exist.- The execution policy is already set to
RemoteSigned
. Changing it fromRemoteSigned
toRemoteSigned
is not a solution. - The script file is created and stored locally.
- The script file is not blocked. The script file was never blocked (see previous point).
- The script file cannot be unblocked because there is nothing to unblock (see previous point).
- The script file is (attempted to be) executed by an administrator.
Windows PowerShell
is the only application involved. NotWindows PowerShell ISE
norCommand Prompt
nor any other tools or editors are relevant.- The cause of the problem has already been identified (see accepted answer). After nearly 8 years, I think all other obvious explanations, whether applicable or not, have been posted, too. If you think otherwise then please read the question and existing answers in their entirety before adding yours.
我在64位Windows 7 Professional上使用Windows PowerShell 2.0.我的 Desktop
上有一个脚本,当我尝试运行该脚本时会导致以下错误:
I am using Windows PowerShell 2.0 on 64-bit Windows 7 Professional. I have a script on my Desktop
that causes the following error when I try to run it:
File C:\Users\UserName\Desktop\Script.ps1 cannot be loaded. The file C:\Users\UserName\Desktop\Script.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing" for more details..
At line:1 char:54
+ C:\Users\UserName\Desktop\TestGetWindowsUpdateLog.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException
我既是域管理员又是本地管理员,如果我运行 Get-ExecutionPolicy -List
,则可以看到我创建的用于配置的 Group Policy Object
PowerShell在计算机级别正确地应用了 RemoteSigned
执行策略:
I am both a domain administrator and a local administrator, and if I run Get-ExecutionPolicy -List
, I can see that the Group Policy Object
I created to configure PowerShell is correctly applying the RemoteSigned
execution policy at the machine level:
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
我自己在记事本
中创建了脚本,并使用了 Sysinternals '<一个href ="https://docs.microsoft.com/sysinternals/downloads/streams" rel ="noreferrer"> streams
实用程序和文件 Properties
对话框以确认该脚本未被视为来自互联网.如果我将脚本复制到域服务器上的网络共享,则可以执行该脚本.如果我运行 Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine
,则仍然不允许执行本地脚本,这是有道理的,因为 MachinePolicy
范围的执行策略将采用优先.
I created the script myself in Notepad
, and used the Sysinternals' streams
utility and the file Properties
dialog to confirm that the script is not being treated as having come from the internet. If I copy the script to a network share on a domain server, then it's allowed to execute. If I run Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine
then the local script is still not allowed to execute, which makes sense since the execution policy at the MachinePolicy
scope will take precedence.
about_Execution_Policies
(当前; 在提出问题时), RemoteSigned
政策是指:
As documented by about_Execution_Policies
(current; at time of question), the RemoteSigned
policy means:
脚本可以运行.
Scripts can run.
需要从Internet上下载的脚本和配置文件上的可信发行商提供数字签名.(包括电子邮件和即时消息传递程序).
Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the Internet (including e-mail and instant messaging programs).
在运行的脚本和在本地计算机上编写的脚本上不需要数字签名(不是从以下位置下载的)互联网).
Does not require digital signatures on scripts that you have run and that you have written on the local computer (not downloaded from the Internet).
从Internet以外的其他来源运行未经签名的脚本和已签名但恶意的脚本的风险.
Risks running unsigned scripts from sources other than the Internet and signed, but malicious, scripts.
我的脚本没有签名,但是由于它是在本地创建和执行的,因此应该满足上面的第三个要点.因此...
My script is not signed, but since it is both created and executed locally, it should satisfy the third bullet point above. Therefore...
- 为什么不允许我的脚本运行?
- 为什么当该要求仅适用于Internet上的文件时,PowerShell为什么抱怨我的脚本未进行数字签名"?
- 为什么从网络共享运行脚本时,PowerShell不再关心脚本未签名?
推荐答案
我最终将其追溯到.NET代码访问安全性.我有一些内部开发的二进制模块,这些模块存储在网络共享上并从网络共享中执行.为了使.NET 2.0/PowerShell 2.0能够加载它们,我向 Intranet
代码组中添加了一个URL规则以信任该目录:
I finally tracked this down to .NET Code Access Security. I have some internally-developed binary modules that are stored on and executed from a network share. To get .NET 2.0/PowerShell 2.0 to load them, I had added a URL rule to the Intranet
code group to trust that directory:
PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups
Microsoft (R) .NET Framework CasPol 2.0.50727.5420
Copyright (c) Microsoft Corporation. All rights reserved.
Security is ON
Execution checking is ON
Policy change prompt is ON
Level = Machine
Code Groups:
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - ...: FullTrust
1.1.2. StrongName - ...: FullTrust
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.2.3. Url - file://Server/Share/Directory/WindowsPowerShell/Modules/*: FullTrust
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
请注意,根据安装的.NET版本以及32位或64位Windows,
Note that, depending on which versions of .NET are installed and whether it's 32- or 64-bit Windows, caspol.exe
can exist in the following locations, each with their own security configuration (security.config
):
-
$ Env:SystemRoot \ Microsoft.NET \ Framework \ v2.0.50727 \
-
$ Env:SystemRoot \ Microsoft.NET \ Framework64 \ v2.0.50727 \
-
$ Env:SystemRoot \ Microsoft.NET \ Framework \ v4.0.30319 \
-
$ Env:SystemRoot \ Microsoft.NET \ Framework64 \ v4.0.30319 \
删除组 1.2.3.
...
PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.
Microsoft (R) .NET Framework CasPol 2.0.50727.9136
Copyright (c) Microsoft Corporation. All rights reserved.
The operation you are performing will alter security policy.
Are you sure you want to perform this operation? (yes/no)
yes
Removed code group from the Machine level.
Success
...我保留了默认的CAS配置,本地脚本现在又可以工作了.自从我修改CAS以来已经有一段时间了,我不确定为什么我的规则似乎会干扰那些将 FullTrust
授予 MyComputer
的人,但是由于 CAS.(PowerShell 3.0所基于的),现在我想这是一个有争议的问题.
...I am left with the default CAS configuration and local scripts now work again. It's been a while since I've tinkered with CAS, and I'm not sure why my rule would seem to interfere with those granting FullTrust
to MyComputer
, but since CAS is deprecated as of .NET 4.0 (on which PowerShell 3.0 is based), I guess it's a moot point now.
这篇关于为什么不允许我在本地创建的脚本在RemoteSigned执行策略下运行?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!