Accès RDP sécurisé Windows Server 2022 (AD) : VPN, RD Gateway, NLA/MFA et GPO

Besoin d’ouvrir un accès RDP à un poste ou serveur Windows Server 2022 joint au domaine ? Voici une méthode complète, sécurisée et conforme aux bonnes pratiques : droits minimaux, VPN ou RD Gateway, NLA/MFA, GPO et durcissement réseau.

Sommaire

Permettre l’accès distant à un poste ou serveur Windows Server 2022 joint au domaine

Vue d’ensemble de la question

Une administratrice gère un Active Directory sur Windows Server 2022. Un employé doit travailler à distance et prendre la main sur une machine du domaine (poste Windows 10/11 ou serveur). Faut‑il le placer simplement dans le groupe Remote Desktop Users ou prévoir une configuration plus complète ? Quelles exigences réseau et de sécurité appliquer ?

Réponse et solutions

Étape	Action	Points clés
Activer le service RDP	– Sur l’hôte cible : Paramètres système ▸ Accès à distance → cocher « Autoriser les connexions à distance ». – Pour plus de deux sessions simultanées ou un usage multi‑utilisateurs, installer le rôle Remote Desktop Session Host et prévoir des CAL RDS.	Sans CAL, le serveur n’offre que deux sessions « administration ».
Attribuer les droits de connexion	– Créer/choisir un compte AD. – Ajouter le compte à Remote Desktop Users (local) ou à un groupe AD référencé par GPO : Computer Configuration ▸ Policies ▸ Windows Settings ▸ Security Settings ▸ User Rights Assignment ▸ Allow log on through Remote Desktop Services.	Aucun droit d’administrateur requis.
Assurer la connectivité	– Mettre en place un VPN (client–site ou site‑à‑site) ou un RD Gateway pour éviter toute exposition directe. – Ouvrir le port TCP 3389 uniquement côté VPN/RD Gateway.	Vérifier la résolution de nom AD ou utiliser l’IP interne.
Sécuriser l’accès	– Activer NLA (Network Level Authentication). – Exiger mot de passe fort et MFA (Azure MFA, Duo…). – Maintenir OS et applications à jour. – Pare‑feu Windows : autoriser la règle Remote Desktop (TCP‑In) profil « Domaine » seulement.	Réduire la surface d’attaque brute force et les risques RDP.
Tester et dépanner	– Depuis le poste distant : `mstsc` → nom/IP de l’hôte. – En cas d’échec : vérifier l’appartenance au groupe avec `whoami /groups`, puis consulter l’Observateur d’évènements (TerminalServices‑LocalSessionManager/Operational) pour les ID 1149/4625.	Les journaux révèlent les problèmes de droits ou d’authentification.

Procédure détaillée et bonnes pratiques

Pré‑requis côté Active Directory et DNS

Le poste/serveur cible doit être joint au domaine et synchronisé avec un contrôleur de domaine (heure, DNS, GPO).
Le compte de l’employé reste dans Domain Users (principe du moindre privilège). Créez si nécessaire un groupe AD (ex. G_RDP_Utilisateurs) pour gérer les droits en masse.
Assurez une résolution DNS interne : via VPN poussez les DNS internes et un suffixe (ex. corp.local). Avec RD Gateway, la résolution se fait côté gateway ; un FQDN du serveur cible reste recommandé.

Activation de RDP sur la machine cible

Deux approches sont possibles : manuelle ou via GPO/PowerShell.

Interface graphique : Paramètres ▸ Système ▸ Bureau à distance → activer « Bureau à distance ». Confirmez l’autorisation de la règle pare‑feu.
PowerShell (administrateur) :

# Activer RDP
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0
# Ouvrir les règles pare-feu RDP (TCP/UDP In) profil Domaine
Enable-NetFirewallRule -DisplayGroup 'Bureau à distance'
# Forcer NLA via GPO ou registre si nécessaire

Attribution des droits de connexion RDP

La méthode recommandée est de lier une GPO à l’OU des hôtes cibles :

Dans la GPO : Computer Configuration ▸ Policies ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ User Rights Assignment.
Définissez Allow log on through Remote Desktop Services → ajoutez votre groupe AD (ex. G_RDP_Utilisateurs).
Vérifiez Deny log on through Remote Desktop Services pour y laisser « Guests », et idéalement « Local account » afin d’empêcher les comptes locaux de se connecter via RDP.
Optionnel : via Restricted Groups ou Group Policy Preferences ▸ Local Users and Groups, ajoutez le groupe AD au groupe local Remote Desktop Users.

