Pour plusieurs raisons, principalement liées à la sécurité, les scripts PowerShell ne sont pas aussi facilement portables et utilisables que peuvent l’être les scripts batch. Cependant, nous pouvons regrouper un script batch avec nos scripts PowerShell pour contourner ces problèmes. Ici, nous allons vous montrer quelques-uns de ces problèmes et comment créer un script batch pour les contourner.
Pourquoi ne puis-je pas simplement copier mon fichier .PS1 sur un autre ordinateur et l’exécuter?
À moins que le système cible n’ait été préconfiguré pour permettre l’exécution de scripts arbitraires, avec les privilèges requis et en utilisant les bons paramètres, vous risquez de rencontrer des problèmes lorsque vous essayez de le faire.
- 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 associe les fichiers .PS1 au Bloc-notes par défaut, au lieu de les envoyer à l’interpréteur de commandes PowerShell. Cela permet d’éviter l’exécution accidentelle de scripts malveillants en double-cliquant simplement dessus. Il existe des moyens de modifier ce comportement, mais ce n’est probablement pas quelque chose que vous voulez faire sur tous les ordinateurs sur lesquels vous transportez vos scripts, surtout si certains de ces ordinateurs ne sont pas les vôtres. - PowerShell n’autorise pas l’exécution de script externe par défaut.
Le paramètre ExecutionPolicy dans 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 du tout 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. Cependant, c’est aussi quelque chose que vous ne voulez pas faire sur n’importe quel ordinateur. - Certains scripts PowerShell ne fonctionneront pas sans les autorisations d’administrateur.
Même avec un compte de niveau administrateur, vous devez toujours passer par le contrôle de compte d’utilisateur (UAC) pour effectuer certaines actions. Nous ne voulons pas désactiver cela, mais c’est toujours bien quand nous pouvons le rendre un peu plus facile à gérer. - Certains utilisateurs peuvent avoir des environnements PowerShell personnalisés.
Vous ne rencontrerez probablement pas souvent cela, mais lorsque vous le faites, l’exécution et le dépannage de vos scripts peuvent être un peu frustrants. Heureusement, nous pouvons contourner ce problème sans apporter de changements permanents.
Étape 1: Double-cliquez pour exécuter.
Commençons par aborder le premier problème – les associations de fichiers .PS1. Vous ne pouvez pas double-cliquer pour exécuter des fichiers .PS1, mais vous pouvez exécuter un fichier .BAT de cette façon. Nous allons donc écrire un fichier de commandes pour appeler le script PowerShell à partir de la ligne de commande pour nous.
Nous n’avons donc pas à réécrire le fichier de commandes pour chaque script, ou à chaque fois que nous déplaçons un script, il utilisera une variable d’auto-référencement pour créer le chemin du fichier pour le script PowerShell. Pour que cela fonctionne, le fichier de commandes devra être placé dans le même dossier que votre script PowerShell et avoir le même nom de fichier. Donc, si votre script PowerShell s’appelle «MyScript.ps1», vous voudrez nommer votre fichier de commandes «MyScript.bat» et vous assurer qu’il se trouve dans le même dossier. Ensuite, mettez ces lignes dans le script batch:
@ECHO OFF PowerShell.exe -Command "& '%~dpn0.ps1'" PAUSE
S’il n’y avait pas les autres restrictions de sécurité en place, ce serait vraiment tout ce qu’il faudrait pour exécuter un script PowerShell à partir d’un fichier de commandes. En fait, la première et la dernière ligne sont principalement une question de préférence – c’est la deuxième ligne qui fait vraiment le travail. Voici la répartition:
@ÉCHO OFF désactive l’écho des commandes. Cela empêche simplement vos autres commandes de s’afficher à l’écran lorsque le fichier de commandes s’exécute. Cette ligne est elle-même masquée par l’utilisation du symbole at (@) devant elle.
PowerShell.exe -Commande « & ‘% ~ dpn0.ps1 ′ » exécute en fait le script PowerShell. PowerShell.exe peut bien sûr être appelé à partir de n’importe quelle fenêtre CMD ou fichier de commandes pour lancer PowerShell sur une console nue comme d’habitude. Vous pouvez également l’utiliser pour exécuter des commandes directement à partir d’un fichier de commandes, en incluant le paramètre -Command et les arguments appropriés. La façon dont cela est utilisé pour cibler notre fichier .PS1 est avec la variable spéciale% ~ dpn0. Exécuté à partir d’un fichier de commandes,% ~ dpn0 évalue la lettre de lecteur, le chemin du dossier et le nom de fichier (sans extension) du fichier de commandes. Étant donné que le fichier de commandes et le script PowerShell se trouveront dans le même dossier et porteront le même nom,% ~ dpn0.ps1 se traduira par le chemin d’accès complet du fichier du script PowerShell.
PAUSE met simplement en pause l’exécution du lot et attend l’entrée de l’utilisateur. Il est généralement utile d’avoir à la fin de vos fichiers de commandes, de sorte que vous ayez une chance de revoir toute sortie de commande avant que la fenêtre ne disparaisse. Au fur et à mesure que nous testons chaque étape, l’utilité de cela deviendra plus évidente.
Ainsi, le fichier de commandes de base est configuré. À des fins de démonstration, ce fichier est enregistré sous «D: Script Lab MyScript.bat» et il y a un «MyScript.ps1» dans le même dossier. Voyons ce qui se passe lorsque nous double-cliquons sur MyScript.bat.
De toute évidence, le script PowerShell n’a pas été exécuté, mais il faut s’y attendre – nous n’avons abordé que le premier de nos quatre problèmes, après tout. Cependant, il y a quelques éléments importants démontrés ici:
- Le titre de la fenêtre montre que le script de commandes a lancé PowerShell avec succès.
- La première ligne de sortie montre qu’un profil PowerShell personnalisé est en cours d’utilisation. Il s’agit du problème potentiel n ° 4, répertorié ci-dessus.
- Le message d’erreur montre les restrictions ExecutionPolicy en vigueur. C’est notre problème n ° 2.
- La partie soulignée du message d’erreur (qui est effectuée de manière native par la sortie d’erreur de PowerShell) montre que le script de traitement ciblait correctement le script PowerShell prévu (D: Script Lab MyScript.ps1). Nous savons donc au moins que beaucoup de choses fonctionnent correctement.
Le profil, dans ce cas, est un simple script d’une ligne utilisé pour cette démonstration pour générer une sortie chaque fois que le profil est actif. Vous pouvez également personnaliser votre propre profil PowerShell pour ce faire, si vous souhaitez tester ces scripts vous-même. Ajoutez simplement la ligne suivante à votre script de profil:
Write-Output 'Custom PowerShell profile in effect!'
L’exécutionPolicy sur le système de test est ici définie sur RemoteSigned. Cela permet l’exécution de scripts créés localement (comme le script de profil), tout en bloquant les scripts provenant de sources externes à moins qu’ils ne soient signés par une autorité de confiance. À des fins de démonstration, la commande suivante a été utilisée pour marquer MyScript.ps1 comme provenant d’une source externe:
Add-Content -Path 'D:Script LabMyScript.ps1' -Value "[ZoneTransfer]`nZoneId=3" -Stream 'Zone.Identifier'
Cela définit le flux de données alternatif Zone.Identifier sur MyScript.ps1 afin que Windows pense que le fichier provient d’Internet. Il peut être facilement inversé avec la commande suivante:
Clear-Content -Path 'D:Script LabMyScript.ps1' -Stream 'Zone.Identifier'
Étape 2: Contourner ExecutionPolicy.
Contourner le paramètre ExecutionPolicy, à partir de CMD ou d’un script batch, est en fait assez facile. Nous modifions simplement la deuxième ligne du script pour ajouter un paramètre supplémentaire à la commande PowerShell.exe.
PowerShell.exe -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'"
Le paramètre -ExecutionPolicy peut être utilisé pour modifier l’ExecutionPolicy qui est utilisé lorsque vous créez une nouvelle session PowerShell. Cela ne persistera pas au-delà de cette session, nous pouvons donc exécuter PowerShell comme celui-ci chaque fois que nous en avons besoin sans affaiblir la posture de sécurité générale du système. Maintenant que nous avons résolu ce problème, recommençons:
Maintenant que le script s’est correctement exécuté, nous pouvons voir ce qu’il fait réellement. Cela nous permet de savoir que nous exécutons le script en tant qu’utilisateur limité. Le script est en fait exécuté par un compte avec des autorisations d’administrateur, mais le contrôle de compte d’utilisateur fait obstacle. Bien que les détails sur la façon dont le script vérifie l’accès administrateur sortent du cadre de cet article, voici le code utilisé pour la démonstration:
if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{Write-Output 'Running as Administrator!'}
else
{Write-Output 'Running Limited!'}
Pause
Vous remarquerez également qu’il existe maintenant deux opérations «Pause» dans la sortie du script – une du script PowerShell et une du fichier de commandes. La raison en sera plus évidente à l’étape suivante.
Étape 3: Obtention d’un accès administrateur.
Si votre script n’exécute aucune commande nécessitant une élévation et que vous êtes presque sûr que vous n’aurez pas à vous soucier des profils personnalisés de qui que ce soit qui vous gênent, vous pouvez ignorer le reste. Si vous exécutez des applets de commande de niveau administrateur, vous aurez besoin de cet élément.
Malheureusement, il n’y a aucun moyen de déclencher l’UAC pour l’élévation à partir d’un fichier de commandes ou d’une session CMD. Cependant, PowerShell nous permet de le faire avec Start-Process. Lorsqu’il est utilisé avec «-Verb RunAs» dans ses arguments, Start-Process essaiera de lancer une application avec des autorisations d’administrateur. Si la session PowerShell n’est pas déjà élevée, cela déclenchera une invite UAC. Pour utiliser cela à partir du fichier de commandes pour lancer notre script, nous finirons par générer deux processus PowerShell – un pour lancer Start-Process et un autre, lancé par Start-Process, pour exécuter le script. La deuxième ligne du fichier de commandes doit être modifiée comme suit:
PowerShell.exe -Command "& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}"
Lorsque le fichier de commandes est exécuté, la première ligne de sortie que nous verrons provient du script de profil PowerShell. Ensuite, il y aura une invite UAC lorsque Start-Process essaiera de lancer MyScript.ps1.
Après avoir cliqué sur l’invite UAC, une nouvelle instance PowerShell apparaîtra. Comme il s’agit d’une nouvelle instance, bien sûr, nous verrons à nouveau l’avis de script de profil. Ensuite, MyScript.ps1 s’exécute et nous voyons que nous sommes bien dans une session élevée.
Et il y a la raison pour laquelle nous avons deux pauses ici aussi. Sinon pour celui du script PowerShell, nous ne verrions jamais la sortie du script – la fenêtre PowerShell apparaîtrait et disparaîtrait dès que le script serait exécuté. Et sans la pause dans le fichier de commandes, nous ne pourrions pas voir s’il y avait des erreurs lors du lancement de PowerShell en premier lieu.
Étape 4: se déplacer dans les profils PowerShell personnalisés.
Débarrassons-nous de cet avis de profil personnalisé désagréable maintenant, d’accord? Ici, ce n’est même pas une nuisance, mais si le profil PowerShell d’un utilisateur modifie les paramètres par défaut, les variables ou les fonctions d’une manière que vous n’auriez peut-être pas anticipée avec votre script, cela peut être vraiment gênant. Il est beaucoup plus simple d’exécuter votre script sans le profil entièrement, vous n’avez donc pas à vous en soucier. Pour ce faire, il suffit de modifier à nouveau la deuxième ligne du fichier batch:
PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}"
L’ajout du paramètre -NoProfile aux deux instances de PowerShell qui sont lancées par le script signifie que le script de profil de l’utilisateur sera complètement contourné dans les deux étapes et que notre script PowerShell s’exécutera dans un environnement par défaut assez prévisible. Ici, vous pouvez voir qu’il n’y a pas d’avis de profil personnalisé dans l’un ou l’autre des obus générés.
Si vous n’avez pas besoin de droits d’administrateur dans votre script PowerShell et que vous avez ignoré l’étape 3, vous pouvez vous passer de la deuxième instance PowerShell et la deuxième ligne de votre fichier de commandes devrait ressembler à ceci:
PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'"
La sortie ressemblera alors à ceci:
(Bien sûr, pour les scripts non-administrateurs, vous pouvez également vous passer d’une pause de fin de script dans votre script PowerShell à ce stade, car tout est capturé dans la même fenêtre de console et y serait maintenu par la pause à la fin de le fichier de commandes quand même.)
Fichiers de commandes terminés.
Selon que vous avez besoin ou non des autorisations d’administrateur pour votre script PowerShell (et vous ne devriez vraiment pas les demander si vous ne le faites pas), le fichier de commandes final devrait ressembler à l’un des deux ci-dessous.
Sans accès administrateur:
@ECHO OFF PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'" PAUSE
Avec accès administrateur:
@ECHO OFF
PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}"
PAUSE
N’oubliez pas de placer le fichier de commandes dans le même dossier que le script PowerShell pour lequel vous souhaitez l’utiliser et de lui donner le même nom. Ensuite, quel que soit le système sur lequel vous transférez ces fichiers, vous pourrez exécuter votre script PowerShell sans avoir à vous soucier des paramètres de sécurité du système. Vous pouvez certainement effectuer ces modifications manuellement à chaque fois, mais cela vous évite ce problème et vous n’aurez pas à vous soucier d’annuler les modifications plus tard.
Références:
