NPS et Microsoft Entra ID : limites, alternatives cloud‑native et bonnes pratiques (2025)

Peut‑on se passer totalement d’Active Directory avec NPS pour authentifier VPN/Wi‑Fi tout en restant 100 % Microsoft Entra ID ? Voici l’état des lieux au 02/10/2025, les limites concrètes et les architectures viables pour réussir une transition “cloud‑first”.

Sommaire

Intégration directe de NPS à Microsoft Entra ID sans Active Directory local

Constat actuel

NPS reste dépendant d’Active Directory (AD DS) pour l’authentification primaire. L’extension NPS Extension for Microsoft Entra MFA n’ajoute qu’un second facteur cloud ; elle ne remplace pas l’annuaire Kerberos/NTLM. (Source : documentation Microsoft)
Microsoft Entra ID ne fournit pas de service RADIUS natif. À ce jour, la passerelle Microsoft “officielle” est le duo NPS + extension Entra MFA. Aucune annonce publique ne présente un « RADIUS as‑a‑Service » 100 % Microsoft. (Source : échanges et docs Microsoft)
Un serveur NPS doit être joint à un domaine AD DS (ou, à défaut, à Azure AD Domain Services, service AD managé). Les identités synchronisées via Azure AD Connect/Cloud Sync arrivent ensuite dans Entra ID. (Source : documentation et Q&A Microsoft)

Conséquences

Impossible, à ce jour, de faire fonctionner NPS exclusivement avec Entra ID comme IdP primaire.
Il faut soit conserver/mettre en place un AD minimal (sur site ou dans Azure IaaS), soit changer de technologie.

Solutions ou contournements possibles

Scénario	Principe	Points clés
AD DS « light » + NPS + Extension MFA	Un contrôleur de domaine minimal (VM Core) authentifie le mot de passe ; l’extension interroge Entra ID pour le MFA.	Mise en œuvre rapide si AD existe déjà ; maintenance et mises à jour AD à prévoir. (Source : Microsoft)
Azure AD Domain Services (AAD DS)	Domaine géré Microsoft ; NPS joint au domaine ; pas d’AD “on‑prem”.	Supprime l’infra locale, mais reste un AD DS managé et conserve les limites NPS. (Source : Microsoft)
RADIUS « cloud‑native » tiers (ex. SecureW2 Cloud RADIUS, JumpCloud RADIUSaaS, etc.)	Le prestataire s’intègre à Entra ID via SAML/OIDC/SCIM et expose un point RADIUS hébergé.	Pas d’AD, haute dispo intégrée, automatisation des certificats, meilleure scalabilité. (Sources : éditeurs)
Azure VPN Gateway (OpenVPN)	Les clients OpenVPN s’authentifient directement sur Entra ID (OAuth2) ; pas de RADIUS/NPS.	Excellent si le besoin est uniquement du VPN P2S Azure. (Source : Microsoft)
Certificate‑Based Authentication (CBA) + Cloud PKI	Entra ID valide des certificats X.509 distribués via Intune ; le RADIUS (souvent cloud) n’interroge plus AD.	Résistant au phishing, supprime les mots de passe ; nécessite EAP‑TLS côté RADIUS.

Lecture rapide : si vous tenez à NPS, il vous faut un AD (local ou AAD DS). Si vous voulez un modèle “cloud‑only”, partez sur RADIUS managé + EAP‑TLS (CBA) ou, pour le VPN P2S Azure, utilisez l’auth Entra ID intégrée à Azure VPN Gateway.

Détails par scénario et architectures de référence

AD DS « light » + NPS + Extension MFA

Cas d’usage : environnements hybrides, besoins legacy (802.1X, VPN L2TP/IKEv2/SSL, RD Gateway), charge modérée à élevée mais gérable, contraintes de conformité exigeant une chaîne RADIUS on‑prem.

Architecture type :

Client (VPN/Wi‑Fi) → RADIUS Client (Firewall/AP/VPN) → NPS (joint à AD) → AD DS
                                                     ↘ Extension MFA → Microsoft Entra (MFA)

Identités : UPN/mot de passe validés par AD DS.
Second facteur : déclenché par l’extension (notification application, code OATH TOTP, SMS/voix selon vos politiques). Remarque : FIDO2/passkeys ne s’appliquent pas nativement au flux RADIUS via l’extension.
Schémas EAP : classiquement PEAP‑MSCHAPv2. L’extension MFA ne s’active pas sur EAP‑TLS (certificat seul), car il n’y a pas de mot de passe à valider.

