Windows Server 2022 : limiter l’accès RDP à 15 PC précis via VPN (pare‑feu, IPsec, RD Gateway)

Vous administrez ~50 postes reliés par VPN et vous devez autoriser le RDP vers un serveur Windows Server 2022 depuis seulement 15 PC. Voici une méthode complète et fiable (pare‑feu, identité, IPsec, RD Gateway, ACL VPN) pour bloquer toutes les autres machines sans vous enfermer dehors.

Sommaire

Contexte et malentendus courants

Le besoin paraît simple : « n’autoriser RDP qu’à 15 postes précis ». Pourtant, plusieurs pièges classiques font perdre du temps.

Le droit “Allow log on through Remote Desktop Services” (secpol.msc) détermine qui (utilisateurs/groupes) a le droit d’ouvrir une session RDP. Il ne filtre ni le réseau d’origine ni la machine cliente.
Ajouter des ordinateurs au groupe “Remote Desktop Users” ne sert à rien : ce groupe attend des comptes utilisateurs, pas des objets ordinateur.
Le pare‑feu Windows Server 2022 ne sait pas filtrer par nom d’ordinateur en clair. Il filtre par adresses IP/réseaux (ou par identité machine si vous activez l’authentification réseau via IPsec).
La piste “Scope > Add > Computer” n’existe pas pour une règle RDP classique ; pour du “par machine”, il faut passer par “Allow the connection if it is secure” + IPsec.

Approche recommandée : 3 couches complémentaires

Pour un blocage robuste et compréhensible, combinez trois contrôles :

Couche	Ce que ça fait	Où	Objectif
Identité	Détermine quels utilisateurs ont le droit RDP	GPO / secpol.msc	N’autoriser que les comptes autorisés (administrateurs et/ou opérateurs)
Réseau	Limite les origines IP pouvant joindre 3389	Pare‑feu Windows du serveur	Réduire la surface d’attaque aux 15 adresses prévues
Identité machine (optionnel mais fort)	Autorise seulement des PC authentifiés (AD) via IPsec	Pare‑feu Windows + règles de sécurité de connexion	Filtrer “par nom d’ordinateur” (groupe d’ordinateurs AD)

Étape 1 — Restreindre par identité (qui peut se connecter)

1.1 Créez des groupes AD dédiés

Dans Active Directory, créez par exemple :
- RDP-ServeurX-Utilisateurs (les comptes autorisés à ouvrir une session RDP sur ce serveur).
- RDP-ServeurX-Admins (vos comptes d’administration, si séparés).
Ajoutez uniquement les comptes nécessaires. Évitez d’y mettre des groupes trop larges (ex. Domain Users).

1.2 Appliquez le droit “Allow log on through Remote Desktop Services”

Option locale (rapide) : sur le serveur, exécutez secpol.msc → Local Policies > User Rights Assignment → Allow log on through Remote Desktop Services → Ajoutez RDP-ServeurX-Utilisateurs et retirez les groupes trop permissifs (gardez les admins nécessaires pour ne pas vous enfermer).

Option GPO (industrialisation) : dans une GPO liée OU/serveur cible :

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
Configurez Allow log on through Remote Desktop Services avec uniquement RDP-ServeurX-Utilisateurs (et vos groupes d’admins).
Vérifiez aussi Deny log on through Remote Desktop Services (qu’il ne bloque pas vos comptes autorisés).

Astuce : appliquez la GPO à une cible précise (filtrage de sécurité, WMI filter si nécessaire) et testez avant généralisation.

Étape 2 — Restreindre par réseau (d’où l’on peut se connecter)

Le serveur ne doit accepter 3389 (TCP/UDP) que depuis vos 15 adresses VPN (ou vos pools strictement nécessaires).

2.1 Stabilisez les IP des 15 postes

Réservations DHCP sur votre serveur/votre concentrateur VPN : mappez chaque adresse MAC/identifiant client VPN → IP fixe.
Si vous n’avez pas de garanties IP, passez directement à l’option IPsec (Étape 3) qui travaille par identité machine.

2.2 Désactivez les règles RDP par défaut

Sur le serveur :

Set-NetFirewallRule -DisplayGroup "Remote Desktop" -Enabled False

2.3 Créez deux règles entrantes personnalisées (TCP et UDP)

