Authentification WiFi Azure AD et Entra ID : Guide d'intégration et de configuration
Ce guide de référence technique fournit aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de sites une feuille de route pratique pour l'intégration de Microsoft Entra ID (Azure AD) aux réseaux WiFi d'entreprise via RADIUS et 802.1X. Il couvre le choix architectural entre Windows NPS sur site et RADIUS natif dans le cloud, le déploiement de l'authentification EAP-TLS basée sur des certificats via Microsoft Intune, ainsi que les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Pour les organisations déjà investies dans l'écosystème Microsoft 365 et Entra ID, ce guide comble le fossé entre la gestion des identités dans le cloud et la sécurité physique du réseau.
Résumé exécutif
Pour les entreprises modernes fortement investies dans l'écosystème Microsoft, relier l'infrastructure d'identité cloud aux réseaux sans fil physiques est un impératif de sécurité critique. Historiquement, l'authentification WiFi reposait sur Active Directory Domain Services (AD DS) sur site et Windows Network Policy Server (NPS). Cependant, à mesure que les organisations migrent vers Microsoft Entra ID (anciennement Azure AD) et adoptent des modèles de sécurité zero-trust, l'approche traditionnelle d'authentification basée sur les identifiants — PEAP-MSCHAPv2 — n'est plus suffisante ni sécurisée.
Ce guide fournit aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de sites une feuille de route pratique pour la mise en œuvre de l'authentification WiFi Azure AD. Nous explorons les différences architecturales entre le maintien d'une empreinte NPS sur site et la migration vers une solution RADIUS native dans le cloud. De manière cruciale, nous détaillons comment exploiter Microsoft Intune pour l'authentification basée sur des certificats (EAP-TLS), ce qui élimine les vulnérabilités liées aux mots de passe et offre une expérience fluide et sans friction pour les utilisateurs finaux. Que vous gériez un hôtel de 500 chambres, une chaîne de magasins ou un déploiement d'envergure dans le secteur public, ce guide vous aidera à sécuriser votre périmètre sans fil en utilisant vos investissements existants dans l'identité Microsoft. Pour une discussion plus large sur les modèles de déploiement, consultez notre Guide de décision Cloud RADIUS vs RADIUS sur site pour les équipes informatiques .
Analyse technique approfondie : Architecture et normes
Le fondement d'un WiFi d'entreprise sécurisé est la norme IEEE 802.1X, qui fournit un contrôle d'accès réseau basé sur les ports. Dans un environnement centré sur Microsoft, l'intégration de 802.1X avec Entra ID nécessite une planification architecturale minutieuse sur trois couches : l'infrastructure sans fil, le serveur d'authentification et l'annuaire d'identité.
Le rôle de RADIUS et 802.1X
Lorsqu'un appareil client (le supplicant) tente de se connecter à un réseau WPA2/WPA3-Enterprise, le point d'accès sans fil (l'authentificateur) bloque tout le trafic à l'exception des paquets EAP (Extensible Authentication Protocol). Le point d'accès transmet ces paquets à un serveur RADIUS. Le serveur RADIUS valide l'identité de l'utilisateur ou de l'appareil par rapport à un service d'annuaire et renvoie un message Access-Accept ou Access-Reject. Ce modèle à trois parties — supplicant, authentificateur, serveur d'authentification — est la pierre angulaire de la sécurité sans fil d'entreprise et est décrit en détail dans notre Définition des points d'accès sans fil : Votre guide ultime 2026 .
Approches architecturales pour les environnements Microsoft
Il existe deux architectures principales pour intégrer l'identité Microsoft à l'authentification WiFi, chacune présentant des compromis distincts :
| Dimension | Hybride sur site (NPS) | Natif dans le cloud (Cloud RADIUS) |
|---|---|---|
| Infrastructure | VM Windows Server ou bare metal requis | Aucun serveur sur site |
| Source d'identité | AD DS via LDAP/Kerberos | Entra ID directement via API |
| Autorité de certification | ADCS sur site + Connecteur Intune | PKI Cloud Intune ou PKI fournisseur |
| Évolutivité | HA/équilibrage de charge manuel | Évolutivité automatique par le fournisseur |
| Idéal pour | AD hybride, appareils hérités | Organisations cloud-first, gérées par Intune |
| Complexité opérationnelle | Plus élevée au départ et en continu | Charge opérationnelle réduite |
Hybride sur site (Windows NPS + AD DS + Azure AD Connect) : C'est l'approche traditionnelle. Windows NPS agit comme serveur RADIUS, authentifiant les requêtes par rapport à un Active Directory sur site. Pour lier cela au cloud, Azure AD Connect synchronise les identités sur site avec Entra ID. Bien que robuste, cela nécessite de maintenir une infrastructure de serveurs sur site, de gérer la haute disponibilité et de déployer une PKI complexe (ADCS) en cas de mise en œuvre d'EAP-TLS.
Natif dans le cloud (Cloud RADIUS + Entra ID + Intune) : Cette approche moderne élimine le besoin de serveurs NPS sur site. Un fournisseur tiers de Cloud RADIUS s'intègre directement à Entra ID via l'API Microsoft Graph. L'authentification se déroule entièrement dans le cloud. Cette architecture s'aligne sur une stratégie cloud-first, réduisant considérablement la charge opérationnelle et s'alignant sur les principes d'accès réseau zero-trust.
EAP-TLS vs PEAP-MSCHAPv2 : Le choix critique
Le choix de la méthode EAP est la décision de sécurité la plus importante de ce déploiement. PEAP-MSCHAPv2 repose sur la saisie par les utilisateurs de leurs identifiants de domaine. Cela est vulnérable au vol d'identifiants, aux attaques de l'homme du milieu et crée une mauvaise expérience utilisateur lorsque les mots de passe expirent. Les recherches ont systématiquement démontré que PEAP-MSCHAPv2 peut être compromis par des attaques de points d'accès malveillants.
EAP-TLS (Transport Layer Security) est la référence absolue du secteur pour un WiFi sécurisé. Il utilise des certificats numériques installés sur l'appareil client pour une authentification mutuelle — le client et le serveur prouvent tous deux leur identité. Il n'y a pas de mots de passe à saisir et la connexion est cryptographiquement forte. Dans un environnement Microsoft, les certificats sont généralement déployés à l'aide de Microsoft Intune via SCEP (Simple Certificate Enrollment Protocol) ou PKCS. C'est la voie recommandée pour tous les nouveaux déploiements et elle est essentielle pour la conformité aux obligations de protection des données PCI DSS (Exigence 8) et GDPR.
Guide de mise en œuvre : Déploiement étape par étape
La mise en œuvre de l'authentification WiFi Entra ID à l'aide d'EAP-TLS et d'Intune nécessite la coordination de plusieurs composants à travers l'identité, la gestion des appareils et l'infrastructure réseau. L'approche en cinq phases suivante est recommandée pour un déploiement natif dans le cloud.
Phase 1 : Préparer l'infrastructure d'identité et de gestion des appareils
Commencez par vérifier que votre locataire Entra ID dispose des licences appropriées. Microsoft 365 E3/E5 ou Enterprise Mobility + Security (EMS) E3/E5 inclut les capacités de gestion des appareils Intune et d'accès conditionnel requises pour ce déploiement. Sans Intune, le déploiement automatisé de certificats n'est pas possible.
Ensuite, établissez votre infrastructure à clés publiques (PKI). Vous avez trois options : une PKI native dans le cloud fournie par votre fournisseur Cloud RADIUS, la propre PKI Cloud de Microsoft (disponible avec la licence Intune Suite), ou un déploiement ADCS sur site existant connecté à Intune via le connecteur de certificat Microsoft Intune. Pour les nouveaux déploiements, une PKI native dans le cloud est fortement recommandée pour éviter les dépendances sur site.
Phase 2 : Configurer Intune pour le déploiement de certificats
Dans le centre d'administration Microsoft Intune, créez un profil de configuration de Certificat approuvé. Téléchargez le certificat de l'autorité de certification racine (Root CA) de votre PKI et déployez-le sur vos groupes d'appareils cibles. Cette étape est critique : elle garantit que les appareils clients font confiance au certificat présenté par le serveur RADIUS lors de la négociation TLS, empêchant ainsi les attaques de l'homme du milieu.
Ensuite, créez un profil de Certificat SCEP (ou PKCS si votre PKI l'exige). Configurez le format du nom de l'objet — pour l'authentification basée sur l'utilisateur, utilisez CN={{UserPrincipalName}} ; pour l'authentification basée sur l'appareil, utilisez CN={{DeviceName}} ou le numéro de série de l'appareil. Définissez le nom alternatif de l'objet (SAN) pour inclure le nom d'utilisateur principal ou l'ID de l'appareil. Attribuez les deux profils aux groupes d'utilisateurs ou d'appareils Entra ID appropriés.
Phase 3 : Configurer l'intégration Cloud RADIUS
Accordez à votre fournisseur Cloud RADIUS les autorisations d'API Microsoft Graph nécessaires dans votre locataire Entra ID. Au minimum, le fournisseur nécessite User.Read.All et GroupMember.Read.All pour valider les appartenances aux groupes lors de l'authentification. Certains fournisseurs exigent également Device.Read.All pour les politiques basées sur les appareils.
Dans le portail de gestion Cloud RADIUS, définissez vos politiques d'authentification. Une politique bien structurée pour un environnement d'entreprise pourrait être : "Autoriser l'accès si le certificat est délivré par [Trusted CA] ET que l'utilisateur est membre du groupe Entra ID [Corporate-WiFi-Users] ET que l'appareil est marqué comme conforme dans Intune." Cette politique multicouche applique simultanément l'identité et la santé de l'appareil.
Phase 4 : Configurer l'infrastructure sans fil
Dans votre contrôleur LAN sans fil ou votre tableau de bord de gestion cloud (tel que Cisco Meraki, Aruba Central ou Juniper Mist), ajoutez les adresses IP du serveur Cloud RADIUS et les secrets partagés en tant que serveurs d'authentification RADIUS. Configurez des serveurs primaires et secondaires pour la redondance. Réglez le délai d'expiration RADIUS sur un minimum de 5 secondes pour tenir compte de la latence des allers-retours vers le cloud.
Créez un nouveau SSID configuré pour WPA2-Enterprise ou WPA3-Enterprise. Attribuez les serveurs RADIUS à ce SSID. Pour les déploiements dans l'Hôtellerie ( Hospitality ), assurez-vous que ce SSID d'entreprise se trouve sur un VLAN distinct de tout réseau invité. Pour les environnements de Commerce de détail ( Retail ), envisagez de déployer le SSID d'entreprise uniquement dans les zones réservées au personnel, en gardant le réseau de la surface de vente séparé.
Phase 5 : Déployer le profil WiFi via Intune
Créez un profil de configuration WiFi dans Intune. Définissez le SSID pour qu'il corresponde exactement à ce que vous avez configuré sur l'infrastructure sans fil. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité. Sous les paramètres EAP, sélectionnez EAP-TLS comme méthode d'authentification. Liez le profil de certificat SCEP en tant que certificat client et spécifiez le profil de l'autorité de certification racine approuvée que vous avez déployé à la phase 2.
Attribuez ce profil WiFi aux mêmes groupes d'appareils qui ont reçu les profils de certificat. Les appareils recevront silencieusement le certificat et la configuration WiFi lors de leur prochaine synchronisation Intune, et se connecteront automatiquement lorsqu'ils seront à portée du SSID — sans aucune interaction de l'utilisateur.
Meilleures pratiques pour les environnements d'entreprise
Les recommandations suivantes représentent le consensus du secteur pour des déploiements Microsoft 802.1X sécurisés et évolutifs sur les sites d'entreprise.
Imposez l'EAP-TLS pour tous les nouveaux déploiements. Ne déployez pas de nouveaux réseaux utilisant PEAP-MSCHAPv2. Les risques de sécurité du WiFi basé sur les identifiants sont bien documentés et incompatibles avec une posture de sécurité zero-trust. L'EAP-TLS est essentiel pour la conformité aux normes PCI DSS, GDPR et ISO 27001.
Automatisez le cycle de vie des certificats. Assurez-vous que lorsqu'un utilisateur est désactivé dans Entra ID ou qu'un appareil est retiré dans Intune, le certificat correspondant est automatiquement révoqué ou que la politique RADIUS bloque immédiatement l'accès. Ceci est particulièrement important dans les environnements à forte rotation tels que l'Hôtellerie ( Hospitality ) et le Commerce de détail ( Retail ), où les changements de personnel sont fréquents.
Mettez en œuvre l'accès conditionnel Entra ID. Exploitez les politiques d'accès conditionnel pour imposer la conformité des appareils comme condition d'accès au réseau. Exiger que les appareils soient marqués comme « conformes » dans Intune avant de pouvoir s'authentifier auprès de RADIUS garantit que seuls les appareils à jour et conformes aux politiques accèdent au réseau de l'entreprise.
Segmentez rigoureusement les réseaux d'entreprise et invités. Le 802.1X est conçu pour les appareils d'entreprise gérés. Pour les visiteurs, les prestataires et le BYOD, mettez en œuvre une solution de WiFi invité dédiée avec un Captive Portal. Celle-ci peut s'intégrer à Entra ID B2B pour l'accès des prestataires, ou utiliser des connexions via les réseaux sociaux et la vérification par SMS pour l'accès du grand public. Ne laissez jamais d'appareils non gérés accéder au SSID 802.1X de l'entreprise.
Prévoyez une stratégie pour les appareils hérités et IoT. Les imprimantes, les capteurs IoT et les appareils hérités qui ne peuvent pas prendre en charge les certificats nécessitent une stratégie distincte. Utilisez le MAC Authentication Bypass (MAB) pour les appareils connus, ou un SSID WPA2-Personal dédié avec une clé PSK complexe et renouvelée, isolé sur un VLAN dédié. La plateforme Sensors de Purple, par exemple, peut fonctionner sur un VLAN IoT dédié, séparé de l'infrastructure d'authentification de l'entreprise.
Surveillez les événements d'authentification. Intégrez les journaux RADIUS à votre SIEM ou utilisez la plateforme WiFi Analytics pour surveiller les échecs d'authentification, les avertissements d'expiration de certificat et les modèles d'accès inhabituels. Une surveillance proactive prévient les pannes avant qu'elles n'impactent les opérations.
Dépannage et atténuation des risques
Même les déploiements bien planifiés rencontrent des problèmes. Voici les modes de défaillance les plus courants et leurs résolutions.
Échecs de déploiement de certificats. Le problème le plus courant dans un déploiement EAP-TLS est que les appareils ne reçoivent pas les certificats d'Intune. Cela est généralement causé par un connecteur de certificat Intune mal configuré (si vous utilisez ADCS sur site), une URL SCEP incorrecte ou des appareils qui ne se synchronisent pas avec Intune. Vérifiez toujours l'état du connecteur de certificat dans le centre d'administration Intune et consultez les journaux de synchronisation des appareils. Assurez-vous que le compte de service SCEP dispose des autorisations nécessaires sur l'autorité de certification.
Problèmes de délai d'attente RADIUS. Si le point d'accès ne peut pas atteindre le serveur RADIUS dans le délai configuré, les clients ne pourront pas se connecter. Assurez-vous que vos règles de pare-feu autorisent les ports UDP 1812 (authentification) et 1813 (comptabilité) en sortie vers les plages IP du fournisseur Cloud RADIUS. Si vous utilisez NPS sur site, déployez au moins deux serveurs NPS et configurez vos points d'accès pour qu'ils basculent de l'un à l'autre.
Échecs de confiance de certificat. Si les clients reçoivent une erreur « certificat de serveur non approuvé », le profil d'autorité de certification racine approuvée n'a pas été déployé correctement sur l'appareil. Vérifiez l'attribution du profil dans Intune et examinez le magasin de certificats de l'appareil. C'est un problème courant avec les appareils nouvellement inscrits qui n'ont pas encore terminé leur première synchronisation Intune.
Extension NPS pour Azure MFA. Bien qu'il soit techniquement possible d'utiliser l'extension NPS pour imposer l'authentification multifactorielle pour le WiFi, cela est fortement déconseillé pour l'accès principal. L'expérience utilisateur consistant à recevoir une invite MFA chaque fois qu'un appareil passe d'un point d'accès à un autre est extrêmement perturbatrice. Fiez-vous à l'authentification forte fournie par le certificat de l'appareil et imposez plutôt la MFA au niveau de la couche applicative.
Conflits de stratégie de groupe. Dans les environnements hybrides, les objets de stratégie de groupe (GPO) qui configurent le client sans fil Windows peuvent entrer en conflit avec les profils WiFi d'Intune. Assurez-vous que les profils Intune sont prioritaires en examinant les paramètres d'inscription MDM et, si nécessaire, en bloquant la configuration sans fil basée sur les GPO pour les appareils gérés par Intune.
ROI et impact commercial
La migration vers une architecture RADIUS native dans le cloud intégrée à Entra ID offre une valeur mesurable et quantifiable sur plusieurs dimensions.
Réduction des tickets d'assistance. Les problèmes de WiFi liés aux mots de passe — verrouillages, mots de passe expirés, supplicants mal configurés — sont une source importante de tickets de support informatique dans les environnements basés sur les identifiants. L'EAP-TLS les élimine entièrement. Les organisations signalent généralement une réduction de 30 à 50 % du volume d'assistance lié au WiFi après la migration vers l'authentification basée sur des certificats.
Économies sur les coûts d'infrastructure. Le démantèlement des serveurs NPS sur site réduit les coûts de calcul, les frais de licence du système d'exploitation et la charge opérationnelle liée au correctif et à la maintenance des clusters à haute disponibilité. Pour une organisation de taille moyenne exploitant deux serveurs NPS, cela peut représenter des économies de 15 000 € à 30 000 € par an en coûts d'infrastructure et d'exploitation.
Amélioration de la posture de sécurité et de la conformité. L'abandon de l'authentification basée sur les identifiants atténue le risque de vol d'identifiants et de mouvement latéral, protégeant ainsi les données sensibles de l'entreprise. Pour les organisations soumises à la norme PCI DSS, cela répond directement aux exigences de contrôle d'accès au réseau. Pour les organisations de Santé ( Healthcare ) manipulant des données de patients, cela soutient la conformité DSPT. Pour les opérateurs de Transport ( Transport ), cela s'aligne sur les exigences de la directive NIS2 en matière de sécurité des réseaux.
Expérience utilisateur améliorée. Une connexion WiFi fluide et automatique — sans invite de mot de passe, sans verrouillage et sans configuration manuelle — améliore la productivité et réduit les frictions pour le personnel. Cela est particulièrement impactant dans les environnements à forte mobilité tels que les centres de distribution, les services hospitaliers et les surfaces de vente au détail.
En traitant votre réseau WiFi comme une extension de votre stratégie d'identité cloud, vous garantissez un accès sécurisé et sans friction qui évolue avec votre organisation. Pour plus de conseils sur les aspects d'intégration SD-WAN des réseaux d'entreprise modernes, consultez Les principaux avantages du SD-WAN pour les entreprises modernes . Pour les considérations de déploiement spécifiques à l'hôtellerie, reportez-vous à Solutions WiFi modernes pour l'hôtellerie que vos clients méritent .
Termes clés et définitions
802.1X
An IEEE standard for port-based Network Access Control (PNAC). It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN, preventing unauthorised access before authentication is complete.
The foundational protocol that prevents unauthorised devices from accessing the enterprise network. All WPA2/WPA3-Enterprise deployments rely on 802.1X.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users who connect and use a network service. Defined in RFC 2865.
The server component that validates credentials or certificates against the directory (Entra ID or AD DS) and instructs the access point to grant or deny access.
Supplicant
The client device (laptop, smartphone, IoT device) attempting to connect to the network. In Windows, the built-in wireless client acts as the supplicant.
In Intune deployments, the supplicant must be configured with the correct WiFi profile and client certificate to communicate successfully with the RADIUS server.
Authenticator
The network device — typically a Wireless Access Point or managed switch — that facilitates the authentication process between the supplicant and the RADIUS server. It enforces access control based on the RADIUS response.
The access point must be configured with the RADIUS server IP address and shared secret. It acts as a relay, forwarding EAP packets between the client and the RADIUS server.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
An EAP method that relies on digital certificates for mutual authentication between the client and the RADIUS server. It is defined in RFC 5216 and is considered one of the most secure EAP standards available.
The recommended authentication method for all new Microsoft 802.1X deployments. It eliminates passwords entirely and is required for compliance with PCI DSS and zero-trust network access frameworks.
NPS (Network Policy Server)
Microsoft's implementation of a RADIUS server and proxy, available as a role in Windows Server. NPS can authenticate users and devices against Active Directory Domain Services.
The traditional on-premise solution for enterprise WiFi authentication in Microsoft environments. Many organisations are now migrating from NPS to Cloud RADIUS solutions as they move to Entra ID.
SCEP (Simple Certificate Enrollment Protocol)
A protocol used for issuing digital certificates to network devices in a scalable, automated manner. Defined in RFC 8894.
The primary method Microsoft Intune uses to silently deploy client certificates to managed devices for EAP-TLS WiFi authentication. Requires a SCEP-compatible Certificate Authority.
Microsoft Entra ID
Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory. It provides user authentication, group management, Conditional Access, and integration with thousands of applications.
The central identity provider in modern Microsoft environments. Cloud RADIUS solutions integrate with Entra ID via Microsoft Graph API to validate user and device identities during WiFi authentication.
Conditional Access
An Entra ID feature that enforces access policies based on signals such as user identity, device compliance status, location, and risk level. Policies can require devices to be Intune-compliant before granting access.
Used in advanced RADIUS deployments to ensure that only compliant, managed devices can authenticate to the corporate WiFi network, even if they present a valid certificate.
PEAP-MSCHAPv2
Protected EAP with Microsoft Challenge Handshake Authentication Protocol version 2. A credential-based EAP method that uses a username and password for authentication, tunnelled within a TLS session.
The legacy authentication method used in many existing NPS deployments. It is vulnerable to credential theft and man-in-the-middle attacks and should be migrated to EAP-TLS in all new deployments.
Études de cas
A 200-location retail chain needs to secure their back-office WiFi for store manager laptops. They currently use a shared WPA2-Personal password (PSK) across all stores, which is rarely rotated. They use Entra ID and Intune for device management. How should they modernise their wireless security?
The retail chain should migrate to WPA3-Enterprise using EAP-TLS across all 200 locations. The recommended architecture is a Cloud RADIUS solution integrated directly with their Entra ID tenant, eliminating the need for on-premise NPS servers at each site. Using Intune, they deploy a SCEP certificate profile to issue unique device certificates to the store manager laptops. A Trusted Root CA profile is deployed first to ensure devices trust the RADIUS server. A WiFi configuration profile is then deployed via Intune, silently connecting devices to the new SSID using the issued certificate. The old PSK SSID is decommissioned once all devices have migrated. For the store's customer-facing WiFi, a separate captive portal solution handles guest access without impacting the corporate authentication infrastructure.
A large conference centre uses on-premise Windows NPS for staff WiFi authentication. They are experiencing frequent connectivity failures during large events because the NPS server becomes overwhelmed with concurrent authentication requests from 500+ staff devices. They are also migrating their identity infrastructure to Entra ID. What is the recommended architecture going forward?
The conference centre should migrate from the on-premise NPS server to a Cloud RADIUS provider that integrates directly with Entra ID. Staff devices should be transitioned to certificate-based authentication (EAP-TLS) managed via Intune, resolving both the scalability issue and the Entra ID migration requirement simultaneously. For the high volume of event attendees, a separate, segmented network using a captive portal solution handles guest onboarding without impacting the corporate RADIUS infrastructure. The two networks should be on separate VLANs with appropriate firewall rules between them. The on-premise NPS server can be decommissioned once all staff devices have successfully migrated.
Analyse de scénario
Q1. Your organisation is completing a full migration from on-premise Active Directory to Entra ID only — no on-premise domain controllers will remain. You currently use Windows NPS for WiFi authentication using PEAP-MSCHAPv2. What is the most secure and operationally efficient approach for the new cloud-only environment, and what specific steps are required?
💡 Astuce :Consider what NPS requires to function and whether those dependencies will exist post-migration. Also consider the security implications of the current EAP method.
Afficher l'approche recommandée
The most secure and efficient approach is to implement a Cloud RADIUS solution integrated directly with Entra ID, and transition to EAP-TLS certificate-based authentication managed via Microsoft Intune. NPS cannot authenticate against Entra ID directly — it requires on-premise AD DS — so it cannot survive the migration without Azure AD Connect maintaining a hybrid identity. The steps are: (1) Select a Cloud RADIUS provider and grant it Microsoft Graph API permissions in Entra ID. (2) Establish a cloud-native PKI or use Microsoft Cloud PKI. (3) Deploy Trusted Root CA and SCEP certificate profiles via Intune. (4) Deploy a WiFi configuration profile via Intune configured for EAP-TLS. (5) Configure the SSID on the wireless infrastructure to use the Cloud RADIUS servers. (6) Decommission NPS once all devices have migrated.
Q2. A hospital IT team wants to implement 802.1X for their medical carts (Windows laptops) using Entra ID. They want to ensure that if a cart is stolen, it cannot connect to the network even if the associated user account is still active. How should the certificate profile and RADIUS policy be configured to achieve this?
💡 Astuce :Consider the difference between user-based and device-based certificate profiles in Intune, and how RADIUS policies can be scoped to device identity.
Afficher l'approche recommandée
The IT team should configure Intune to deploy device certificates (not user certificates) to the medical carts. In the SCEP profile, the Subject Name should reference the device identity (e.g., CN={{DeviceName}} or the device serial number) rather than the user UPN. The RADIUS policy should be configured to authenticate the device certificate and validate the device against Entra ID device objects. If a cart is stolen, the IT team can remotely wipe the device via Intune (which removes the certificate from the device's certificate store) or revoke the specific device certificate in the PKI. Either action immediately blocks network access without affecting any user accounts. This approach is superior to user-based certificates for shared devices like medical carts.
Q3. You have successfully deployed EAP-TLS via Intune for all 800 corporate laptops across a university campus. However, the IT department frequently brings in external contractors who need internet access for project work. These contractors use their own personal or company-issued laptops that are not enrolled in your Intune tenant. How should you provide access for these contractors without compromising the security of the corporate 802.1X network?
💡 Astuce :Remember the architectural principle separating managed device authentication from unmanaged device access. Consider how Entra ID B2B could be leveraged.
Afficher l'approche recommandée
Do not attempt to provision 802.1X access for unmanaged contractor devices. Instead, deploy a separate Guest SSID backed by a Captive Portal solution. For contractors who have their own corporate Entra ID tenants, configure the captive portal to support Entra ID B2B collaboration, allowing them to authenticate with their own corporate credentials via the portal. For contractors without a compatible identity provider, use a sponsored access workflow where a university staff member approves the access request. The contractor network should be on a separate VLAN with internet-only access and no route to internal university resources. This maintains the integrity of the 802.1X corporate network while providing a secure, auditable access path for external parties.
Q4. During a post-deployment review, your security team flags that several devices on the corporate WiFi are still using PEAP-MSCHAPv2 despite the EAP-TLS rollout. Investigation reveals these are IoT devices — smart displays, environmental sensors, and a fleet of network printers — that do not support certificate-based authentication. How should these devices be handled?
💡 Astuce :Consider the options available for devices that cannot support EAP-TLS, and the importance of network segmentation.
Afficher l'approche recommandée
IoT devices and legacy hardware that cannot support EAP-TLS should not be placed on the corporate 802.1X SSID. The recommended approach is to create a dedicated IoT SSID on a separate VLAN with strict firewall rules limiting communication to only the services those devices require (e.g., print servers, management platforms). For authentication, use MAC Authentication Bypass (MAB) for devices with known, fixed MAC addresses, or a WPA2-Personal SSID with a complex, regularly rotated PSK. The IoT VLAN should have no access to corporate file shares, Active Directory, or sensitive internal resources. Purple's Sensors platform, for example, is designed to operate on a dedicated IoT network segment, separate from corporate infrastructure.
Points clés à retenir
- ✓Traditional on-premise Windows NPS servers are being replaced by Cloud RADIUS solutions that integrate directly with Entra ID, eliminating on-premise infrastructure dependencies.
- ✓Credential-based authentication (PEAP-MSCHAPv2) is a significant security risk and should be migrated to EAP-TLS certificate-based authentication in all new and existing deployments.
- ✓EAP-TLS is the gold standard for secure, passwordless WiFi — certificates are deployed silently via Microsoft Intune using SCEP or PKCS profiles.
- ✓Microsoft Intune is the cornerstone of a modern Microsoft WiFi authentication stack, managing the full certificate lifecycle from issuance to revocation.
- ✓802.1X is designed exclusively for Intune-managed corporate devices; unmanaged guests and contractors must use a separate Captive Portal solution.
- ✓Entra ID Conditional Access can enforce device compliance as a prerequisite for WiFi authentication, ensuring only patched and policy-compliant devices connect.
- ✓RADIUS ports 1812 (authentication) and 1813 (accounting) must be open outbound from the wireless infrastructure to the RADIUS server — this is the most common cause of deployment failures.