Forces : très compatible matériel/protocoles, support Microsoft, apprend peu de nouveautés aux équipes.
Limites : dette technique AD DS, NPS non “cluster‑aware”, CA/Conditional Access non évaluées comme dans un flux interactif web, MFA limité aux méthodes supportées par l’extension.

Azure AD Domain Services (AAD DS)

AAD DS fournit un domaine managé (LDAP/Kerberos/NTLM) synchronisé depuis Entra ID. NPS rejoint ce domaine, ce qui supprime vos DC on‑prem tout en conservant le paradigme AD.

Pour qui ? organisations sans datacenter, mais dépendantes d’un schéma AD pour NPS/802.1X/VPN.
À connaître : c’est un service managé ; vous gérez policies et objets, mais pas les rôles FSMO ni les mises à jour OS.

RADIUS « cloud‑native » tiers

Ces fournisseurs exposent des endpoints RADIUS hautement disponibles (Anycast/PoP multiples), pilotés par des identités synchronisées depuis Entra ID (SCIM) et/ou fédérées (SAML/OIDC). Ils automatisent souvent le cycle de vie certificats (EAP‑TLS) via MDM (Intune), avec distribution just‑in‑time et renouvellements silencieux.

Points forts : pas d’AD ni de NPS à opérer, SLA/HA intrinsèque, montée en charge horizontale, logs centralisés, politiques par groupe Entra ID.
Points d’attention : dépendance fournisseur, coût récurrent, diligence RGPD/contrats, intégration fine MDM/endpoint à valider.

Azure VPN Gateway (OpenVPN + Entra ID)

Le client Azure VPN s’authentifie directement via un flux OAuth2/OpenID Connect contre Entra ID ; on peut appliquer Conditional Access (par ex. exigence de conformité device) et éviter RADIUS. Idéal pour un besoin VPN P2S exclusivement dans Azure.

CBA (Certificate‑Based Authentication) + Cloud PKI

Avec Entra ID CBA, l’utilisateur (ou l’appareil) présente un certificat X.509, validé côté cloud par Entra ID ; côté réseau, on privilégie EAP‑TLS. Le RADIUS n’a plus à contacter AD DS : il vérifie la chaîne, les EKU et les attributs, puis décide (ou délègue à un service cloud qui orchestre la vérification).

Atout : flux sans mot de passe, résistant au phishing et aux interceptions (MS‑CHAPv2 est historiquement attaqué).
Pré‑requis : MDM (Intune) + Cloud PKI, gabarits de certificats, EAP‑TLS côté supplicant, et un RADIUS compatible (cloud ou NPS si vous gardez AD pour CRL/OCSP, etc.).

Flux d’authentification type avec NPS + Extension MFA

L’équipement (VPN, AP Wi‑Fi, RD Gateway, etc.) envoie une requête RADIUS à NPS.
NPS valide d’abord les identifiants contre AD DS (Kerberos/NTLM via le compte de l’ordinateur NPS dans le domaine).
En cas de réussite, le plug‑in appelle le service MFA d’Entra ID avec le UPN de l’utilisateur.
Entra ID déclenche la seconde étape (par ex. notification Authenticator, OATH TOTP, SMS/voix selon vos politiques).
NPS renvoie Access‑Accept ou Access‑Reject au client RADIUS, avec les attributs nécessaires (VLAN, filtre, session‑timeout…).

Compatibilités/limitations fréquentes :

Protocoles : PEAP‑MSCHAPv2 et PAP sont supportés par l’extension. EAP‑TLS n’active pas le MFA de l’extension (pas de mot de passe).
UPN requis : alignez UserPrincipalName sur l’adresse Entra ID pour éviter les échecs MFA.
Conditional Access : le flux NPS+MFA n’est pas un SSO web ; certaines évaluations (ex. conformité device) ne s’appliquent pas comme dans un flux OIDC.
Numéro d’association (AP Wi‑Fi) : prévoyez des session‑timeouts raisonnables pour éviter la surcharge de challenges.

Recommandations pratiques

