Authentification WiFi d'entreprise sans Active Directory ni serveur sur site

Résumé exécutif

La plupart des organisations ont migré leur identité vers le cloud. Microsoft Entra ID, Okta et Google Workspace gèrent désormais les utilisateurs, les groupes et les politiques d'accès pour la messagerie, les applications SaaS et la gestion des appareils. Pourtant, le WiFi d'entreprise n'a pas suivi le rythme. Les points d'accès attendent toujours un serveur RADIUS, et ce serveur RADIUS a historiquement été Windows Network Policy Server (NPS) connecté à un contrôleur de domaine Active Directory sur site.

Cette incompatibilité oblige les équipes informatiques à maintenir une infrastructure sur site redondante uniquement pour faire fonctionner le WiFi. La solution est le cloud RADIUS : un service d'authentification entièrement géré qui communique en RADIUS avec vos points d'accès et en OAuth2, SCIM et SAML avec votre fournisseur d'identité cloud. Associez-le à la distribution de certificats EAP-TLS via votre MDM, et vous obtenez un déploiement 802.1X complet sans serveurs sur site, sans correctifs de système d'exploitation et avec une révocation instantanée des accès directement liée à votre annuaire cloud.

Purple exploite le cloud RADIUS sur plus de 80 000 sites dans le monde, avec une disponibilité de 99,999 % (données internes Purple, 2024) et des intégrations natives avec Microsoft Entra ID, Okta et Google Workspace. Vous pouvez être opérationnel sur vos points d'accès existants Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet en moins d'une heure.

Analyse technique approfondie

L'incompatibilité de protocole au cœur du problème

Le défi fondamental réside dans le fait que les fournisseurs d'identité cloud et les points d'accès WiFi parlent des langages totalement différents. Microsoft Entra ID (anciennement Azure AD) authentifie les utilisateurs via SAML, OIDC et OAuth2 - les protocoles utilisés par les navigateurs et les applications SaaS. Les points d'accès WiFi utilisent RADIUS (Remote Authentication Dial-In User Service, RFC 2865), un protocole basé sur UDP conçu dans les années 1990 pour le bas débit et les VPN. Microsoft n'a jamais fourni de point de terminaison RADIUS natif pour Entra ID. Vous ne pouvez pas pointer un point d'accès Meraki ou Aruba directement vers Azure et espérer que le 802.1X fonctionne.

C'est le mur auquel se heurte chaque équipe informatique cloud-first lorsqu'elle tente de sécuriser le WiFi du personnel avec WPA2-Enterprise ou WPA3-Enterprise. Quelque chose doit combler le fossé entre le point d'accès et le fournisseur d'identité cloud. Ce quelque chose, c'est le cloud RADIUS.

Pourquoi PEAP-MSCHAPv2 échoue sans Active Directory

Historiquement, les déploiements 802.1X reposaient sur PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol avec Microsoft Challenge Handshake Authentication Protocol version 2). L'utilisateur saisissait son nom d'utilisateur et son mot de passe, le point d'accès transmettait la demande au serveur RADIUS, et le serveur RADIUS validait le mot de passe par rapport à un hachage NTLM stocké dans Active Directory.

Microsoft Entra ID ne stocke pas les hachages NTLM. Il ne s'agit pas d'un défaut de configuration, mais d'un choix architectural délibéré. Entra ID est un fournisseur d'identité cloud moderne, et non un contrôleur de domaine. Par conséquent, un serveur RADIUS pointant vers Entra ID ne peut pas valider un défi PEAP-MSCHAPv2. La seule façon de faire fonctionner PEAP avec Entra ID est de déployer Entra Domain Services, un Active Directory géré et payant qui se synchronise à partir d'Entra ID, puis d'exécuter NPS sur celui-ci. Cela réintroduit la majeure partie de ce que vous essayiez d'éliminer : les machines virtuelles Windows Server, les correctifs du système d'exploitation, le stockage des hachages NTLM et la gestion manuelle des certificats.

EAP-TLS : la bonne réponse pour les organisations cloud-first

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) remplace les mots de passe par des certificats numériques X.509. L'appareil présente un certificat au serveur RADIUS. Le serveur RADIUS valide le certificat par rapport à une autorité de certification (CA) de confiance. Comme il n'y a pas de mot de passe dans l'échange, le serveur RADIUS n'a pas besoin d'un stockage de hachages NTLM. Il lui suffit de faire confiance à la CA et de vérifier l'appartenance de l'utilisateur à un groupe dans le fournisseur d'identité pour appliquer le bon VLAN et la bonne politique d'accès.

