Sécuriser RDP avec Azure MFA via l'extension NPS : guide complet

Le protocole RDP (Remote Desktop Protocol) reste le vecteur d'attaque numéro un des ransomwares et des intrusions en environnement Windows. Des milliers de serveurs exposent leur port 3389 sans aucune protection supplémentaire, offrant aux attaquants une surface d'entrée béante. L'authentification multifacteur (MFA) constitue la parade la plus efficace : même si un attaquant obtient un identifiant et un mot de passe valide — via phishing, brute force ou credential stuffing — il ne peut pas franchir la deuxième barrière d'authentification sans posséder le second facteur. L'extension NPS Azure MFA permet d'ajouter ce MFA à vos connexions RDP sans imposer une migration complète vers Azure AD Join ou Intune. Il s'agit d'une solution hybride, idéale pour les environnements Active Directory on-premises qui utilisent déjà Azure Active Directory en synchronisation. Ce guide vous accompagne de l'installation du rôle NPS jusqu'au test complet de l'authentification multifacteur sur RDP, avec les commandes précises, les stratégies réseau à configurer et le dépannage des erreurs les plus fréquentes. Vous obtiendrez un environnement RDP sécurisé par le MFA Azure, opérationnel en quelques heures.

Architecture globale : NPS, RADIUS et extension Azure MFA

Avant de plonger dans les étapes d'installation, il est crucial de comprendre le flux d'authentification mis en place. L'architecture repose sur trois composants principaux qui communiquent entre eux via le protocole RADIUS.

Le Remote Desktop Gateway (RD Gateway) joue le rôle de point d'entrée. Il accepte les connexions RDP entrantes depuis Internet et les tunnélise via HTTPS (port 443), évitant ainsi d'exposer le port 3389 directement. RD Gateway délègue l'authentification à un serveur RADIUS.

Le serveur NPS (Network Policy Server) est le serveur RADIUS de Windows Server. Il reçoit la requête d'authentification depuis RD Gateway, vérifie les informations d'identité dans Active Directory, puis passe la main à l'extension Azure MFA pour le second facteur.

L'extension NPS Azure MFA est un plugin installé sur le serveur NPS. Elle intercepte la requête après la validation du premier facteur (mot de passe AD) et déclenche une demande MFA vers le service Azure MFA dans le cloud. L'utilisateur reçoit alors une notification push sur Microsoft Authenticator, un appel téléphonique ou un SMS.

Le flux complet est le suivant :

1. L'utilisateur ouvre une session RDP vers RD Gateway.
2. RD Gateway envoie une requête RADIUS Access-Request au serveur NPS.
3. NPS valide le mot de passe AD (premier facteur).
4. L'extension NPS Azure MFA contacte les serveurs Azure MFA dans le cloud.
5. L'utilisateur approuve la notification ou saisit l'OTP.
6. Azure MFA renvoie un Access-Accept à NPS.
7. NPS retransmet l'Access-Accept à RD Gateway.
8. La session RDP est établie.

Ce modèle hybride est particulièrement adapté aux organisations qui ont synchronisé leur AD on-premises vers Azure AD via Azure AD Connect, sans nécessairement migrer tous leurs postes vers Azure AD Join. C'est une approche pragmatique qui préserve l'investissement dans l'infrastructure Active Directory existante tout en tirant parti des capacités MFA d'Azure.

Prérequis avant l'installation

La mise en place de cette architecture nécessite plusieurs prérequis techniques et licences qu'il convient de vérifier avant de démarrer.

Côté Azure AD / Microsoft Entra ID :

