Authentification WiFi avec Azure AD et Entra ID : Guide d'intégration et de configuration

Synthèse

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 sur 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 d'exploitation de sites une feuille de route pratique pour mettre en œuvre 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 cloud-native. De plus, nous détaillons comment exploiter Microsoft Intune pour l'authentification basée sur les 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 vente au détail ou un grand déploiement dans le secteur public, ce guide vous aidera à sécuriser votre réseau 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 pour les équipes informatiques : Cloud RADIUS vs RADIUS sur site .

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 niveaux : l'infrastructure sans fil, le serveur d'authentification et l'annuaire d'identité.

Le rôle de RADIUS et de 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 transfère ces paquets vers 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 tripartite — 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 Wireless Access Points Definition: Your Ultimate 2026 Guide .

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 :

Hybride sur site (Windows NPS + AD DS + Azure AD Connect) : Il s'agit de l'approche traditionnelle. Windows NPS fait office de 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, cette solution 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 d'implémentation d'EAP-TLS.

Cloud-Native (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 fait 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'inscrivant dans 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. Cette méthode est vulnérable au vol d'identifiants, aux attaques de type "homme du milieu" et génère une mauvaise expérience utilisateur lorsque les mots de passe expirent. Les recherches ont constamment 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 aucun mot 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é avec PCI DSS (Exigence 8) et les obligations de protection des données du GDPR.

Guide d'implémentation : Déploiement étape par étape

L'implémentation de l'authentification Entra ID WiFi à l'aide d'EAP-TLS et d'Intune nécessite la coordination de plusieurs composants au sein de l'infrastructure d'identité, de gestion des appareils et de réseau. L'approche en cinq phases suivante est recommandée pour un déploiement cloud-native.

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 fonctionnalités de gestion des appareils Intune et d'accès conditionnel requises pour ce déploiement. Sans Intune, le déploiement automatisé de certificats est impossible.

Ensuite, établissez votre infrastructure à clés publiques (PKI). Vous disposez de trois options : une PKI cloud-native fournie par votre fournisseur Cloud RADIUS, la propre Cloud PKI 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 cloud-native est fortement recommandée afin d'é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éversez 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 essentielle : elle garantit que les appareils clients font confiance au certificat présenté par le serveur RADIUS lors de la liaison TLS, évitant ainsi les attaques de type "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 (Subject Name) — pour une authentification basée sur l'utilisateur, utilisez CN={{UserPrincipalName}} ; pour une authentification basée sur l'appareil, utilisez CN={{DeviceName}} ou le numéro de série de l'appareil. Configurez le nom alternatif de l'objet (SAN) pour inclure le nom d'utilisateur principal (User Principal Name) ou l'identifiant 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 Microsoft Graph API nécessaires dans votre locataire Entra ID. Au minimum, le fournisseur requiert 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 émis 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 conformité 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 et les secrets partagés du serveur Cloud RADIUS en tant que serveurs d'authentification RADIUS. Configurez des serveurs primaires et secondaires pour la redondance. Définissez le délai d'attente (timeout) RADIUS à un minimum de 5 secondes pour s'adapter à la latence des aller-retours avec le cloud.

Créez un nouvel SSID configuré pour le WPA2-Enterprise ou le WPA3-Enterprise. Associez les serveurs RADIUS à ce SSID. Pour les déploiements dans le secteur de l' Hôtellerie , assurez-vous que ce SSID d'entreprise se trouve sur un VLAN distinct de tout réseau invité. Pour les environnements de la Vente au détail , 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. Configurez 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é. Dans les paramètres EAP, sélectionnez EAP-TLS comme méthode d'authentification. Associez le profil de certificat SCEP en tant que certificat client et spécifiez le profil d'autorité de certification racine de confiance (Trusted Root CA) que vous avez déployé lors de 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 requise.

Bonnes 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 dans les espaces d'entreprise.

Imposez l'EAP-TLS sur 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 des identifiants sont bien documentés et incompatibles avec une posture de sécurité zero-trust. L'EAP-TLS est essentiel pour la conformité avec PCI DSS, la GDPR et la norme 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. Cela est particulièrement important dans les environnements à forte rotation de personnel tels que l' Hôtellerie et le Commerce de détail , où les changements de personnel sont fréquents.

Implémentez l'accès conditionnel Entra ID. Tirez parti des 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 corrigés et conformes aux politiques accèdent au réseau de l'entreprise.

Segmentez rigoureusement les réseaux d'entreprise et invités. Le protocole 802.1X est conçu pour les appareils d'entreprise gérés. Pour les visiteurs, les prestataires et le BYOD, implémentez une solution de Guest WiFi 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. N'autorisez jamais d'appareils non gérés sur le SSID 802.1X de l'entreprise.

Planifiez pour les appareils existants et IoT. Les imprimantes, les capteurs IoT et les appareils existants qui ne peuvent pas prendre en charge les certificats nécessitent une stratégie distincte. Utilisez le contournement d'authentification MAC (MAB) pour les appareils connus, ou un SSID WPA2-Personnel 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 permet d'éviter les pannes avant qu'elles n'impactent les opérations.

Dépannage et atténuation des risques

Même les déploiements les mieux 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 parviennent pas à recevoir les certificats d'Intune. Cela est généralement dû à 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 examinez les journaux de synchronisation des appareils. Assurez-vous que le compte de service SCEP dispose des autorisations nécessaires sur l'autorité de certification (CA).

Problèmes de délai d'attente RADIUS. Si le point d'accès ne peut pas joindre 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 d'adresses IP du fournisseur Cloud RADIUS. Si vous utilisez NPS sur site, déployez au minimum deux serveurs NPS et configurez vos points d'accès pour qu'ils basculent de l'un à l'autre en cas de défaillance. Échecs de confiance du certificat. Si les clients reçoivent une erreur "certificat de serveur non approuvé", le profil de l'autorité de certification racine de confiance n'a pas été déployé correctement sur l'appareil. Vérifiez l'attribution du profil dans Intune et contrôlez le magasin de certificats de l'appareil. Il s'agit d'un problème courant avec les appareils nouvellement enregistrés qui n'ont pas encore effectué 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 multifacteur 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 perturbante. Appuyez-vous plutôt sur l'authentification forte fournie par le certificat de l'appareil et imposez 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 ont la priorité en examinant les paramètres d'enregistrement 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 & Impact Commercial

La migration vers une architecture RADIUS cloud-native intégrée à Entra ID offre une valeur mesurable et quantifiable dans plusieurs dimensions.

Réduction des tickets de support. Les problèmes de WiFi liés aux mots de passe (verrouillages, mots de passe expirés, supplicants mal configurés) constituent une source importante de tickets de support informatique dans les environnements basés sur les identifiants. EAP-TLS élimine complètement ces désagréments. Les organisations constatent généralement une réduction de 30 à 50 % du volume de tickets d'assistance liés au WiFi après la migration vers l'authentification par certificat.

É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 aux correctifs 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 de fonctionnement.

Amélioration de la 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 déplacement latéral, protégeant ainsi les données d'entreprise sensibles. 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é qui gèrent des données de patients, cela soutient la conformité DSPT. Pour les opérateurs de Transport , cela s'aligne sur les exigences de la directive NIS2 en matière de sécurité réseau.

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 bénéfique dans les environnements à forte mobilité tels que les centres de distribution, les services hospitaliers et les points de vente. En traitant votre réseau WiFi comme une extension de votre stratégie d'identité cloud, vous garantissez un accès sécurisé et fluide qui évolue avec votre organisation. Pour obtenir des conseils supplémentaires sur les aspects d'intégration SD-WAN des réseaux d'entreprise modernes, consultez The Core SD-WAN Benefits for Modern Businesses . Pour les considérations de déploiement spécifiques au secteur de l'hôtellerie, reportez-vous à Modern Hospitality WiFi Solutions Your Guests Deserve .