Utilisation du protocole Remote Desktop Protocol (RDP) pour se connecter à votre serveur Windows

Le Remote Desktop Protocol (RDP) est un protocole réseau propriétaire Microsoft qui permet un accès graphique complet et chiffré à une machine Windows distante via le port TCP 3389. Il transmet la sortie d’affichage du serveur vers le client et les entrées clavier/souris du client vers le serveur, vous offrant ainsi une session interactive en direct sur une machine sur laquelle vous n’êtes pas physiquement présent.

Pour les administrateurs de serveurs, RDP est la méthode principale de gestion d’une instance Windows Server — que ce serveur soit une machine bare-metal dans un centre de données, un environnement VPS Hosting, ou un Serveur Dédié fonctionnant sous Windows Server 2019, 2022 ou ultérieur. Ce guide couvre le flux de travail complet : activer RDP, le sécuriser contre les vecteurs d’attaque réels, se connecter depuis Windows, macOS et Linux, et diagnostiquer les pannes qui prennent les administrateurs au dépourvu.

Fonctionnement interne de RDP

Avant de toucher à un seul paramètre de configuration, comprendre l’architecture du protocole s’avère précieux lors du dépannage.

RDP fonctionne via TCP (et optionnellement UDP pour la redirection multimédia) et utilise TLS 1.2/1.3 pour le chiffrement du transport dans toutes les versions modernes de Windows Server. La pile de session se compose de plusieurs canaux virtuels qui transportent simultanément des types de données distincts :

• Canal graphique — mises à jour d’affichage compressées utilisant RemoteFX ou l’accélération GDI
• Canal d’entrée — événements clavier et souris
• Canal presse-papiers — partage bidirectionnel du presse-papiers
• Canaux de redirection de lecteurs/imprimantes — mappage des ressources locales dans la session distante
• Canal audio — redirection de la lecture audio distante et de l’enregistrement

Chaque canal est multiplexé sur une seule connexion TCP vers le port 3389 par défaut. Le composant côté serveur est TermService (Remote Desktop Services), et l’écouteur est géré par RDPWinST.sys au niveau du noyau. Lorsque vous modifiez le port d’écoute, vous modifiez une valeur de registre que ce pilote lit au démarrage du service.

L’authentification au niveau du réseau (NLA) ajoute une couche d’authentification pré-session utilisant CredSSP (Credential Security Support Provider). Avec NLA activé, le client doit s’authentifier avec des informations d’identification valides avant que le serveur alloue une session de bureau complète, ce qui réduit considérablement la surface d’attaque pour les attaques par déni de service et par force brute contre l’écran de connexion.

Liste de contrôle des prérequis

Confirmez chaque élément ci-dessous avant de tenter une connexion :

• Une instance Windows Server (2016, 2019 ou 2022) avec RDP activé
• L’adresse IPv4 publique ou un nom d’hôte résolvable pour le serveur
• Un compte de niveau administrateur valide sur le serveur
• Un client RDP installé sur votre machine locale
• Le port 3389 (ou votre port personnalisé) ouvert dans le pare-feu du système d’exploitation et dans tout pare-feu réseau ou groupe de sécurité en amont
• Support NLA côté client (activé par défaut sur tous les clients RDP modernes sous Windows, macOS et Linux)

Étape 1 : Activer RDP sur le Windows Server

RDP est désactivé par défaut sur les nouvelles installations de Windows Server. Il existe deux méthodes fiables pour l’activer.

Méthode A : Interface graphique (Propriétés système)

1. Ouvrez le Gestionnaire de serveur ou appuyez sur Win + R, tapez sysdm.cpl et appuyez sur Entrée.
2. Accédez à l’onglet Accès à distance.
3. Sous Bureau à distance, sélectionnez Autoriser les connexions à distance à cet ordinateur.
4. Assurez-vous que Autoriser uniquement les connexions des ordinateurs exécutant le Bureau à distance avec authentification au niveau du réseau est coché.
5. Cliquez sur OK.

