PowerShell Remoting : WinRM en Workgroup, comment ça marche ?

I. Présentation

Vous souhaitez administrer une machine à distance via PowerShell, mais elle est en groupe de travail ? Comment faire pour que la connexion soit acceptée ? C'est ce que nous allons voir dans ce tutoriel !

En environnement Active Directory, il est simple d'administrer à distance une machine Windows par l'intermédiaire de PowerShell. En effet, il est possible de s'authentifier de façon sécurisée avec un compte de l'annuaire, en utilisant le protocole Kerberos.

Néanmoins, ce n'est pas aussi simple lorsque les deux machines sont en groupe de travail (WORKGROUP) ou que la machine à administrer à distance est en groupe de travail. Dans ce cas, la connexion a de fortes chances d'échouer.

Ce mode de fonctionnement nécessite une configuration spécifique qui sera évoquée dans cet article.

Remarque : nous partons du principe que WinRM est déjà actif sur la machine à administrer, car il s'agit d'un serveur Windows Server et il est activé par défaut. Sinon, activez-le avec la commande suivante : Enable-PSRemoting –SkipNetworkProfileCheck.

II. Erreur lors de la connexion WinRM en workgroup

Prenons un exemple fréquent : vous venez d'installer un nouveau serveur nommé SRV-CORE, il est donc en groupe de travail suite à l'installation du système Windows Server. Vous souhaitez finaliser la configuration à distance depuis votre serveur SRV-WAC, à coups de commandes et scripts PowerShell, via WinRM, mais ça ne fonctionne pas...

Vous pouvez rencontrer plusieurs erreurs lors de l'utilisation d'Invoke-Command et Enter-PSSession, dont :

• Cette erreur lorsque les deux machines sont en groupe de travail

La connexion au serveur distant SRV-CORE a échoué avec le message d’erreur suivant: 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.

• Cette erreur lorsque la machine source est dans un domaine AD et la machine de destination en groupe de travail

La connexion au serveur distant SRV-CORE a échoué avec le message d’erreur suivant: WinRM ne peut pas
traiter la demande. L’erreur suivante s’est produite avec le code d’erreur 0x80090311 lors de l’utilisation de
l’authentification Kerberos: Nous n’avons pas pu vous connecter avec ces informations d’identification, car votre
domaine n’est pas disponible. Vérifiez que votre appareil est connecté au réseau de votre organisation, puis
réessayez. Si vous vous connectiez sur cet appareil avec d’autres informations d’identification auparavant, vous
pouvez utiliser celles-ci pour vous connecter.

Ce comportement s'explique parce que WinRM accepte l'authentification Kerberos par défaut. Or, nous ne sommes pas en mesure de respecter ce prérequis (Windows ne supporte pas, à ce jour, le Kerberos en workgroup). Ce problème de sécurité est documenté sur le site de Microsoft.

Get-ChildItem -Path WSMan:\localhost\Service\Auth\

Il y a deux solutions pour résoudre cette erreur :

• Sur l'hôte source, ajouter l'hôte de destination en tant que machine de confiance (TrustedHosts) et s'authentifier via NTLM
• Opter pour une connexion HTTPS avec authentification par certificat, à la place du HTTP

La seconde méthode est plus contraignante puisqu'elle implique l'utilisation d'un certificat. Lorsqu'il s'agit de la préparation d'un serveur, il est préférable de s'intéresser à la première option.

III. WinRM : ajouter un nouvel TrustedHosts

L'option TrustedHosts dans WinRM permet de définir une liste d’adresses IP ou de noms d’hôtes auxquels un ordinateur peut faire confiance pour les connexions à distance (via HTTP sans Kerberos). Cette option est utile lorsque les machines ne sont pas dans le même domaine ou en groupe de travail, comme c'est le cas ici.

Ouvrez une console PowerShell en tant qu'administrateur, puis exécutez la commande suivante. Elle liste les hôtes de confiance déclarés sur la machine locale.

Get-Item WSMan:\localhost\Client\TrustedHosts

Cette liste est vide puisque la propriété Value n'a pas de valeur.

Sur le serveur source, c'est-à-dire celui depuis lequel vous souhaitez vous connecter à la machine distante (SRV-WAC), vous devez modifier cette liste. Si le serveur se nomme SRV-CORE, nous devons exécuter cette commande :

Set-Item WSMAN:\localhost\Client\TrustedHosts -Value SRV-CORE -Force

Note : vous pouvez aussi préciser une adresse IP plutôt qu'un nom d'hôte.

Ensuite, sans même avoir redémarré le service WinRM, la connexion fonctionne :

$Identifiants = Get-Credential -UserName SRV-CORE\Administrateur -Message "Mot de passe"
Invoke-Command -ComputerName SRV-CORE -Credential $Identifiants -ScriptBlock { hostname }

Cette fois-ci, la connexion aboutie alors que les deux machines sont en groupe de travail ! Il n'y a aucune action à effectuer l'hôte de destination, à partir du moment où le service WinRM est actif et que le pare-feu autorise les flux.

Il est à noter que la commande Set-Item utilisée précédemment va écraser la liste de TrustedHosts déclarée sur la machine locale. Pour ajouter une valeur, il est nécessaire d'ajouter le paramètre -Concatenate à la commande. Si vous venez d'installer un serveur et que vous envisagez de le renommer, vous pouvez ainsi ajouter son nom actuel et son futur nom.

Set-Item WSMAN:\localhost\Client\TrustedHosts -Value WIN-XYZ1234 -Force
Set-Item WSMAN:\localhost\Client\TrustedHosts -Value SRV-CORE -Force -Concatenate

Dans le cas où vous souhaitez rétablir la configuration par défaut, purgez la liste via cette commande :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "" –Force

Vous pouvez aussi autoriser tous les noms d'hôtes de cette façon :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" –Force

IV. Conclusion

En suivant ce tutoriel, vous devriez parvenir à utiliser l'administration à distance PowerShell over WinRM même en groupe de travail. Une alternative consiste à s'orienter vers SSH, à condition de disposer de PowerShell 7 et d'avoir configuré le serveur SSH sur l'hôte de destination.

Pour approfondir ce point, vous pouvez lire cet article :

• Comment configurer l'administration à distance PowerShell via SSH ?

Florian BURNEL Co-founder of IT-Connect

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.

Voir la bio complète