Cloud‑only ? Favorisez un RADIUS managé intégré à Entra ID (SCIM/SAML/OIDC) + EAP‑TLS, ou utilisez Azure VPN Gateway avec auth Entra ID si votre périmètre ne concerne que le VPN P2S Azure.
Hybride/legacy ? Déployez un contrôleur de domaine minimal (Windows Server Core) dans Azure, joignez vos NPS au domaine, synchronisez via Azure AD Connect/Cloud Sync, exposez le moins de ports possible.
Renforcer la sécurité : ciblez EAP‑TLS (CBA) à moyen terme, décommissionnez MS‑CHAPv2, appliquez TLS 1.2+ sur RADIUS‑over‑TLS si supporté, contrôlez les cipher suites et automatisez le cycle de vie certs avec Intune.
Haute dispo & scalabilité : NPS ne sait pas “clustériser” ses policies. Répliquez la configuration (export/import), placez deux serveurs NPS derrière un load‑balancer L4 et/ou déclarez plusieurs serveurs côté clients RADIUS. Pour des milliers de req/s multi‑régions, privilégiez un RADIUS cloud.
Observabilité : activez les journaux NPS (texte et/ou SQL), surveillez les journaux d’authentification Entra ID (Azure MFA Server extension/NPS extension), agrégés dans Sentinel ou votre SIEM.

Checklist de déploiement rapide (NPS + Extension MFA)

Créer/joindre une VM Windows Server Core à AD DS (ou AAD DS).
Installer le rôle Network Policy and Access Services (sous‑rôle NPS).
Enregistrer les serveurs NPS dans AD (autorisations RAS & IAS).
Installer l’extension NPS pour Entra MFA, renseigner locataire/ID d’application/secret, valider la connectivité sortante vers Entra.
Configurer Connection Request Policies et Network Policies (ex. PEAP‑MSCHAPv2), attribuer les RADIUS clients (NAS, AP, VPN concentrators).
Tester avec un compte MFA activé (UPN aligné), contrôler les journaux NPS et Entra.
Industrialiser : exporter les policies, versionner, déployer un second NPS, équilibrer la charge, documenter la procédure de reprise.

Haute disponibilité & performance

Volet	NPS “maison”	RADIUS cloud‑native
Disponibilité	2+ NPS, LB L4, réplication manuelle des policies	Multi‑PoP/Anycast, SLA fournis par l’éditeur
Montée en charge	Horizontale (ajout de nœuds), tuning OS/crypto, dimensionnement VM	Élastique côté service, auto‑scale
Maintenance	Patch OS, sauvegardes, tests post‑patch	Abstraction opérée par le fournisseur
Attribution VLAN/ACL	Attributs RADIUS configurés à la main	Politiques dynamiques par groupe/claim Entra ID
Coûts	Licences/VM/LB/ops (CAPEX/OPEX)	Abonnement (OPEX), coûts prévisibles

Migration vers un modèle cloud (EAP‑TLS + CBA)

Décider : quelles parties du réseau (Wi‑Fi, VPN, filaire 802.1X) basculent sur EAP‑TLS ?
Préparer l’identité : normaliser les UPN, définir les groupes Entra ID (Wi‑Fi‑Corp, Admin‑VPN…), planifier SCIM si RADIUS cloud.
PKI & certificats : adopter une Cloud PKI ou CA d’entreprise, définir EKU, contraintes SAN, durées de vie, revocation (OCSP/CRL).
MDM : distribuer automatiquement les certificats device/user via Intune, configurer les profils EAP‑TLS et SSID/“VPN profile”.
RADIUS : choisir le fournisseur cloud ou garder NPS (temporairement), modéliser les policies par groupes.
Pilote : exécuter un POC sur un SSID distinct, mesurer l’expérience, la charge et la journalisation.
Basculer : migrer par vagues (bâtiment, BU), prévoir un plan de retour arrière (SSID invité, fallback PEAP limité).

FAQ éclair express

