Comment configurer Windows pour qu'il fonctionne plus facilement avec les scripts PowerShell

Windows et PowerShell ont des fonctionnalités de sécurité intégrées et des configurations par défaut destinées à empêcher les utilisateurs finaux de lancer accidentellement des scripts dans le cadre de leurs activités quotidiennes. Toutefois, si vos activités quotidiennes impliquent régulièrement d’écrire et d’exécuter vos propres scripts PowerShell, cela peut être plus un inconvénient qu’un avantage. Ici, nous allons vous montrer comment contourner ces fonctionnalités sans compromettre totalement la sécurité..

Pourquoi et comment Windows et PowerShell empêchent-ils l'exécution de scripts?.

PowerShell est en réalité le shell de commande et le langage de script destinés à remplacer les scripts CMD et batch sur les systèmes Windows. En tant que tel, un script PowerShell peut être configuré pour faire tout ce que vous pouvez faire manuellement à partir de la ligne de commande. Cela équivaut à rendre pratiquement tous les changements possibles sur votre système, dans la limite des restrictions en vigueur sur votre compte utilisateur. Ainsi, si vous pouviez simplement cliquer deux fois sur un script PowerShell et l'exécuter avec les privilèges d'administrateur complets, une simple couche unique comme celle-ci pourrait vraiment gâcher votre journée:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorActionAction silencieuseContinuer

NE PAS exécuter la commande ci-dessus!

Cela passe simplement par le système de fichiers et supprime tout ce qu'il peut. Fait intéressant, cela peut ne pas rendre le système inutilisable aussi rapidement que vous le pensez, même lorsqu'il est exécuté à partir d'une session avec privilèges élevés. Mais si quelqu'un vous appelle après avoir exécuté ce script, parce que soudainement, il ne peut pas trouver ses fichiers ni exécuter certains programmes, «l'éteindre et l'activer à nouveau» les mènera probablement dans Windows Startup Repair où ils seront avertis. rien qui puisse être fait pour résoudre le problème. Ce qui pourrait être pire, c’est qu'au lieu d’obtenir un script qui bloque leur système de fichiers, votre ami pourrait être amené à en exécuter un qui télécharge et installe un enregistreur de frappe ou un service d’accès à distance. Ensuite, au lieu de vous poser des questions sur Startup Repair, ils risquent de poser des questions à la police sur la fraude bancaire!

Il devrait maintenant être évident de comprendre pourquoi certaines choses sont nécessaires pour protéger les utilisateurs finaux contre eux-mêmes, pour ainsi dire. Mais les utilisateurs chevronnés, les administrateurs système et les autres geeks sont généralement (à quelques exceptions près) un peu plus méfiants face à ces menaces, sachant les repérer et les éviter facilement, et souhaitant simplement continuer à travailler. Pour ce faire, ils devront soit désactiver, soit contourner quelques obstacles:

PowerShell n'autorise pas l'exécution de script externe par défaut.
Le paramètre ExecutionPolicy de PowerShell empêche l’exécution de scripts externes par défaut dans toutes les versions de Windows. Dans certaines versions de Windows, la valeur par défaut n'autorise pas l'exécution de script. Nous vous avons montré comment modifier ce paramètre dans Comment autoriser l'exécution de scripts PowerShell sous Windows 7, mais nous en parlerons également à quelques niveaux..
PowerShell n'est pas associé à l'extension de fichier .PS1 par défaut.
Nous en avons parlé initialement dans notre série PowerShell Geek School. Windows définit l'action par défaut pour que les fichiers .PS1 les ouvrent dans le Bloc-notes au lieu de les envoyer à l'interpréteur de commandes PowerShell. Ceci afin d'empêcher directement l'exécution accidentelle de scripts malveillants lorsqu'ils sont simplement double-cliqués.
Certains scripts PowerShell ne fonctionneront pas sans autorisations d'administrateur.
Même avec un compte de niveau administrateur, vous devez toujours utiliser le contrôle de compte d'utilisateur pour effectuer certaines actions. Pour les outils de ligne de commande, cela peut être un peu lourd pour le moins. Nous ne voulons pas désactiver le contrôle de compte d'utilisateur, mais il est toujours agréable de pouvoir le traiter un peu plus facilement..

