Cette séquence de travaux vise à mettre en œuvre le protocole winRM pour gérer à distance une instance de serveur Windows et ses différents rôles, au travers de Powershell et des outils RSAT.
¶ Présentation de WinRM
WinRM (Windows Remote Management) est un protocole de gestion à distance développé par Microsoft qui permet d'administrer et de contrôler des systèmes Windows à distance. Il s'agit de l'implémentation Microsoft du standard WS-Management (Web Services for Management), qui définit un protocole SOAP pour la gestion des serveurs, appareils et applications.
¶ Caractéristiques principales de WinRM
- Communication sécurisée : WinRM utilise le protocole HTTPS pour les communications et prend en charge l'authentification Kerberos, NTLM et les certificats.
- Gestion à distance complète : Permet d'exécuter des commandes PowerShell, de redémarrer des systèmes, de gérer des services et d'effectuer pratiquement toutes les tâches administratives sans être physiquement présent sur la machine.
- Intégration native avec PowerShell : WinRM est le fondement de PowerShell Remoting, permettant d'exécuter des scripts et des commandes PowerShell sur des ordinateurs distants.
- Compatible avec les outils RSAT : Les outils d'administration de serveur à distance (Remote Server Administration Tools) s'appuient sur WinRM pour fonctionner.
¶ Fonctionnement de WinRM
WinRM fonctionne selon un modèle client-serveur :
- Le service WinRM doit être activé et configuré sur l'ordinateur cible (serveur)
- Le client se connecte au serveur via le protocole WS-Management
- Les commandes sont exécutées sur le serveur distant
- Les résultats sont renvoyés au client
WinRM utilise par défaut les ports TCP 5985 (HTTP) et 5986 (HTTPS).
¶ Préparation de l'environnement
Afin d’expérimenter WinRM, nous aurons besoin d’un serveur (Windows Server Core) et d’un client Windows, au sein d’un même réseau local virtuel et isolé derrière un routeur (pfSense).
Nous allons donc bien entendu utiliser notre mini-lab avec l'extension Windows.
Les VM debian du mini-lab ne sont pas nécessaires dans notre contexte, elles pourront rester éteintes.
¶ Paramétrage initial du Serveur Windows
Connectez-vous sur le serveur Windows Core et lancez l’utilitaire sconfig (en ligne de commande) ; il est possible que cet utilitaire se lance de lui-même au démarrage :
Nous allons maintenant ajuster et vérifier les paramètres du serveur :
- Option 2 : définir le nom de la machine :
SRV-XY01(ou XY sont vos initiales) - Option 3 : ajouter un user admin local (
prenom.nom) (optionnel) - Option 4 : activer/vérifier que la gestion à distance est activée (winRM) ; ajouter également la réponse au ping.
- Option 5 : choisir Automatique
- Option 7 : activer le bureau à distance (permet d’accéder à la console de base via RDP, ce qui peut être pratique et confortable) – Choisir l’authentification de type NLA (option 1)
- Option 8 : Fixer/vérifier les paramètres adresse IP (
192.168.1.20/24et la passerelle pfSense192.168.1.1) et serveurs DNS (1.1.1.1et1.0.0.1) - Option 13 : Redémarrez le serveur
Exemple de capture d'écran depuis un bureau à distance sur le client Windows :
¶ Contrôle à distance par PowerShell
¶ Configuration du serveur
Le serveur est déjà configuré par les opérations précédentes. En cas de doute, il est possible via Powershell d’activer et configurer automatiquement le service WinRM :
Enable-psremoting
¶ Configuration côté client
Sur la machine cliente Windows, lancer PowerShell avec élévation de privilèges (exécuter en tant qu'administrateur) :
Ne pas utiliser PowerShell ISE (car la commande
winrm qcplus bas va échouer)
Tout d’abord, le profil du réseau doit être de type Private. Comment vérifier cela :
Get-NetConnectionProfile
La connexion Réseau est ici de type Public. Pour modifier (adapter selon le nom effectif de votre interface réseau) :
Set-NetConnectionProfile -Name "Réseau" -NetworkCategory Private
La connexion Réseau est maintenant de type Private :
On active maintenant la fonctionnalité WinRM côté client :
winrm qc
En réalité le client Windows n'a pas besoin du service WinRM (contrairement au serveur). Mais il faut l'activer uniquement pour pouvoir gérer la liste des hôtes de confiance que nous verrons juste après.
On vérifie que le serveur répond au ping :
ping 192.168.1.20
Si tout est ok, on obtient :
Envoi d’une requête 'Ping' 192.168.1.20 avec 32 octets de données :
Réponse de 192.168.1.20 : octets=32 temps<1ms TTL=128
Réponse de 192.168.1.20 : octets=32 temps<1ms TTL=128
Réponse de 192.168.1.20 : octets=32 temps<1ms TTL=128
Réponse de 192.168.1.20 : octets=32 temps<1ms TTL=128
Puis on autorise la connexion vers la machine cible (on reconnaît le serveur comme cible fiable) :
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.20"
Résultat :
Configuration de la sécurité WinRM.
Cette commande modifie la liste TrustedHosts pour le client WinRM. Les ordinateurs figurant dans la liste TrustedHosts
ne sont pas nécessairement authentifiés. Or, le client risque d'envoyer des informations d'identification à destination
de ces ordinateurs. Êtes-vous sûr de vouloir modifier cette liste ?
[O] Oui [N] Non [S] Suspendre [?] Aide (la valeur par défaut est « O ») : o
¶ Connexion au serveur
Depuis la machine cliente, on prend la main sur le serveur avec PowerShell :
Enter-PSSession -ComputerName '192.168.1.20' -Credential 'administrateur'
Si tout va bien, votre Shell est désormais connecté sur le serveur (le prompt est modifié) :
[192.168.1.20]: PS C:\Users\Administrateur\Documents>
¶ Opérations sur le serveur
Depuis ce "PowerShell distant", nous allons faire de notre serveur un contrôleur de domaine fonctionnel via la ligne de commande.
Réalisez un cliché instantané du serveur à ce stade, pour y revenir en cas d'échec.
¶ Installation du rôle Services AD-DS
Add-WindowsFeature -Name AD-Domain-Services -IncludeAllSubFeature
La progression de l'installation est affichée en haut de la fenêtre. Puis on obtient ce résultat :
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Services AD DS, Gestion de stratégie de g...
¶ Installation du rôle Services DNS
Add-WindowsFeature -Name DNS -IncludeAllSubFeature
Résultat :
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Serveur DNS}
Certains tutoriels vous indiquerons qu'à ce stade il faut également installer les outils RSAT. Eh bien justement, non : ceci ne vaut que pour un serveur embarquant une GUI et les outils d'administration associés. Au contraire, nous voulons ici les installer ailleurs que sur le serveur. Pour la même raison, l'option
-IncludeManagementToolsn'apparaît pas dans les deux commandes précédentes.
¶ Promotion en contrôleur de domaine
Maintenant, nous allons promouvoir le serveur comme contrôleur de domaine :
- On génère une version chiffrée du mot de passe d’administration du domaine, via la variable
AdminPwd; il faut personnaliser ce mot de passe bien entendu :
$AdminPwd = ConvertTo-SecureString "Azerty/123" -AsPlaintext -Force
- on définit avec deux variables le nom du domaine et son nom NetBios (là aussi, il faut personnaliser)
$NomDomaine = "pascal.lan"
$NomDomaineNetBios = "PASCAL"
- Puis on lance la commande pour lancer la promotion, basée sur notamment sur ces paramètres personnalisés, et d'autres plus génériques :
Install-ADDSForest `
-CreateDnsDelegation:$false `
-DomainName $NomDomaine `
-DomainNetbiosName $NomDomaineNetBios `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Default" `
-ForestMode "Default" `
-InstallDNS:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-SafeModeAdministratorPassword $AdminPwd -Force:$true
Un certain nombre d’avertissements non bloquants doivent apparaître tout au long du processus. Puis :
Message Context RebootRequired Status
------- ------- -------------- ------
L’opération s’est déroulée avec succès. DCPromo.General.1 False Success
Même si ce message indique qu'un redémarrage n'est pas requis, le serveur va redémarrer automatiquement, en indiquant sur sa console pendant un certain temps Application des paramètres de l’ordinateur.
Cette dernière commande ne vaut que lors de la création d'un domaine. Pour promouvoir un contrôleur sur un domaine existant, la commande est plutôt
Install-ADDSDomainController, avec des options légèrement différentes.
¶ Création d'un utilisateur basique
Une fois que le serveur est redémarré et opérationnel, il faut rétablir la connexion WinRM depuis le client :
Enter-PSSession -ComputerName '192.168.1.20' -Credential 'administrateur'
Nous allons à titre d'exemple créer un utilisateur standard du domaine (vous pouvez bien sûr personnaliser le contenu) :
New-ADUser `
-Name "Jean DUPONT" `
-DisplayName "Jean DUPONT" `
-GivenName "Jean" `
-Surname "DUPONT" `
-SamAccountName "jdupont" `
-AccountPassword (ConvertTo-SecureString -AsPlainText "Azerty/123" -Force) `
-Enable $true `
-ChangePasswordAtLogon $false
¶ Administration RSAT
Nous allons maintenant découvrir comment on peut gérer notre serveur à distance depuis un client Windows.
¶ Intégration du client dans le domaine
La première chose à faire est d'intégrer notre client Windows dans le domaine que nous venons de créer.
¶ Modification du DNS
Nous allons indiquer au client que son serveur DNS est désormais le contrôleur de domaine.
On pourrait faire ceci en modifiant la configuration du serveur DHCP (sur pfSense) mais on préfère ici ne pas modifier ce dernier.
Sur le client Windows, accédez à la gestion des connexions réseau : Win+R et ncpa.cpl :
Dans les propriétés de la connexions, modifiez les paramètres IPv4 en fixant l'adresse du serveur DNS :
vous pouvez aussi en profiter pour désactiver IPv6 en décochant le protocole IPv6, selon le veil adage : "ce qu'on ne gère pas, on le désactive."
¶ Rattachement au domaine
Toujours sur le client Windows, accédez à aux propriétés du système : Win+R et sysdm.cpl, et modifiez le nom de l'ordinateur et son appartenance :
Il faut saisir un credential autorisé (l'administrateur du domaine) :
Si tout est conforme, l'ordinateur est "adopté", et il faut le redémarrer :
Lors de la reconnexion, on utilise des identifiants propres au domaine, et notamment ici l'administrateur :
Il faut ensuite supprimer l'ancien administrateur local de l'ordinateur (qui n'a pas de mot de passe) pour un rattachement exclusif au domaine, et plus de sécurité :
¶ Installation des outils RSAT
Les outils RSAT (Remote Server Administration Tools) sont des fonctionnalités facultatives de Windows, disponibles avec la version professionnelle, qui permettent d'administrer des serveurs et des rôles du domaine, depuis une machine client distante. Lorsqu'on installe et qu'on gère Windows Serveur en mode GUI (expérience de bureau), ces modules s'installent sur le serveur. Cette pratique courante n'est pas la meilleure, car par principe les ressources du serveur doivent être utilisées de façon exclusive pour les services rendus, pour plus de performance, de fiabilité et de sécurité (moins de surface d'exposition aux risques).
Nous allons installer les outils principaux (au nombre de 4) sur notre client Windows, en utilisant PowerShell.
La gestion des RSAT est disponible aussi depuis les paramètres Windows :
- Pour afficher les outils RSAT déjà installés :
Get-WindowsCapability -Name RSAT* -Online | Where-Object {$_.State -eq "Installed"}
Attention l'installation de ces outils peut être longue, car elle implique un certain nombre de dépendances.
- Pour installer le RSAT Gestionnaire de Serveur :
Get-WindowsCapability -Name "Rsat.ServerManager*" -Online | Add-WindowsCapability -Online - Pour installer le RSAT Gestionnaire de l'AD DS :
Get-WindowsCapability -Name "Rsat.ActiveDirectory*" -Online | Add-WindowsCapability -Online - Pour installer le RSAT Gestionnaire de DNS :
Get-WindowsCapability -Name "Rsat.DNS*" -Online | Add-WindowsCapability -Online - Pour installer le RSAT Gestionnaire des stratégies de groupe :
Get-WindowsCapability -Name "Rsat.GroupPolicy.Management*" -Online | Add-WindowsCapability -Online
On vérifie les outils RSAT maintenant installés :
Get-WindowsCapability -Name RSAT* -Online | Where-Object {$_.State -eq "Installed"}
On doit obtenir cette liste :
Name : Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
State : Installed
DisplayName : RSAT : outils Active Directory Domain Services Directory et services LDS (Lightweight Directory Services)
Description : Les outils Active Directory Domain Services (AD DS) et les services AD LDS (Lightweight Directory Services) comprennent des outils de composant logiciel enfichable et de ligne de commande pour la gestion à distance d'AD DS et d'AD LDS sous Windows Server.
DownloadSize : 0
InstallSize : 53252970
Name : Rsat.Dns.Tools~~~~0.0.1.0
State : Installed
DisplayName : RSAT : outils du serveur DNS
Description : Les outils du serveur DNS incluent le composant logiciel enfichable Gestionnaire DNS, l'outil de ligne de commande dnscmd.exe et le module Windows PowerShell pour le serveur DNS.
DownloadSize : 0
InstallSize : 17841540
Name : Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
State : Installed
DisplayName : RSAT : outils de gestion de stratégie de groupe
Description : Les outils de gestion de stratégie de groupe incluent la console de gestion des stratégies de groupe, l'éditeur de gestion des stratégies de groupe et l'éditeur d'objets GPO Starter de stratégie de groupe.
DownloadSize : 0
InstallSize : 48967574
Name : Rsat.ServerManager.Tools~~~~0.0.1.0
State : Installed
DisplayName : RSAT : gestionnaire de serveur
Description : Le Gestionnaire de serveur inclut la console du Gestionnaire de serveur et des outils PowerShell pour la gestion à distance de Windows Server, et inclut des outils pour configurer à distance l'association de cartes réseau sur Windows Server et Best Practices Analyzer.
DownloadSize : 0
InstallSize : 87548122
¶ Création d'un dossier partagé
Pour illustrer les différents outils d'administration RSAT, nous allons mettre en place un partage simple sur le serveur.
Depuis le client Windows, toujours connecté comme administrateur, on appelle le gestionnaire de serveur :
Celui-ci n'est connecté pour le moment à aucun serveur.
Cliquez sur (1) Ajouter d'autres serveurs à gérer depuis le tableau de bord. Dans la fenêtre qui apparaît, cliquer sur Rechercher maintenant, la liste des ordinateurs du domaine va apparaître, sélectionnez le serveur :
Désormais, les rôles portés par notre serveur sont accessibles :
Dans le menu de gauche, choisir Services de fichiers et de stockage, puis Partages, et enfin dans le menu TÂCHES choisir Nouveau partage :
L'assistant de création de partage se lance ; on va utiliser dans notre exemple les choix par défaut, en repérant le chemin d'accès au partage (chemin UNC) dont nous aurons besoin plus loin :
On prend garde aussi à activer l'énumération basée sur l'accès, ce qui est une bonne pratique, et qui vise à ne pas rendre visible le dossier partagé à qui n'y a pas accès :
¶ Gestion de l'annuaire Active Directory
Regardons maintenant (et rapidement) du côté de la console de gestion de l'annuaire AD, via l'outil RSAT correspondant sur le client Windows :
Nous voyons les différents composants de l'AD, et notamment l'utilisateur que nous avons ajouté avec PowerShell :
C'est avec cette console que l'on peut gérer les UO (Unités d'Organisations), les groupes, les utilisateurs et l'ensemble des objets presents au sein de l'AD.
J'en profite pour rappeler que Active Directory repose sur le protocole et les outils LDAP, et qu'à ce titre on retrouvera beaucoup de notions propres à LDAP (attributs, Distinguished Name, Domain Component, Organisational Unit, Common Name, ...)
¶ Gestion des stratégies de groupe
Voici une console très intéressante, qui permet de gérer les stratégies de groupe du domaine :
A titre d'exemple, nous allons créer une GPO pour l'ensemble du domaine dont le but est de créer un lecteur réseau (M:) rattaché au dossier partagé créé plus haut. Depuis la console, dans notre domaine, un clic droit sur les stratégies par défaut du domaine (Default Domain Policies) et Modifier. On ajoute un lecteur dans Configuration Utilisateur > Préférences > Paramètres Windows > Mappages de lecteur :
Voici les détails de ce mappage :
Notons que pour l'emplacement du dossier, j'ai utilisé le FQDN du serveur (
srv-pm01.pascal.lan) plutôt que son nom simple (srv-pm01) ; ceci est une bonne pratique de sécurité, selon une philosophie plus générale visant à toujours identifier les ressources avec leur chemin absolu.
Pour appliquer immédiatement la GPO, on peut lancer la commande gpupdate depuis la ligne de commande :
Le lecteur apparaît alors dans l'explorateur de fichiers (pour tous les utilisateurs) :
¶ Gestionnaire DNS
Regardons maintenant l'outil (la console) qui permet de gérer le rôle DNS du serveur :
On sélectionne le serveur à administrer :
Notons au passage que si plusieurs contrôleurs de domaine sont présents sur le domaine (ce qui est d'ailleurs recommandé), chacun assure le rôle DNS, et ils se synchronisent automatiquement entre eux pour assurer la cohérence de l'Active Directory et des zones DNS.
A titre d'exemple, nous allons ajouter à notre DNS une zone de recherche inversée (reverse DNS) associée au réseau local :
Choisissez les options par défaut proposées pour la création de la zone, il faut juste bien indiquer l'adresse IPv4 du réseau.
Pourquoi l'ajoute d'une zone de recherche inversée est importante ?
L'ajout d'une zone de recherche inversée (Reverse Lookup Zone ou PTR) pour un sous-réseau local comme ici 192.168.1.0/24 dans un environnement de domaine offre plusieurs avantages significatifs :
- Résolution inverse d'adresses IP
- Permet de traduire une adresse IP en nom de domaine complet (FQDN)
- Complète la résolution directe (nom vers IP) par la résolution inverse (IP vers nom)
- Authentification Kerberos optimisée
- Kerberos utilise souvent la résolution inverse pour valider les connexions
- Accélère le processus d'authentification dans l'environnement de domaine
- Réduit les délais d'attente lors des tentatives de connexion
- Dépannage réseau amélioré
- Les outils comme ping, tracert et netstat peuvent afficher les noms au lieu des adresses IP
- Facilite l'analyse des journaux d'événements et des connexions
- Sécurité renforcée
- Certains services vérifient la correspondance entre enregistrements A et PTR
- Facilite la détection des anomalies sur le réseau
- Simplification de WinRM
- WinRM fonctionne plus efficacement avec une résolution DNS complète
- eut réduire les problèmes de configuration lors de l'établissement de sessions à distance
Même si elle n'est pas strictement nécessaire sur un petit réseau de laboratoire, la mise en place de cette zone est une pratique recommandée en administration système.
¶ Connexion d'un utilisateur standard
Avant de conclure, nous pouvons connecter sur notre client Windows l'utilisateur standard que nous avons créé plus haut :
Une session locale va être créée à son attention, et les GPO utilisateurs (une seule en l'état) vont être appliquées :
Notre domaine Windows est opérationnel, et ne demande plus qu'à être construit (et sécurisé) au gré des besoins.
¶ Conclusion
Ce TP sur WinRM (Windows Remote Management) nous a permis d'explorer en profondeur les mécanismes d'administration à distance des systèmes Windows, un élément essentiel dans la gestion moderne des infrastructures informatiques.
Nous avons pu mettre en œuvre l'ensemble de la chaîne de configuration nécessaire à une administration distante efficace : depuis la préparation et la configuration du serveur Windows Server Core, jusqu'à l'utilisation des outils RSAT sur un poste client pour gérer l'Active Directory, les stratégies de groupe, le DNS et les partages de fichiers.
L'utilisation combinée de WinRM et PowerShell a démontré la puissance de cette approche pour automatiser des tâches complexes comme la promotion d'un serveur en contrôleur de domaine, sans nécessiter d'interface graphique. Cette méthodologie s'inscrit parfaitement dans les tendances actuelles de l'administration système où l'automatisation et la gestion "Infrastructure as Code" prennent une place prépondérante.