EAP-TLS est résistant au phishing par conception. Il n'y a aucun identifiant à voler. Il répond aux directives de la CISA sur l'authentification multifacteur résistante au phishing et s'aligne sur les exigences du PCI DSS pour une authentification forte sur les réseaux qui traitent les données des titulaires de cartes. C'est la méthode d'authentification recommandée par la norme IEEE 802.1X pour les flottes d'appareils gérés.

Architecture d'authentification 802.1X cloud-first : les appareils s'authentifient via EAP-TLS via le cloud RADIUS de Purple, qui valide les certificats et applique la politique basée sur les groupes depuis Entra ID, Okta ou Google Workspace.

Comment le MDM remplace la CA sur site

Dans un déploiement 802.1X traditionnel, les certificats étaient émis par une autorité de certification sur site exécutant Active Directory Certificate Services (AD CS). Dans un déploiement cloud-first, le MDM assume ce rôle en utilisant SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro et d'autres plateformes MDM peuvent demander des certificats à une CA hébergée dans le cloud et les déployer de manière invisible sur les appareils gérés.

Le flux fonctionne comme suit. L'administrateur informatique crée un profil de certificat SCEP dans le MDM, ciblé sur les groupes d'appareils qui nécessitent un accès WiFi. Le MDM déploie automatiquement le certificat sur les appareils Windows, macOS, iOS, iPadOS, Android Enterprise et ChromeOS. L'utilisateur ne voit rien. Le certificat est lié à l'identité de l'appareil dans le MDM et se renouvelle automatiquement avant son expiration. Lorsque l'appareil se connecte au WiFi, il présente le certificat au serveur cloud RADIUS, qui le valide par rapport à la CA et applique la bonne politique réseau.

Pour les organisations utilisant Microsoft Intune, Microsoft Cloud PKI fournit une CA entièrement gérée qui s'intègre directement aux profils SCEP d'Intune, éliminant ainsi le besoin d'un serveur NDES (Network Device Enrollment Service) sur site. Pour les flottes Mac et iOS gérées par Jamf, la CA intégrée de Jamf ou une CA cloud tierce remplit la même fonction.

SCIM et révocation d'accès instantanée

L'un des aspects opérationnels les plus importants de cloud RADIUS est le provisionnement SCIM (System for Cross-domain Identity Management). SCIM est un standard ouvert qui pousse les modifications d'identité depuis la source de vérité - votre fournisseur d'identité cloud - vers les systèmes dépendants en temps réel. Lorsqu'un employé est désactivé dans Entra ID ou Okta, SCIM pousse immédiatement cette modification vers le service cloud RADIUS. Lors de la tentative d'authentification suivante de l'appareil, le serveur RADIUS renvoie un Access-Reject. Avec un délai d'expiration de session court configuré sur le point d'accès, l'appareil est retiré du réseau quelques minutes seulement après la désactivation du compte.

Il s'agit d'une amélioration matérielle de la sécurité par rapport aux réseaux PSK partagés, où le seul moyen de révoquer l'accès est de modifier le mot de passe sur chaque appareil, et par rapport aux déploiements RADIUS hérités qui reposent sur des synchronisations LDAP périodiques avec un délai de plusieurs heures ou jours.

RadSec : sécuriser le trafic RADIUS sur Internet

Le RADIUS traditionnel utilise UDP et ne fournit qu'une authentification de message de base. Lorsque votre serveur RADIUS se trouve dans le même centre de données que vos points d'accès, cela est acceptable. Lorsque votre serveur RADIUS est un service cloud, le trafic d'authentification traverse l'Internet public. RadSec (RADIUS sur TLS, RFC 6614) chiffre l'échange RADIUS à l'aide de TLS, garantissant la confidentialité et l'intégrité du trafic d'authentification. Purple prend en charge RadSec nativement, avec un repli IPsec pour les points d'accès qui ne prennent pas encore en charge RadSec.

Guide d'implémentation

Le déploiement de cloud RADIUS avec EAP-TLS nécessite quatre étapes coordonnées. Un SSID pilote peut être opérationnel en moins d'une heure si Entra ID et un MDM sont déjà en place.