Méthode B : PowerShell (Recommandée pour l’automatisation)

Pour les déploiements sans interface ou scriptés, PowerShell est plus rapide et scriptable :

# Enable RDP
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' `
    -Name "fDenyTSConnections" -Value 0

# Enable NLA
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' `
    -Name "UserAuthentication" -Value 1

# Allow RDP through Windows Firewall
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Confirm the service is running
Set-Service -Name TermService -StartupType Automatic
Start-Service TermService

Vérification de la règle de pare-feu

Le groupe de règles de pare-feu intégré « Bureau à distance » couvre les règles entrantes nécessaires. Vérifiez avec :

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction

Si vous êtes derrière le groupe de sécurité d’un fournisseur cloud (courant sur les environnements VPS avec cPanel ou VPS gérés), vous devez également ouvrir le port 3389 dans le panneau de pare-feu externe du fournisseur — le pare-feu du système d’exploitation seul n’est pas suffisant.

Étape 2 : Localiser l’adresse IP publique du serveur

Depuis la console du serveur

Ouvrez une invite de commandes élevée et exécutez :

ipconfig /all

Recherchez l’adresse IPv4 sous l’adaptateur réseau actif. Sur un serveur avec plusieurs cartes réseau (courant sur le matériel dédié), identifiez l’adaptateur connecté au réseau public en croisant avec la passerelle par défaut.

Pour une sortie plus claire, utilisez PowerShell :

Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.IPAddress -notlike "127.*" } |
    Select-Object InterfaceAlias, IPAddress

Depuis votre panneau de contrôle d’hébergement

Si vous avez provisionné le serveur via un fournisseur d’hébergement, l’IP publique est répertoriée dans le tableau de bord du panneau de contrôle. Pour les Serveurs Dédiés AlexHost, l’IP est affichée immédiatement après le provisionnement dans l’espace client.

Cas limite important : Si votre serveur se trouve derrière un NAT (par exemple, un cloud privé ou un hyperviseur avec réseau interne), l’IP affichée par ipconfig sera une adresse privée RFC 1918. Vous devrez vous connecter à l’IP publique de la passerelle NAT et configurer la redirection de port vers l’IP privée du serveur sur le port 3389.

Étape 3 : Se connecter au serveur via RDP

Depuis Windows

Le client intégré est mstsc.exe (Microsoft Terminal Services Client). Lancez-le depuis Exécuter (Win + R) ou le menu Démarrer :

mstsc /v:YOUR_SERVER_IP:3389

Pour une session en plein écran avec la redirection de lecteurs désactivée (une valeur par défaut axée sur la sécurité) :

mstsc /v:YOUR_SERVER_IP /f /nodrives

Dans l’interface graphique :

1. Entrez l’IP du serveur dans le champ Ordinateur.
2. Cliquez sur Afficher les options pour pré-remplir le nom d’utilisateur, ce qui évite l’invite de saisie des informations d’identification supplémentaire.
3. Sous l’onglet Expérience, sélectionnez la vitesse de connexion appropriée pour optimiser le rendu.
4. Cliquez sur Connexion, acceptez l’avertissement de certificat lors de la première connexion (vérifiez l’empreinte du certificat si la sécurité est critique), et entrez votre mot de passe.

Depuis macOS

L’application officielle Microsoft Remote Desktop de Microsoft (disponible gratuitement sur le Mac App Store) est le client recommandé.

1. Ouvrez l’application et cliquez sur le bouton +, puis sur Ajouter un PC.
2. Entrez l’IP du serveur dans Nom du PC.
3. Sous Compte utilisateur, cliquez sur Ajouter un compte utilisateur et entrez vos informations d’identification.
4. Configurez optionnellement les paramètres d’Affichage et la redirection Appareils et audio.
5. Double-cliquez sur la connexion enregistrée pour initier la session.

Depuis Linux

Deux options matures existent sous Linux :

Remmina (basé sur GTK, recommandé pour les environnements de bureau) :