Ces mêmes problèmes sont abordés dans la section Comment utiliser un fichier de commandes pour faciliter l’exécution des scripts PowerShell, dans laquelle nous vous expliquons comment écrire un fichier de commandes pour les contourner temporairement. Nous allons maintenant vous montrer comment configurer votre système avec une solution à plus long terme. N'oubliez pas qu'en règle générale, vous ne devez pas effectuer ces modifications sur des systèmes que vous n'utilisez pas exclusivement. Sinon, vous exposez les autres utilisateurs à un risque accru de rencontrer les mêmes problèmes que ces fonctionnalités visent à éviter..

Changer l’association de fichier .PS1.

L'association par défaut des fichiers .PS1 est le premier et peut-être le principal inconvénient à contourner. L'association de ces fichiers à autre chose que PowerShell.exe est utile pour empêcher l'exécution accidentelle de scripts indésirables. Toutefois, étant donné que PowerShell est livré avec un environnement ISE (Integrated Scripting Environment) spécialement conçu pour l'édition de scripts PowerShell, pourquoi voudrions-nous ouvrir les fichiers .PS1 dans le Bloc-notes par défaut? Même si vous n'êtes pas prêt à activer complètement la fonctionnalité de double-clic pour exécuter, vous voudrez probablement modifier ces paramètres.

Vous pouvez modifier l’association de fichiers .PS1 en choisissant le programme de votre choix à l’aide du panneau de configuration par défaut, mais le fait d’exploiter directement dans le registre vous donnera un peu plus de contrôle sur le mode d’ouverture des fichiers. Cela vous permet également de définir ou de modifier des options supplémentaires disponibles dans le menu contextuel pour les fichiers .PS1. N'oubliez pas de faire une sauvegarde du registre avant de le faire!

Les paramètres de registre contrôlant le mode d'ouverture des scripts PowerShell sont stockés à l'emplacement suivant:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Pour explorer ces paramètres avant de les modifier, jetez un œil à cette clé et à ses sous-clés avec Regedit. La clé Shell ne doit avoir qu'une seule valeur, «(Par défaut)», qui est définie sur «Ouvrir». Ceci est un pointeur sur l'action par défaut pour double-cliquer sur le fichier, ce que nous verrons dans les sous-clés.

Développez la clé Shell et vous verrez trois sous-clés. Chacun de ceux-ci représente une action que vous pouvez effectuer et qui est spécifique aux scripts PowerShell..

Vous pouvez développer chaque clé pour explorer les valeurs qu'il contient, mais elles correspondent fondamentalement aux valeurs par défaut suivantes:

0 - Exécuter avec PowerShell. "Exécuter avec PowerShell" est en fait le nom d'une option déjà présente dans le menu contextuel des scripts PowerShell. Le texte est simplement extrait d'un autre emplacement au lieu d'utiliser le nom de la clé comme les autres. Et ce n'est toujours pas l'action double-clic par défaut.
Modifier - Ouvrir dans PowerShell ISE. Cela est beaucoup plus logique que le Bloc-notes, mais vous devez toujours cliquer avec le bouton droit sur le fichier .PS1 pour le faire par défaut..
Ouvrir - Ouvrir dans le Bloc-notes. Notez que ce nom de clé est également la chaîne stockée dans la valeur «(Par défaut)» de la clé Shell. Cela signifie qu'un double-clic sur le fichier le «ouvrira» et que cette action est normalement configurée pour utiliser le Bloc-notes..

