powershell - scripts - ¿Por qué mi script creado localmente no puede ejecutarse bajo la política de ejecución RemoteSigned?

running scripts is disabled on this system windows 10

Question

Estoy usando Windows PowerShell 2.0 en Windows 7 Professional de 64 bits. Tengo un script en mi escritorio que causa el siguiente error cuando trato de ejecutarlo:

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

Soy un administrador de dominio y un administrador local, y si ejecuto Get-ExecutionPolicy -List , puedo ver que el Group Policy Object que creé para configurar PowerShell aplica correctamente la política de ejecución RemoteSigned a nivel de máquina:

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy    RemoteSigned
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine       Undefined

Creé el script yo mismo en el Notepad de Notepad , y utilicé la utilidad de streams Sysinternals y el cuadro de diálogo Properties del archivo para confirmar que el script no está siendo tratado como procedente de Internet. Si copio el script en un recurso compartido de red en un servidor de dominio, entonces se permite su ejecución. Si ejecuto Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine , el script local aún no se puede ejecutar, lo que tiene sentido ya que la política de ejecución en el alcance de MachinePolicy tendrá prioridad.

Tal como lo documenta about_Execution_Policies , la política RemoteSigned significa:

• Los scripts se pueden ejecutar.

• Requiere una firma digital de un editor de confianza en scripts y archivos de configuración que se descargan de Internet (incluidos los programas de correo electrónico y de mensajería instantánea).

• No requiere firmas digitales en las secuencias de comandos que ha ejecutado y que ha escrito en la computadora local (no descargadas de Internet).

• Riesgos que ejecutan scripts sin firmar de fuentes distintas de Internet y scripts firmados, pero maliciosos.

Mi secuencia de comandos no está firmada, pero dado que se crea y se ejecuta localmente, debe cumplir con el tercer punto anterior. Entonces, ¿por qué no se le permite correr? ¿Por qué PowerShell se queja de que mi script "no está firmado digitalmente" cuando ese requisito solo debería aplicarse a archivos de Internet? ¿Y por qué ya no le importa que el script no se firme cuando se ejecuta desde un recurso compartido de red?

Answer 1

¿Está el archivo bloqueado? Tuve el mismo problema y pude resolverlo haciendo clic con el botón derecho en el archivo .PS1, Propiedades y eligiendo Desbloquear.

Answer 2

Algunas cosas para verificar:

¿Puedes cambiar a irrestricto?

Set-ExecutionPolicy Unrestricted

¿Está establecida la política de grupo?

• Computer Configuration/Administrative Templates/Windows Components/Windows PowerShell
• User Configuration/Administrative Templates/Windows Components/Windows PowerShell

Además, ¿cómo llamas a Script.ps1?

¿Esto permite que se ejecute?

powershell.exe -executionpolicy bypass -file ./Script.ps1

Answer 3

Ejecuta debajo de 2 comandos en la ventana de PowerShell

1. Set-ExecutionPolicy sin restricciones

2. Desbloquear-Archivo -Path D: / PowerShell / Script.ps1

Answer 4

Estaba teniendo el mismo problema y lo solucioné cambiando el programa predeterminado para abrir archivos .ps1 en PowerShell. Fue establecido en el Notepad de Notepad .

Answer 5

Este es un problema IDE. Cambie la configuración en la GUI de PowerShell. Vaya a la pestaña Herramientas y seleccione Opciones, y luego Opciones de depuración . Luego marque la casilla Desactivar el requisito para que los scripts se firmen . Hecho.

Answer 6

Finalmente rastreé esto hasta .NET Code Access Security . Tengo algunos módulos binarios desarrollados internamente que se almacenan y ejecutan desde un recurso compartido de red. Para obtener .NET 2.0 / PowerShell 2.0 para cargarlos, agregué una regla de URL al grupo de códigos de Intranet para confiar en ese directorio:

PS C:/Users/UserName> & "$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

Tenga en cuenta que, dependiendo de qué versiones de .NET estén instaladas y si es Windows de 32 o 64 bits, caspol.exe puede existir en las siguientes ubicaciones, cada una con su propia configuración de security.config ( 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/

Después de eliminar el grupo 1.2.3 (dejándome con la configuración predeterminada para CAS), los scripts locales ahora funcionan nuevamente. Ha pasado un tiempo desde que hice ajustes con CAS, y no estoy seguro de por qué mi regla parece interferir con los que otorgan FullTrust a MyComputer , pero desde que CAS está en desuso desde .NET 4.0 (en el que se basa PowerShell 3.0) , Supongo que es un punto discutible ahora.

Answer 7

Intente ejecutar la GUI de Powershell como administrador

Answer 8

Lo que funciona para mí fue hacer clic derecho en el archivo .ps1 y luego en las propiedades. Haga clic en el botón "DESBLOQUEAR". Funciona muy bien después de pasar horas tratando de cambiar las políticas.

Answer 9

Si el archivo se copia desde una ubicación de red, es decir, otra computadora, Windows puede haber bloqueado ese archivo. Haga clic derecho en el archivo y haga clic en el botón de desbloqueo para ver si funciona.