Aucun droit d’administration n’est requis pour ouvrir une session RDP standard. Évitez d’ajouter l’utilisateur dans « Administrators ».

Connectivité : VPN ou RD Gateway

Jamais d’exposition directe du port 3389 sur Internet. Deux architectures éprouvées :

VPN : le client rejoint le réseau interne. Choix courants : IKEv2, SSTP. Ouvrez les ports VPN sur le pare‑feu périmétrique, puis laissez RDP accessible uniquement « profil Domaine » côté hôtes. Avantages : compatibilité large, visibilité totale du réseau. Points d’attention : posture du poste, split‑tunneling, durcissement du client VPN.
RD Gateway : proxy RDP encapsulé en HTTPS (TCP 443) + UDP 3391. Demande un certificat public (CN = rdgw.votre‑domaine). On contrôle finement « qui » se connecte et « à quoi » via des CAP (Connection Authorization Policies) et RAP (Resource Authorization Policies). Idéal avec MFA.

Durcissement RDP via GPO

Appliquez une GPO « Sécurité RDP » sur l’OU des serveurs/postes accessibles :

Computer Configuration ▸ Administrative Templates ▸ Windows Components ▸ Remote Desktop Services ▸ Remote Desktop Session Host ▸ Security :
- Require user authentication for remote connections by using NLA : Enabled.
- Set client connection encryption level : High (ou FIPS selon politique interne).
- Require use of specific security layer for RDP connections : SSL (TLS).
- Always prompt for password upon connection : Enabled.
- Do not allow drive/printer/clipboard/COM port redirection : à activer selon la sensibilité (au minimum, limitez le presse‑papier et les lecteurs).
- Set time limit for active but idle RDS sessions et End a disconnected session : évitez les sessions orphelines.
- Set keep‑alive connection interval : améliore la détection de sessions tombées.
Computer Configuration ▸ Administrative Templates ▸ System ▸ Credentials Delegation :
- Restrict delegation of credentials : Require Remote Credential Guard si compatible (réduit les risques de vol de tickets/NTLM).
Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ Security Options :
- Verrouillage de compte (seuils, durées), complexité des mots de passe.

Gestion des certificats RDP

Par défaut, RDP utilise un certificat auto‑signé. Déployez un certificat approuvé pour supprimer les alertes et activer l’authentification serveur forte :

Mettre en place l’auto‑inscription d’un certificat Computer avec l’usage « Server Authentication » via AD CS.
Dans la GPO RDP : Remote Desktop Services ▸ Remote Desktop Session Host ▸ Security ▸ Server authentication certificate template → spécifiez le modèle.
Sur RD Gateway : installez un certificat public correspondant au FQDN exposé.

MFA et accès conditionnel

MFA obligatoire pour toute entrée depuis Internet. Sur RD Gateway, intégrez une solution MFA (extension NPS, fournisseur tiers) pour protéger la CAP.
Restreignez par adresses IP de pays/clients autorisés sur le pare‑feu périmétrique.
Optionnel : contrôles de posture (antivirus actif, chiffrement disque) via votre solution MDM/EDR et VPN.

Licences et scénarios multi‑utilisateurs

Un Windows Server autorise deux sessions d’administration sans CAL. Pour des sessions utilisateurs régulières ou simultanées, déployez le rôle RDS Session Host avec CAL RDS (par utilisateur ou par appareil), ainsi qu’un serveur de licences RDS.
Un poste Windows 10/11 joint au domaine accepte une seule session interactive à la fois et ne nécessite pas de CAL RDS.

Exemples de règles pare‑feu Windows

Limiter les règles RDP aux profils « Domaine » et aux adresses du VPN/RD Gateway :

# Activer uniquement en profil Domaine
Set-NetFirewallRule -DisplayGroup 'Bureau à distance' -Profile Domain -Enabled True
# Restreindre la règle TCP-in à l'adresse du RD Gateway (ex. 10.10.10.5)
Set-NetFirewallRule -DisplayName 'Bureau à distance - Mode utilisateur (TCP-In)' -RemoteAddress 10.10.10.5
# Même chose pour UDP-in si utilisé
Set-NetFirewallRule -DisplayName 'Bureau à distance - Mode utilisateur (UDP-In)' -RemoteAddress 10.10.10.5

