Comment configurer MFA pour RD Gateway : architecture, étapes et meilleures pratiques

Introduction

Le passerelle de bureau à distance (RD Gateway) sécurise RDP via HTTPS, mais les mots de passe à eux seuls ne peuvent pas arrêter le phishing, le remplissage d'identifiants ou les attaques par force brute. L'ajout de l'authentification multi-facteurs (MFA) comble cette lacune en vérifiant l'identité de l'utilisateur avant qu'une session ne soit établie. Dans ce guide, vous apprendrez comment la MFA s'intègre avec RD Gateway et NPS, les étapes de configuration exactes, et les conseils opérationnels qui maintiennent votre déploiement fiable à grande échelle.

Pourquoi RD Gateway a-t-il besoin de MFA ?

Le portail RD centralise et audite remote access , mais il ne peut pas neutraliser les identifiants volés par lui-même. Le credential stuffing et le phishing contournent régulièrement les défenses à facteur unique, en particulier là où des protocoles anciens et une large exposition existent. L'application de l'authentification multifacteur au niveau d'authentification RDG bloque la plupart des attaques courantes et augmente considérablement le coût des intrusions ciblées.

Pour les RDP exposés à Internet, les risques dominants sont la réutilisation des mots de passe, les tentatives de force brute, la relecture de jetons et le détournement de session via des TLS mal configurés. La MFA contrecarre ces risques en exigeant un second facteur résistant à la relecture des identifiants.

De nombreux cadres—NIST 800-63, contrôles ISO/IEC 27001 et diverses bases de référence en matière d'assurance cybernétique—s'attendent implicitement ou explicitement à une MFA sur remote access Les chemins. La mise en œuvre de l'authentification multifacteur sur RDG satisfait à la fois l'intention de contrôle et les attentes des auditeurs sans réarchitecturer votre pile de livraison.

Comment MFA s'intègre-t-il à l'architecture RD Gateway ?

Le plan de contrôle est simple : l'utilisateur lance RDP via RDG ; RDG envoie l'authentification à NPS via RADIUS ; NPS évalue la politique et invoque le fournisseur MFA ; en cas de succès, NPS renvoie Access-Accept et RDG termine la connexion. L'autorisation d'accès aux actifs internes est toujours régie par RD CAP/RD RAP, donc la vérification d'identité est additive plutôt que perturbatrice.

• Flux d'authentification et points de décision
• Considérations UX pour les utilisateurs distants

Flux d'authentification et points de décision