Si vous souhaitez vous en tenir aux chaînes de commande prédéfinies déjà disponibles, vous pouvez simplement modifier la valeur «(par défaut)» dans la clé Shell afin qu'elle corresponde au nom de la clé qui correspond à ce que vous souhaitez que vous fassiez par un double-clic. Cela peut facilement être fait à partir de Regedit ou vous pouvez utiliser les leçons de notre tutoriel sur l'exploration du registre avec PowerShell (plus un petit tweak PSDrive) pour commencer à créer un script réutilisable capable de configurer vos systèmes. Les commandes ci-dessous doivent être exécutées à partir d'une session PowerShell élevée, similaire à l'exécution de CMD en tant qu'administrateur..

Tout d'abord, vous souhaiterez configurer un lecteur PSDrive pour HKEY_CLASSES_ROOT, car celui-ci n'est pas configuré par défaut. La commande pour cela est:

Registre HKCR New-PSDrive HKEY_CLASSES_ROOT

Maintenant, vous pouvez naviguer et éditer les clés de registre et les valeurs dans HKEY_CLASSES_ROOT, exactement comme vous le feriez dans les HKCU et HKLM PSDrives classiques..

Pour configurer un double-clic afin de lancer les scripts PowerShell directement:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Par défaut)' 0

Pour configurer un double-clic pour ouvrir des scripts PowerShell dans PowerShell ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Par défaut) "Modifier"

Pour restaurer la valeur par défaut (double-cliquez pour ouvrir les scripts PowerShell dans le bloc-notes):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Par défaut) "Ouvrir'

Ce ne sont que les bases de la modification de l’action par défaut du double-clic. Nous verrons plus en détail comment personnaliser le traitement des scripts PowerShell lors de leur ouverture dans PowerShell à partir de l'Explorateur dans la section suivante. Gardez à l'esprit que la portée empêche les lecteurs PSDrive de persister d'une session à l'autre. Vous voudrez donc probablement inclure la ligne New-PSDrive au début de tout script de configuration que vous construisez à cet effet ou l'ajouter à votre profil PowerShell. Sinon, vous devrez exécuter ce bit manuellement avant d'essayer d'apporter des modifications de cette façon..

Modification du paramètre PowerShell ExecutionPolicy.

ExecutionPolicy de PowerShell constitue une autre couche de protection contre l'exécution de scripts malveillants. Il y a plusieurs options pour cela, et deux manières différentes de le configurer. Du plus sécurisé au moins sécurisé, les options disponibles sont les suivantes:

Restreint - Aucun script n'est autorisé à s'exécuter. (Paramètre par défaut pour la plupart des systèmes.) Cela empêchera même l’exécution de votre script de profil..
AllSigned - Tous les scripts doivent être signés numériquement par un éditeur approuvé pour s'exécuter sans que l'utilisateur ne soit invité à le faire. Les scripts signés par les éditeurs explicitement définis comme non approuvés, ou les scripts non signés numériquement, ne seront pas exécutés. PowerShell demandera à l'utilisateur de confirmer si un script est signé par un éditeur non défini comme approuvé ou non approuvé. Si vous n'avez pas signé numériquement votre script de profil et établi une confiance dans cette signature, celui-ci ne pourra pas être exécuté. Faites attention aux éditeurs en qui vous avez confiance, car vous pouvez toujours exécuter des scripts malveillants si vous faites confiance au mauvais..
RemoteSigned - Pour les scripts téléchargés depuis Internet, il s'agit en réalité de la même chose que «AllSigned». Toutefois, les scripts créés localement ou importés de sources autres qu'Internet sont autorisés à s'exécuter sans invite de confirmation. Ici, vous devrez également faire attention aux signatures numériques en lesquelles vous avez confiance, mais encore plus aux scripts non signés que vous choisissez d'exécuter. Il s'agit du niveau de sécurité le plus élevé sous lequel vous pouvez avoir un script de profil de travail sans avoir à le signer numériquement..
Sans restriction - Tous les scripts sont autorisés à s'exécuter, mais une invite de confirmation sera requise pour les scripts provenant d'Internet. À partir de ce moment, vous avez entièrement le choix d'éviter d'exécuter des scripts non fiables..
Bypass - Tout fonctionne sans avertissement. Soyez prudent avec celui-ci.
Non défini - Aucune stratégie n'est définie dans la portée actuelle. Ceci est utilisé pour permettre le retour aux stratégies définies dans les portées inférieures (plus de détails ci-dessous) ou aux valeurs par défaut du système d'exploitation.