Exemple PowerShell :

# Listez vos 15 adresses (séparées par des virgules)
$ips = "10.20.30.11,10.20.30.12,10.20.30.13,10.20.30.14,10.20.30.15,10.20.30.16,10.20.30.17,10.20.30.18,10.20.30.19,10.20.30.20,10.20.30.21,10.20.30.22,10.20.30.23,10.20.30.24,10.20.30.25"

# TCP 3389

New-NetFirewallRule -DisplayName "RDP TCP depuis postes autorisés" `  -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress $ips`
-Action Allow -Profile Domain -InterfaceType RemoteAccess

# UDP 3389 (optimisations RDP modernes)

New-NetFirewallRule -DisplayName "RDP UDP depuis postes autorisés" `  -Direction Inbound -Protocol UDP -LocalPort 3389 -RemoteAddress $ips`
-Action Allow -Profile Domain -InterfaceType RemoteAccess

Paramètres clés :

RemoteAddress : saisissez uniquement vos IP autorisées (ou une plage VPN maîtrisée).
InterfaceType = RemoteAccess : limite explicitement aux interfaces VPN.
Profils : Domain (et Private si pertinent), jamais Public.

2.4 Exemple d’inventaire des 15 postes

#	Nom d’ordinateur	Adresse IP VPN	MAC / Identifiant	Réservation DHCP
1	PC-RDG-001	10.20.30.11	AA-BB-CC-01-02-03	Oui
2	PC-RDG-002	10.20.30.12	AA-BB-CC-04-05-06	Oui
…	…	…	…	…
15	PC-RDG-015	10.20.30.25	AA-BB-CC-XX-YY-ZZ	Oui

Étape 3 — IP instables ? Passez au filtrage par identité machine (IPsec)

Si vos IP clients ne sont pas fixes ou que vous souhaitez un contrôle « par nom d’ordinateur », activez l’authentification réseau (IPsec). L’idée : vous autorisez RDP uniquement si la connexion est sécurisée et que la machine cliente appartient à un groupe d’ordinateurs AD précis.

3.1 Principe

Sur le serveur, créez une règle de pare‑feu RDP en mode “Allow the connection if it is secure” et “Only allow connections from these computers” → ajoutez un groupe d’ordinateurs AD (ex. RDP-ServeurX-Ordinateurs) contenant vos 15 PC.
Déployez des règles de sécurité de connexion (IPsec) qui forcent l’authentification machine (Kerberos ou certificats) entre ces PC et le serveur.

3.2 Mise en place via GPO (recommandé)

GPO A — Serveur (liée à l’OU du serveur) :

Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security.
Inbound Rules → New Rule > Custom :
- Program : Any, Protocol : TCP, Local port : 3389.
- Scope : Any (le tri se fera par identité, pas par IP).
- Action : Allow the connection if it is secure → Customize :
  - Require authentication (Kerberos par défaut en domaine).
  - Authorized computers : cochez Only allow connections from these computers et ajoutez le groupe AD RDP-ServeurX-Ordinateurs.
  - (Optionnel) Authorized users : laissez vide si le contrôle utilisateur est déjà géré à l’Étape 1.
- Profile : Domain (et Private si nécessaire). Name : RDP TCP (IPsec) – Clients autorisés.
Répétez pour UDP 3389 (mêmes paramètres, protocole UDP).
Connection Security Rules → New > Isolation :
- Choisissez Require authentication for inbound and outbound connections.
- Authentication : Default (Computer Kerberos) si toutes les machines sont jointes au domaine ; sinon Computer certificate.
- Profile : Domain.
- Cette règle ordonnera au serveur d’accepter/établir des sessions IPsec avec les clients de domaine.

GPO B — Clients (liée à l’OU contenant RDP-ServeurX-Ordinateurs) :

Dans Connection Security Rules : créez une règle Server‑to‑Server ou Isolation qui requiert l’authentification pour communiquer avec l’IP/FQDN du serveur (ou avec son groupe de serveurs).
Authentication : Kerberos (ou certificats si hors domaine).
Profile : Domain.

Résultat : si le PC n’appartient pas au groupe d’ordinateurs autorisés ou n’établit pas IPsec, le trafic 3389 est rejeté avant l’invite de connexion RDP. Vous avez du « par nom d’ordinateur » robuste.