Les points de décision clés incluent l'endroit où la logique MFA s'exécute (NPS avec l'extension Entra MFA ou un proxy RADIUS tiers), quels facteurs sont autorisés et comment les échecs sont gérés. Centraliser les décisions sur NPS simplifie l'audit et le contrôle des modifications. Pour de grands environnements, envisagez une paire NPS dédiée pour découpler l'évaluation des politiques de la capacité RDG et simplifier les fenêtres de maintenance.

Considérations UX pour les utilisateurs distants

Les notifications push et basées sur des applications offrent l'expérience la plus fiable dans le RDP flux d'identification. Les SMS et les appels vocaux peuvent échouer lorsqu'aucune interface utilisateur de demande secondaire n'existe. Éduquez les utilisateurs sur les demandes attendues, les délais d'attente et les raisons de refus pour réduire les tickets de support. Dans les régions à forte latence, prolongez modérément les délais de défi pour éviter les échecs faux sans masquer les abus réels.

Qu'est-ce que la liste de contrôle des prérequis ?

Une configuration propre commence par des rôles de plateforme vérifiés et une hygiène d'identité. Assurez-vous que RDG est stable sur un serveur Windows pris en charge et planifiez un chemin de retour. Confirmez les groupes de répertoire pour définir l'accès des utilisateurs et validez que les administrateurs peuvent distinguer les changements de politique des problèmes de certificat ou de réseau.

• Rôles, Ports et Certificats
• Préparation du répertoire et de l'identité

Rôles, Ports et Certificats

Déployez le rôle NPS sur un serveur avec une connectivité AD fiable. Standardisez sur RADIUS UDP 1812/1813 et documenter toute utilisation héritée 1645/1646. Sur RDG, installez un certificat TLS de confiance public pour l'auditeur HTTPS et supprimez les protocoles et chiffrements faibles. Enregistrez les secrets partagés dans un coffre-fort, pas dans un ticket ou une note de bureau.

Préparation du répertoire et de l'identité

Créez des groupes AD dédiés pour les utilisateurs et les administrateurs autorisés par RDG ; évitez le champ "Utilisateurs du domaine". Vérifiez que les utilisateurs sont inscrits dans MFA s'ils utilisent Entra ID. Pour les fournisseurs tiers, synchronisez les identités et testez un utilisateur pilote de bout en bout avant un large enrollement. Alignez les formats de nom d'utilisateur (UPN vs sAMAccountName) entre RDG, NPS et la plateforme MFA pour éviter les incohérences silencieuses.

Quelle est la configuration étape par étape de la MFA pour RD Gateway ?

• Installer et enregistrer NPS
• Ajouter le portail RD en tant que client RADIUS
• Créer des politiques NPS (CRP et NP)
• Installer l'extension MFA ou un agent tiers
• Point RD Gateway vers NPS Central (magasin RD CAP)
• Test MFA de bout en bout

Étape 1 — Installer et enregistrer NPS

Installez le rôle de Services de politique réseau et d'accès, ouvrez nps.msc , et enregistrez NPS dans Active Directory afin qu'il puisse lire les attributs des utilisateurs. Vérifiez le Serveur de politique réseau Le service (IAS) fonctionne et le serveur peut atteindre un contrôleur de domaine avec une faible latence. Notez le FQDN/IP NPS pour les journaux et les politiques.

Commandes optionnelles :

Installer-WindowsFeature NPAS -IncludeManagementTools nps.msc

Exécuter netsh nps ajouter serveur enregistré

Get-Service IAS | Start-Service  
Test-Connection -Count 4 -ComputerName (Get-ADDomainController -Discover).HostName

Étape 2 — Ajouter RD Gateway en tant que client RADIUS

Dans les clients RADIUS, ajoutez votre passerelle RD par IP/FQDN, définissez un nom convivial (par exemple, RDG01 ), et utilisez un secret partagé long et voûté. Ouvrez UDP 1812/1813 sur le serveur NPS et confirmez la connectivité. Si vous exécutez plusieurs RDG, ajoutez chacun explicitement (les définitions de sous-réseau sont possibles mais plus faciles à mal définir).

Commandes optionnelles

Ajouter un client : netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=OUI

netsh advfirewall firewall add rule name="RADIUS Auth (UDP 1812)" dir=in action=allow protocol=UDP localport=1812
netsh advfirewall firewall add rule name="RADIUS Acct (UDP 1813)" dir=in action=allow protocol=UDP localport=1813

Étape 3 — Créer des politiques NPS (CRP et NP)

Créez une politique de demande de connexion limitée à l'adresse IPv4 de votre client RDG. Choisissez Authentifier sur ce serveur (pour Microsoft Entra MFA via l'extension NPS) ou Transférer vers RADIUS distant (pour un proxy MFA tiers). Ensuite, créez une politique réseau qui inclut votre(s) groupe(s) AD (par exemple, GRP_RDG_Utilisateurs ) avec accès accordé. Assurez-vous que les deux politiques se situent au-dessus des règles générales.

Commandes optionnelles

# Vérifiez qu'un utilisateur est dans le groupe autorisé
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Aperçu de la politique d'exportation à titre de référence : reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Étape 4 — Installer l'extension MFA ou l'agent tiers

Pour Microsoft Entra MFA, installez l'extension NPS, exécutez le script de liaison du locataire et redémarrez NPS. Confirmez que les utilisateurs sont inscrits à MFA et préfèrent les méthodes push/app. Pour MFA tiers, installez le proxy/agent RADIUS du fournisseur, configurez les points de terminaison/les secrets partagés et pointez votre CRP vers ce groupe distant.

Commandes optionnelles

# Entra MFA NPS Extension lier  
Set-Location "C:\Program Files\Microsoft\AzureMfa\"  
.\AzureMfaNpsExtnConfigSetup.ps1  
Redémarrer-Service IAS

# Bouton de journalisation utile (0–3)  
New-Item -Path HKLM:\SOFTWARE\Microsoft\AzureMfa -Force | Out-Null  
New-ItemProperty HKLM:\SOFTWARE\Microsoft\AzureMfa -Name LOG_LEVEL -Value 2 -PropertyType DWord -Force | Out-Null

Configurer un groupe et un serveur RADIUS à distance : netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Étape 5 — Pointer le RD Gateway vers le NPS central (magasin RD CAP)

Sur le serveur RD Gateway, définissez le magasin RD CAP sur le serveur central exécutant NPS, ajoutez l'hôte NPS + le secret partagé, et vérifiez la connectivité. Alignez RD CAP sur vos groupes d'utilisateurs autorisés et RD RAP sur les ordinateurs/collections spécifiques. Si l'authentification multifacteur réussit mais que l'accès échoue, vérifiez d'abord la portée de RAP.

Étape 6 — Tester MFA de bout en bout