• Un tenant Azure AD actif avec synchronisation via Azure AD Connect depuis votre AD on-premises.
• Les utilisateurs concernés doivent exister dans Azure AD (synchronisés ou natifs).
• Une licence incluant Azure MFA : Azure AD Premium P1 ou P2, Microsoft 365 Business Premium, ou Microsoft 365 E3/E5. La MFA peut aussi être activée via les Security Defaults sans licence Premium.
• Les utilisateurs doivent avoir configuré leur méthode MFA dans My Sign-Ins (https://mysignins.microsoft.com).

Côté infrastructure Windows Server :

• Windows Server 2016, 2019 ou 2022 pour le serveur NPS. Il peut s'agir d'un serveur dédié ou d'un contrôleur de domaine (déconseillé en production pour des raisons de sécurité).
• Le serveur NPS doit être joint au domaine Active Directory.
• Un serveur RD Gateway déployé (peut être sur la même machine que NPS dans des environnements de taille réduite).
• Accès Internet sortant sur le serveur NPS vers les endpoints Azure MFA (ports 443).
• PowerShell 5.1 minimum et .NET Framework 4.7.2 ou supérieur.

Résolution DNS : Le serveur NPS doit pouvoir résoudre les noms de domaine Azure (*.azure.com, *.microsoft.com) et atteindre les URLs suivantes en HTTPS sortant : login.microsoftonline.com, adnotifications.windowsazure.com, strongauthenticationservice.auth.microsoft.com.

Installer le rôle NPS sur Windows Server

Si NPS n'est pas déjà installé sur votre serveur, commencez par ajouter le rôle via le Gestionnaire de serveur ou PowerShell.

Via PowerShell (recommandé) :

Install-WindowsFeature NPAS -IncludeManagementTools

Cette commande installe le rôle Network Policy and Access Services, qui inclut NPS, le serveur RADIUS et les outils de gestion associés. Après l'installation, vérifiez que le service est actif :

Get-Service IAS | Select-Object Name, Status, StartType

Enregistrer NPS dans Active Directory : Cette étape est indispensable pour que NPS puisse lire les propriétés d'accès à distance des comptes utilisateurs dans l'AD.

netsh nps add registeredserver domain=votre-domaine.local server=NOM-SERVEUR-NPS

Ou via la console NPS : clic droit sur "NPS (Local)" → "Register server in Active Directory".

Vérifier que NPS est bien membre du groupe AD : Le compte ordinateur du serveur NPS doit être membre du groupe "RAS and IAS Servers" dans Active Directory. Vérifiez dans "Utilisateurs et ordinateurs Active Directory" → dossier Users → groupe "RAS and IAS Servers".

Ouvrez la console NPS (nps.msc) pour vous familiariser avec l'interface. Vous y trouverez les sections "RADIUS Clients and Servers", "Policies" (Network Policies et Connection Request Policies) et "Accounting".

Télécharger et installer l'extension NPS Azure MFA

L'extension NPS Azure MFA est un composant développé par Microsoft, téléchargeable depuis le Centre de téléchargement Microsoft. Sa version actuelle supporte les environnements Azure Commercial, Azure Government et Azure China.

Téléchargement :

# Via PowerShell sur le serveur NPS
$url = "https://aka.ms/npsmfa"
$output = "C:\Temp\NpsExtnForAzureMfaInstaller.exe"
Invoke-WebRequest -Uri $url -OutFile $output

Alternativement, téléchargez directement depuis le portail Azure : Azure Active Directory → Security → MFA → NPS extension.

Installation : Exécutez l'installateur NpsExtnForAzureMfaInstaller.exe en tant qu'administrateur. L'assistant d'installation est simple : acceptez les termes de licence, choisissez le répertoire d'installation (par défaut : C:\Program Files\Microsoft\AzureMfa) et lancez l'installation.

L'extension installe :

• Un DLL qui s'accroche au pipeline NPS.
• Un script PowerShell de configuration (AzureMfaNpsExtnConfigSetup.ps1).
• Les certificats nécessaires pour l'authentification vers Azure.

Vérification de l'installation :

Get-Module -ListAvailable | Where-Object {$_.Name -like "*Azure*"}
# Vérifie que le module AzureAD ou MSOnline est disponible

L'extension NPS s'intègre comme un plugin DLL dans le processus NPS. Elle est référencée dans le registre Windows sous HKLM:\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters dans la clé ExtensionDLLs.

Configurer l'extension NPS Azure MFA

La configuration de l'extension est réalisée via un script PowerShell fourni avec l'installation. Ce script effectue plusieurs opérations : il récupère votre tenant ID Azure AD, génère un certificat auto-signé pour l'authentification, et l'enregistre dans Azure AD.

Étape 1 — Récupérer votre Tenant ID Azure AD :

# Dans Azure Portal : Azure Active Directory → Overview → Tenant ID
# Ou via PowerShell :
Connect-AzureAD
(Get-AzureADTenantDetail).ObjectId

Étape 2 — Exécuter le script de configuration :

cd "C:\Program Files\Microsoft\AzureMfa\Config"
.\AzureMfaNpsExtnConfigSetup.ps1

Le script vous demande votre Tenant ID Azure AD, puis se connecte à Azure AD pour enregistrer un certificat. Vous devez vous authentifier avec un compte Global Administrator ou Authentication Administrator.

Le script effectue les actions suivantes :

1. Installe le module MSOnline si absent.
2. Crée un certificat auto-signé dans le store "Local Machine\My".
3. Enregistre la clé publique du certificat dans Azure AD.
4. Configure la clé de registre HKLM:\SOFTWARE\Microsoft\AzureMfa avec le Tenant ID et l'empreinte du certificat.

Vérification dans le registre :

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\AzureMfa"
# Doit afficher : CLIENT_CERT_THUMBPRINT, TENANT_ID

Redémarrer le service NPS :

Restart-Service IAS -Force
Get-Service IAS

Vérifiez dans l'Observateur d'événements (Event Viewer) → Applications and Services Logs → Microsoft → AzureMfa que les événements de démarrage de l'extension s'affichent sans erreur.

Créer les stratégies réseau NPS (Network Policies)

Les Network Policies NPS définissent les conditions sous lesquelles l'accès est accordé ou refusé. Pour RDP via RD Gateway, vous devez créer deux types de politiques : une Connection Request Policy et une Network Policy.

Connection Request Policy (CRP) : Elle détermine comment NPS traite les requêtes RADIUS entrantes. Dans notre cas, NPS traite les requêtes localement (pas de proxy RADIUS vers un autre serveur).

Dans la console NPS → Policies → Connection Request Policies :

1. Créez une nouvelle politique nommée "RD Gateway - Azure MFA".
2. Condition : Type de port NAS = "Virtual (VPN)".
3. Paramètres : "Authenticate requests on this server".

Network Policy : Elle définit les conditions d'accès des utilisateurs.

1. Créez une nouvelle Network Policy nommée "RDP Users - MFA Required".
2. Conditions :
   • User Groups : ajoutez le groupe AD contenant vos utilisateurs RDP (ex : "RDP-Users" ou "Domain Users").
   • NAS Port Type : "Virtual (VPN)".
3. Permissions : "Access Granted".
4. Constraints : Authentication Methods — cochez "Microsoft: Protected EAP (PEAP)" et "Microsoft: Encrypted Authentication version 2 (MS-CHAPv2)".
5. Settings : il est possible de configurer des restrictions d'horaires, de jours de connexion ou d'adresses IP source.

Important : Désactivez ou supprimez les Network Policies existantes qui pourraient accorder l'accès sans MFA (notamment "Connections to Microsoft Routing and Remote Access server" et "Connections to other access servers"). Vérifiez l'ordre de priorité des politiques : la politique la plus spécifique doit apparaître en premier.

Configurer RD Gateway pour utiliser NPS comme RADIUS

RD Gateway doit être configuré pour déléguer l'authentification à votre serveur NPS via RADIUS. Cette configuration se fait dans la console Remote Desktop Gateway Manager.

Sur le serveur RD Gateway :

1. Ouvrez "Remote Desktop Gateway Manager" (tsgateway.msc).
2. Clic droit sur le serveur → Properties → RD CAP Store.
3. Sélectionnez "Request clients to send a statement of health to a Central Network Policy Server (NPS)".
4. Cliquez sur "Add" et saisissez l'adresse IP ou le FQDN de votre serveur NPS.
5. Définissez un secret partagé RADIUS (au moins 20 caractères, complexe).

Sur le serveur NPS — Ajouter RD Gateway comme client RADIUS :

1. Dans la console NPS → RADIUS Clients and Servers → RADIUS Clients.
2. Clic droit → New RADIUS Client.
3. Nom : "RD Gateway", adresse IP : IP du serveur RD Gateway.
4. Secret partagé : identique à celui configuré sur RD Gateway.
5. Vendor : Microsoft.

RD CAP et RD RAP : Dans RD Gateway Manager, assurez-vous de configurer :

• Une RD CAP (Connection Authorization Policy) qui définit qui peut se connecter via la passerelle.
• Une RD RAP (Resource Authorization Policy) qui définit quelles ressources internes sont accessibles.

Ces politiques fonctionnent en complément des Network Policies NPS. La RD CAP est validée en premier (accès à la passerelle), puis la RD RAP (accès à la ressource interne).

Tester l'authentification MFA sur RDP

Avant de déployer en production, effectuez des tests complets avec un compte utilisateur de test qui a configuré son MFA dans Azure AD.

Vérifier l'enregistrement MFA de l'utilisateur test : Connectez-vous sur https://mysignins.microsoft.com avec le compte de test et vérifiez que Microsoft Authenticator ou une autre méthode MFA est bien enregistrée.

Test de connexion RDP via RD Gateway :

1. Ouvrez le client RDP (mstsc.exe).
2. Dans l'onglet "Advanced" → Settings, spécifiez le RD Gateway : rdgateway.votre-domaine.fr:443.
3. Saisissez l'adresse de la machine cible dans "Computer".
4. Connectez-vous avec les identifiants AD (domaine\utilisateur / mot de passe).
5. Dans les 30 secondes, vous devriez recevoir une notification push sur Microsoft Authenticator.
6. Approuvez la notification.
7. La connexion RDP s'établit.

Test avec code OTP (TOTP) : Si l'utilisateur préfère utiliser un code TOTP, lors de la demande MFA, saisissez le code à 6 chiffres généré par l'application Authenticator. La fenêtre de validité est de 30 secondes.

Vérification dans les logs NPS :

# Observateur d'événements → Security → Event ID 6272 (accès accordé)
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=6272]]" | Select-Object -First 5 | Format-List