Comme suggéré par la description de Undefined, les stratégies ci-dessus peuvent être définies dans un ou plusieurs domaines. Vous pouvez utiliser Get-ExecutionPolicy, avec le paramètre -List, pour voir toutes les étendues et leur configuration actuelle..

Les portées sont répertoriées par ordre de priorité, la portée définie la plus haute remplaçant toutes les autres. Si aucune stratégie n'est définie, le système revient à son paramètre par défaut (dans la plupart des cas, cela est restreint)..

MachinePolicy représente une stratégie de groupe en vigueur au niveau de l'ordinateur. Ceci est généralement appliqué uniquement dans un domaine, mais peut également être effectué localement.
UserPolicy représente une stratégie de groupe en vigueur pour l'utilisateur. Ceci est également généralement utilisé uniquement dans les environnements d'entreprise.
Le processus est une étendue spécifique à cette instance de PowerShell. Les modifications apportées à la stratégie dans cette étendue n’affecteront pas les autres processus PowerShell en cours d’exécution et seront inefficaces une fois la session terminée. Cela peut être configuré par le paramètre -ExecutionPolicy lors du lancement de PowerShell ou par la syntaxe Set-ExecutionPolicy appropriée depuis la session..
CurrentUser est une étendue configurée dans le registre local et s'applique au compte d'utilisateur utilisé pour lancer PowerShell. Cette portée peut être modifiée avec Set-ExecutionPolicy.
LocalMachine est une étendue configurée dans le registre local et s'appliquant à tous les utilisateurs du système. Il s'agit de l'étendue par défaut modifiée si Set-ExecutionPolicy est exécuté sans le paramètre -Scope. Comme il s’applique à tous les utilisateurs du système, il ne peut être modifié qu’à partir d’une session surélevée..

Étant donné que cet article traite principalement de la sécurité afin de faciliter la convivialité, nous nous intéressons uniquement aux trois portées les plus basses. Les paramètres MachinePolicy et UserPolicy ne sont vraiment utiles que si vous souhaitez appliquer une stratégie restrictive qui n'est pas simplement contournée. En conservant nos modifications au niveau Process ou inférieur, nous pouvons utiliser à tout moment le paramètre de stratégie que nous jugeons approprié pour une situation donnée..

