NPS, RADIUS et EAP‑TLS : authentification par appareil pour terminaux joints à Microsoft Entra ID — limites, alternatives et plan de migration

Peut‑on authentifier un PC joint uniquement à Microsoft Entra ID sur un Wi‑Fi 802.1X via NPS en EAP‑TLS avec identité d’appareil ? Voici une réponse claire, des scénarios pratico‑pratiques et un plan de migration sans surprises.

Sommaire

NPS et authentification par appareil pour les terminaux joints à Microsoft Entra ID

Vue d’ensemble de la question

Un administrateur réseau souhaite utiliser Network Policy Server (NPS) comme serveur RADIUS pour réaliser une authentification EAP‑TLS basée sur l’identité de l’appareil (inclusion du DeviceID dans le certificat) pour des postes exclusivement joints à Microsoft Entra ID (anciennement Azure AD), c’est‑à‑dire sans compte d’ordinateur dans Active Directory Domain Services (AD DS). L’objectif est d’appliquer des règles 802.1X « par appareil » sans opérer d’annuaire local.

Réponse courte

Non. Tel quel, NPS ne sait pas résoudre un DeviceID Entra ID pour l’associer à un objet d’ordinateur. L’authentification appareil via EAP‑TLS exige, côté NPS, un compte machine dans AD DS (ou un domaine managé compatible) pour la validation primaire. Sur un poste cloud‑only (joint Entra ID sans AD DS), NPS ne peut donc pas réaliser d’authentification par appareil. Il reste toutefois possible de faire de l’authentification utilisateur (EAP‑TLS utilisateur, PEAP, etc.).

Pourquoi NPS ne voit pas les terminaux Entra ID‑only

NPS, rôle Windows Server, a été conçu pour déléguer la validation d’identité aux contrôleurs de domaine AD DS. Dans un échange EAP‑TLS, NPS :

vérifie la chaîne de certification (racines/intermédiaires, CRL/OCSP),
analyse les champs Subject/SAN et les Enhanced Key Usages du certificat,
mappe ce certificat à un objet de sécurité dans AD DS (utilisateur ou ordinateur) afin d’évaluer les conditions des stratégies NPS (appartenance à un groupe, restrictions, etc.).

Sans objet d’ordinateur dans AD DS, l’étape 3 échoue pour l’authentification « par appareil ». Le DeviceID de Microsoft Entra ID, même injecté dans le certificat via Intune, n’est pas résolu par NPS car il n’existe ni connecteur natif ni API Windows NPS permettant d’interroger directement Entra ID pendant la décision RADIUS.

À retenir : NPS dépend d’AD DS pour la validation primaire. En l’absence de compte machine AD, l’authentification par appareil n’est pas possible. En revanche, l’authentification utilisateur reste pleinement supportée.

Quelles options s’offrent à vous ?

Option	Principe	Prérequis clés	Avantages	Limites	Quand l’utiliser
Hybrid Azure AD Join	Créer/synchroniser un compte d’ordinateur AD pour chaque poste.	AD DS + AAD Connect, gabarit de certificat machine, PKI, Intune/GP.	Compatible NPS, EAP‑TLS appareil possible, contrôle par groupes AD.	Entraîne une dépendance AD DS, complexité de synchronisation.	Environnements on‑prem existants ou besoins forts de « machine‑based ».
Azure AD Domain Services (AAD DS)	Utiliser un domaine managé compatible LDAP/Kerberos et y joindre les postes.	Instance AAD DS, jointure domaine des terminaux (ou comptes machine pré‑créés).	Offre un annuaire de type AD sans DC à gérer, NPS peut s’y connecter.	Coût et périmètre fonctionnel spécifiques, changements d’adhésion au domaine.	Quand on veut limiter l’empreinte AD tout en gardant NPS avec EAP‑TLS appareil.
Cloud RADIUS tiers	Serveur RADIUS as‑a‑Service capable d’interroger Entra ID/Intune.	Intégration OAuth/Graph/MDM, profils cert SCEP/PKCS, connecteurs réseau.	Pas d’AD DS requis, règles dynamiques par DeviceID et posture MDM.	Dépendance éditeur, coûts récurrents, migration de policies.	Flotte 100 % cloud cherchant « device‑based » sans AD.
Authentification utilisateur uniquement	Certificat utilisateur EAP‑TLS (ou PEAP) délivré via Intune/PKI.	Identités dans AD DS, Intune/PKI, distribution des racines.	Sécurité élevée (mutual TLS), pas de comptes machines nécessaires.	Pas de device‑based dans NPS ; posture à appliquer côté MDM/CA.	Transition rapide ou modèle « user‑centric » assumé.