sudo apt install remmina remmina-plugin-rdp   # Debian/Ubuntu
sudo dnf install remmina remmina-plugin-rdp   # RHEL/Fedora

Lancez Remmina, créez une nouvelle connexion, sélectionnez RDP comme protocole, entrez l’IP du serveur, les informations d’identification, et connectez-vous.

FreeRDP (ligne de commande, idéal pour les scripts ou les clients sans interface) :

sudo apt install freerdp2-x11
xfreerdp /v:YOUR_SERVER_IP /u:Administrator /p:'YourPassword' /cert:ignore /dynamic-resolution

L’indicateur /cert:ignore supprime l’avertissement de certificat — acceptable dans un environnement contrôlé mais devrait être remplacé par un épinglage de certificat approprié en production.

Comparaison des clients RDP

Étape 4 : Renforcer RDP contre les menaces réelles

RDP est l’un des services les plus activement ciblés sur internet. Shodan indexe régulièrement des millions de points de terminaison RDP exposés, et des campagnes automatisées de force brute fonctionnent 24h/24 et 7j/7. Les mesures suivantes ne sont pas optionnelles pour tout serveur en production.

Changer le port d’écoute par défaut

Passer de 3389 à un port non standard élimine la grande majorité des scanners automatisés. Modifiez le registre :

$newPort = 54321  # Replace with your chosen port
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' `
    -Name "PortNumber" -Value $newPort -Type DWord

# Update firewall rule
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound `
    -Protocol TCP -LocalPort $newPort -Action Allow

# Disable the default rule
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"

Restart-Service TermService

N’oubliez pas de mettre à jour votre groupe de sécurité cloud pour autoriser le nouveau port et bloquer 3389.

Restreindre l’accès par adresse IP

Si votre poste de travail administratif dispose d’une IP statique, restreignez RDP à cette IP uniquement :

Set-NetFirewallRule -DisplayName "RDP Custom Port" `
    -RemoteAddress "YOUR_ADMIN_IP"

Appliquer une politique de verrouillage de compte

Prévenez les attaques par force brute en configurant un seuil de verrouillage de compte. Dans la stratégie de groupe (gpedit.msc) :

• Seuil de verrouillage du compte : 5 tentatives invalides
• Durée de verrouillage du compte : 30 minutes
• Réinitialiser le compteur de verrouillage du compte après : 15 minutes

Ou via PowerShell :

net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:15

Déployer un VPN ou un tunnel SSH comme passerelle

L’approche la plus robuste consiste à ne pas exposer RDP à l’internet public du tout. Placez RDP derrière un VPN (WireGuard ou OpenVPN) ou un tunnel SSH. Les administrateurs se connectent d’abord au VPN, puis via RDP à l’IP privée du serveur. Cela élimine entièrement la surface d’attaque.

Activer Windows Defender Credential Guard

Sur Windows Server 2016 et versions ultérieures, Credential Guard isole les hachages d’informations d’identification dans une enclave de sécurité basée sur la virtualisation, empêchant les attaques pass-the-hash qui peuvent pivoter depuis une session RDP compromise.

Auditer et journaliser les sessions RDP

Activez l’audit via la stratégie de groupe sous Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d’audit > Ouverture/fermeture de session. Journalisez les événements de succès et d’échec. Transférez les journaux vers un SIEM ou examinez au minimum régulièrement Event ID 4624 (ouverture de session réussie) et Event ID 4625 (ouverture de session échouée) dans l’Observateur d’événements.

Étape 5 : Dépannage des échecs de connexion RDP courants

Connexion refusée (Code d’erreur 0x204 / « L’ordinateur distant est inaccessible »)

Il s’agit presque toujours d’un problème de pare-feu ou de routage.

# Test from the client machine (replace with your server IP and port)
Test-NetConnection -ComputerName YOUR_SERVER_IP -Port 3389

Si TcpTestSucceeded retourne False, le port est bloqué. Vérifiez :

