À propos des exigences à distance

Article
06/21/2023

DESCRIPTION COURTE

Décrit la configuration requise et la configuration système requises pour l’exécution de commandes distantes dans PowerShell.

DESCRIPTION DÉTAILLÉE

Cette rubrique décrit la configuration système requise, les exigences utilisateur et les ressources requises pour établir des connexions distantes et exécuter des commandes distantes dans PowerShell. Il fournit également des instructions pour la configuration des opérations distantes.

Remarque : De nombreuses applets de commande (notamment Get-Service, Get-Process, Get-WMIObject, Get-EventLog et Get-WinEvent applets de commande) obtiennent des objets à partir d’ordinateurs distants à l’aide de méthodes Microsoft .NET Framework pour récupérer les objets. Ils n’utilisent pas l’infrastructure de communication à distance PowerShell. Les exigences de ce document ne s’appliquent pas à ces applets de commande.

Pour rechercher les applets de commande qui ont un paramètre ComputerName, mais qui n’utilisent pas la communication à distance PowerShell, lisez la description du paramètre ComputerName des applets de commande.

CONFIGURATION SYSTÈME REQUISE

Pour exécuter des sessions distantes sur Windows PowerShell 3.0, les ordinateurs locaux et distants doivent avoir les éléments suivants :

Windows PowerShell 3.0 ou version ultérieure
Microsoft .NET Framework 4 ou version ultérieure
Gestion à distance Windows 3.0

Pour exécuter des sessions distantes sur Windows PowerShell 2.0, les ordinateurs locaux et distants doivent avoir les éléments suivants :

Windows PowerShell 2.0 ou version ultérieure
Microsoft .NET Framework 2.0 ou version ultérieure
Gestion à distance Windows 2.0

Vous pouvez créer des sessions distantes entre les ordinateurs exécutant Windows PowerShell 2.0 et Windows PowerShell 3.0. Toutefois, les fonctionnalités qui s’exécutent uniquement sur Windows PowerShell 3.0, telles que la possibilité de déconnecter et de se reconnecter aux sessions, ne sont disponibles que lorsque les deux ordinateurs exécutent Windows PowerShell 3.0.

Pour trouver le numéro de version d’une version installée de PowerShell, utilisez la variable automatique $PSVersionTable.

Windows Remote Management (WinRM) 3.0 et Microsoft .NET Framework 4 sont inclus dans Windows 8, Windows Server 2012 et versions plus récentes du système d’exploitation Windows. WinRM 3.0 est inclus dans Windows Management Framework 3.0 pour les systèmes d’exploitation plus anciens. Si l’ordinateur n’a pas la version requise de WinRM ou de Microsoft .NET Framework, l’installation échoue.

AUTORISATIONS DE L’UTILISATEUR

Pour créer des sessions distantes et exécuter des commandes distantes, par défaut, l’utilisateur actuel doit être membre du groupe Administrateurs sur l’ordinateur distant ou fournir les informations d’identification d’un administrateur. Sinon, la commande échoue.

Les autorisations requises pour créer des sessions et exécuter des commandes sur un ordinateur distant (ou dans une session distante sur l’ordinateur local) sont établies par la configuration de session (également appelée « point de terminaison ») sur l’ordinateur distant auquel la session se connecte. Plus précisément, le descripteur de sécurité sur la configuration de session détermine qui a accès à la configuration de session et qui peut l’utiliser pour se connecter.

Les descripteurs de sécurité sur les configurations de session par défaut, Microsoft.PowerShell, Microsoft.PowerShell32 et Microsoft.PowerShell.Workflow, autorisent l’accès uniquement aux membres du groupe Administrateurs.

Si l’utilisateur actuel n’a pas l’autorisation d’utiliser la configuration de session, la commande pour exécuter une commande (qui utilise une session temporaire) ou créer une session persistante sur l’ordinateur distant échoue. L’utilisateur peut utiliser le paramètre ConfigurationName des applets de commande qui créent des sessions pour sélectionner une configuration de session différente, si elle est disponible.

Les membres du groupe Administrateurs sur un ordinateur peuvent déterminer qui a l’autorisation de se connecter à l’ordinateur à distance en modifiant les descripteurs de sécurité sur les configurations de session par défaut et en créant de nouvelles configurations de session avec différents descripteurs de sécurité.

Pour plus d’informations sur les configurations de session, consultez about_Session_Configurations.