Étape 1 : Connecter le cloud RADIUS à votre fournisseur d'identité

Connectez Purple à votre fournisseur d'identité via le consentement de l'administrateur OAuth2 (pour Entra ID) ou un jeton d'API (pour Okta et Google Workspace). Cela autorise Purple à lire les utilisateurs, les groupes et les appartenances aux groupes à partir de l'annuaire. Configurez le provisionnement SCIM pour pousser les changements d'état des utilisateurs vers Purple en temps réel. Aucun identifiant de principal de service n'est stocké sur le disque. Les modifications de groupe se propagent lors du prochain événement d'authentification, et non selon un calendrier de synchronisation.

Étape 2 : Configurer votre MDM et votre profil SCEP

Dans Microsoft Intune, créez un profil de certificat approuvé pour la racine de la CA, puis créez un profil de certificat SCEP pointant vers la CA gérée par Purple. Ciblez ces deux profils vers les groupes d'appareils qui nécessitent un accès WiFi. Pour Jamf, configurez une charge utile SCEP dans un profil de configuration. Le MDM pousse les certificats de manière silencieuse. Vérifiez la distribution des certificats dans le tableau de bord de conformité du MDM avant de continuer.

Étape 3 : Définir les politiques réseau dans le tableau de bord RADIUS cloud

Créez des politiques RADIUS qui associent les groupes de fournisseurs d'identité à des VLAN spécifiques et à des contrôles d'accès. Par exemple, associez le groupe Entra ID « Staff-Finance » au VLAN 20 avec un accès complet à Internet, et associez « Staff-Contractors » au VLAN 30 avec un accès limité dans le temps qui expire automatiquement. Le tableau de bord de Purple applique ces politiques au moment de l'authentification, sans qu'aucune modification du pare-feu ne soit nécessaire.

Étape 4 : Mettre à jour la configuration des points d'accès

Mettez à jour la configuration de l'SSID sur vos points d'accès pour utiliser WPA2-Enterprise ou WPA3-Enterprise avec 802.1X. Saisissez les noms d'hôte ou les adresses IP des terminaux principaux et secondaires du cloud RADIUS de Purple, ainsi que le secret partagé. Configurez les points d'accès pour utiliser l'attribution dynamique de VLAN basée sur les attributres RADIUS renvoyés par Purple. Testez avec un seul SSID sur un sous-ensemble de points d'accès avant de déployer sur l'ensemble du parc.

Cloud RADIUS vs RADIUS sur site : une comparaison directe du temps de déploiement, de la dépendance à Active Directory, de la haute disponibilité, des correctifs du système d'exploitation, de l'intégration de l'identité et de la gestion du cycle de vie des certificats.

Bonnes pratiques

Ces recommandations reflètent les normes IEEE 802.1X, les exigences PCI DSS v4.0 et l'expérience opérationnelle acquise sur le parc de plus de 80 000 sites de Purple.

Imposer l'EAP-TLS pour les appareils gérés. Les mots de passe sont sensibles au phishing et au credential stuffing. Les certificats fournissent une preuve cryptographique de l'identité et de la conformité de l'appareil. L'EAP-TLS est la seule méthode 802.1X résistante au phishing par conception.

Utiliser SCIM pour une révocation instantanée. Les synchronisations LDAP périodiques laissent une fenêtre durant laquelle un employé licencié conserve l'accès au réseau. SCIM garantit que l'accès est révoqué dès que le compte est désactivé chez le fournisseur d'identité.

Déployer un RADIUS multi-région. Configurez vos points d'accès avec au moins deux terminaux RADIUS dans des régions géographiques différentes. Purple fournit par défaut un basculement multi-région actif-actif, le basculement s'effectuant en quelques secondes.

Segmenter le trafic avec des VLAN dynamiques. Utilisez les appartenances aux groupes de fournisseurs d'identité pour attribuer dynamiquement les utilisateurs à des VLAN spécifiques. Cela isole le trafic sensible et limite la surface d'impact d'un appareil compromis sans nécessiter de modifications manuelles du pare-feu.

Activer RadSec. Si vos points d'accès prennent en charge RadSec, activez-le pour chiffrer le trafic d'authentification entre le point d'accès et le serveur RADIUS cloud. Ceci est particulièrement important pour les succursales et les sites où le point d'accès se trouve sur un segment de réseau non sécurisé.

