Résolution des problèmes d'exécution de script PowerShell sur Windows Server 2008 R2

Dépannage des restrictions d'exécution de scripts PowerShell

Lorsqu'ils travaillent avec Windows Server 2008 R2, les utilisateurs peuvent rencontrer une erreur indiquant que l'exécution des scripts PowerShell est désactivée sur le système. Ce problème peut survenir lors de la tentative d'exécution d'un script via cmd.exe, même après avoir défini la stratégie d'exécution sur Sans restriction.

Malgré la confirmation que la politique d'exécution est définie sur Sans restriction, les scripts peuvent toujours ne pas s'exécuter, provoquant de la frustration et entravant la progression. Ce guide explorera les causes courantes de ce problème et fournira des étapes pour garantir une exécution réussie du script.

Comprendre et implémenter les politiques d'exécution de script dans PowerShell

Les scripts fournis visent à résoudre le problème de la désactivation de l'exécution des scripts PowerShell sur Windows Server 2008 R2. Le premier script définit la stratégie d'exécution sur **Bypass** pour la session PowerShell en cours à l'aide de **Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force**. Cette commande permet à tous les scripts de s'exécuter temporairement sans restriction. Le script accède ensuite au répertoire contenant le script **Management_Install.ps1** et l'exécute à l'aide de **powershell .Management_Install.ps1**. Cette approche garantit que le changement de politique d'exécution n'est que temporaire et n'affecte pas la sécurité globale du système.

Le deuxième script, un fichier batch, définit également la stratégie d'exécution sur **Contourner**, mais le fait à partir de la ligne de commande. Il utilise **powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"** pour y parvenir. Après avoir modifié la stratégie d'exécution, le script accède au répertoire de script et exécute le script PowerShell à l'aide de **powershell -File .Management_Install.ps1**. Le script batch se termine par une commande **pause** pour garder la fenêtre d'invite de commande ouverte, permettant à l'utilisateur de voir les messages de sortie ou d'erreur. Cette méthode est utile pour automatiser le processus et l’intégrer dans des processus par lots plus importants.

Signature de script et sécurité dans PowerShell

Le troisième exemple de script montre comment signer un script PowerShell pour se conformer à des politiques d'exécution plus strictes. Tout d'abord, un certificat auto-signé est créé à l'aide de **New-SelfSignedCertificate**. Ce certificat peut ensuite être exporté avec **Export-Certificate** et importé dans des magasins de certificats approuvés à l'aide de **Import-Certificate**. En important le certificat dans les magasins **TrustedPublisher** et **Root**, le système fera confiance aux scripts signés avec ce certificat. Le script **Management_Install.ps1** est ensuite signé à l'aide de **Set-AuthenticodeSignature**.

La signature de scripts garantit que seuls les scripts fiables peuvent s'exécuter sur le système, offrant ainsi une couche de sécurité supplémentaire. Cette approche est particulièrement utile dans les environnements soumis à des exigences de sécurité strictes où les stratégies d'exécution sont définies sur **AllSigned** ou **RemoteSigned**. En signant le script, les administrateurs peuvent garantir que les scripts ne sont pas falsifiés et proviennent d'une source fiable, atténuant ainsi les risques de sécurité potentiels. Cette méthode combine sécurité et fonctionnalité, permettant l’exécution des scripts nécessaires tout en préservant l’intégrité du système.

# Ensure the script execution policy is set to Bypass
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

# Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

# Execute the PowerShell script
powershell .\Management_Install.ps1

@echo off

:: Set PowerShell execution policy to Bypass
powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"

:: Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

:: Run the PowerShell script
powershell -File .\Management_Install.ps1

pause

# Sample script content
Write-Output "Executing Management Install Script"

# Save this script as Management_Install.ps1

# To sign the script, follow these steps:
# 1. Create a self-signed certificate (if you don't have one)
$cert = New-SelfSignedCertificate -DnsName "PowerShellLocalCert" -CertStoreLocation "Cert:\LocalMachine\My"

# 2. Export the certificate to a file
Export-Certificate -Cert $cert -FilePath "C:\PowerShellLocalCert.cer"

# 3. Import the certificate to Trusted Publishers and Trusted Root Certification Authorities
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher"
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\Root"

# 4. Sign the script with the certificate
Set-AuthenticodeSignature -FilePath .\Management_Install.ps1 -Certificate $cert

Garantir la conformité à la politique d’exécution des scripts et la sécurité du système

Lors de la gestion de Windows Server 2008 R2, il est crucial de comprendre les différentes stratégies d'exécution disponibles dans PowerShell et leur impact sur l'exécution des scripts. Les stratégies d'exécution PowerShell sont conçues pour empêcher l'exécution de scripts potentiellement dangereux. Les quatre stratégies principales sont **Restricted**, **AllSigned**, **RemoteSigned** et **Unrestricted**. **Restricted** est la stratégie par défaut et n'autorise l'exécution d'aucun script. **AllSigned** nécessite que tous les scripts et fichiers de configuration soient signés par un éditeur de confiance. **RemoteSigned** nécessite que tous les scripts et fichiers de configuration téléchargés sur Internet soient signés par un éditeur de confiance, mais permet aux scripts créés localement de s'exécuter sans signature.

Comprendre ces politiques aide les administrateurs à choisir le niveau de sécurité approprié pour leur environnement. Dans les scénarios où les scripts doivent être exécutés régulièrement, définir la stratégie sur **Sans restriction** peut être risqué, car cela permet à tous les scripts de s'exécuter sans aucune restriction. Les administrateurs devraient plutôt envisager d'utiliser **RemoteSigned** ou **AllSigned** pour équilibrer sécurité et fonctionnalité. En signant des scripts et en gérant les certificats, les administrateurs peuvent garantir que seuls des scripts fiables s'exécutent sur leurs systèmes, réduisant ainsi le risque d'exécution de code malveillant.