Peut‑on activer le MFA “full Conditional Access” avec NPS ? Pas comme sur un flux web. L’extension NPS déclenche un challenge MFA pris en charge, mais l’évaluation CA (conformité device, etc.) est différente d’un flux OIDC/Fed.
Les passkeys/FIDO2 fonctionnent‑elles avec NPS ? Pas en tant que second facteur via l’extension. Pour du “passwordless”, basculez vers EAP‑TLS (certificats) ou des scénarios applicatifs web/OIDC.
Puis‑je éliminer AD DS en gardant NPS ? Non ; NPS a besoin d’un domaine AD DS (ou AAD DS). Sans AD, changez d’approche (RADIUS cloud + CBA/EAP‑TLS ou Azure VPN Gateway + Entra ID).
AAD DS remplace‑t‑il Entra ID ? Non. AAD DS fournit un domaine AD managé (LDAP/Kerberos/NTLM) complémentaire à Entra ID pour des workloads legacy (dont NPS).

Erreurs fréquentes et dépannage

Symptôme	Cause probable	Correctif
MFA ne se déclenche pas	UPN non aligné, utilisateur sans méthode MFA, EAP‑TLS utilisé	Aligner UPN, enregistrer une méthode MFA supportée, tester en PEAP‑MSCHAPv2
Access‑Reject après MFA OK	Policy NPS trop restrictive, groupe incorrect, attributs manquants	Vérifier l’ordre des policies, l’appartenance aux groupes, ajouter les attributs RADIUS requis
Échecs massifs en heures de pointe	NPS saturé, pas de redondance, timeouts trop courts	Ajouter un second NPS, load‑balancer, augmenter les timeouts et dimensionner la VM
Wi‑Fi décroche régulièrement	Re‑authentifications trop fréquentes, rotation d’IP/PoP RADIUS, roaming AP	Ajuster session‑timeout, stabiliser routage/LB, activer 802.11r/k/v selon AP
Incompatibilité supplicant	Paramétrage PEAP/EAP non homogène, ciphers obsolètes	Uniformiser EAP côté MDM, n’autoriser que TLS 1.2+, vérifier les suites cryptographiques

Modèle de politique NPS (exemple)

Network Policy: Wi‑Fi‑Corp‑PEAP
 Conditions:
   - Windows Groups: Entreprise\WiFi_Utilisateurs
 Constraints:
   - Authentication Methods: PEAP (Inner: MS‑CHAPv2)
   - EAP Types: PEAP (TLS1.2+), pas d’EAP‑TLS dans ce profil
 Settings:
   - RADIUS Attributes (Standard): Session-Timeout = 28800
   - Vendor-Specific (selon constructeur AP): VLAN = 20

Garde‑fous sécurité

Chiffrage : forcer TLS 1.2+ pour EAP‑TLS/PEAP, désactiver SSL/TLS hérités, surveiller les ciphers.
Comptes de service : principe du moindre privilège pour NPS, rotation de secrets de l’extension, durcissement du système (CIS/DoD si requis).
Journalisation : activer la journalisation détaillée NPS et corréler avec les logs Entra ID (catégorie authentification). Conserver selon vos règles de conformité.
Exposition : pas d’ouverture RDP/WinRM publique ; accès via bastion/Jump Server. Séparer rôle NPS et DC.

Coûts & trajectoire

Court terme : si vous avez déjà AD DS, NPS+MFA est économique pour stabiliser VPN/Wi‑Fi. Moyen terme : réduire la surface MS‑CHAPv2, migrer vers EAP‑TLS. Long terme : externaliser RADIUS (SaaS) ou s’appuyer sur des flux Entra ID natifs (OIDC pour applis, Azure VPN Gateway pour P2S) afin de supprimer l’exploitation RADIUS/NPS.

À retenir

Au 02 octobre 2025, NPS ne peut pas servir de RADIUS « pure cloud » avec Microsoft Entra ID comme unique IdP.
Vos options réalistes : conserver/mettre en place un AD (local ou AAD DS), ou adopter un RADIUS cloud‑native intégré à Entra ID (idéalement avec EAP‑TLS/CBA). Pour le VPN P2S Azure, privilégiez l’auth Entra ID d’Azure VPN Gateway.

Prochaines étapes recommandées :

Cartographier vos usages RADIUS (VPN, Wi‑Fi, filaire, RD Gateway).
Décider du cap : NPS transitoire (avec AD minimal) ou RADIUS cloud‑native.
Si RADIUS cloud : lancer un POC EAP‑TLS avec Intune + Cloud PKI et synchronisation SCIM.
Si NPS : déployer 2 nœuds, exporter/industrialiser les policies, tester la reprise, durcir l’OS.
Planifier la migration vers EAP‑TLS et la dépréciation de PEAP‑MSCHAPv2.