L'Event ID 6272 confirme que NPS a accordé l'accès. L'Event ID 6273 indique un refus — vérifiez la raison dans les détails de l'événement.

Dépannage — erreurs RADIUS courantes et logs NPS

Plusieurs types de problèmes peuvent survenir lors de la mise en place. Voici les erreurs les plus fréquentes et leurs solutions.

Erreur "Access-Reject" sans raison apparente :

• Vérifiez que l'utilisateur est bien synchronisé dans Azure AD : Get-AzureADUser -SearchString "prenom.nom"
• Vérifiez que l'utilisateur a un méthode MFA enregistrée dans Azure AD.
• Vérifiez les logs NPS dans l'Observateur d'événements → Custom Views → Server Roles → Network Policy and Access Services.

Timeout MFA (l'utilisateur ne reçoit pas la notification) :

• Le timeout par défaut de NPS est de 30 secondes. L'extension Azure MFA a besoin de plus de temps pour les notifications push. Modifiez le timeout RADIUS dans la configuration du client RADIUS sur RD Gateway (passez à 60 secondes).
• Vérifiez que le serveur NPS a accès à Internet vers les endpoints Azure MFA.

Erreur de certificat :

# Vérifier que le certificat est valide
$thumbprint = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\AzureMfa").CLIENT_CERT_THUMBPRINT
Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq $thumbprint}

