La communication à distance de PowerShell (PSRemoting) est l’une des fonctionnalités les plus utilisées de tout PowerShell. Pourquoi ? Parce qu’elle est incroyablement utile ! En utilisant une seule commande, vous pouvez vous connecter de manière transparente à un ou des milliers d’ordinateurs distants et exécuter des commandes.
Dans ce Guide Ultime, vous plongerez profondément dans PSRemoting. Vous découvrirez ce que c’est, comment ça fonctionne, et toutes les technologies diverses qui permettent à PSRemoting de fonctionner. Ce guide ne couvrira pas comment utiliser PSRemoting. Vous verrez de nombreuses références à plusieurs de nos guides pratiques tout au long du processus.
Comment Fonctionne PSRemoting
En résumé, PSRemoting vous permet d’exécuter des commandes sur des ordinateurs distants comme si vous étiez assis devant eux. PSRemoting propose un ensemble de fonctionnalités qui connecte et authentifie un utilisateur, exécute des commandes à distance et renvoie toute sortie de cette commande à l’ordinateur local.
Imaginez PSRemoting comme telnet, SSH, voire même psexec. C’est simplement un moyen d’exécuter des commandes sur des ordinateurs via PowerShell.
PSRemoting repose fortement sur un concept appelé session. Une session est un terme utilisé pour décrire une coquille distante qui exécute des commandes à l’intérieur. Le processus de création d’une de ces sessions passe par de nombreuses étapes en arrière-plan.
Lorsque vous initiez une session PSRemoting, les étapes approximatives suivantes sont effectuées :
- Le client tente de se connecter au serveur de destination sur un écouteur WinRM (plus d’informations sur les écouteurs WinRm ci-dessous). Un écouteur WinRM est un petit service web qui s’exécute sur le serveur de destination. WinRM est l’implémentation de Microsoft d’une norme appelée WSMan. WSMan est une norme ouverte créée avec de nombreuses autres grandes entreprises technologiques de l’époque comme Dell, Intel et Sun Microsystems.
- Lorsque le client se connecte à l’écouteur via le protocole HTTP ou HTTPS, le processus d’authentification commence. Tous les détails de chaque méthode d’authentification seront abordés ultérieurement, mais pour l’instant, sachez simplement que le client doit transmettre des informations d’identification au serveur d’une manière ou d’une autre.
- Après que le client se soit connecté et authentifié auprès du serveur, PSRemoting crée une session.
- Une fois que PSRemoting a créé la session, elle est prête à être utilisée. À ce stade, le client peut commencer à envoyer des informations au serveur, qui renvoie toute sortie nécessaire, appelée sérialisation. Cette communication est généralement chiffrée.
Écouteurs WinRM : disponibles pour la connexion
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
Vous pouvez découvrir tous les écouteurs WinRm en cours d’exécution sur n’importe quel ordinateur Windows en utilisant la commande winrm ci-dessous.
Les écouteurs WinRm ont quelques composants importants. Ils ont :
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- Le type de transport – Chaque écouteur WinRM a besoin d’un moyen de communiquer avec le client ; ils le font via un transport utilisant soit HTTP soit HTTPS.
- Un empreinte de certificat facultative – Lorsqu’un écouteur WinRM utilise HTTPS pour le transport, il doit savoir quelle clé privée utiliser pour authentifier le client ; cette clé est trouvée en utilisant une empreinte de certificat.
Utilisez un écouteur HTTPS lorsque c’est possible. La configuration du transport HTTPS renforce la sécurité en garantissant la validité du serveur et en chiffrant à la fois l’authentification et le trafic de transport. Lors de l’émission d’un certificat, utilisez un certificat de confiance d’une autorité de certification, si possible, plutôt qu’un certificat auto-signé.
Hôtes de confiance : Validation d’un serveur
Comment fonctionne l’authentification PSRemoting sur WinRM
Comme mentionné précédemment, l’une des premières étapes de PSRemoting est l’authentification. L’authentification est l’une des parties les plus complexes mais essentielles de PSRemoting.
Lors de l’introduction de PSRemoting, il n’avait qu’un seul mécanisme d’authentification, Windows Remote Management (WinRM), mais de nos jours, vous pouvez également vous authentifier en utilisant SSH, comme vous le verrez plus tard.
WinRM prend en charge deux types distincts d’authentification : un nom d’utilisateur et un mot de passe, ou un certificat avec divers types d’authentification pour une combinaison nom d’utilisateur/mot de passe.
Authentification de base
En commençant par le plus facile, mais aussi le moins sécurisé, il y a l’authentification de base. Ce type d’authentification est une norme intégrée dans le protocole HTTP. L’authentification de base envoie une copie encodée en base64 du nom d’utilisateur et du mot de passe dans l’en-tête HTTP du client vers le récepteur.
Comme l’authentification de base ne fait que coder le nom d’utilisateur et le mot de passe sans les chiffrer, il est trivial d’intercepter les informations d’identification sur le réseau.
N’utilisez pas l’authentification de base à moins que vous n’ayez absolument pas d’autre choix. Il existe de nombreuses autres méthodes plus sécurisées par lesquelles WinRM peut s’authentifier !
Authentification Kerberos
Votre client et votre serveur se trouvent-ils tous deux dans un environnement Active Directory ? Si c’est le cas, vous utilisez déjà l’authentification Kerberos pour de nombreux services de votre réseau.
Lorsque le client WinRM tente de se connecter à un récepteur WinRM via Kerberos :
- Le serveur tente d’abord de récupérer une clé de session ou un ticket granting ticket pour le client depuis un contrôleur de domaine.
- Le contrôleur de domaine vérifie le client et le serveur et, s’ils sont valides et dignes de confiance, il émet le jeton.
- Le serveur valide ensuite la connexion du client en utilisant le jeton de confiance plutôt que le nom d’utilisateur et le mot de passe.
Pendant l’authentification Kerberos, le contrôleur de domaine valide à la fois le client et le serveur lors des étapes de récupération du ticket, empêchant ainsi toute personne malveillante d’usurper l’identité du serveur.
Kerberos est une méthode d’authentification mature et sécurisée, et c’est le type d’authentification par défaut lorsque le client et le serveur sont tous deux membres d’un domaine Active Directory. Cependant, cela nécessite que le client et le serveur soient tous deux intégrés au même domaine Active Directory ou qu’il existe une relation de confiance entre les domaines.
Authentification par négociation
WinRm peut également tenter d’utiliser Kerberos et, si ce n’est pas disponible, essayer d’utiliser un protocole d’authentification appelé NT Lan Manager (NTLM).
Lors de l’utilisation de NTLM :
- Le serveur envoie au client une chaîne.
- Le client chiffre ensuite la chaîne avec le hachage du mot de passe de l’utilisateur.
- La chaîne chiffrée est ensuite renvoyée au serveur qui envoie le nom d’utilisateur, la chaîne d’origine et la chaîne chiffrée à un contrôleur de domaine.
- Le contrôleur de domaine recherche ensuite le hachage du mot de passe de cet utilisateur et répète le même processus de chiffrement sur la chaîne pour s’assurer qu’elle correspond.
NTLM est bon pour valider le client, mais contrairement à Kerberos, il ne valide pas le serveur. Cela ouvre la porte à plusieurs attaques où le serveur pourrait être usurpé par un attaquant.
Vous pouvez améliorer la sécurité de NTLM en validant également le serveur avec un certificat d’authentification du serveur et en l’assignant à un écouteur WinRM HTTPS. Dans cette configuration, le client est authentifié avec NTLM auprès du contrôleur de domaine, et le serveur est authentifié avec un certificat de confiance. Bien que cette configuration fournisse à la fois une authentification du client et du serveur, le protocole NTLM utilise un chiffrement plus ancien avec une taille de clé obsolète.
Pour ces raisons, NTLM n’est utilisable que si vous ajoutez le serveur à la liste des hôtes de confiance ou utilisez un écouteur HTTPS.
Authentification par Digest
Une des méthodes d’authentification les moins courantes à utiliser dans WinRM est l’authentification par Digest. NTLM et Digest sont des méthodes d’authentification similaires. Comme NTLM, Digest génère une chaîne unique qui est chiffrée avec le hachage du mot de passe de l’utilisateur. Le mot de passe n’a alors pas besoin d’être envoyé au serveur.
Digest utilise l’algorithme de hachage MD5 pour chiffrer le mot de passe. En raison de ce choix d’algorithme, Digest est généralement considéré comme obsolète et ne devrait pas être utilisé. MD5 présente diverses vulnérabilités connues qui le rendent inadapté à une utilisation cryptographique.
Provider de Support de Sécurité des Informations d’Identification (CredSSP)
Bien que nous pourrions rentrer dans les détails de CredSSP, ce n’est pas nécessaire. Pourquoi ? Parce que quand il s’agit de PSRemoting et WinRM, CredSSP est généralement implémenté pour une raison, le « problème du deuxième saut » que vous découvrirez ci-dessous.
Lorsqu’il est configuré pour une authentification CredSSP, le client et le serveur WinRM utilisent tous deux une authentification par négociation pour authentifier à la fois l’utilisateur et le client. Mais une fois terminé, le mot de passe de l’utilisateur est envoyé au serveur.
Parce que le mot de passe est envoyé après que le processus d’authentification ait été terminé, il est désormais crypté. CredSSP crypte également le mot de passe avec les clés de session TLS de sorte que la chaîne cryptée soit unique entre les sessions.
CredSSP est utile car après l’authentification, le serveur peut alors se connecter à autre chose en votre nom. Cependant, lorsque cela se produit, vous faites entièrement confiance au serveur auquel vous vous êtes connecté avec le mot de passe utilisateur.
Authentification basée sur les certificats
On peut soutenir que la méthode d’authentification la plus sécurisée à utiliser avec PSRemoting est l’authentification basée sur les certificats. Dans cette méthode d’authentification, un échange de clés typique se produit avec une clé privée et publique sur le client et un serveur validant le certificat.
WinRM authentifie l’utilisateur en mappant un utilisateur sur le serveur dans WinRm. La seule chose qui est transmise pendant le processus d’authentification est la clé publique, donc c’est une manière très sécurisée d’authentifier
Bien que le plus sécurisé, l’authentification basée sur des certificats n’est pas trop courante. Pourquoi ? Tout simplement à cause du travail nécessaire pour le configurer. Vous devez :
- Construire une autorité de certification
- Créer un certificat d’authentification utilisateur
- Partager la clé publique
- Utiliser un compte utilisateur local avec les autorisations appropriées (groupe Administrateurs probablement)
- Configurer un écouteur HTTPS
- … et d’autres étapes.
Vous ne pouvez pas utiliser un utilisateur de domaine pour vous authentifier avec des certificats même si le client et le serveur font tous deux partie d’Active Directory.
Options d’authentification par défaut de l’OS Windows
Maintenant que vous avez vu qu’il existe de nombreuses options d’authentification différentes disponibles, comment savez-vous lesquelles sont disponibles par défaut ? Ci-dessous, vous verrez un tableau avec deux colonnes indiquant si le client WinRM, par défaut, est activé et si ce type d’authentification particulier est activé par défaut.
Tous les types d’authentification mentionnés ci-dessus sont configurables, mais en utilisant le tableau ci-dessous, vous aurez une bonne idée de ce que vous devrez configurer vous-même.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
Le Problème du deuxième saut ou problème du double saut
Un des plus gros problèmes avec PSRemoting est connu sous le nom de « problème du deuxième saut » ou « double saut ». Cette situation survient lorsque vous vous connectez à un système distant via PSRemoting et que vous devez ensuite vous connecter à un autre ordinateur distant.
Cette situation pose problème car lorsque le client WinRm s’authentifie sur le premier ordinateur distant, le serveur ne valide que l’identité du client d’origine sans envoyer le mot de passe au serveur. Lorsque vous essayez de vous connecter au deuxième ordinateur à partir du serveur de la première connexion, le dernier serveur n’a aucun moyen de valider l’identité de l’utilisateur.
Vous pouvez résoudre le problème du double saut de plusieurs manières, soit en utilisant CredSSP ou la délégation Kerberos.
Utilisation de CredSSP
La façon la plus courante de contourner le problème du double saut est d’utiliser CredSSP. L’authentification CredSSP contourne cette situation en stockant une information d’identification utilisateur sur le premier serveur distant que le serveur devenu client peut ensuite transmettre au deuxième serveur distant.
Il y a cependant un hic à l’utilisation de CredSSP. Les informations d’identification utilisateur stockées sur le premier serveur distant peuvent être stockées en texte clair, ce qui pose un problème de sécurité évident. Dans les systèmes d’exploitation plus récents, un hachage du mot de passe et du Ticket Granting Ticket (TGT) Kerberos peuvent être utilisés ensemble pour s’authentifier en tant qu’utilisateur n’importe où sur le réseau, tout comme un mot de passe en texte clair, mais cela réduit un peu le risque.
Avec la négociation, le client et le serveur échangent des informations pour se valider mutuellement, mais le mot de passe de l’utilisateur n’est jamais accessible. En raison de cette fonctionnalité de sécurité, il n’y a aucun moyen pour le premier serveur de vous authentifier lorsque vous vous connectez au deuxième serveur.
Utilisation de la Délégation Kerberos
Kerberos, comme mentionné précédemment, est une manière courante de configurer PSRemoting. Faisant partie du système Active Directory omniprésent et déjà configuré par défaut, il est extrêmement courant. Bien que Kerberos, en soi, soit une méthode appropriée pour authentifier WinRM, il ne résout pas le problème du double saut.
Pour contourner le scénario du double saut, vous pouvez utiliser un deuxième type d’authentification appelé Délégation Kerberos. Bien qu’il existe de nombreuses variantes de la Délégation Kerberos, la seule capable (et suffisamment sécurisée) de servir d’alternative à CredSSP est appelée Constrained Kerberos Délégation, plus précisément la Délégation Kerberos basée sur les ressources.
La Délégation Kerberos basée sur les ressources consiste à déléguer des jetons d’authentification Kerberos basés sur des ressources de domaine, comme des ordinateurs, dans ce cas, limités à une liste spécifique d’objets Kerberos (Active Directory).
Pour configurer cette délégation Kerberos, vous devez éditer l’objet ADComputer du troisième ordinateur dans la chaîne. Par exemple, si vous deviez vous connecter à distance depuis ClientA vers ServerB puis ServerC, vous devez éditer l’objet ADComputer pour ServerC, mais vous devez également savoir quel sera ServerB. Pour cet exemple, exécutez la commande ci-dessous dans PowerShell:
L’utilisation de la délégation Kerberos basée sur les ressources fonctionne pour les connexions à distance comme… ou… mais elle ne fonctionnera pas avec PSRemoting. Vous ne pourrez pas vous connecter à un troisième ordinateur lorsque vous êtes connecté à un ordinateur via WinRM en utilisant PSRemoting.
La configuration de la délégation Kerberos basée sur les ressources est une commande PowerShell en une seule ligne à l’aide de la cmdlet Set-ADComputer. Par exemple, si vous êtes connecté à ServerB depuis ClientA via PSRemoting et que vous souhaitez vous connecter à ServerC avec …, vous pouvez le faire en exécutant la commande PowerShell ci-dessous.
WinRm met en cache les connexions échouées pendant 15 minutes. En raison de cette fonctionnalité, vous pourriez ne pas être en mesure de vous connecter au troisième ordinateur même après avoir configuré la délégation Kerberos basée sur les ressources. Pour remédier à cela, attendez ou exécutez la commande
klist purge -LI 0x3e7sur le troisième ordinateur pour purger les jetons Kerberos échoués.
Comment fonctionne l’authentification PSRemoting sur SSH
Bien que l’authentification WinRM soit la méthode d’authentification la plus courante pour PSRemoting, depuis PowerShell v6, vous avez une autre option : SSH. Utiliser SSH comme méthode d’authentification vous permet d’utiliser PSRemoting avec Linux.
Contrairement à WinRM, SSH nécessite une configuration supplémentaire à la fois sur le client et sur le serveur, comme la configuration d’un client SSH sur le client Windows et…
L’utilisation de SSH pour gérer l’authentification signifie que vous êtes limité aux types d’authentification pris en charge par SSH. Cela réduit la liste aux deux principaux : l’authentification basée sur mot de passe et l’authentification basée sur une clé publique.
D’autres types d’authentification sont pris en charge par SSH, mais ils sont généralement considérés comme moins sécurisés que les options basées sur le mot de passe et la clé publique, nous nous concentrerons donc uniquement sur ces deux-là.
Authentification par mot de passe
La manière la plus simple de configurer l’authentification SSH avec PSRemoting est l’authentification basée sur le mot de passe. L’authentification basée sur mot de passe vous permet de fournir un mot de passe pour vous valider.
Dans le processus d’authentification SSH, le mot de passe est échangé après que la connexion SSH est établie et le mot de passe est crypté lors de la transmission. Contrairement à certaines méthodes d’authentification utilisées par WinRM, comme Kerberos, cette méthode d’authentification n’envoie pas le mot de passe complet au serveur.
On peut comparer l’authentification par mot de passe SSH à la méthode d’authentification de base de WinRM utilisant un écouteur HTTPS. Le mot de passe lui-même n’est pas protégé de manière significative, mais l’ensemble de la connexion, y compris le mot de passe, est chiffré et le serveur est validé sur la base d’un certificat.
Authentification basée sur les certificats
Alors que l’authentification par mot de passe est facile à configurer et simple à utiliser, elle présente deux problèmes.
- Le premier est qu’il n’y a aucun moyen de s’authentifier de manière sécurisée dans un format non assisté.
- L’authentification par mot de passe envoie toujours un mot de passe à travers le réseau. Bien que le mot de passe soit crypté dans la connexion SSH, le serveur reçoit le mot de passe complet. Si le serveur est compromis de quelque manière que ce soit, cela pourrait devenir un problème de sécurité.
L’authentification basée sur les certificats, en revanche, n’envoie aucune donnée sensible à travers le réseau comme le mot de passe. Au lieu de cela, le serveur possède une copie d’une clé publique, le client possède une copie de la clé privée et les négociations se déroulent sur le serveur.
A rough workflow goes as follows:
- Lorsque le client tente de s’authentifier, il envoie l’ID ou l’empreinte de la clé publique au serveur.
- Si le serveur a la clé publique répertoriée comme autorisée, il répond avec une chaîne chiffrée avec la clé publique.
- Le client déchiffre ensuite la chaîne avec la clé privée.
- La clé privée est ensuite hachée avec un ID de session.
- L’ID de session est renvoyé au serveur, qui le compare ensuite au hash généré à l’aide de la chaîne originale et de l’ID de session.
- Si le hash de l’ID de session côté client correspond à l’ID de session côté serveur, le client s’authentifie et est autorisé à se connecter.
Tout ce qui est chiffré avec la clé publique ne peut être déchiffré qu’avec la clé privée associée. Tout ce qui est chiffré avec la clé privée ne peut être déchiffré qu’avec la clé publique. L’ID de session est également inclus pour fournir ce que l’on appelle Perfect Forward Secrecy (PFS).
Le PFS offre une sécurité si la clé privée est compromise, l’attaquant ne serait pas en mesure de déchiffrer tous les messages échangés. Un ID de session unique signifie que le secret partagé utilisé pour chiffrer la communication est différent pour chaque session.
L’authentification basée sur des certificats avec SSH, comme WinRm, nécessite des efforts supplémentaires tels que la génération de la paire de clés privée/publique et l’autorisation de la clé publique sur le serveur distant.
Droits d’utilisateur requis pour se connecter
Par défaut, deux groupes locaux d’utilisateurs peuvent se connecter à un serveur à distance en utilisant PSRemoting; Administrateurs et Utilisateurs de gestion à distance.
Bien que vous puissiez simplement ajouter des comptes d’utilisateurs au groupe Administrateurs local sur un serveur distant, vous devriez toujours fournir le moins d’accès possible. Si un utilisateur a simplement besoin de se connecter avec PSRemoting à un ordinateur distant, vous pouvez ajouter le compte utilisateur au groupe Utilisateurs de gestion à distance; pas aux Administrateurs.
Pour contrôler davantage l’accès à PSRemoting, vous pouvez également utiliser une fonctionnalité appelée Administration Juste Assez (JEA). JEA permet aux utilisateurs non administrateurs d’exécuter uniquement des commandes spécifiques en tant qu’administrateurs dans le mode de langage restreint de PowerShell.
Implicit vs. « Explicit » Remoting
Si vous avez déjà utilisé PSRemoting, vous êtes probablement familier avec des commandes telles que Invoke-Command, New-PSSession, Enter-PSSession, etc. Lorsque vous exécutez ces commandes, il est clair que vous vous connectez d’une manière ou d’une autre à un ordinateur distant. Vous utilisez explicitement PSRemoting.
Lorsque vous exécutez des commandes spécifiques à PSRemoting, vous exécutez explicitement ces commandes, mais saviez-vous qu’il y a une autre façon ? Au lieu d’inviter directement Invoke-Command et d’autres cmdlets, vous pouvez exploiter PSRemoting en utilisant l’implicit PSRemoting.
L’Implicit PSRemoting peut donner l’impression que vous exécutez les commandes localement dans votre session PowerShell, mais elles s’exécutent en réalité sur une machine distante. Un bon exemple de cela est l’utilisation d’un module qui n’est pas installé sur votre système. Au lieu de l’installer localement, vous pouvez exporter les commandes depuis une PSSession, ce qui vous permettra de les exécuter comme si elles étaient installées localement.
Dans la capture d’écran ci-dessous, vous pouvez voir que je n’ai pas la commande Test-PendingReboot. Ensuite, j’ai établi une connexion avec une machine distante et exporté cette commande.
Ensuite, si ce module est importé, je peux exécuter la commande Test-PendingReboot. Cela est illustré ci-dessous, mais vous remarquerez que le nom de l’ordinateur dans la sortie n’est pas le nom du périphérique à partir duquel PowerShell s’exécute, mais le périphérique à partir duquel la commande a été importée.