Détails techniques et bonnes pratiques

Comprendre le mapping certificat → annuaire

Dans un monde NPS + AD DS, l’authentification EAP‑TLS « appareil » repose sur un certificat ordinateur dont le Subject/SAN (et les EKU) permettent de lier la connexion à un compte machine AD. Exemple de modèle :

Subject:    CN=%ComputerName%
SAN (DNS):  %ComputerName%.domain.local
EKU:        Client Authentication (1.3.6.1.5.5.7.3.2)

Intune permet d’injecter des variables (ex. {{DeviceID}}) dans le Subject ou les SAN. Cependant, NPS n’exploite pas ce DeviceID pour faire une recherche Entra ID ; il cherche un objet correspondant dans AD DS (ou AAD DS).

EAP‑TLS utilisateur : ce que NPS sait très bien faire

Le schéma le plus simple est d’émettre des certificats utilisateur via Intune (SCEP/PKCS) :

Modèle : Client Authentication, Subject au format UPN, SAN UPN.
Chaînes : distribuer racines/intermédiaires aux supplicants et à NPS.
Stratégies NPS : conditions sur des groupes AD utilisateurs (ex. « Wi‑Fi‑Employés »), méthode EAP‑TLS.
Posture : conformité Intune, chiffrement du disque, patch, etc., via politiques MDM et accès conditionnel aux ressources applicatives.

Ce modèle offre une robustesse cryptographique identique à l’authentification appareil, tout en évitant la gestion de comptes machines lorsque l’organisation bascule massivement vers le cloud.

À propos de l’extension NPS pour MFA

On lit souvent que l’on peut « ajouter la MFA » à NPS. Précisons :

L’extension NPS MFA s’insère après une authentification primaire réussie auprès d’AD DS.
Elle cible les méthodes basées sur des secrets (PAP/CHAP/MS‑CHAPv2/PEAP‑MSCHAPv2). Elle n’intercale pas de second facteur dans un flux EAP‑TLS « pur » côté Wi‑Fi, car le protocole ne prévoit pas d’étape interactive compatible avec la majorité des supplicants 802.1X.
En pratique, la MFA NPS est pertinente pour VPN/RDS/802.1X mot de passe, pas pour EAP‑TLS Wi‑Fi.

Scénarios de contournement détaillés

Hybrid Azure AD Join

But : conserver NPS et obtenir un objet machine en AD DS pour activer l’EAP‑TLS par appareil.

Mettre en place la jointure hybride (GPO/Intune) et la synchronisation AAD Connect.
Émettre un certificat ordinateur via Intune (SCEP/PKCS) ou via GPO/AD CS.
Configurer les policies NPS : NAS Port Type (Wireless/Wired), EAP‑TLS, condition « Membres de : WiFi‑Computers ».
Tester le roaming 802.1X, la révocation (CRL/OCSP) et le renouvellement cert.

Pro‑tip : isolez vos équipements (IoT, imprimantes) dans des VLANs dédiés via RADIUS attributes (Tunnel‑Private‑Group‑ID, etc.) mappés à des groupes AD de machines.

Azure AD Domain Services (AAD DS)

But : réduire l’empreinte serveurs tout en gardant des primitives AD pour NPS.

Déployer AAD DS crée un domaine managé auquel NPS peut s’adosser. Pour faire de l’EAP‑TLS appareil, il faut joindre les postes à ce domaine (ou pré‑créer leurs comptes) et y émettre des certificats ordinateur. Les contrôleurs de domaine sont opérés par Microsoft ; vous administrez comptes, groupes et GPO dans le périmètre pris en charge.

Cloud RADIUS tiers

But : supprimer la dépendance à AD DS et basculer sur un moteur RADIUS capable de parler nativement à Entra ID/Intune.

Intégration IdP (OIDC/SAML/Graph) pour résoudre les identités et DeviceID en temps réel.
Connecteur MDM pour récupérer la posture de conformité (chiffrement, jailbreak, versions OS).
Politiques granulaires : allow/deny/quarantine par DeviceID, groupe dynamique, balises Intune, etc.
Option « PKI managée » ou compatibilité avec votre AC existante.