Flux de décision recommandé

Le besoin est ponctuel et administratif → utilisez les deux sessions d’administration + VPN/RD Gateway + NLA/MFA.
Plusieurs utilisateurs en simultané sur un même serveur applicatif → RDS Session Host avec CAL RDS + RD Gateway + MFA.
Postes utilisateurs distants gérés → Always On VPN ou solution cloud desktop (AVD/Windows 365) selon vos contraintes.

Configuration étape par étape

Création du groupe AD et GPO

Créer le groupe G_RDP_Utilisateurs et y ajouter l’employé.
Créer une GPO « RDP Accès Sécurisé » liée à l’OU des hôtes cibles.
Configurer les paramètres Allow log on through RDS (ajoutez votre groupe) et les paramètres de sécurité décrits plus haut.
Forcer l’application via gpupdate /force et vérifiez whoami /groups côté machine cible.

Mise en place d’un RD Gateway

Installer le rôle « Remote Desktop Services » → RD Gateway.
Assigner un certificat public valide au service.
Définir les CAP (qui peut se connecter, MFA requis) et RAP (vers quelles ressources).
N’ouvrir que TCP 443 (et UDP 3391 si souhaité) vers la gateway depuis Internet. Ne pas publier 3389.
Distribuer un fichier .rdp ou un client RDP préconfiguré (adresse de la gateway, FQDN des cibles).

Mise en place d’un VPN orienté entreprise

Choisir IKEv2 ou SSTP pour traverser les proxys.
Activer MFA sur l’authentification VPN.
Déployer la configuration via GPO/MDM : serveur, méthodes d’authentification, DNS internes, suffixe de recherche.
Limiter réseau via ACL et segmentation (l’utilisateur n’a accès qu’aux hôtes nécessaires).

Durcissement complémentaire

Journalisation : activer l’audit des ouvertures de session réussies/échouées. Collecter les événements 1149 (tentatives RDP), 4624/4625 (succès/échec), 4776 (NTLM), 4648 (utilisation d’identifiants explicites).
LAPS : gérer les mots de passe des comptes locaux admin pour éviter leur réutilisation.
Blocage des comptes : seuil, durée et fenêtre d’observation adaptés à votre risque.
Renouvellement de certificats : surveiller les expirations (RD Gateway, certificats RDP serveurs).

Dépannage ciblé

Symptôme	Vérifications	Actions correctives
« Accès refusé » avant le mot de passe	Utilisateur absent de Allow log on through RDS ou du groupe Remote Desktop Users. Règle Deny log on through RDS trop large.	Corriger la GPO, exécuter `gpresult /r` et `whoami /priv`, tester de nouveau.
Impossible d’établir la session	Port 3389 bloqué entre client (via VPN/RDGW) et hôte. Service TermService arrêté.	`Test-NetConnection <hôte> -Port 3389`, démarrer le service, vérifier pare‑feu et profils.
Certificat non approuvé	Certificat auto‑signé ou CN ne correspondant pas au FQDN.	Déployer un certificat approuvé (AD CS pour hôtes, public pour RD Gateway).
Connexions lentes	Bande passante/latence, redirections périphériques excessives, absence d’UDP RDP.	Désactiver redirections inutiles, ouvrir UDP 3391 pour RDGW, ajuster la qualité de l’expérience.
Échecs d’authentification à répétition	Brute force externe, compte verrouillé, horloge non synchronisée.	Activer MFA, géo‑filtrage et listes d’autorisation IP, vérifier NTP/heure.

Commandes utiles

# Côté client
mstsc /v:serveur.corp.local
mstsc /admin          # Session d'administration
mstsc /remoteGuard    # Si Remote Credential Guard déployé

# Côté serveur/PC cible

quser                 # Voir les sessions
qwinsta               # Lister les sessions
logoff            # Déconnecter une session
whoami /groups        # Vérifier l'appartenance aux groupes
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' | Select TimeCreated, Id, Message -First 10
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 | Format-Table TimeCreated, Id, Message -Auto

Modèle de GPO prêt à l’emploi

Créez une GPO « RDP – Accès sécurisé » et appliquez les paramètres ci‑dessous :