3.3 Remarques pratiques

Assurez‑vous que le VPN transporte IPsec (transport mode) sans l’altérer.
Sur des environnements mixtes/non joints au domaine, préférez l’authentification certificat machine.
Surveillez l’onglet Monitoring du pare‑feu avancé pour voir les associations SAs IPsec actives.

Option : RD Gateway (+ NPS) pour un point d’entrée unique

Le RD Gateway ajoute une passerelle TLS entre Internet/VPN et vos hôtes RDP. Bénéfices : plus d’ouverture 3389 directe, journalisation centralisée, et politiques d’accès (CAP/RAP) par utilisateur. C’est souvent la meilleure architecture pour exposer RDP de façon contrôlée.

Principe minimal : on n’ouvre 3389 sur le serveur que depuis l’adresse du RD Gateway. Le Gateway autorise l’accès RDP aux utilisateurs membres d’un groupe AD (CAP) et vers des ressources précises (RAP).
Contrôle par machine : pour approcher le « par nom d’ordinateur client », combinez RD Gateway avec NPS et une authentification par certificat de l’appareil. En exigeant un certificat machine sur les 15 PC et des conditions NPS appropriées, vous contournez la variabilité IP sans ouvrir à tout le monde.

Étapes clés :

Installez le rôle Remote Desktop Gateway (NPS inclus).
Créez une CAP autorisant un groupe d’utilisateurs (ex. RDP-ServeurX-Utilisateurs).
Créez une RAP qui cible uniquement le(s) serveur(s) autorisés.
Sur le serveur cible : ouvrez 3389 uniquement depuis l’IP du RD Gateway.
(Option) Déployez des certificats ordinateur sur les 15 PC et adaptez les conditions NPS pour ne laisser passer que ces appareils.

Option : ACL côté VPN

Si votre concentrateur VPN le permet, appliquez une ACL :

Source : objet/groupe correspondant à vos 15 postes.
Destination : IP du serveur Windows.
Ports : TCP/UDP 3389.

Avantage : rien à changer sur le serveur. Inconvénient : dépend du modèle/firmware VPN et de la précision d’inventaire.

Contrôles & dépannage

Tests rapides

Depuis un PC non autorisé, tentez un RDP : la connexion doit échouer avant l’invite d’identification.
Depuis un PC autorisé, validez à la fois TCP et UDP (latence, qualité d’affichage).

Journaux utiles

Security : événements 4624 (succès) / 4625 (échec) – type de logon 10 (RDP).
Microsoft‑Windows‑TerminalServices‑RemoteConnectionManager/Operational : suivi des connexions (par ex. 1149).
Windows Defender Firewall with Advanced Security : activez la journalisation des paquets bloqués.

# Activer les logs de paquets bloqués pour le profil courant
netsh advfirewall set currentprofile logging droppedconnections enable
netsh advfirewall set currentprofile logging filename "C:\Windows\System32\LogFiles\Firewall\pfirewall.log"

Diagnostics PowerShell

# Voir les règles RDP actives
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Format-Table -Auto

# Vérifier vos règles personnalisées

Get-NetFirewallRule | Where-Object DisplayName -like "*RDP*" |
Get-NetFirewallAddressFilter |
Select-Object Name,RemoteAddress

# Vérifier l'interface type (doit contenir RemoteAccess)

Get-NetFirewallRule | Where-Object DisplayName -like "*RDP*" |
Get-NetFirewallInterfaceFilter |
Select-Object Name,InterfaceType

Pièges fréquents

Une autre règle “autorise tout” sur 3389 (ex. “Remote Desktop – User Mode”) restée activée.
IP clients non stables : vos règles par IP deviennent inopérantes.
NLA désactivée : augmente la surface d’attaque. Laissez NLA activée.
GPO en conflit : utilisez gpresult /h et l’RSOP pour résoudre.

Bonnes pratiques sécurité

Plan d’accès d’urgence : KVM/iLO/iDRAC/console hyperviseur avant de durcir le RDP.
Mises à jour régulières du serveur et des clients RDP (failles RDP historiques).
MFA si vous utilisez RD Gateway.
Mots de passe forts, verrouillage de compte, politique d’expiration, audit.
Changer le port RDP n’est pas une protection suffisante ; privilégiez identité + filtrage réseau + IPsec/RD Gateway.