Ce scénario est souvent le plus naturel pour une flotte 100 % cloud visant une authentification par appareil sans héberger d’AD.

Authentification utilisateur uniquement (avec posture MDM)

Si la priorité est d’aller vite en éliminant les comptes machines :

Déployer des certificats utilisateur via Intune (SCEP/PKCS).
Configurer NPS en EAP‑TLS utilisateur avec policies basées sur des groupes AD d’utilisateurs.
Renforcer la sécurité : conformité Intune stricte, accès conditionnel aux apps, segmentation réseau (VLAN), Device Compliance as a Gate côté applicatif.

Vous approchez ainsi un niveau de garantie équivalent « utilisateur + posture », sans machine‑based NPS.

FAQ technique

Peut‑on faire comprendre à NPS le DeviceID Entra ID en ajoutant un OID personnalisé dans le certificat ?

Non. NPS ne dispose pas d’une logique permettant d’interroger Entra ID pour traduire un OID « DeviceID » en objet de sécurité. Il faut un objet AD (ordinateur ou utilisateur) pour évaluer les policies.

Et si je configure NPS pour une mapping rule par Subject ou par Issuer ?

Ces réglages influent sur la validation du certificat, pas sur la résolution d’identité au sens « objet AD ». Pour une policy « machine‑based », il faut un compte machine consommable par NPS.

Le « Cloud Kerberos Trust » résout‑il le problème ?

Non. Cloud Kerberos Trust cible l’authentification Kerberos pour Windows/SSO. RADIUS/802.1X n’est pas concerné, et NPS ne reçoit aucun super‑pouvoir Entra ID via ce mécanisme.

Pourquoi parle‑t‑on autant de posture Intune si je fais de l’EAP‑TLS utilisateur ?

Parce qu’on peut compenser l’absence d’identité appareil dans NPS par des contrôles de conformité MDM (chiffrement, jailbreak, AV, OS). L’accès réseau reste chiffré et mutuellement authentifié, et l’accès aux ressources critiques est conditionné côté applicatif (VPN, proxy, SaaS).

Arbre de décision (pragmatique)

Vous avez déjà AD DS et vous souhaitez restreindre l’accès par machine ? → Hybrid Join et EAP‑TLS appareil via NPS.
Vous n’avez pas/plus d’AD DS mais vous acceptez un domaine managé ? → AAD DS + jointure des postes + NPS.
Vous visez 100 % cloud sans domaine ? → Cloud RADIUS tiers intégrant Entra ID/Intune.
Vous voulez réduire la complexité à court terme ? → EAP‑TLS utilisateur uniquement + posture MDM + segmentation réseau.

Modèle d’architecture (textuel)

[Supplicants 802.1X] --TLS--> [NPS/RADIUS] --LDAP/Kerberos--> [AD DS ou AAD DS]
                                          \--(optionnel)--> [Extension MFA (PEAP/MSCHAPv2)]
                                          \--(tiers)------> [Cloud RADIUS &lt;--API--&gt; Entra ID/Intune]

Playbook de mise en œuvre

Communs à tous les scénarios

PKI : gabarits conformes (EKU, key size, SHA‑256+), CRL/OCSP joignables depuis NPS et les supplicants.
Chaînes : racines/intermédiaires distribuées (GPO/Intune), y compris côté contrôleurs Wi‑Fi.
Chiffrement WPA2‑Enterprise/WPA3‑Enterprise : privilégier WPA3 si compatible.
Segmentation : prévoir VLANs d’isolement et d’onboarding (MAC‑auth bypass, portail captive si nécessaire).

Spécifique « Hybrid Join »

Activer la jointure hybride et vérifier la présence des comptes machine dans AD.
Émettre des certificats ordinateur (Intune SCEP ou AD CS auto‑enrollment).
Configurer NPS : Connection Request Policies + Network Policies avec EAP‑TLS, constraints temporels/VLAN.
Activer la journalisation NPS et exporter les événements (SIEM).

Spécifique « Cloud RADIUS tiers »

Intégrer Entra ID (OIDC) et Intune (API MDM) ; créer des règles dynamiques (DeviceID, OS, conformité).
Déployer agents/connecteurs sur les contrôleurs Wi‑Fi (si requis).
Basculer SSID pilote, observer latence RADIUS, taux d’échec, posture.
Étendre progressivement à la production, sunset NPS si objectif « full cloud ».