1. Le pare-feu du système d’exploitation sur le serveur (Get-NetFirewallRule -DisplayGroup "Remote Desktop")
2. Le groupe de sécurité ou la liste de contrôle d’accès du fournisseur cloud
3. Tout pare-feu matériel intermédiaire entre le client et le serveur

Erreur d’authentification (« Une erreur d’authentification s’est produite. La fonction demandée n’est pas prise en charge. »)

Cela signifie généralement que le client ne prend pas en charge la version du Credential Security Support Provider (CredSSP) requise par le serveur, ce qui survient souvent après une mise à jour de sécurité Windows (correctif CVE-2018-0886). Correctif côté serveur :

# Temporary workaround — update the client instead when possible
Set-ItemProperty -Path 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters' `
    -Name "AllowEncryptionOracle" -Value 2 -Type DWord

Le correctif permanent consiste à mettre à jour le client RDP vers une version corrigée qui prend en charge le protocole CredSSP mis à jour.

« La session distante a été déconnectée car aucun serveur de licences Bureau à distance n’est disponible »

Cela se produit lorsque le rôle Remote Desktop Session Host (RDSH) du serveur est installé mais qu’aucun serveur de licences RD n’est configuré. Pour un accès administratif simple (pas des déploiements RDSH multi-utilisateurs), supprimez le rôle RDSH ou configurez une période de grâce de 120 jours :

# Check licensing mode
(Get-WmiObject -Namespace root/CIMV2/TerminalServices -Class Win32_TerminalServiceSetting).LicensingType

Une valeur de 2 signifie Par appareil, 4 signifie Par utilisateur. Pour un accès administrateur uniquement, la valeur doit être 5 (non configuré / période de grâce).

Écran noir après la connexion

Un écran noir lors d’une connexion RDP indique généralement l’une des trois causes suivantes :

• Plantage d’Explorer.exe : Appuyez sur Ctrl + Alt + End pour ouvrir le Gestionnaire des tâches, puis exécutez explorer.exe depuis Fichier > Exécuter une nouvelle tâche.
• Conflit de pilote d’affichage : Désactivez l’accélération matérielle dans la session RDP via la stratégie de groupe.
• Problème de remoting GPU : Sur les serveurs avec des GPU dédiés (pertinent pour les charges de travail GPU Hosting), assurez-vous que l’adaptateur RemoteFX vGPU est correctement configuré.

Session RDP lente ou avec des latences

Optimisez les performances en ajustant les paramètres d’expérience de connexion dans mstsc :

mstsc /v:YOUR_SERVER_IP /f

Dans l’onglet Expérience, sélectionnez LAN (10 Mbps ou plus) et désactivez Arrière-plan du bureau, Lissage des polices et Composition du bureau pour une réactivité maximale sur les liaisons à latence élevée.

RDP vs. Protocoles d’accès à distance alternatifs

Pour l’administration de Windows Server, RDP reste le meilleur choix en termes de performance, d’intégration native et de profondeur des fonctionnalités. SSH est le protocole privilégié pour les environnements VPS Hosting basés sur Linux.

Gestion de plusieurs sessions RDP et des informations d’identification enregistrées

Enregistrement des fichiers de connexion RDP

mstsc prend en charge les fichiers de configuration .rdp, qui sont des fichiers en texte brut que vous pouvez gérer avec un système de contrôle de version :

full address:s:YOUR_SERVER_IP:3389
username:s:Administrator
prompt for credentials:i:1
audiomode:i:0
redirectdrives:i:0
redirectclipboard:i:1

Enregistrez sous server.rdp et double-cliquez pour lancer, ou invoquez via :

mstsc server.rdp

Gestionnaire d’informations d’identification

Sur Windows, les informations d’identification RDP enregistrées sont stockées dans le Gestionnaire d’informations d’identification (control keymgr.dll). Pour les scripts automatisés ou les pipelines CI/CD nécessitant un accès RDP, utilisez l’utilitaire cmdkey :

