Authentification WiFi d'entreprise sans Active Directory ni serveur sur site
Ce guide explique comment déployer une authentification WiFi WPA2/3-Enterprise sécurisée sans Active Directory sur site, sans Windows NPS ni serveur RADIUS. Il aborde l'incompatibilité de protocole entre les fournisseurs d'identité cloud et le protocole 802.1X, les arguments en faveur d'EAP-TLS par rapport à PEAP-MSCHAPv2, et comment déployer un serveur RADIUS cloud avec des certificats émis par MDM par rapport à Microsoft Entra ID, Okta ou Google Workspace. Écrit pour les responsables informatiques des organisations cloud-first et à forte utilisation de Mac/Chromebook prêtes à retirer leur infrastructure sur site.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
Synthèse décisionnelle
La plupart des entreprises ont migré leur gestion des identités 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 les e-mails, les applications SaaS et la gestion des appareils. Pourtant, le WiFi d'entreprise n'a pas suivi le rythme. Les points d'accès requièrent toujours un serveur RADIUS. Historiquement, ce serveur RADIUS était le plus souvent un serveur Windows Network Policy Server (NPS) relié à un contrôleur de domaine Active Directory local.
Ce décalage oblige les équipes informatiques à maintenir une infrastructure locale 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 ainsi que SAML avec votre fournisseur d'identité cloud. Associez cela au déploiement de certificats EAP-TLS via votre MDM, et vous obtenez un déploiement 802.1X complet - sans aucun serveur local, sans correctifs de système d'exploitation et avec une révocation immédiate des droits d'accès directement depuis votre annuaire cloud.
Purple opère Cloud-RADIUS sur plus de 80 000 sites à travers le monde avec une résilience de 99,999 % (données internes de Purple, 2024) et des intégrations natives pour Microsoft Entra ID, Okta et Google Workspace. En moins d'une heure, 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.
Analyse technique approfondie
L'incompatibilité des protocoles 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 datant des années 1990, conçu pour les accès par ligne commutée et les VPN. Microsoft n'a jamais fourni de point de terminaison RADIUS natif pour Entra ID. Vous ne pouvez pas diriger un point d'accès Meraki ou Aruba directement vers Azure et espérer que le 802.1X fonctionne.
C'est l'obstacle auquel se heurte toute équipe informatique adepte du cloud-first lorsqu'elle tente de sécuriser le WiFi des collaborateurs avec le WPA2-Enterprise ou le WPA3-Enterprise. Une passerelle est nécessaire entre le point d'accès et le fournisseur d'identité cloud. Cette passerelle, c'est Cloud-RADIUS.
Pourquoi PEAP-MSCHAPv2 échoue sans Active Directory
Par le passé, 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, l'Access Point transmettait la demande au serveur RADIUS, et le serveur RADIUS comparait le mot de passe avec un hachage NTLM stocké dans Active Directory.
Microsoft Entra ID ne stocke pas les hachages NTLM. Il ne s'agit pas d'une faille de configuration, mais d'une décision architecturale délibérée. 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 une demande PEAP-MSCHAPv2. La seule façon d'utiliser PEAP avec Entra ID consiste à déployer Entra Domain Services - un Active Directory géré et payant synchronisé avec Entra ID - et à y superposer NPS. Ce faisant, vous réintroduisez exactement ce que vous cherchiez à éliminer : des machines virtuelles Windows Server, des correctifs de système d'exploitation, le stockage de hachages NTLM et la gestion manuelle des certificats.
EAP-TLS : La bonne solution pour les entreprises axées sur le cloud
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 à l'aide d'une autorité de certification (CA) de confiance. Comme aucun mot de passe n'est transmis lors de cet échange, le serveur RADIUS n'a pas besoin de stocker de hachage NTLM. Il lui suffit de faire confiance à la CA et de vérifier l'appartenance de l'utilisateur à un groupe au sein du fournisseur d'identité pour appliquer le bon VLAN et la politique d'accès appropriée.
EAP-TLS est intrinsèquement résistant au phishing. Il n'y a aucun identifiant susceptible d'être volé. Il répond aux directives de la CISA en matière d'authentification multifacteur résistante au phishing et est conforme aux exigences PCI-DSS pour une authentification forte sur les réseaux traitant des données de titulaires de cartes. Il s'agit de la méthode d'authentification recommandée par l'IEEE 802.1X pour les flottes d'appareils gérés.
Architecture d'authentification 802.1X axée sur le cloud : les appareils s'authentifient en EAP-TLS via le RADIUS-as-a-Service cloud de Purple, qui valide les certificats et applique les politiques basées auf groupes d'Entra ID, Okta ou Google Workspace.
Comment le MDM remplace la CA locale
Dans un déploiement 802.1X traditionnel, les certificats étaient émis par une autorité de certification locale exécutant Active Directory Certificate Services (AD CS). Dans un déploiement cloud-first, le MDM assume ce rôle à l'aide de SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro et d'autres plateformes MDM peuvent demander des certificats auprès d'une autorité de certification hébergée dans le cloud et les déployer de manière transparente sur les appareils gérés.
Le flux de travail est le suivant : l'administrateur informatique crée un profil de certificat SCEP dans le MDM, ciblant les groupes d'appareils qui nécessitent un accès WiFi. Le MDM pousse automatiquement le certificat sur les appareils Windows, macOS, iOS, iPadOS, Android Enterprise et ChromeOS. L'utilisateur ne remarque 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 RADIUS cloud. Celui-ci le valide auprès de l'autorité de certification et applique la politique réseau correspondante.
Pour les entreprises utilisant Microsoft Intune, Microsoft Cloud PKI fournit une autorité de certification entièrement gérée qui s'intègre directement aux profils SCEP d'Intune. Cela élimine le besoin d'un serveur NDES (Network Device Enrollment Service) local. Pour les flottes de Mac et d'appareils iOS gérées par Jamf, l'autorité de certification intégrée de Jamf ou une autorité de certification cloud tierce remplit le même rôle.
SCIM et révocation instantanée des droits d'accès
L'un des aspects opérationnels les plus critiques de Cloud RADIUS est le provisionnement SCIM (System for Cross-domain Identity Management). SCIM est une norme ouverte qui pousse les modifications d'identité en temps réel depuis la source unique de vérité - votre fournisseur d'identité cloud - vers les systèmes dépendants. Lorsqu'un employé est désactivé dans Microsoft Entra ID ou Okta, SCIM transmet immédiatement ce changement au service Cloud RADIUS. Lors de la tentative d'authentification suivante de l'appareil, le serveur RADIUS renvoie un refus d'accès. Si un court délai d'expiration de session est configuré sur l'access point, l'appareil est déconnecté du réseau dans les minutes qui suivent la désactivation du compte.
Cela représente une amélioration significative de la sécurité par rapport aux réseaux utilisant des clés partagées PSK (où l'accès ne peut être révoqué qu'en modifiant le mot de passe sur tous les appareils) et par rapport aux déploiements RADIUS plus anciens qui reposent sur des synchronisations LDAP périodiques avec un délai de plusieurs heures ou jours.
RadSec : Sécurisation du trafic RADIUS sur Internet
Le RADIUS classique utilise UDP und n'offre qu'une authentification de message de base. Si votre serveur RADIUS se trouve dans le même centre de données que vos points d'accès, cela est acceptable. Cependant, si votre serveur RADIUS est un service Cloud, le trafic d'authentification passe par l'Internet public. RadSec (RADIUS over TLS, RFC 6614) chiffre les échanges RADIUS à l'aide de TLS, garantissant ainsi la confidentialité et l'intégrité du trafic d'authentification. Purple prend en charge RadSec de manière native, avec un repli IPsec pour les points d'accès qui ne prennent pas encore en charge RadSec.
-
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
Guide d'implémentation
Le déploiement de Cloud RADIUS avec EAP-TLS nécessite quatre étapes coordonnées. Un SSID pilote peut être mis en service 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 administrateur OAuth2 (pour Microsoft Entra ID) ou un jeton API (pour Okta et Google Workspace). Cela autorise Purple à lire les utilisateurs, les groupes et les appartenances aux groupes depuis le répertoire. Configurez le provisionnement SCIM pour transmettre les modifications d'état des utilisateurs en temps réel à Purple. Aucun identifiant de principal de service n'est stocké sur le disque. Les modifications de groupe prennent effet lors du prochain événement d'authentification, et non selon un calendrier de synchronisation fixe.
Étape 2 : Configurer le MDM et le profil SCEP
Dans Microsoft Intune, créez un profil de certificat approuvé pour l'autorité de certification racine (CA Root), puis un profil de certificat SCEP pointant vers la CA gérée par Purple. Ciblez ces deux profils sur les groupes d'appareils qui ont besoin d'un accès WiFi. Pour Jamf, configurez une charge utile SCEP dans un profil de configuration. Le MDM déploie les certificats de manière silencieuse. Vérifiez le déploiement des certificats dans le tableau de bord de conformité du MDM avant de continuer.
Étape 3 : Définir les règles réseau dans le tableau de bord Cloud RADIUS
Créez des règles RADIUS qui attribuent des groupes du fournisseur d'identité à des VLAN et des contrôles d'accès spécifiques. Par exemple, attribuez au groupe Microsoft Entra ID "Staff-Finance" le VLAN 20 avec un accès Internet complet, et au groupe "Staff-Contractors" le VLAN 30 mit un accès limité dans le temps qui expire automatiquement. Le tableau de bord de Purple applique ces règles directement lors du processus d'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 du 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 RADIUS Cloud primaires et secondaires de Purple ainsi que le secret partagé. Configurez les points d'accès pour qu'ils utilisent l'attribution dynamique de VLAN basée sur les attributs RADIUS renvoyés par Purple. Testez cette configuration avec un seul SSID sur une sélection de points d'accès avant de procéder au déploiement sur l'ensemble du site.
RADIUS Cloud vs. RADIUS local : Une comparaison directe en termes de temps de déploiement, de dépendance à Active Directory, de haute disponibilité, de correctifs de système d'exploitation, d'intégration d'identité et de 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 les plus de 80 000 sites de Purple.
Imposez le protocole EAP-TLS pour les appareils gérés. Les mots de passe sont vulnérables au phishing et au bourrage d'identifiants. Les certificats fournissent une preuve cryptographique d'identité et de conformité de l'appareil. Le protocole EAP-TLS est la seule méthode 802.1X intrinsèquement résistante au phishing.
Utilisez SCIM pour la révocation instantanée des accès. Les synchronisations LDAP périodiques laissent une fenêtre d'opportunité durant laquelle un ancien employé conserve l'accès au réseau. SCIM garantit que l'accès est révoqué à l'instant même où le compte est désactivé dans le fournisseur d'identité.
Déployez un système RADIUS multi-région. Configurez vos points d'accès avec au moins deux terminaux RADIUS situés dans des régions géographiques différentes. Purple offre par défaut un basculement actif-actif multi-région qui s'exécute en quelques secondes.
Segmentez le trafic avec des VLAN dynamiques. Utilisez les adhésions aux groupes du fournisseur d'identité pour attribuer dynamiquement les utilisateurs à des VLAN spécifiques. Cela permet d'isoler le trafic sensible et de limiter la portée d'un appareil compromis sans nécessiter de modifications manuelles du pare-feu.
Activez RadSec. Si vos points d'accès prennent en charge RadSec, activez-le afin de chiffrer le trafic d'authentification entre le point d'accès et le serveur RADIUS Cloud. Cela est particulièrement crucial pour les succursales et les sites où le point d'accès est situé sur un segment de réseau non sécurisé.
Surveillez 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 après 10 mois. Configurez des alertes pour les appareils dont le renouvellement échoue avant l'expiration du certificat.
Pour une analyse plus approfondie des normes et des frameworks de sécurité pour le WiFi d'entreprise, consultez notre guide Enterprise WiFi Security: A Complete Guide for 2026 .
-
Dépannage et atténuation des risques
La transition vers un Cloud RADIUS introduit de nouvelles dépendances. Préparez-vous à ces scénarios d'erreur courants avant qu'ils n'impactent la production.
Expiration des certificats. Si un certificat d'appareil expire avant que le MDM ne le renouvelle, l'authentification de l'appareil échoue de manière silencieuse. L'utilisateur voit un message d'erreur sans explication. Évitez cela en configurant le renouvellement automatique MDM à 80 % de la durée de vie du certificat et en surveillant le tableau de bord de conformité MDM pour identifier les appareils dont les certificats vont bientôt expirer.
Échecs de synchronisation MDM. Un appareil qui ne respecte plus les politiques de conformité MDM ou qui ne se connecte plus peut ne pas recevoir de certificat renouvelé. Implémentez des politiques de conformité qui signalent les appareils défectueux et alertent les administrateurs avant l'expiration du certificat.
Le pare-feu bloque le trafic RADIUS. Les points d'accès doivent pouvoir atteindre les points de terminaison Cloud RADIUS via le port UDP 1812 (authentification) et le port UDP 1813 (comptabilité), ou via le port TCP 2083 pour RadSec. Les règles de pare-feu sortantes dans les succursales bloquent souvent ces ports. Testez l'accessibilité depuis le VLAN de gestion du point 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 modifications de statut des utilisateurs ne sont pas transmises. Surveillez le statut de synchronisation SCIM à la fois dans le fournisseur d'identité et dans le tableau de bord Purple. Configurez des alertes pour les erreurs de synchronisation.
Systèmes hérités sans support de certificat. Les appareils IoT, les imprimantes et le matériel plus ancien peuvent ne pas prendre en charge EAP-TLS. Pour ces appareils, utilisez iPSK (clés pré-partagées individuelles) au lieu d'une clé PSK partagée. Purple prend en charge iPSK nativement, en attribuant à chaque appareil une clé unique et en plaçant chaque appareil dans le bon VLAN, sans nécessiter de support de supplicant 802.1X.
-
ROI et impact commercial
La migration d'un RADIUS local vers le Cloud RADIUS offre une valeur mesurable pour l'infrastructure, les opérations et la sécurité.
| Dimension | NPS local | Cloud RADIUS (Purple) |
|---|---|---|
| Coûts d'infrastructure | Licences Windows Server, puissance de calcul VM, stockage | Abonnement par point d'accès, aucun matériel serveur |
| Haute disponibilité | Manuelle – deux serveurs plus réplication | Multi-région active-active, par défaut |
| Correctifs du système d'exploitation | Mensuels, par votre équipe | Gérés par le fournisseur |
| Tickets d'assistance WiFi | Élevé – réinitialisations de mot de passe, intégration manuelle | Réduit de 80 % (données clients de Purple) |
| Révocation des accès | Des heures à des jours via la synchronisation LDAP | Quelques secondes via SCIM |
Les équipes informatiques qui utilisent le WiFi pour les employés de Purple constatent généralement une baisse de 80 % des tickets d'assistance WiFi (données internes de Purple, 2024), grâce à l'élimination des réinitialisations de mot de passe et de l'intégration manuelle des appareils. L'authentification basée sur les certificats répond également à l'exigence 8.3 de la norme PCI-DSS sur l'authentification forte et à la mesure A.9.4 de la norme ISO 27001 sur le contrôle des accès aux systèmes et aux applications, allégeant ainsi la charge d'audit pour votre équipe de sécurité.
Pour les entreprises des secteurs du commerce de détail et de l'hôtellerie , la possibilité de gérer le WiFi des employés et le WiFi invité via un tableau de bord cloud unique doté d'une couche d'identité unifiée réduit la complexité opérationnelle sur plusieurs sites. Pour les entreprises de transport et de santé , la révocation instantanée des accès et l'historique complet d'audit répondent aux exigences réglementaires sans outils supplémentaires.
La couche WiFi Analytics de Purple complète l'infrastructure d'authentification avec des données d'occupation et de travail hybride. Ainsi, le WiFi des employés passe d'un centre de coûts à une source d'informations opérationnelles.
Lecture recommandée : Enterprise WiFi Security: A Complete Guide for 2026 – OpenWrt Custom Firmware Integration with Purple WiFi
Définitions clés
802.1X
Une norme IEEE (IEEE 802.1X-2020) pour le contrôle d'accès réseau basé sur les ports. Elle exige que les appareils s'authentifient avant que le point d'accès n'accorde l'accès au réseau, en utilisant un échange EAP médié par un serveur RADIUS.
Les équipes IT utilisent 802.1X pour s'assurer que seuls les utilisateurs et appareils autorisés se connectent au réseau de l'entreprise. Il fournit un chiffrement par utilisateur, des clés par session et un historique d'audit complet de chaque événement de connexion.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Un protocole réseau qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA) pour l'accès au réseau.
Les points d'accès transmettent chaque demande de connexion au serveur RADIUS, qui décide d'autoriser l'appareil et de lui attribuer un VLAN. Le RADIUS-as-a-Service cloud remplace les serveurs NPS ou FreeRADIUS sur site.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Une méthode d'authentification 802.1X qui utilise un échange mutuel de certificats X.509 à la place des mots de passe.
EAP-TLS est la référence absolue pour les parcs d'appareils gérés. Il résiste au phishing, ne nécessite aucun stockage de hachage de mot de passe et est la seule méthode 802.1X conforme aux directives MFA de la CISA sur la résistance au phishing.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol avec Microsoft Challenge Handshake Authentication Protocol version 2. Une méthode 802.1X héritée qui valide les mots de passe par rapport aux hachages NTLM stockés dans l'Active Directory.
PEAP-MSCHAPv2 échoue dans les environnements cloud uniquement car Microsoft Entra ID ne stocke pas les hachages NTLM. Les organisations qui migrent depuis un AD sur site doivent remplacer PEAP par EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Un protocole utilisé par les plateformes MDM pour demander et installer automatiquement des certificats numériques sur les appareils, sans interaction de l'utilisateur.
Les équipes IT utilisent SCEP avec Intune ou Jamf pour déployer silencieusement des certificats WiFi sur les appareils des employés. SCEP remplace le serveur NDES (Network Device Enrollment Service) sur site dans les déploiements cloud-first.
SCIM
System for Cross-domain Identity Management (RFC 7644). Un standard ouvert qui automatise l'échange en temps réel d'informations d'identité utilisateur entre les systèmes informatiques.
Le protocole SCIM garantit que lorsqu'un employé est désactivé dans Microsoft Entra ID ou Okta, ce changement est immédiatement transmis au service RADIUS cloud, révoquant l'accès WiFi en quelques secondes plutôt qu'en plusieurs heures.
NPS
Network Policy Server. L'implémentation RADIUS de Microsoft, généralement exécutée sur Windows Server dans le cadre d'un environnement Active Directory sur site.
Les organisations cloud-first abandonnent NPS pour éliminer les VM Windows Server, les correctifs d'OS et la dépendance à l'Active Directory sur site. Le RADIUS cloud est son remplaçant direct.
RadSec
RADIUS sur TLS (RFC 6614). Un protocole qui chiffre le trafic d'authentification RADIUS à l'aide de TLS, remplaçant le transport en texte clair basé sur UDP utilisé par le RADIUS traditionnel.
Le protocole RadSec est essentiel lors de l'utilisation d'un RADIUS cloud, car le trafic d'authentification doit traverser l'internet public entre le point d'accès et le service cloud. Purple prend en charge RadSec nativement.
iPSK
Individual Pre-Shared Key. Une variante de WPA2-Personal qui attribue une clé pré-partagée unique à chaque appareil, plutôt qu'une clé partagée unique pour tous les appareils.
La technologie iPSK est utilisée pour les appareils IoT, les imprimantes et d'autres matériels ne prenant pas en charge EAP-TLS de la norme 802.1X. Elle offre une traçabilité par appareil et une affectation VLAN sans nécessiter de prise en charge des certificats.
VLAN dynamique
Une technique de segmentation réseau où le serveur RADIUS renvoie un identifiant de VLAN dans la réponse Access-Accept, et le point d'accès place automatiquement l'appareil sur ce VLAN.
Les VLAN dynamiques permettent aux équipes IT de segmenter le personnel, les prestataires, les appareils IoT et les invités sur des segments réseau distincts en fonction de leur appartenance à un groupe de fournisseurs d'identité, sans modification manuelle du pare-feu.
Exemples concrets
Une chaîne de vente au détail de 400 sites doit sécuriser le WiFi du personnel sur l'ensemble de ses sites. Elle utilise des points d'accès Cisco Meraki et exploite Microsoft Entra ID avec Intune pour la gestion des appareils. Elle utilise actuellement un PSK WPA2-Personal partagé car elle ne dispose pas d'Active Directory sur site pour exécuter NPS. Un audit interne récent a signalé ce PSK partagé comme un écart de conformité PCI-DSS.
La chaîne déploie le RADIUS cloud de Purple. Tout d'abord, elle connecte Purple à Entra ID via le consentement administrateur OAuth et configure le provisionnement SCIM. Dans Intune, elle crée un profil de certificat de confiance pour la racine de l'autorité de certification (CA) Purple et un profil de certificat SCEP étendu au groupe d'appareils 'Staff-Retail'. Intune pousse silencieusement les certificats vers tous les terminaux de point de vente et tablettes du personnel gérés. Dans le tableau de bord Meraki, elle met à jour le SSID du personnel en WPA2-Enterprise, saisit les points de terminaison principal et secondaire du RADIUS cloud de Purple, et active l'attribution dynamique de VLAN. Lorsqu'un appareil se connecte, il présente son certificat émis par Intune, Purple le valide par rapport à la CA et vérifie le groupe Entra ID, puis l'appareil est placé sur le VLAN 10 (réseau du personnel) ou le VLAN 20 (réseau de gestion) en fonction de l'appartenance au groupe. Le PSK partagé est retiré. Le déploiement sur les 400 sites prend un seul week-end, car aucun matériel sur site n'est déployé - seules des modifications de configuration SSID dans Meraki sont requises.
Une université de 15 000 étudiants utilise Google Workspace comme principal fournisseur d'identité. L'équipe informatique souhaite fournir un WiFi sécurisé pour le personnel et les étudiants sur un parc d'appareils personnels (BYOD) composé de MacBooks, Chromebooks et téléphones Android. Elle ne dispose pas d'Active Directory sur site et ne souhaite pas gérer de serveurs.
L'université intègre le RADIUS cloud de Purple à Google Workspace. Pour les Chromebooks gérés, elle utilise Google Admin pour pousser un profil de certificat WiFi via SCEP, inscrivant silencieusement chaque appareil. Pour les MacBooks et téléphones Android personnels (BYOD), elle déploie une application d'intégration légère qui authentifie l'utilisateur avec ses identifiants Google et installe un certificat sur l'appareil en un seul clic. Les connexions suivantes utilisent EAP-TLS de manière transparente. Purple associe les unités d'organisation de Google Workspace à des VLAN : le personnel se connecte au VLAN 10, les étudiants au VLAN 20 et les visiteurs invités sur un SSID avec Captive Portal. Lorsqu'un étudiant obtient son diplôme et que son compte Google est suspendu, SCIM pousse la modification vers Purple et son accès WiFi est révoqué en quelques minutes.
Questions d'entraînement
Q1. Votre organisation a entièrement migré de son Active Directory local vers Microsoft Entra ID. Votre WiFi personnel actuel utilise PEAP-MSCHAPv2 avec un serveur NPS qui était joint à l'ancien domaine. Après le démantèlement du contrôleur de domaine, le personnel signale qu'il ne peut plus se connecter au WiFi. Quelle est la cause première et quelle est la solution correcte à long terme ?
Conseil : Réfléchissez à ce que PEAP-MSCHAPv2 requiert de la part de l'annuaire, et si Microsoft Entra ID le fournit.
Voir la réponse type
La cause première est que PEAP-MSCHAPv2 exige que le serveur RADIUS valide le mot de passe de l'utilisateur par rapport à un hachage NTLM stocké dans Active Directory. Le contrôleur de domaine étant démantelé, NPS n'a plus d'annuaire par rapport auquel valider. Entra ID ne stocke pas les hachages NTLM, NPS ne peut donc pas être redirigé vers Entra ID. La bonne solution à long terme consiste à remplacer NPS par un service cloud RADIUS, à migrer de PEAP-MSCHAPv2 vers EAP-TLS et à utiliser le MDM (Intune) pour émettre des certificats d'appareil via SCEP. Cela élimine toute dépendance vis-à-vis d'un annuaire local.
Q2. Vous déployez cloud RADIUS pour une flotte de 200 terminaux MacBooks d'entreprise gérés par Jamf Pro. Votre fournisseur d'identité est Okta. Quelle est la méthode la plus sécurisée et la plus efficace sur le plan opérationnel pour attribuer les identifiants WiFi à ces appareils ?
Conseil : Recherchez une méthode qui ne nécessite aucune interaction de l'utilisateur, évite les mots de passe et s'intègre à votre MDM existant.
Voir la réponse type
Configurez Jamf Pro pour utiliser SCEP afin de pousser silencieusement les certificats d'appareil vers les MacBooks. Créez une charge utile SCEP dans un profil de configuration Jamf, pointant vers l'autorité de certification gérée par votre fournisseur cloud RADIUS. Ciblez le profil sur le groupe d'appareils concerné. Jamf déploiera le certificat sur chaque MacBook automatiquement, sans aucune interaction de l'utilisateur. Configurez le profil WiFi dans le même profil de configuration pour utiliser EAP-TLS avec le certificat émis par SCEP. Connectez le service cloud RADIUS à Okta via SCIM pour vous assurer que lorsqu'un employé est désactivé dans Okta, son accès WiFi soit révoqué immédiatement.
Q3. Un employé est licencié à 9h00 un lundi. Son compte Microsoft Entra ID est désactivé par les RH à 9h05. À 9h30, une alerte de sécurité indique que l'ordinateur portable de l'employé est toujours connecté au WiFi de l'entreprise depuis le parking. Quelle configuration manque-t-il, et comment y remédier ?
Conseil : Comment le serveur RADIUS apprend-il que le statut de l'utilisateur a changé chez le fournisseur d'identité ?
Voir la réponse type
Le déploiement repose sur des synchronisations LDAP périodiques plutôt que sur le provisionnement SCIM. La synchronisation LDAP n'a pas encore été exécutée depuis que le compte a été désactivé, le service cloud RADIUS considère donc toujours l'utilisateur comme actif. La solution consiste à activer le provisionnement SCIM entre Microsoft Entra ID et le service cloud RADIUS. SCIM pousse les changements d'état des utilisateurs en temps réel, de sorte que lorsque le compte est désactivé dans Microsoft Entra ID à 9h05, le service RADIUS reçoit le changement immédiatement. La prochaine fois que l'appareil tente de se réauthentifier (ce qui est contrôlé par le délai d'expiration de la session sur le point d'accès), il reçoit un Access-Reject. Définir un délai d'expiration de session court (15 à 30 minutes) sur le point d'accès limite la fenêtre maximale entre la désactivation du compte et l'exclusion du réseau.
Q4. Votre site dispose de 50 appareils IoT - lecteurs d'affichage dynamique, capteurs environnementaux et imprimantes - qui ne prennent pas en charge 802.1X EAP-TLS. Comment sécurisez-vous ces appareils sur la même infrastructure WiFi que le réseau de votre personnel en EAP-TLS ?
Conseil : Déterminez quelle méthode d'authentification offre une traçabilité par appareil sans nécessiter de prise en charge des certificats.
Voir la réponse type
Utilisez iPSK (clés pré-partagées individuelles) pour les appareils IoT. Attribuez une clé pré-partagée unique à chaque appareil dans le tableau de bord cloud RADIUS, ainsi qu'une attribution de VLAN. Chaque appareil s'authentifie avec sa clé unique, que le serveur RADIUS valide et utilise pour placer l'appareil sur le VLAN IoT, isolé du réseau du personnel. Si un appareil est compromis ou mis hors service, vous révoquez uniquement la clé de cet appareil sans affecter les autres. Cette approche offre une traçabilité par appareil et une segmentation du réseau sans nécessiter de support de suppliant 802.1X sur le matériel IoT.
Continuer la lecture de cette série
Comment révoquer l'accès WiFi lorsqu'un employé s'en va
Ce guide montre aux équipes informatiques et opérationnelles comment supprimer l'accès WiFi du personnel lorsqu'un employé s'en va, sans perturber le reste des collaborateurs. Il compare le protocole 802.1X basé sur des certificats, l'iPSK spécifique à l'identité et le déprovisionnement via SCIM, puis fournit un plan d'action pour le jour même, une méthode de test et un modèle de preuves d'audit.
WiFi BYOD sécurisé : intégration de certificats Passpoint vs xPSK (iPSK)
Un guide technique complet pour les équipes informatiques sur la sécurisation des appareils non gérés des employés et des étudiants (BYOD) à l'aide de certificats Passpoint EAP-TLS sans intervention vs les solutions xPSK spécifiques aux constructeurs (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise : quelle est la différence et lequel devriez-vous utiliser ?
Ce guide de référence technique propose une comparaison complète des protocoles de sécurité WPA2 Personal et WPA2 Enterprise au sein des environnements WiFi d'entreprise. Il détaille les différences d'architecture, les méthodologies de déploiement et les implications en matière de sécurité de chaque norme afin d'aider les architectes réseau et les responsables informatiques à prendre des décisions de déploiement éclairées.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.