EMPLACEMENTS RÉSEAU WINDOWS

À compter de Windows PowerShell 3.0, l’applet de commande Enable-PSRemoting peut activer la communication à distance sur les versions client et serveur de Windows sur des réseaux privés, de domaine et publics.

Sur les versions serveur de Windows avec des réseaux privés et de domaine, l’applet de commande Enable-PSRemoting crée des règles de pare-feu qui autorisent l’accès à distance illimité. Il crée également une règle de pare-feu pour les réseaux publics qui autorise l’accès à distance uniquement à partir d’ordinateurs du même sous-réseau local. Cette règle de pare-feu de sous-réseau local est activée par défaut sur les versions serveur de Windows sur des réseaux publics, mais Enable-PSRemoting réapplique la règle en cas de modification ou de suppression.

Sur les versions clientes de Windows avec des réseaux privés et de domaine, par défaut, l’applet de commande Enable-PSRemoting crée des règles de pare-feu qui autorisent l’accès à distance illimité.

Pour activer la communication à distance sur les versions clientes de Windows avec des réseaux publics, utilisez le paramètre SkipNetworkProfileCheck de l’applet de commande Enable-PSRemoting. Il crée une règle de pare-feu qui autorise l’accès à distance uniquement à partir d’ordinateurs du même sous-réseau local.

Pour supprimer la restriction de sous-réseau local sur les réseaux publics et autoriser l’accès à distance à partir de tous les emplacements sur les versions client et serveur de Windows, utilisez l’applet de commande Set-NetFirewallRule dans le module NetSecurity. Exécutez la commande suivante :

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any

Dans Windows PowerShell 2.0, sur les versions serveur de Windows, Enable-PSRemoting crée des règles de pare-feu qui autorisent l’accès à distance sur tous les réseaux.

Dans Windows PowerShell 2.0, sur les versions clientes de Windows, Enable-PSRemoting crée des règles de pare-feu uniquement sur des réseaux privés et de domaine. Si l’emplacement réseau est public, Enable-PSRemoting échoue.

EXÉCUTER EN TANT QU’ADMINISTRATEUR

Les privilèges d’administrateur sont requis pour les opérations de communication à distance suivantes :

Établissement d’une connexion distante à l’ordinateur local. Il s’agit généralement d’un scénario de « bouclage ».
Gestion des configurations de session sur l’ordinateur local.
Affichage et modification des paramètres WS-Management sur l’ordinateur local. Voici les paramètres du nœud LocalHost du lecteur WSMAN :

Pour effectuer ces tâches, vous devez démarrer PowerShell avec l’option « Exécuter en tant qu’administrateur », même si vous êtes membre du groupe Administrateurs sur l’ordinateur local.

Dans Windows 7 et dans Windows Server 2008 R2, pour démarrer Windows PowerShell avec l’option « Exécuter en tant qu’administrateur » :

Cliquez sur Démarrer, cliquez sur Tous les programmes, sur Accessoires, puis sur le dossier Windows PowerShell.
Cliquez avec le bouton droit sur Windows PowerShell, puis cliquez sur « Exécuter en tant qu’administrateur ».

Pour démarrer Windows PowerShell avec l’option « Exécuter en tant qu’administrateur » :

Cliquez sur Démarrer, cliquez sur Tous les programmes, puis sur le dossier Windows PowerShell.
Cliquez avec le bouton droit sur Windows PowerShell, puis cliquez sur « Exécuter en tant qu’administrateur ».

L’option « Exécuter en tant qu’administrateur » est également disponible dans d’autres entrées de l’Explorateur Windows pour Windows PowerShell, y compris les raccourcis. Cliquez avec le bouton droit sur l’élément, puis cliquez sur « Exécuter en tant qu’administrateur ».

Lorsque vous démarrez Windows PowerShell à partir d’un autre programme tel que Cmd.exe, utilisez l’option « Exécuter en tant qu’administrateur » pour démarrer le programme.

COMMENT CONFIGURER VOTRE ORDINATEUR POUR LA COMMUNICATION À DISTANCE

Les ordinateurs exécutant toutes les versions prises en charge de Windows peuvent établir des connexions à distance et exécuter des commandes distantes dans PowerShell sans aucune configuration. Toutefois, pour recevoir des connexions et autoriser les utilisateurs à créer des sessions PowerShell gérées par l’utilisateur local et à distance (« PSSessions ») et à exécuter des commandes sur l’ordinateur local, vous devez activer la communication à distance PowerShell sur l’ordinateur.