Procédure “tout‑en‑un” : version minimaliste (par IP fixes)

Créer les groupes AD RDP-ServeurX-Utilisateurs et y placer uniquement les comptes autorisés.
Configurer le droit Allow log on through Remote Desktop Services (secpol.msc ou GPO) avec ce groupe (et vos admins).
Désactiver toutes les règles entrantes RDP par défaut du groupe Remote Desktop.
Créer deux règles entrantes personnalisées 3389/TCP et 3389/UDP avec RemoteAddress limité aux 15 IP, InterfaceType = RemoteAccess, Profile = Domain.
Stabiliser les IP (réservations DHCP).
Tester depuis un poste non autorisé (échec avant l’invite) et un poste autorisé (succès).

Procédure “tout‑en‑un” : version robuste (par identité machine via IPsec)

Créer RDP-ServeurX-Ordinateurs (groupe AD) et y placer les 15 PC.
GPO Serveur :
- Règles entrantes RDP (TCP/UDP) en Allow if secure + Authorized computers = groupe AD.
- Connection Security Rule : Isolation (Require inbound/outbound, Kerberos).
GPO Clients (ciblée sur le groupe d’ordinateurs) :
- Connection Security Rule vers le serveur (Require, Kerberos).
Fermer 3389 aux IP générales (désactiver les règles par défaut).
Tester et monitorer les SAs IPsec.

FAQ ciblée

Peut-on filtrer RDP “par nom d’ordinateur” sans IPsec ?
Pas nativement. Le pare‑feu s’exprime en IP. Pour du “par machine” côté Windows, utilisez l’option Allow if secure + IPsec (auth machine) ou placez un RD Gateway/NPS avec certificats machine.

Faut-il aussi filtrer l’UDP 3389 ?
Oui. Depuis Windows 8/Server 2012, RDP utilise UDP pour de meilleures performances. Filtrez TCP et UDP.

Une ACL VPN suffit‑elle ?
Souvent oui. C’est propre et central. Mais gardez une défense en profondeur côté serveur.

Que faire si un poste autorisé devient compromis ?
Retirez‑le du groupe AD (utilisateurs et/ou ordinateurs) et, si IPsec, révoquez le certificat machine si vous en utilisez. Enquêtez via vos journaux.

Checklist finale

✔ Comptes utilisateurs autorisés seulement (GPO/secpol).
✔ Règles RDP par défaut désactivées.
✔ Règles 3389 TCP/UDP whitelistées (IP fixes) ou RDP Allow if secure + IPsec (groupe d’ordinateurs AD).
✔ InterfaceType = RemoteAccess (VPN) sur les règles.
✔ NLA activée.
✔ Journalisation pare‑feu/événements vérifiée.
✔ Accès d’urgence prêt avant durcissement.

Exemples PowerShell supplémentaires

Ré‑activer temporairement RDP pour maintenance (toutes interfaces du domaine) :

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Start-Sleep -Seconds 600
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -Enabled False

Exporter la configuration pare‑feu avant/après :

netsh advfirewall export "C:\Temp\fw_before.wfw"
# ... vos changements ...
netsh advfirewall export "C:\Temp\fw_after.wfw"

Auditer les IP qui frappent 3389 (compteur basique) :

# Nécessite la journalisation des paquets droppés
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern ":3389" |
  ForEach-Object {
    if ($_ -match "SRC=([\d\.]+)") { $matches[1] }
  } | Group-Object | Sort-Object Count -Descending |
  Select-Object Name,Count

Conclusion

Windows Server 2022 ne sait pas, à lui seul, “filtrer RDP par nom d’ordinateur”. Pour atteindre l’objectif, combinez : contrôle par identité (qui a le droit RDP) + liste blanche d’IP (si vos adresses sont stables) ou IPsec (pour un vrai contrôle par machine) + contraintes VPN (InterfaceType = RemoteAccess/ACL côté concentrateur). En ajoutant un RD Gateway, vous centralisez l’accès et durcissez encore la surface d’attaque. Ce trio fournit un verrou efficace contre tout poste non autorisé, sans sacrifier l’opérabilité.