Si le certificat est expiré (durée de vie par défaut : 1 an ou 2 ans selon la version), réexécutez le script AzureMfaNpsExtnConfigSetup.ps1 pour en générer un nouveau.

Activer les logs détaillés de l'extension :

Set-ItemProperty "HKLM:\SOFTWARE\Microsoft\AzureMfa" -Name "VERBOSE_LOG" -Value 1
Restart-Service IAS -Force

Les logs détaillés apparaissent dans l'Observateur d'événements → Applications and Services Logs → Microsoft → AzureMfa → AuthNRequestsPerUserThrottled.

Vérifier la connectivité vers Azure :

Test-NetConnection -ComputerName strongauthenticationservice.auth.microsoft.com -Port 443
Test-NetConnection -ComputerName adnotifications.windowsazure.com -Port 443

Comparatif avec d'autres solutions de sécurisation RDP

L'extension NPS Azure MFA n'est pas la seule approche pour sécuriser l'accès RDP. Voici un comparatif avec les alternatives principales.

Azure AD Join + Conditional Access : Si tous vos postes sont joints à Azure AD (ou Hybrid Azure AD Join), vous pouvez utiliser les politiques d'accès conditionnel pour imposer le MFA. Cette approche est plus moderne et intégrée, mais nécessite une migration complète vers Azure AD Join — ce qui n'est pas toujours possible pour les environnements serveur ou les postes anciens. Elle convient parfaitement aux environnements full cloud ou aux nouveaux déploiements.

Always On VPN avec MFA : Au lieu de sécuriser RDP directement, vous pouvez imposer un VPN (Always On VPN avec NPS + Azure MFA) comme prérequis à toute connexion RDP. C'est une approche en profondeur qui ajoute une couche réseau supplémentaire. La complexité d'administration est cependant plus élevée, et l'expérience utilisateur peut être moins fluide.

PIM Just-in-Time (JIT) via Azure Bastion : Azure Bastion est un service PaaS qui fournit un accès RDP/SSH sécurisé depuis le portail Azure, sans exposer de port RDP sur Internet. Combiné avec Privileged Identity Management (PIM), il permet un accès Just-in-Time limité dans le temps. C'est la solution la plus sécurisée pour les machines virtuelles Azure, mais elle nécessite que les machines soient dans Azure.

Solution NPS + Azure MFA — Le bon choix pour :

• Les infrastructures hybrides on-premises avec Azure AD Connect.
• Les organisations qui ne peuvent pas migrer vers Azure AD Join à court terme.
• Les environnements avec un RD Gateway existant.
• Les projets avec un budget minimal (pas de coût supplémentaire si les licences Azure AD Premium sont déjà présentes).