Erreurs fréquentes et remèdes

CRL injoignable → l’EAP‑TLS échoue de façon aléatoire. Remède : publier CRL/OCSP en HTTP(s), ouvrir le trafic sortant.
Mauvais EKU → certificats marqués « Server Authentication » au lieu de « Client Authentication ». Remède : corriger le gabarit.
Chaîne incomplète côté contrôleur Wi‑Fi → échecs pendant la négociation TLS. Remède : importer l’intermédiaire de l’AC EAP.
Confusion MFA/EAP‑TLS → attendre une « MFA Wi‑Fi » avec EAP‑TLS. Remède : MFA sur VPN/portails, posture MDM pour Wi‑Fi.
Absence de compte machine AD → impossible d’appliquer une policy NPS par appareil. Remède : Hybrid Join, AAD DS ou Cloud RADIUS.

Sécurité : comment approcher le niveau « appareil+utilisateur » sans AD DS

En EAP‑TLS utilisateur, combinez :

Certificats utilisateurs non exportables, stockage TPM, renouvellement court (6–12 mois).
Conformité Intune (BitLocker/FileVault, OS minimum, AV, jailbreak/root).
Accès conditionnel (par appli) et MDM app‑protection (politiques MAM).
Segmentation réseau (VLAN/ACL) et micro‑segmentation côté datacenter/cloud.
Supervision : journaux NPS exportés (CEF/LEEF), corrélation avec logs RADIUS/AP et Intune.

Checklist opérationnelle

Élément	OK	Notes
Chaîne PKI & CRL/OCSP accessibles
Profils cert Intune (utilisateur/ordinateur) correctement déployés
Groupes (utilisateurs ou ordinateurs) pour policies NPS
Attributs RADIUS (VLAN, ACL) testés
Surveillance et export SIEM des logs NPS
Plan de rotation des certificats (renouvellement, révocation)

Modèles de policies NPS (exemples)

Network Policy: "WiFi-Users-EAPTLS"
 Conditions:
   - Windows Group: GRP-WIFI-USERS
 Constraints:
   - Authentication: Microsoft: Smart Card or other certificate (EAP-TLS)
 Settings:
   - RADIUS Attributes: Tunnel-Medium-Type=IEEE-802
                         Tunnel-Pvt-Group-ID=20 (VLAN Corp)

Network Policy: "WiFi-Devices-EAPTLS" (nécessite des comptes machines AD)
 Conditions:
   - Windows Group: GRP-WIFI-COMPUTERS
 Constraints:
   - Authentication: EAP-TLS (certificat ordinateur)
 Settings:
   - VLAN = 30 (Device), Session-Timeout = 86400

Plan de migration conseillé

Évaluer : cartographier SSID, contrôleurs, méthodes EAP actuelles, présence/absence d’AD.
Choisir le scénario (Hybrid Join, AAD DS, Cloud RADIUS, User‑only) selon contraintes et objectifs.
Piloter : créer un SSID de test, limiter à un site/BU, instrumenter la télémétrie.
Industrialiser : gabarits cert, automatisation Intune, scripts d’import RACINE/INTER.
Sécuriser : posture Intune, segmentation, surveillance, PRA sur la PKI et NPS.

Conclusion

Le verdict est net : NPS ne peut pas authentifier « par appareil » un poste joint uniquement à Microsoft Entra ID, faute de connectivité native vers Entra ID et d’objet machine dans AD. Trois voies existent pour obtenir un résultat de type device‑based : Hybrid Join (conserver AD), AAD DS (domaine managé) ou Cloud RADIUS (intégration native Entra ID/Intune). À défaut, l’EAP‑TLS utilisateur reste une option hautement sécurisée, à compléter par la posture MDM, l’accès conditionnel et une segmentation réseau soignée.

Références conceptuelles rapides

NPS : serveur RADIUS Windows appuyé sur AD DS.
EAP‑TLS : authentification mutuelle par certificats (client/serveur).
Entra ID : ex‑Azure AD, annuaire cloud des identités.
Intune : MDM/MAM et distribution des certificats (SCEP/PKCS).
AAD DS : domaine managé compatible LDAP/Kerberos pour workloads nécessitant un AD.