Utiliser WinRM pour la gestion à distance d’un serveur Windows

Après avoir vu comment gérer notre serveur à distance en utilisant le service Bureau à distance, nous allons voir le protocole WinRM.

I. Qu’est-ce que WinRM ?

WinRM, Windows Remote Management, repose sur du HTTP et il est l’implémentation chez Microsoft du standard WS-Management, basé sur SOAP. Ceci implique qu’il n’est plus un protocole RPC et peut donc passer plus facilement les firewalls.

Au niveau des ports utilisés, on en trouve deux :

• HTTP : 5985
• HTTPS : 5986

Il est préférable d’utiliser la déclinaison HTTPS du protocole WinRM (sur le port 5986) afin de profiter d’une connexion sécurisée. Cependant, il faut disposer d’un service de génération de certificat pour signer les communications.

II. WinRM est-il opérationnel ?

Sous Windows Server Core, la « Gestion à distance » est activée par défaut, ce qui implique que WinRM est actif. Pour s’en assurer, contrôlez l’état du service WinRM :

Get-Service WinRM

On remarque sur la copie d’écran ci-dessous que le service est sur l’état « Running » ce qui signifie qu’il est en cours d’exécution.

Get-Service WinRM
Get-Service WinRM

De ce fait, l’utilisation du protocole WinRM est envisageable dès à présent.

Que faire si ce n’est pas le cas ?

Ouvrez l’utilitaire « sconfig » et si l’option « Configurer l’administration à distance » est sur « Désactivé » alors indiquez le choix « 4 ». Ensuite, indiquez « 1 » pour activer la gestion à distance (WinRM) et patientez jusqu’à la validation. Vérifiez à nouveau que le service WinRM est bien en cours.

Si l'on veut le faire avec PowerShell, car nous sommes là pour manipuler PowerShell au maximum, il suffit d'exécuter la commande suivante :

Enable-PSRemoting

Cette commande toute simple va permettre de configurer le service WinRM, de gérer le pare-feu Windows, etc... Une autre façon de faire, c'est d'utiliser la commande suivante qui est un peu historique et qui existait avant le cmdlet Enable-PSRemoting :

winrm quickconfig

Dans le même esprit que la commande PowerShell, cette commande permet de réaliser une configuration rapide de WinRM, dans le but de démarrer le service et de faire en sorte qu'il démarre automatiquement. Cela va également permettre de créer une exception dans le pare-feu de Windows pour autoriser les connexions et de créer un listener pour être à l'écoute des demandes de connexion.

Voici un exemple :

Exemple - winrm quickconfig
Exemple - winrm quickconfig

WinRM étant actif sur notre Windows Server, nous pouvons poursuivre.

III. Par quels biais utiliser WinRM ?

Trois méthodes d’administration principales s’appuient sur WinRM :

  • Ouverture de session PowerShell à distance
  • Administration à distance du serveur via le « Gestionnaire de serveur » d’un autre serveur
  • Administration à distance du serveur via Windows Admin Center

IV. Ouvrir une session PowerShell à distance

Toujours dans l’environnement Active Directory que j’utilise depuis le départ, au sein du domaine « it-connect.local », je vais tenter à partir d’un PC sous Windows nommé « PC-01 » d’ouvrir une session PowerShell à distance à destination du serveur « CORE01 ». Bien entendu, via WinRM.

Pour ouvrir une connexion PowerShell à distance, on s’appuie sur le commandlet « Enter-PSSession », comme ceci :

Enter-PSSession -ComputerName CORE01 -Credential "IT-CONNECT\Administrateur"

Pour expliquer la commande ci-dessus, on précise le nom de l’hôte cible (ComputerName) et le compte utilisateur à utiliser se connecter (Credential). Une fois la commande validée, il est nécessaire d’indiquer le mot de passe de l’utilisateur précisé dans le paramètre Credential.

Ouvrir une session PowerShell à distance avec Enter-PSSession
Ouvrir une session PowerShell à distance avec Enter-PSSession

Après quelques secondes, la connexion doit être établie et vous devez être connecté sur le serveur CORE01 depuis le PC-01, et ce à distance via WinRM !

On remarque que l’on se trouve sur le serveur distant, car la ligne de commande est précédée par « [CORE01] ». Pour le vérifier, il suffit de saisir la commande « hostname » et on remarque que la valeur « CORE01 » est retournée : bravo ! Vous êtes bien connectés à l’hôte distant 😉

Administrez votre serveur comme si vous étiez directement connecté dessus. Pour terminer la session à tout moment, saisissez « exit ».

V. Afficher la configuration actuelle de WinRM

WinRM est un service qui dispose de sa propre configuration. Une configuration que l'on peut récupérer à l'aide de la commande suivante :

winrm get winrm/config

On obtient une sortie très complète de toute la configuration WinRM.

Si l'on veut afficher une partie spécifique de la configuration, par exemple tout le bloc "Client", on peut affiner notre commande de cette manière :

winrm get winrm/config/client

La sortie de cette commande est intéressante dans le sens où l'on peut voir quelles sont les méthodes d'authentification autorisées (Auth > Basic / Kerberos / etc.), mais aussi les hôtes de confiance déclarés (TrustedHosts).

VI. Administrer un serveur via WinRM depuis un PC hors domaine