Depuis un client externe, connectez-vous via RDG à un hôte connu et confirmez une invite MFA, NPS 6272 (Accès accordé), et une session réussie. Testez également les chemins négatifs (pas dans le groupe, pas inscrit, facteur incorrect, jeton expiré) pour valider la clarté des erreurs et la préparation du support.

Quel est le manuel de dépannage de l'authentification multifacteur pour RD Gateway ?

Le dépannage est le plus rapide lorsque vous séparez les couches réseau, politique et identité. Commencez par vérifier la connectivité RADIUS et les ports, puis validez la correspondance des politiques, puis examinez l'inscription MFA et les types de facteurs. Gardez un compte de test avec des conditions contrôlées afin de pouvoir reproduire les résultats de manière cohérente pendant les fenêtres de changement.

• Pas de prompt, de boucles ou de délais d'attente
• Correspondance de politique et portée de groupe
• Journalisation et télémétrie que vous utiliserez réellement
• Renforcement de la sécurité et meilleures pratiques opérationnelles
• Périmètre, TLS et Moindre Privilège
• Surveillance, Alerte et Contrôle des Changements
• Résilience et Récupération

Pas de prompt, de boucles ou de délais d'attente

Aucun message d'invite indique souvent des lacunes dans l'ordre de la politique ou l'inscription MFA. Les boucles suggèrent un décalage de secret partagé ou une récursion de transfert entre NPS et un proxy. Les délais d'attente indiquent généralement des UDP 1812/1813 bloqués, un routage asymétrique ou une inspection IDS/IPS trop agressive. Augmentez temporairement la verbosité des journaux pour confirmer quel saut échoue.

Correspondance de politique et portée de groupe

Confirmez que la politique de demande de connexion cible le client RDG et s'applique avant toute règle générale. Dans la politique réseau, vérifiez le groupe AD exact et le comportement de nesting des groupes ; certains environnements nécessitent une atténuation de l'enflure des jetons ou une adhésion directe. Surveillez les problèmes de canonisation des noms d'utilisateur entre les noms UPN et de style NT.

Journalisation et télémétrie que vous utiliserez réellement

Utilisez NPS Accounting pour la corrélation et maintenez les journaux opérationnels RDG activés. Depuis votre plateforme MFA, examinez les invites par utilisateur, les refus et les modèles géo/IP. Établissez un tableau de bord léger : volume d'authentification, taux d'échec, principales raisons d'échec et temps moyen de défi. Ces indicateurs guident à la fois la capacité et sécurité ajustement.

Renforcement de la sécurité et meilleures pratiques opérationnelles

MFA est nécessaire mais pas suffisant. Combinez-le avec la segmentation du réseau, un TLS moderne, le principe du moindre privilège et une surveillance rigoureuse. Maintenez une base de référence courte et appliquée - le durcissement ne fonctionne que s'il est appliqué de manière cohérente et vérifié après les correctifs et les mises à jour.

Périmètre, TLS et Moindre Privilège

Placez RDG dans un segment DMZ renforcé avec uniquement les flux nécessaires vers le LAN. Utilisez un certificat public de confiance sur RDG et désactivez l'héritage. TLS et des chiffrements faibles. Restreindre l'accès RDG via des groupes AD dédiés ; éviter les droits d'accès larges et s'assurer que les RAPs RD ne mappent que les systèmes et ports dont les utilisateurs ont réellement besoin.

Surveillance, Alerte et Contrôle des Changements

Alerte sur les pics d'authentifications échouées, les géographies inhabituelles ou les demandes répétées par utilisateur. Enregistrer les modifications de configuration sur NPS, RDG et la plateforme MFA avec une trace d'approbation. Traiter les politiques comme du code : suivre les modifications dans le contrôle de version ou au moins dans un registre de modifications, et tester dans un environnement de préproduction avant le passage en production.

Résilience et Récupération

Exécutez NPS de manière redondante et configurez RDG pour référencer plusieurs serveurs RADIUS. Documentez le comportement fail-open par rapport au comportement fail-closed pour chaque composant ; par défaut, utilisez fail-closed pour l'accès externe. Sauvegardez la configuration NPS, les politiques RDG et les paramètres MFA ; répétez la récupération, y compris le remplacement de certificat et la réinscription de l'extension ou de l'agent MFA après une reconstruction.

Conclusion

Ajouter MFA au RD Gateway comble la plus grande lacune des RDP exposés à Internet : l'abus d'identifiants. En centralisant la politique sur NPS et en intégrant Entra MFA ou un fournisseur RADIUS tiers, vous appliquez une vérification d'identité solide sans perturber les modèles RD CAP/RD RAP. Validez avec des tests ciblés, surveillez en continu et associez MFA avec TLS renforcé, le principe du moindre privilège et un design NPS/RDG résilient.