Bonnes pratiques complémentaires pour durcir RDP

L'ajout du MFA est une étape majeure, mais elle doit s'accompagner d'autres mesures de sécurité pour former une défense en profondeur.

Restreindre l'accès RDP au niveau réseau : Même avec MFA, exposer RD Gateway sur Internet impose des restrictions IP si possible. Utilisez un pare-feu pour n'autoriser que les plages IP de votre organisation ou de vos utilisateurs nomades vers le port 443 de RD Gateway.

Activer Network Level Authentication (NLA) : NLA force l'authentification avant l'établissement complet de la session RDP, ce qui protège contre certaines attaques de déni de service et les exploits pré-authentification. Activez NLA sur tous vos serveurs RDP cibles.

Surveiller les comptes verrouillés : Avec la politique de verrouillage de compte (Account Lockout Policy) correctement configurée, les tentatives de brute force seront rapidement bloquées. Surveillez l'Event ID 4740 (compte verrouillé) dans les logs du contrôleur de domaine.

Désactiver RDP sur les machines non concernées : Appliquez une GPO pour désactiver le service Remote Desktop sur toutes les machines qui n'en ont pas besoin. Réduire la surface d'attaque reste la mesure la plus efficace.

Journalisation et SIEM : Centralisez les logs NPS (Event IDs 6272, 6273) et les logs Azure AD Sign-In dans votre SIEM. Créez des alertes sur les connexions depuis des pays inhabituels ou les tentatives d'accès en dehors des heures de travail.

Pour aller plus loin sur la sécurisation de votre infrastructure Active Directory, consultez notre guide sur le pentest Active Directory et notre article sur la sécurisation des accès distants. Vous pouvez également découvrir nos approches de sécurité cloud hybride et les stratégies de gestion des identités et des accès IAM.

Pour les références officielles, consultez la documentation Microsoft sur l'extension NPS Azure MFA et la documentation NPS Windows Server.

Questions fréquentes sur Azure MFA et NPS pour RDP

L'extension NPS Azure MFA est-elle compatible avec Windows Server 2012 R2 ?

Non. L'extension NPS Azure MFA requiert Windows Server 2016 minimum. Windows Server 2012 R2 n'est plus supporté pour ce composant. Si vous utilisez encore Windows Server 2012 R2 comme serveur NPS, vous devez d'abord migrer vers une version supportée. Notez que Windows Server 2012 R2 est également en fin de support étendu Microsoft depuis octobre 2023.

Peut-on utiliser l'extension NPS Azure MFA sans Azure AD Connect (sans synchronisation) ?

Non, l'extension NPS Azure MFA nécessite que les utilisateurs existent dans Azure AD. Si votre AD on-premises n'est pas synchronisé avec Azure AD, les utilisateurs ne seront pas reconnus lors de la vérification MFA. Vous devez configurer Azure AD Connect avec la synchronisation de hachage de mots de passe (Password Hash Sync) ou l'authentification pass-through (PTA) pour que cela fonctionne.

Que se passe-t-il si le service Azure MFA est indisponible ?

En cas d'indisponibilité du service Azure MFA, l'extension NPS refusera les connexions par défaut (comportement de sécurité "fail closed"). Il n'existe pas de mode de contournement automatique. Pour les situations d'urgence, Microsoft recommande d'activer le mode "Bypass" temporaire dans le portail Azure AD → Security → MFA → Fraud alert, mais cette option doit être utilisée avec une extrême parcimonie et uniquement par les administrateurs autorisés.

L'extension NPS Azure MFA supporte-t-elle les comptes locaux Windows (non AD) ?

Non. L'extension NPS Azure MFA ne fonctionne qu'avec des comptes Active Directory synchronisés dans Azure AD. Les comptes locaux Windows ou les comptes présents uniquement dans Azure AD sans correspondant on-premises ne sont pas supportés dans ce scénario d'extension NPS. Pour ces cas, envisagez Azure AD Join direct ou Azure Bastion.

Comment renouveler le certificat de l'extension NPS Azure MFA avant expiration ?

Le certificat généré lors de la configuration a une durée de vie d'environ 1 à 2 ans selon la version de l'extension. Pour le renouveler, réexécutez simplement le script PowerShell AzureMfaNpsExtnConfigSetup.ps1 sur le serveur NPS. Le script détectera le certificat expirant, en générera un nouveau, et l'enregistrera automatiquement dans Azure AD. Redémarrez ensuite le service NPS (Restart-Service IAS). Planifiez cette opération dans votre calendrier de maintenance avec une alerte 30 jours avant expiration.