Si vous administrez un serveur via WinRM à partir d'un autre serveur ou d'un poste de travail membre du même domaine Active Directory, l'authentification va fonctionner sans problème et WinRM va autoriser la connexion.

Par contre, si vous effectuez la connexion depuis un PC qui n'est pas membre du même domaine Active Directory que le serveur cible, je suis à peu près sûr que vous allez avoir un message d'erreur. Pourtant, c'est un cas classique, surtout si l'on travaille chez un prestataire de service et que l'on administre les serveurs de ses clients... Par sécurité, WinRM est configuré par défaut pour bloquer ce type de connexion, sauf si l'authentification est effectuée via HTTPS ou que l'hôte distant (notre PC) est déclaré en tant qu'hôte de confiance (TrustedHosts).

Voici deux messages d'erreur que vous pouvez rencontrer :

Enter-PSSession: Connecting to remote server CORE01.it-connect.local failed with the following error message : Le client WinRM ne peut pas traiter la demande. Si le modèle d’authentification n’est pas Kerberos, ou si l’ordinateur client n’est pas membre d’un domaine, le transport HTTPS doit être utilisé ou l’ordinateur de destination doit être ajouté au paramètre de configuration TrustedHosts. Utilisez winrm.cmd pour configurer TrustedHosts. Notez que les ordinateurs dans la liste TrustedHosts ne sont peut-être pas authentifiés. Pour plus d’informations, exécutez la commande suivante : winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

Et :

Enter-PSSession: Connecting to remote server CORE01.it-connect.local failed with the following error message : Accès refusé. For more information, see the about_Remote_Troubleshooting Help topic.

Dans ce cas, nous devons effectuer deux actions :

  • Ajouter notre PC en tant qu'hôte de confiance sur le serveur où l'on souhaite se connecter via WinRM
  • Ajouter notre serveur cible en tant qu'hôte de confiance depuis le PC où l'on émet la connexion WinRM

Autrement dit, il faut que les hôtes s'approuvent mutuellement.

  • Sur le serveur cible - CORE01

Sur le serveur CORE01, je vais approuver mon PC qui est hors domaine Active Directory, en spécifiant son nom d'hôte :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'SURFACE-FLO-7'

Il faudra valider avec "O" pour confirmer la modification de la config WinRM. On pourrait aussi préciser l'adresse IP source plutôt que le nom d'hôte :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.10.10.6'

On peut spécifier plusieurs valeurs en indiquant une virgule entre chaque valeur. Ensuite, on peut regarder quelles sont les TrustedHosts déclarées sur le serveur avec cette commande (ou winrm get winrm/config/client) :

Get-Item WSMan:\localhost\Client\TrustedHosts

  • Sur le PC source - SURFACE-FLO-7

Sur mon poste local, je vais ajouter l'hôte CORE01 au sein des hôtes de confiance. Sur le même principe, j'exécute cette commande en tant qu'administrateur :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "CORE01.it-connect.local"

Dans les deux cas, si vous souhaitez ouvrir un peu plus les vannes (attention à la sécurité), vous pouvez remplacer le nom d'hôte par "*", ce qui signifie "toutes les machines".

VII. Gérer depuis le « Gestionnaire de serveur »

Pour en finir sur ce chapitre avec le service WinRM, on va voir comment gérer notre serveur « CORE01 » depuis le « Gestionnaire de serveur » d’un autre serveur : SRV-ADDS-01.

Eh oui, il est temps de retoucher à l’interface graphique. Les manipulations effectuées dans cette partie sont en totalité réalisées sur le serveur SRV-ADDS-01. Ce serveur est sous Windows Server 2022, en installation complète (donc avec interface graphique), mais ça peut être à partir d'un serveur avec une autre version.

Ouvrez le « Gestionnaire de serveur » et sur la gauche sélectionnez « Tous les serveurs ». Profitez-en pour faire un clic droit sur cette zone et choisissez « Ajouter des serveurs ».

Dans la zone « Nom » indiquez « CORE01 » et cliquez sur « Rechercher maintenant ». Dans la liste, le serveur « CORE01 » doit apparaître, cliquez dessus pour le sélectionner et cliquez sur la flèche pour l’envoyer dans la colonne de droite.

Validez avec « OK » pour ajouter le serveur et établir la connexion.

Sur la partie centrale de la console, vous avez désormais la possibilité de gérer deux serveurs : SRV-ADDS-01 et CORE01.

On remarque que diverses actions sont disponibles :

En utilisant ce mode de gestion à distance, vous pourrez réaliser simplement certaines tâches :

- Installer et supprimer des rôles et fonctionnalités

- Redémarrer le serveur

- Gérer le serveur (planificateur de tâches, observateur d’événements, performance, gestion des utilisateurs, des dossiers partagés, des services, des disques ainsi que l’accès au gestionnaire de périphérique.

- Initier une connexion RDP (Bureau à distance)

- Exécuter les compteurs de performances

- Créer une association de cartes réseau

Je vous recommande de regarder mon tutoriel sur Windows Admin Center car il est plus dans l'air du temps en comparaison du Gestionnaire de serveur, mais ce dernier présente l'avantage d'être natif à tous les serveurs Windows Server.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Florian Burnel

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

florian has 3481 posts and counting.See all posts by florian