Pourquoi mon script créé localement n'est-il pas autorisé à s'exécuter dans le cadre de la politique d'exécution RemoteSigned ?

Question

Puisque cette question continue d'attirer des réponses qui sont soit réfutées par le corps de la question ou qui n'abordent pas le problème réel, veuillez lire ce simple résumé de ce que vous devez savoir :

• C'est no une question du type "Pourquoi mon installation par défaut de PowerShell n'exécute-t-elle pas les scripts ?".
• C'est no une question du type "Pourquoi mon installation de PowerShell n'exécute-t-elle pas les scripts téléchargés depuis l'internet ?".
• La question est de savoir pourquoi le RemoteSigned La politique d'exécution empêche l'exécution de script quand elle ne devrait pas.
• RemoteSigned es el sólo politique d'exécution que je veux utiliser. Je suis conscient que d'autres politiques moins restrictives sont disponibles. Si ces politiques étaient des substituts acceptables, je les aurais simplement utilisées à la place et cette question n'existerait pas.
• La politique d'exécution est déjà réglé sur RemoteSigned . En le changeant de RemoteSigned a RemoteSigned n'est pas une solution.
• Le fichier script est créé et stocké localement.
• Le fichier script n'est pas bloqué. Le fichier script n'a jamais été bloqué (voir point précédent).
• Le fichier script ne peut être débloqué car il n'y a rien à débloquer (voir point précédent).
• Le fichier script est (tenté d'être) exécuté par un administrateur.
• Windows PowerShell est la seule application concernée. Non Windows PowerShell ISE ni Command Prompt ni aucun autre outil ou éditeurs ne sont pertinents.
• La cause du problème a déjà a été identifié (voir réponse acceptée). Après presque 8 ans, je pense que toutes les autres explications évidentes explications évidentes, qu'elles soient applicables ou non, ont été postées aussi. Si vous pensez le contraire, alors veuillez lire la question et l'existant réponses existantes dans leur intégralité avant d'ajouter le vôtre.

---

J'utilise Windows PowerShell 2.0 sur Windows 7 Professionnel 64 bits. J'ai un script sur mon ordinateur. Desktop qui provoque l'erreur suivante lorsque j'essaie de l'exécuter :

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

Je suis à la fois un administrateur de domaine et un administrateur local, et si j'exécute Get-ExecutionPolicy -List je peux voir que le Group Policy Object que j'ai créé pour configurer PowerShell applique correctement les RemoteSigned politique d'exécution au niveau de la machine :

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

J'ai créé le script moi-même en Notepad et a utilisé le Sysinternals ' streams et le fichier Properties pour confirmer que le script n'est pas traité comme provenant d'internet. Si je copie le script sur un partage réseau sur un serveur de domaine, alors il est autorisé à s'exécuter. Si j'exécute Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine alors le script local n'est toujours pas autorisé à s'exécuter, ce qui est logique puisque la politique d'exécution au niveau du MachinePolicy aura la priorité.

Comme le montrent les documents suivants about_Execution_Policies ( actuel ; au moment de la question ), le RemoteSigned la politique signifie :

• Les scripts peuvent s'exécuter.

• Exige une signature numérique d'un éditeur de confiance sur les scripts et les fichiers de configuration qui sont téléchargés depuis Internet. (y compris les programmes de courrier électronique et de messagerie instantanée).

• N'exige pas de signatures numériques sur les scripts que vous avez exécutés et que vous avez écrits sur l'ordinateur local (et non téléchargés sur l'Internet).

• Risque d'exécuter des scripts non signés provenant de sources autres qu'Internet et des scripts signés, mais malveillants.

Mon script n'est pas signé, mais comme il est à la fois créé et exécuté localement, il devrait satisfaire au troisième point ci-dessus. Par conséquent...

• Pourquoi mon script n'est-il pas autorisé à s'exécuter ?
• Pourquoi PowerShell se plaint-il que mon script "n'est pas signé numériquement" alors que cette exigence ne devrait s'appliquer qu'aux fichiers provenant d'Internet ?
• Pourquoi PowerShell ne se soucie-t-il plus du fait que le script n'est pas signé lorsqu'il est exécuté depuis un partage réseau ?

Answer 1

Quelques éléments à vérifier :

Pouvez-vous passer à la catégorie "sans restriction" ?

Set-ExecutionPolicy Unrestricted

La politique de groupe est-elle définie ?

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

Aussi, comment appelez-vous script.ps1 ?

Cela lui permet-il de fonctionner ?

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

Answer 2

Le fichier est-il bloqué ? J'ai rencontré le même problème et j'ai pu le résoudre en cliquant avec le bouton droit de la souris sur le fichier .PS1, en sélectionnant Propriétés et en choisissant Débloquer.

Answer 3

Lorsque vous exécutez un script PowerShell .ps1, vous pouvez obtenir le message suivant : ".ps1 n'est pas signé numériquement. Le script ne s'exécutera pas sur le système." Pour le corriger, vous devez exécuter la commande ci-dessous pour exécuter Set-ExecutionPolicy et modifier le paramètre de la politique d'exécution.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Answer 4

J'ai découvert en exécutant un fichier PS1 pour un lecteur mappé à Dropbox que je reçois toujours cette erreur. En ouvrant les propriétés du PS1, il n'y a pas de "Unblock".

La seule chose qui fonctionne pour moi est

powershell.exe -executionpolicy bypass -file . \<strkeep>script<strkeep>.ps1

Answer 5

J'ai finalement trouvé la cause de ce problème Sécurité de l'accès au code .NET . J'ai quelques modules binaires développés en interne qui sont stockés et exécutés à partir d'un partage réseau. Pour que .NET 2.0/PowerShell 2.0 les chargent, j'avais ajouté une règle URL à l'élément Intranet groupe de code pour faire confiance à ce répertoire :

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

Notez que, selon les versions de .NET installées et selon qu'il s'agit de Windows 32 ou 64 bits, caspol.exe peut exister dans les endroits suivants, chacun avec sa propre configuration de sécurité ( 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\

Après avoir supprimé le groupe 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

...je me retrouve avec la configuration CAS par défaut et les scripts locaux fonctionnent à nouveau. Cela fait un moment que je n'ai pas bricolé avec le CAS, et je ne sais pas pourquoi ma règle semble interférer avec ces octrois.... FullTrust a MyComputer mais comme CAS est déprécié à partir de .NET 4.0 (sur lequel PowerShell 3.0 est basé), je suppose que c'est un point discutable maintenant.