cmdkey /generic:YOUR_SERVER_IP /user:Administrator /pass:YourPassword
mstsc /v:YOUR_SERVER_IP
cmdkey /delete:YOUR_SERVER_IP

Supprimez les informations d’identification immédiatement après utilisation pour éviter une exposition persistante des informations d’identification.

Liste de contrôle pratique des points essentiels

Utilisez ceci comme matrice de vérification avant déploiement et après incident :

Configuration initiale

• RDP activé via fDenyTSConnections = 0 dans le registre
• NLA appliqué (UserAuthentication = 1)
• TermService défini sur Automatique et en cours d’exécution
• Règle de pare-feu active pour le port correct

Réseau et contrôle d’accès

• Port par défaut 3389 changé pour un port non standard
• Groupe de sécurité cloud mis à jour pour refléter le nouveau port
• Liste d’autorisation IP configurée dans la règle de pare-feu
• RDP non directement exposé à internet (passerelle VPN préférée)

Authentification et renforcement

• Politique de verrouillage de compte configurée (5 tentatives / verrouillage de 30 minutes)
• Mot de passe fort et unique pour tous les comptes avec accès RDP
• Credential Guard activé sur Windows Server 2016+
• Accès RDP limité au groupe Administrateurs intégré ou à un groupe RDP dédié

Surveillance

• Politique d’audit activée pour les événements d’ouverture/fermeture de session
• Alertes Event ID 4625 configurées pour les échecs répétés
• Journaux de session examinés périodiquement ou transférés vers un SIEM

Côté client

• Client RDP mis à jour vers la dernière version
• Fichiers .rdp stockés de manière sécurisée et non soumis dans des dépôts publics
• Informations d’identification enregistrées dans le Gestionnaire d’informations d’identification examinées et nettoyées régulièrement

Foire aux questions

Quel port RDP utilise-t-il, et peut-il être modifié ?

RDP écoute sur le port TCP 3389 par défaut. Vous pouvez le modifier en modifiant la valeur DWORD PortNumber sous HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp et en redémarrant le service TermService. Mettez à jour vos règles de pare-feu en conséquence.

Qu’est-ce que l’authentification au niveau du réseau (NLA) et doit-elle toujours être activée ?

NLA exige que le client s’authentifie via CredSSP avant que le serveur crée une session de bureau complète. Cela empêche les utilisateurs non authentifiés d’atteindre l’écran de connexion Windows, réduisant considérablement l’exposition aux attaques par bourrage d’informations d’identification et par déni de service. Elle doit toujours être activée sur les serveurs en production, sauf si vous avez une exigence spécifique de compatibilité avec un client hérité.

Pourquoi ma connexion RDP se coupe-t-elle après une période d’inactivité ?

Les délais d’expiration de session sont contrôlés par la stratégie de groupe sous Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Limites de durée de session. Les stratégies pertinentes sont Définir une limite de temps pour les sessions déconnectées et Définir une limite de temps pour les sessions des services Bureau à distance actives mais inactives. Définissez-les selon vos exigences opérationnelles plutôt que de les laisser aux valeurs par défaut.

Plusieurs utilisateurs peuvent-ils se connecter simultanément à un Windows Server via RDP ?

Une installation standard de Windows Server prend en charge deux sessions RDP administratives simultanées. Pour plus d’utilisateurs simultanés, vous avez besoin du rôle Remote Desktop Session Host (RDSH) et de licences d’accès client Remote Desktop Services (RDS CAL) valides. Sans licence appropriée, le serveur entre dans une période de grâce de 120 jours avant de refuser les connexions.

Est-il sûr d’exposer RDP directement sur l’internet public ?

Non. Exposer directement RDP sur le port 3389 à internet invite les attaques automatisées par force brute, les campagnes de livraison de ransomwares (RDP est le principal vecteur d’accès initial pour les ransomwares), et l’exploitation de vulnérabilités non corrigées. Placez toujours RDP derrière un VPN, restreignez l’accès par IP, changez le port par défaut, et appliquez NLA et des politiques de verrouillage de compte comme base minimale.