Surveiller le cycle de vie des certificats. Configurez le renouvellement automatique MDM pour qu'il se déclenche à 80 % de la durée de vie du certificat. Pour un certificat d'un an, le renouvellement commence au bout de 10 mois. Alertez sur les appareils qui ne parviennent pas à se renouveler avant l'expiration du certificat. Pour un aperçu plus large des normes et frameworks de sécurité WiFi d'entreprise, consultez notre Sécurité WiFi d'entreprise : Le guide complet pour 2026 .

Résolution des problèmes et atténuation des risques

La transition vers un RADIUS cloud introduit de nouvelles dépendances. Préparez-vous à ces modes de défaillance courants avant qu'ils n'affectent la production.

Expiration des certificats. Si le certificat d'un appareil expire avant que le MDM ne le renouvelle, l'authentification de l'appareil échoue silencieusement. L'utilisateur voit une erreur de connexion sans explication. Atténuez ce risque en configurant le renouvellement automatique du MDM à 80 % de la durée de vie du certificat et en surveillant le tableau de bord de conformité du MDM pour repérer les appareils dont les certificats expirent.

Échecs de synchronisation MDM. Un appareil qui n'est plus conforme au MDM ou qui ne parvient pas à s'y connecter peut ne pas recevoir de certificat renouvelé. Mettez en œuvre des politiques de conformité qui signalent les appareils défectueux et alertent les administrateurs avant l'expiration du certificat.

Blocage du trafic RADIUS par le pare-feu. Les points d'accès doivent pouvoir atteindre les points de terminaison RADIUS cloud sur le port UDP 1812 (authentification) et le port UDP 1813 (comptabilité), ou le port TCP 2083 pour RadSec. Les règles de pare-feu sortantes des succursales bloquent fréquemment ces ports. Testez la connectivité depuis le VLAN de gestion des points d'accès avant le déploiement.

Échecs de provisionnement SCIM. Si la connexion SCIM entre le fournisseur d'identité et Purple est interrompue, les changements d'état des utilisateurs ne seront pas propagés. Surveillez l'état de la synchronisation SCIM à la fois dans le fournisseur d'identité et dans le tableau de bord Purple. Configurez des alertes pour les échecs de synchronisation.

Appareils existants sans prise en charge des certificats. Les appareils IoT, les imprimantes et le matériel plus ancien peuvent ne pas prendre en charge l'EAP-TLS. Pour ces appareils, utilisez l'iPSK (clés pré-partagées individuelles) plutôt qu'une clé PSK partagée. Purple prend en charge l'iPSK de manière native, en attribuant une clé unique par appareil et en plaçant chaque appareil sur le bon VLAN sans nécessiter de support de suppliant 802.1X.

ROI et impact commercial

La migration d'un RADIUS sur site vers un RADIUS cloud offre une valeur mesurable en termes d'infrastructure, d'opérations et de sécurité.

Les équipes informatiques qui utilisent le Staff WiFi de Purple constatent généralement une baisse de 80 % des tickets de support WiFi (données internes Purple, 2024), grâce à l'élimination des réinitialisations de mots de passe et de l'intégration manuelle des appareils. L'authentification par certificat répond également à l'exigence PCI DSS 8.3 pour l'authentification forte et au contrôle ISO 27001 A.9.4 pour le contrôle d'accès aux systèmes et applications, allégeant ainsi la charge d'audit de votre équipe de sécurité.

Pour les organisations du commerce de détail et de l' hôtellerie , la possibilité de gérer le Staff WiFi et le Guest WiFi depuis un tableau de bord cloud unique - avec une couche d'identité unifiée - réduit la complexité opérationnelle sur les parcs multi-sites. Pour les opérateurs de transport et les prestataires de santé , la capacité de révocation instantanée et la piste d'audit complète répondent aux exigences réglementaires sans outils supplémentaires.

La couche WiFi Analytics de Purple ajoute des données d'occupation et de travail hybride à l'infrastructure d'authentification, transformant le Staff WiFi d'un centre de coûts en une source d'intelligence opérationnelle.

Lecture associée : Sécurité WiFi d'entreprise : Le guide complet pour 2026 - Intégration du micrologiciel personnalisé OpenWrt avec Purple WiFi