Pour conserver un certain équilibre entre sécurité et convivialité, la stratégie présentée dans la capture d'écran est probablement la meilleure. La définition de la stratégie LocalMachine sur Restricted empêche généralement l'exécution de scripts par une personne autre que vous. Bien sûr, cela peut être évité par les utilisateurs qui savent ce qu'ils font sans trop d'effort. Mais cela devrait empêcher les utilisateurs non avertis en technologies de déclencher accidentellement quelque chose de catastrophique dans PowerShell. Le fait que CurrentUser (c'est-à-dire) soit défini sur Non restreint vous permet d'exécuter manuellement les scripts à partir de la ligne de commande comme bon vous semble, mais conserve un rappel de prudence pour les scripts téléchargés depuis Internet. Le paramètre RemoteSigned au niveau Processus doit être défini dans un raccourci vers PowerShell.exe ou (comme nous le ferons ci-après) dans les valeurs de registre qui contrôlent le comportement des scripts PowerShell. Cela facilitera la fonctionnalité de double-clic pour exécuter tous les scripts que vous écrivez, tout en mettant en place une barrière plus forte contre l'exécution non intentionnelle de scripts (potentiellement malveillants) à partir de sources externes. Nous voulons le faire ici car il est beaucoup plus facile de double-cliquer accidentellement sur un script que de l'appeler manuellement à partir d'une session interactive..

Pour définir les stratégies CurrentUser et LocalMachine comme dans la capture d'écran ci-dessus, exécutez les commandes suivantes à partir d'une session PowerShell avec privilèges élevés:

Set-ExecutionPolicy restreint Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Pour appliquer la stratégie RemoteSigned sur les scripts exécutés à partir de l'Explorateur, nous devrons modifier une valeur dans l'une des clés de registre que nous examinions précédemment. Cela est particulièrement important car, selon votre version de PowerShell ou de Windows, la configuration par défaut peut être de contourner tous les paramètres ExecutionPolicy sauf AllSigned. Pour voir quelle est la configuration actuelle de votre ordinateur, vous pouvez exécuter cette commande (en vous assurant que le HKCR PSDrive est mappé en premier):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Select-Object '(Par défaut)'

Votre configuration par défaut sera probablement l'une des deux chaînes suivantes, ou quelque chose d'assez similaire:

(Vu sur Windows 7 SP1 x64, avec PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-file" "% 1"

(Vu sous Windows 8.1 x64, avec PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "if ((Get-ExecutionPolicy) -ne 'AllSigned') Set-ExecutionPolicy -Scope Process Bypass; & '% 1 '"

Le premier n’est pas mauvais, car il ne fait qu’exécuter le script dans les paramètres ExecutionPolicy existants. Cela pourrait être amélioré en appliquant des restrictions plus strictes pour une action plus sujet aux accidents, mais cela n'était de toute façon pas initialement prévu pour être déclenché par un double-clic, et la stratégie par défaut est généralement restreinte après tout. La deuxième option, cependant, consiste à contourner complètement la politique d'exécution que vous êtes susceptible d'avoir en place, même restreinte. Étant donné que le contournement sera appliqué dans la portée du processus, il n’affecte que les sessions lancées lorsque les scripts sont exécutés à partir de l’explorateur. Cependant, cela signifie que vous pourriez éventuellement lancer des scripts auxquels vous pourriez vous attendre (et que vous voulez) que votre politique interdise..

Pour définir ExecutionPolicy au niveau processus pour les scripts lancés à partir de l'Explorateur, conformément à la capture d'écran ci-dessus, vous devez modifier la même valeur de registre que celle que nous venons de demander. Vous pouvez le faire manuellement dans Regedit, en le changeant comme suit:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

Vous pouvez également modifier le paramètre dans PowerShell si vous préférez. N'oubliez pas de faire cela à partir d'une session surélevée, avec le mappage HKCR PSDrive.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(Par défaut) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -ExecutionPolicy "" RemoteSigned "" -file "" %1"'

Exécuter des scripts PowerShell en tant qu'administrateur.

Tout comme il est déconseillé de désactiver entièrement le contrôle de compte d'utilisateur, il est également déconseillé d'exécuter des scripts ou des programmes dotés de privilèges élevés, sauf si vous en avez réellement besoin pour effectuer des opérations nécessitant un accès administrateur. Il est donc déconseillé de créer une invite UAC dans l'action par défaut des scripts PowerShell. Cependant, nous pouvons ajouter une nouvelle option de menu contextuel pour nous permettre d’exécuter facilement des scripts dans des sessions élevées lorsque cela est nécessaire. Cette méthode est similaire à la méthode utilisée pour ajouter «Ouvrir avec le Bloc-notes» au menu contextuel de tous les fichiers - mais, ici, nous allons uniquement cibler les scripts PowerShell. Nous allons également reprendre certaines techniques utilisées dans l'article précédent, dans lesquelles nous utilisions un fichier de commandes au lieu de piratages du registre pour lancer notre script PowerShell..

Pour faire cela dans Regedit, retournez dans la clé Shell à:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Là, créez une nouvelle sous-clé. Appelez-le “Exécuter avec PowerShell (Admin)”. En-dessous, créez une autre sous-clé appelée «Command». Définissez ensuite la valeur «(Par défaut)» sous Commande à ceci:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' -Verb RunAs  "

Faire la même chose dans PowerShell nécessitera en réalité trois lignes cette fois-ci. Un pour chaque nouvelle clé et un pour définir la valeur «(par défaut)» pour Command. N'oubliez pas l'altitude et la cartographie HKCR.

Nouvel élément 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Exécuter avec PowerShell (Admin)' Nouvel élément 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Exécuter avec PowerShell (Admin) \ Command' Set-ItemProperty ' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Exécuter avec PowerShell (Admin) \ Command "(valeur par défaut)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Processus de démarrage PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Exécution de verbe "'

Portez également une attention particulière aux différences entre la chaîne introduite dans PowerShell et la valeur réelle enregistrée dans le registre. En particulier, nous devons envelopper le tout entre guillemets simples et doubler les guillemets internes afin d'éviter des erreurs dans l'analyse des commandes..

Vous devriez maintenant avoir une nouvelle entrée de menu contextuel pour les scripts PowerShell, intitulée «Exécuter avec PowerShell (Admin)»..

La nouvelle option engendrera deux instances PowerShell consécutives. Le premier est juste un lanceur pour le second, qui utilise Start-Process avec le paramètre «-Verb RunAs» pour demander une élévation pour la nouvelle session. À partir de là, votre script devrait pouvoir être exécuté avec les privilèges d’administrateur après avoir cliqué sur l’invite UAC..

La touche finale.

Quelques ajustements supplémentaires à cela peuvent encore rendre la vie un peu plus facile. D'une part, que diriez-vous de vous débarrasser complètement de la fonction Notepad? Copiez simplement la valeur «(par défaut)» à partir de la touche de commande sous Éditer (ci-dessous), au même emplacement sous Ouvrir.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

Ou, vous pouvez utiliser ce morceau de PowerShell (avec Admin & HKCR bien sûr):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(par défaut) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe ""% 1 "'

Une autre gêne mineure est l’habitude de la console de disparaître une fois le script terminé. Lorsque cela se produit, nous n’avons aucune chance d’examiner les résultats du script à la recherche d’erreurs ou d’autres informations utiles. Cela peut être résolu en mettant une pause à la fin de chacun de vos scripts, bien sûr. Alternativement, nous pouvons modifier les valeurs «(par défaut)» pour nos touches de commande afin d'inclure le paramètre «-NoExit». Ci-dessous les valeurs modifiées.

(Sans accès administrateur)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

(Avec accès administrateur)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Processus de démarrage PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Verbes RunAs "

Et bien sûr, nous vous donnerons également les commandes PowerShell. Dernier rappel: Elevation & HKCR!

(Non-admin)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(par défaut) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned "" -file ""% 1 "'

(Admin)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Exécuter avec PowerShell (Admin) \ Command "(Par défaut)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Exécution de verbe "'

Prendre pour un tour.

Pour tester cela, nous allons utiliser un script qui peut nous montrer les paramètres ExecutionPolicy en place et indiquer si le script a été lancé avec les autorisations d'administrateur. Le script s'appellera «MyScript.ps1» et sera stocké dans «D: \ Script Lab» sur notre système exemple. Le code est ci-dessous, pour référence.

if (([[Security.Principal.WindowsPrincipal]] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrateur")) Write-Output 'Running as Administrator!' Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Utilisation de l'action "Exécuter avec PowerShell":

Utilisation de l'action «Exécuter avec PowerShell (Admin)», après avoir cliqué sur UAC:

Pour illustrer l'exécution de la stratégie d'exécution au niveau de la procédure, nous pouvons faire croire à Windows que le fichier provient d'Internet avec ce morceau de code PowerShell:

Add-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Value "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier '

Heureusement, nous avions activé -NoExit. Sinon, cette erreur aurait tout simplement disparu, et nous n'aurions pas su!

Le Zone.Identifier peut être supprimé avec ceci:

Clear-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

Références utiles:

Exécution de scripts PowerShell à partir d'un fichier de commandes - Blog de programmation de Daniel Schroeder
Vérification des autorisations d'administrateur dans PowerShell - Salut, scripteur! Blog