Windows Server 2012 et les versions plus récentes de Windows Server sont activées pour la communication à distance PowerShell par défaut. Si les paramètres sont modifiés, vous pouvez restaurer les paramètres par défaut en exécutant l’applet de commande Enable-PSRemoting.

Sur toutes les autres versions prises en charge de Windows, vous devez exécuter l’applet de commande Enable-PSRemoting pour activer la communication à distance PowerShell.

Les fonctionnalités de communication à distance de PowerShell sont prises en charge par le service WinRM, qui est l’implémentation Microsoft du protocole WS-Management (Web Services for Management). Lorsque vous activez la communication à distance PowerShell, vous modifiez la configuration par défaut de WS-Management et ajoutez la configuration système qui permet aux utilisateurs de se connecter à WS-Management.

Pour configurer PowerShell pour recevoir des commandes distantes :

Démarrez PowerShell avec l’option « Exécuter en tant qu’administrateur ».
À l’invite de commandes, tapez : Enable-PSRemoting

Pour vérifier que la communication à distance est correctement configurée, exécutez une commande de test telle que la commande suivante, qui crée une session distante sur l’ordinateur local.

New-PSSession

Si la communication à distance est correctement configurée, la commande crée une session sur l’ordinateur local et retourne un objet qui représente la session. La sortie doit ressembler à l’exemple de sortie suivant :

Id Name        ComputerName    State    ConfigurationName
-- ----        ------------    -----    -----
1  Session1    localhost       Opened   Microsoft.PowerShell

Si la commande échoue, pour obtenir de l’aide, consultez about_Remote_Troubleshooting.

COMPRENDRE LES STRATÉGIES

Lorsque vous travaillez à distance, vous utilisez deux instances de PowerShell, une sur l’ordinateur local et une sur l’ordinateur distant. Par conséquent, votre travail est affecté par les stratégies Windows et les stratégies PowerShell sur les ordinateurs locaux et distants.

En général, avant de vous connecter et comme vous établissez la connexion, les stratégies sur l’ordinateur local sont en vigueur. Lorsque vous utilisez la connexion, les stratégies sur l’ordinateur distant sont en vigueur.

Limitations d’authentification de base sur Linux et macOS

Lors de la connexion d’un système Linux ou macOS à Windows, l’authentification de base via HTTP n’est pas prise en charge. L’authentification de base peut être utilisée via HTTPS en installant un certificat sur le serveur cible. Le certificat doit avoir un nom CN qui correspond au nom d’hôte, n’est pas expiré ou révoqué. Un certificat auto-signé peut être utilisé à des fins de test.

Découvrez comment : configurer WINRM pour HTTPS pour plus d’informations.

La commande suivante, exécutée à partir d’une invite de commandes avec élévation de privilèges, configure l’écouteur HTTPS sur Windows avec le certificat installé.

$hostinfo = '@{Hostname="<DNS_NAME>"; CertificateThumbprint="<THUMBPRINT>"}'
winrm create winrm/config/Listener?Address=*+Transport=HTTPS $hostinfo

Côté Linux ou macOS, sélectionnez Basic pour l’authentification et -UseSSl.

REMARQUE : L’authentification de base ne peut pas être utilisée avec des comptes de domaine ; un compte local est requis et le compte doit se trouver dans le groupe Administrateurs.

# The specified local user must have administrator rights on the target machine.
# Specify the unqualified username.
$cred = Get-Credential username
$session = New-PSSession -Computer <hostname> -Credential $cred `
  -Authentication Basic -UseSSL

Une alternative à l’authentification de base sur HTTPS est négocier. Cela entraîne l’authentification NTLM entre le client et le serveur et la charge utile est chiffrée via HTTP.

L’exemple suivant illustre l’utilisation de Negotiate with New-PSSession :

# The specified user must have administrator rights on the target machine.
$cred = Get-Credential username@hostname
$session = New-PSSession -Computer <hostname> -Credential $cred `
  -Authentication Negotiate

Notes

Windows Server nécessite un paramètre de Registre supplémentaire pour permettre aux administrateurs, autres que l’administrateur intégré, de se connecter à l’aide de NTLM. Reportez-vous au paramètre de Registre LocalAccountTokenFilterPolicy sous Négocier l’authentification dans l’authentification pour les connexions à distance