Points clés
- Choisir des méthodes d’accès à distance sécurisées : n’utilisez RDP, WinRM ou l’Assistance à distance qu’en cas de besoin, en appliquant le moindre privilège et des règles de pare-feu cadrées pour limiter l’exposition.
- Activer RDP avec l’authentification au niveau du réseau : exigez le NLA pour toutes les sessions, n’ajoutez que des utilisateurs de confiance et restreignez l’accès du pare-feu aux réseaux d’administration connus.
- Configurer WinRM sur HTTPS pour une automatisation sécurisée : utilisez des écouteurs de confiance, désactivez l’authentification non chiffrée et cadrez l’accès aux sous-réseaux d’administration.
- Paramétrer l’Assistance à distance avec consentement et contrôle des rôles : activez l’assistance sollicitée ou proposée via GPO et imposez des prompts d’approbation de l’utilisateur avant connexion.
- Vérifier et journaliser la configuration de l’accès à distance : faites-le en testant depuis un poste de travail d’administration. Confirmez la journalisation dans le SIEM et exportez les données de groupes et de pare-feu pour les audits.
- Standardiser et maintenir à grande échelle : appliquez les configurations via GPO ou automatisation, vérifiez régulièrement les dérives et gardez des procédures de retour arrière prêtes pour la réponse aux incidents.
Les MSP ont besoin d’une référence de configuration sécurisée pour l’administration à distance, applicable facilement à l’ensemble des terminaux et serveurs Windows. Il faut toutefois activer les services en les cadrant et en les durcissant, afin d’éviter tout risque inutile. Pour mettre en place une configuration sûre, vous aurez besoin du bon transport, de règles de pare-feu cadrées, d’attributions de groupes au moindre privilège et d’une journalisation vérifiable.
Ce guide donne à votre équipe MSP ou informatique une méthode concrète pour activer Remote Desktop Protocol (RDP), Windows Remote Management (WinRM) et l’Assistance à distance. Les étapes présentées sont auditables, contrôlées et parfaitement adaptées à un déploiement à grande échelle.
Activer l’administration à distance sous Windows en toute sécurité : les étapes
Avant de commencer à activer l’administration à distance sous Windows, vous devrez mettre en place les exigences de base suivantes :
📌 Prérequis :
- Vous devez avoir déjà créé un groupe d’administration pour les Utilisateurs du Bureau à distance ou les administrateurs locaux.
- Les équipes informatiques doivent restreindre l’accès à distance aux sous-réseaux d’administration ou à des serveurs de rebond désignés, à l’aide de règles de pare-feu.
- Des certificats de confiance doivent être configurés pour les écouteurs WinRM HTTPS sur tous les terminaux gérés.
- Vous devrez transférer les événements de connexion et de session distante vers un collecteur de logs centralisé ou vers un outil SIEM (Security Information and Event Management).
Check-list des prérequis
| Composant | Exigence | Objectif |
| Identité | Groupe de sécurité AD SG-RemoteAdmins | Contrôle d’accès au moindre privilège. |
| Réseau | Sous-réseau d’administration connu (ex. : 10.0.5.0/24) | Cadrage du pare-feu. |
| PKI | Certificat de serveur web émis par le domaine | Chiffrement de WinRM (port 5986). |
Étape 1 : choisir les transports et activer RDP en toute sécurité
📌 Cas d’usage :
- Cette étape vous permet d’assurer l’administration à distance sans exposer largement les systèmes, avec un accès contrôlé et sécurisé.
- Elle vous permet de diagnostiquer, d’automatiser ou d’assister les utilisateurs à distance tout en imposant l’authentification.
📌 Prérequis :
- Vous aurez besoin de droits d’administration sur le système pour activer RDP et configurer les règles de pare-feu.
- Cela suppose un accès aux Propriétés système, aux paramètres du Pare-feu Windows ou à la console de gestion des stratégies de groupe.
Procédure :
- Commencez par choisir le transport à utiliser :
- RDP pour le dépannage interactif
- WinRM pour l’administration par scripts
- l’Assistance à distance pour les sessions guidées
- Une fois votre transport choisi, ouvrez Propriétés système > Utilisation à distance et sélectionnez Autoriser les connexions à distance.
- Exigez ensuite l’authentification au niveau du réseau (NLA) pour toutes les sessions RDP.
- N’ajoutez que des comptes de confiance au groupe Utilisateurs du Bureau à distance.
- Activez les règles de pare-feu intégrées du Bureau à distance dans le Pare-feu Windows Defender avec fonctions avancées de sécurité.
- Cadrez les règles de pare-feu sur les sous-réseaux d’administration de confiance ou les serveurs de rebond.
💡 Aide-mémoire des ports :
- RDP : TCP 3389 (NLA requis)
- WinRM (HTTPS) : TCP 5986
Assistance à distance : TCP 135 + ports dynamiques (ou RPC)
Étape 2 : activer WinRM pour une administration à distance sécurisée
📌 Cas d’usage :
- Permet une administration à distance sécurisée par scripts avec PowerShell.
- Réduit la dépendance à RDP en autorisant l’automatisation et la configuration sans accès complet au bureau.
📌 Prérequis :
- Vous aurez besoin de droits d’administration sur les terminaux ou les contrôleurs de domaine.
- Cela suppose un accès avancé à la console de gestion des stratégies de groupe (GPMC) ou à PowerShell en local.
- Vous devez disposer d’un certificat reconnu par le terminal.
Procédure :
- Configurez Windows Remote Management (WinRM) sur HTTPS pour prendre en charge la communication à distance PowerShell.
- Créez un écouteur HTTPS de confiance via PowerShell :
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="serverFQDN";CertificateThumbprint="thumbprint"}
- Désactivez ensuite l’authentification Basic et non chiffrée :
winrm set winrm/config/service/auth @{Basic="false"}
winrm set winrm/config/service @{AllowUnencrypted="false"}
- N’autorisez que les sous-réseaux d’administration à l’aide de règles de pare-feu ou de filtres IP. Remplacez par :
New-NetFirewallRule -DisplayName "Allow WinRM HTTPS" -Direction Inbound -Protocol TCP -LocalPort 5986 -RemoteAddress 192.168.10.0/24
- Appuyez-vous sur la configuration de la stratégie de groupe WinRM d’IBM pour un déploiement à l’échelle du domaine.
Étape 3 : configurer l’Assistance à distance et les portées de pare-feu
📌 Cas d’usage :
- Cela permet un dépannage sécurisé et guidé par l’utilisateur lorsqu’une intervention directe d’un administrateur est nécessaire.
- Cela garantit que les collaborateurs peuvent apporter leur aide sans exposer les systèmes à un accès trop large.
📌 Prérequis :
- Vérifiez que vous disposez de droits d’administration locaux ou de domaine sur les systèmes cibles.
- Confirmez que vous pouvez accéder à la console de gestion des stratégies de groupe (GPMC) ou aux paramètres locaux du système où les politiques seront appliquées.
- Assurez-vous que les équipes de support sont bien ajoutées aux groupes de sécurité désignés auxquels seront accordés les droits d’Assistance à distance.
Procédure :
- Commencez par activer l’Assistance à distance (si nécessaire).
- Ouvrez la console de gestion des stratégies de groupe (GPMC).
- Accédez ensuite à Configuration ordinateur > Modèles d’administration > Système > Assistance à distance
- Activez Configurer l’offre d’assistance à distance et Configurer l’assistance à distance sollicitée.
- Dans la même fenêtre, désignez ensuite les groupes de sécurité du support de votre MSP comme assistants autorisés.
- Sous Assistance à distance sollicitée, configurez la durée de vie maximale du ticket (réglez-la sur 30 minutes).
- Exigez le consentement de l’utilisateur en veillant à ce que Autoriser les assistants à contrôler l’ordinateur à distance soit réglé sur Demander le consentement.
- Dans le Pare-feu Windows Defender, activez les règles entrantes suivantes :
- Bureau à distance
- Windows Remote Management
- Gestion des services à distance
- Pensez à les cadrer sur vos réseaux d’administration via l’onglet Portée > Adresse IP distante
Étape 4 : sécuriser l’accès à distance en vérifiant les paramètres
📌 Cas d’usage :
- Cela garantit que les paramètres d’accès à distance sont correctement appliqués et durcis.
- Cela fournit des preuves auditables pour les revues de conformité et de sécurité.
- Cette étape vous aide à repérer les erreurs de configuration avant qu’elles ne deviennent exploitables.
📌 Prérequis :
- Vous aurez besoin d’un poste de travail d’administration avec RDP et la communication à distance PowerShell activés.
- Cette étape nécessite un accès au SIEM pour valider les logs.
Procédure :
- Validez toutes les configurations d’accès à distance depuis un poste de travail d’administration.
- Testez RDP avec l’authentification au niveau du réseau (NLA) et WinRM sur HTTPS.
- Vérifiez que les ID d’événement des connexions à distance et de la communication à distance PowerShell sont bien enregistrés dans le SIEM.
- Exportez des instantanés de l’appartenance aux groupes, des portées de pare-feu et de l’état des écouteurs WinRM à titre de preuve. Utilisez les commandes PowerShell suivantes :
- Pour obtenir les données d’appartenance aux groupes :
Get-LocalGroupMember -Group "Administrators" - Pour recueillir les données sur les portées de pare-feu : Get-NetFirewallRule | Format-Table Name, Enabled, Direction, Action
- Pour obtenir les données sur l’état des écouteurs WinRM : Get-WSManInstance -ResourceURI winrm/config/Listener -Enumerate
- Pour obtenir les données d’appartenance aux groupes :
- Maintenez un bon niveau de sécurité en imposant TLS, en exigeant le MFA (authentification forte) et en appliquant des mises à jour régulières.
Étape 5 : maintenir l’administration à distance, le retour arrière et l’accès console d’urgence
📌 Cas d’usage :
- Cela constitue un filet de sécurité en cas d’usage abusif ou de compromission de l’administration à distance.
- Cela garantit que les administrateurs peuvent désactiver rapidement RDP et WinRM tout en conservant l’accès à la console d’urgence.
📌 Prérequis :
- Des droits d’administration sont nécessaires pour modifier les paramètres d’administration à distance.
- Vous aurez besoin d’un accès aux stratégies de groupe ou à PowerShell pour désactiver RDP/WinRM.
Procédure :
- Définissez un plan de retour arrière rapide pour désactiver l’administration à distance en cas d’usage abusif ou de compromission détectés.
- Veillez à conserver un runbook concis reprenant les commandes ou les étapes GPO pour désactiver RDP et WinRM.
- Maintenez un accès console d’urgence indépendant de l’authentification réseau : console directe, IPMI, console de l’hôte de virtualisation.
- Testez régulièrement le retour arrière et l’accès console afin de garantir leur disponibilité en cas d’incident.
Étape 6 : déployer et valider les configurations d’administration à distance à grande échelle
📌 Cas d’usage :
- Cette étape vous permet d’appliquer des politiques d’accès à distance homogènes sur l’ensemble des terminaux.
- Elle vous permet de standardiser les configurations WinRM, de pare-feu et de journalisation dans les environnements de domaine.
- Elle garantit que les appareils en groupe de travail ou en environnement hybride restent alignés sur les références de configuration de sécurité de l’entreprise.
📌 Prérequis :
- Des droits d’administration sont nécessaires pour créer et lier des GPO, ainsi qu’un accès à Active Directory pour les systèmes joints au domaine.
- Vous aurez besoin d’un outil de gestion de configuration ou de supervision capable de détecter les dérives, comme Intune.
Procédure :
- Commencez par appliquer des politiques d’accès à distance homogènes sur les terminaux. Voici comment :
- Utilisez des GPO pour imposer les écouteurs WinRM HTTPS, les portées de pare-feu et les paramètres de journalisation.
- Liez les politiques aux unités d’organisation (OU) contenant les systèmes gérés.
- Standardisez les configurations avec des GPO en suivant ces procédures :
- Configurez les paramètres du service WinRM en suivant ce chemin : Configuration ordinateur > Stratégies > Modèles d’administration > Composants Windows
- Activez les groupes de règles de pare-feu prédéfinis pour le Bureau à distance, WinRM et la gestion des services à distance.
- Configurez les politiques de journalisation pour la journalisation des blocs de script PowerShell et les événements de connexion à distance.
- Prenez en charge les appareils en groupe de travail ou hybrides grâce à ces méthodes :
- Déployez des scripts PowerShell signés pour configurer WinRM et les portées de pare-feu.
- Validez les signatures afin de garantir que les scripts sont fiables et n’ont pas été altérés.
- Enfin, vérifiez et corrigez les dérives de configuration à travers ces tâches :
- Exportez régulièrement des instantanés des règles de pare-feu, de l’état des écouteurs WinRM et de l’appartenance aux groupes.
- Comparez-les aux références de configuration à l’aide de PowerShell Desired State Configuration (DSC) ou d’outils de supervision.
- Automatisez la remédiation lorsqu’une dérive est détectée, afin de rétablir la conformité.
Résoudre les problèmes les plus fréquents
Problème : « connexion WinRM HTTPS refusée ».
- Solution : assurez-vous que le CN (Common Name) du certificat correspond exactement au FQDN du serveur.
Problème : « RDP fonctionne en local mais pas via le VPN ».
Solution : vérifiez que le sous-réseau du VPN figure bien dans l’onglet Portée de la règle du Pare-feu Windows.
⚠️ Points de vigilance
| Risques | Conséquences possibles | Mesures correctives |
| WinRM activé sans HTTPS | Exposition des identifiants sur des canaux non chiffrés | Désactiver l’écouteur HTTP, imposer HTTPS via GPO |
| Portées de pare-feu trop larges | Accès à distance depuis des réseaux non fiables | Restreindre les portées aux sous-réseaux d’administration via GPO ou script |
| Absence de procédures de retour arrière | Retards dans la désactivation de l’accès à distance lors d’un incident | Conserver un runbook pour désactiver rapidement RDP et WinRM |
Bonnes pratiques pour activer l’administration à distance sous Windows en toute sécurité
| Pratique | Objectif | Bénéfice apporté |
| Authentification au niveau du réseau (NLA) pour RDP et HTTPS pour WinRM | Impose une authentification avant l’ouverture de session | Bloque le vol d’identifiants et les attaques par force brute, et empêche les accès non autorisés |
| Règles de pare-feu cadrées | Limite l’accès à distance aux réseaux de confiance | Réduit l’exposition et la surface d’exposition aux attaques |
| Accès basé sur les rôles | Attribuer les permissions selon la fonction occupée | Évite l’accumulation de privilèges et les usages abusifs de l’accès à distance |
| Journalisation centralisée | Capturer l’activité à distance et l’utilisation des scripts | Accélère les audits et la réponse aux incidents |
| Contrôle par GPO | Appliquer des paramètres homogènes sur tous les terminaux | Réduit les dérives et les erreurs manuelles |
Exemples d’implémentation pour activer l’administration à distance sous Windows en toute sécurité
Voici quelques points de repère qui vous aideront à déployer l’administration des accès à distance sous Windows en toute sécurité.
- Activez RDP avec NLA pour bloquer les attaques par force brute avant l’ouverture des sessions.
- Créez un écouteur WinRM HTTPS pour sécuriser le trafic d’administration à distance par chiffrement.
- Restreignez les règles de pare-feu aux adresses CIDR (Classless Inter-Domain Routing) d’administration afin de limiter l’accès aux réseaux d’administration de confiance.
- Vous pouvez ajouter les groupes de support aux Utilisateurs du Bureau à distance pour accorder un accès contrôlé aux équipes de support autorisées.
- Désactivez l’authentification Basic pour WinRM afin d’éviter l’exposition des identifiants en clair
- Pour vérifier la connectivité et confirmer la réussite de la configuration, exécutez des appels de test en communication à distance.
- Générez un fichier de preuve JSON pour consigner les groupes locaux, les portées de pare-feu, l’état des écouteurs et les résultats des tests, avec horodatage.
- Appliquez une variante pilotée par GPO pour imposer la même configuration de façon homogène sur tous les terminaux.
Idées d’intégration NinjaOne pour activer l’administration à distance sous Windows en toute sécurité
- Vous pouvez utiliser NinjaOne pour déployer le script d’activation selon le rôle de l’appareil, ce qui vous permet d’appliquer la bonne configuration à chaque type de système.
- Planifiez une vérification régulière de NLA pour RDP, de WinRM HTTPS, des portées de pare-feu et de l’appartenance aux groupes locaux afin d’assurer une conformité et une sécurité continues.
- Joignez des instantanés de preuve à NinjaOne Documentation pour attester de l’état de configuration et rester prêt pour les audits.
- Ouvrez automatiquement des tickets dans NinjaOne Ticketing lorsque les portées de pare-feu dérivent ou que des comptes non autorisés apparaissent parmi les Utilisateurs du Bureau à distance, afin de déclencher une remédiation immédiate.
Déployer l’administration à distance Windows sur votre réseau en toute sécurité
L’administration à distance peut être sûre et fiable à condition de choisir les transports de manière réfléchie, de cadrer l’exposition du pare-feu, d’utiliser une authentification moderne et de collecter des preuves. Une fois ces paramètres appliqués et vérifiés, vous disposez d’un accès prévisible et auditable.
Sujets connexes :