User Rights Assignment : « Allow log on through RDS » → G_RDP_Utilisateurs. « Deny log on through RDS » → Guests, Local account.
Security : NLA = Enabled, Security layer = SSL (TLS), Encryption level = High, Always prompt for password = Enabled.
Device and Resource Redirection : interdire presse‑papiers/lecteurs/caméra selon sensibilité.
Session Time Limits : idle = 15–30 min, disconnected = 1–2 h.
RDP Certificate : modèle « Computer » auto‑inscrit.

Cas particuliers et recommandations

Contrôleurs de domaine : évitez l’accès RDP régulier. Préférez consoles d’administration à distance, PowerShell Remoting et outils dédiés. Si RDP nécessaire : RD Gateway + MFA, suivi renforcé et accès JIT (just‑in‑time).
Accès externe temporaire : utilisez des identités éphémères, une durée d’appartenance limitée au groupe G_RDP_Utilisateurs et des mots de passe de durée de vie courte.
Journalisation centralisée : envoyez les logs RDP/Sécurité vers votre SIEM, mettez en place des alertes sur 4625 en rafale et 1149 hors horaires.
Postes non gérés : éviter de leur donner un accès VPN complet. Préférez RD Gateway + MFA + redirections limitées, ou une solution de bureau hébergé.

Informations complémentaires utiles

Limites sans licence RDS : Windows Server autorise toujours deux connexions « admin » gratuites ; l’accès à un poste Windows 10/11 joint au domaine ne nécessite pas de CAL RDS, mais n’accepte qu’une seule session interactive simultanée.
Moderniser l’accès :
- RD Gateway + MFA : remplace souvent un VPN complet ; chiffre le trafic RDP via HTTPS.
- Always On VPN ou DirectAccess : connectivité réseau transparente dès l’ouverture de session.
- Azure Virtual Desktop / Windows 365 : centralise et sécurise les postes distants.
Bonnes pratiques :
- Journaliser toutes les ouvertures de session et activer le verrouillage après plusieurs échecs.
- Réviser trimestriellement les membres de Remote Desktop Users.
- Sauvegarder et renouveler les certificats si un RD Gateway est déployé (évite les alertes SSL).

Exemple de check‑list opérationnelle

Point	Vérifié	Notes
Hôte joint au domaine, GPO appliquées	□
RDP activé + règles pare‑feu profil Domaine	□
Groupe AD « G_RDP_Utilisateurs » créé et rempli	□
GPO « Allow log on through RDS » configurée	□
VPN ou RD Gateway opérationnel(le) avec MFA	□
Certificats RDP/RD Gateway valides	□
Redirections périphériques restreintes	□
Surveillance des événements 1149/4624/4625	□

FAQ rapide

Un simple ajout dans « Remote Desktop Users » suffit‑il ?
Non, pas pour un accès externe. L’ajout est nécessaire pour l’autorisation locale, mais il doit être complété par une connectivité sécurisée (VPN ou RD Gateway), une GPO correctement définie (NLA, chiffrement, droits), et des contrôles MFA.

Faut‑il ouvrir 3389 sur Internet ?
Jamais. Passez par un RD Gateway (443) ou un VPN. Ouvrir 3389 sur Internet expose votre SI aux scans et attaques en force brute.

Comment gérer plusieurs utilisateurs simultanés sur un même serveur applicatif ?
Déployez RDS Session Host avec des CAL RDS et un RD Gateway. Paramétrez des CAP/RAP et appliquez un durcissement GPO.

Le client doit‑il résoudre le FQDN du serveur cible ?
Avec VPN : oui, car la résolution se fait côté client sur DNS interne. Avec RD Gateway : la gateway résout côté réseau interne, mais l’usage d’un FQDN cohérent reste recommandé pour l’audit et les certificats.

Peut‑on éviter de stocker des identifiants dans les clients RDP ?
Oui : activez « Always prompt for password » via GPO et utilisez Remote Credential Guard lorsque c’est possible.

Conclusion

La combinaison gagnante pour un accès RDP sûr à une machine Windows Server 2022 (ou un poste Windows 10/11) jointe au domaine est la suivante : droits minimaux via un groupe AD dédié, tunnel sécurisé via VPN ou RD Gateway (jamais de 3389 exposé), NLA + MFA, certificats valides, durcissement GPO et journalisation continue. Cette approche garantit une expérience utilisateur fluide et une posture de sécurité robuste.