Enterprise WiFi authentication without Active Directory or an on-prem server
Ce guide explique comment déployer une authentification WiFi WPA2/3-Enterprise sécurisée sans Active Directory sur site, Windows NPS ou serveur RADIUS. Il aborde l'incompatibilité de protocole entre les fournisseurs d'identité cloud et 802.1X, les arguments en faveur d'EAP-TLS par rapport à PEAP-MSCHAPv2, et comment déployer un 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 composante Mac/Chromebook prêtes à abandonner leur infrastructure sur site.
Écouter ce guide
Voir la transcription du podcast
📚 Part of our core series: Sécurité et authentification WiFi d'entreprise : le guide complet →
Synthèse
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. Mais 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 assurer le fonctionnement du WiFi. La solution est le RADIUS cloud : 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 RADIUS cloud dans plus de 80 000 sites à travers le monde, avec une disponibilité de 99,999 % (données internes de 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 les connexions d'accès à distance 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 RADIUS cloud.
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'une lacune de configuration, mais d'une décision architecturale délibérée. Entra ID est un fournisseur d'identité cloud moderne, pas un contrôleur de domaine. Par conséquent, un serveur RADIUS pointé 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é payant qui se synchronise à partir d'Entra ID, puis d'exécuter NPS par rapport à celui-ci. Cela réintroduit la majeure partie de ce que vous cherchiez à éliminer : les machines virtuelles Windows Server, les correctifs de 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
L'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 chez le fournisseur d'identité pour appliquer le bon VLAN et la bonne politique d'accès.
L'EAP-TLS est résistant au phishing par conception. Il n'y a pas d'identifiant à voler. Il répond aux directives de la CISA sur l'authentification multifacteur résistante au phishing et s'aligne sur les exigences de la norme 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 l'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 RADIUS cloud de Purple, qui valide les certificats et applique une 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 reprend 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 pousser silencieusement vers 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 pousse automatiquement le certificat vers 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 RADIUS cloud, 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 Jamfats, l'AC intégrée de Jamf ou une AC cloud tierce répond au même objectif.
SCIM et révocation instantanée des accès
L'un des aspects les plus importants sur le plan opérationnel du RADIUS cloud 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 RADIUS cloud. La prochaine fois que l'appareil tente de s'authentifier, le serveur RADIUS renvoie un message Access-Reject. Avec un court délai d'expiration de session configuré sur le point d'accès, l'appareil est exclu 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 changer 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 supportent pas encore RadSec.
Guide d'implémentation
Le déploiement du RADIUS cloud 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 RADIUS cloud à votre fournisseur d'identité
Connectez Purple à votre fournisseur d'identité via le consentement administrateur OAuth2 (pour Entra ID) ou un jeton 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 de l'événement d'authentification suivant, 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 l'AC, puis créez un profil de certificat SCEP pointant vers l'AC gérée par Purple. Ciblez ces deux profils sur 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 du fournisseur 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 Internet complet, 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 requise.
Étape 4 : Mettre à jour la configuration des points d'accès
Mettez à jour la configuration 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 points de terminaison principal et secondaire du RADIUS cloud de Purple, ainsi que le secret partagé. Configurez les points d'accès pour utiliser l'attribution dynamique de VLAN basée sur les attributs 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.
RADIUS cloud 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.
Exigez l'EAP-TLS pour les appareils gérés. Les mots de passe sont sensibles au phishing et au credential stuffing (bourrage d'identifiants). 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 conçue pour résister nativement au phishing.
Utilisez 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éployez un RADIUS multi-région. Configurez vos points d'accès avec au moins deux points de terminaison 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.
Segmentez le trafic avec des VLAN dynamiques. Utilisez les appartenances aux groupes du fournisseur d'identité pour attribuer dynamiquement les utilisateurs à des VLAN spécifiques. Cela isole le trafic sensible et limite la zone d'impact 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 pour chiffrer le trafic d'authentification entre le point d'accès et le serveur RADIUS cloud. Cela 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é.
Surveillez le cycle de vie des certificats. Configurez le renouvellement automatique du 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. Configurez des alertes pour les appareils qui ne parviennent pas à se renouveler avant l'expiration du certificat.
Pour une analyse plus large des normes et frameworks de sécurité WiFi d'entreprise, consultez notre guide Sécurité WiFi d'entreprise : le guide complet pour 2026 .
Dépannage et atténuation des risques
La transition vers le RADIUS cloud introduit de nouvelles dépendances. Préparez-vous à ces modes de défaillance courants avant qu'ils n'affectent la production.
Certificat. 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. Limitez 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 le certificat arrive à expiration.
Échecs de synchronisation MDM. Un appareil qui n'est plus conforme au MDM ou qui ne parvient pas à se connecter peut ne pas recevoir de certificat renouvelé. Implémentez des politiques de conformité qui signalent les appareils défaillants 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 l'accessibilité 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 modifications de l'état de l'utilisateur ne seront pas propagées. 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 les matériels plus anciens peuvent ne pas prendre en charge EAP-TLS. Pour ces appareils, utilisez des clés iPSK (clés individuelles pré-partagées) 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é.
| Dimension | NPS sur site | Cloud RADIUS (Purple) |
|---|---|---|
| Coût de l'infrastructure | Licences Windows Server, calcul VM, stockage | Abonnement par point d'accès, aucun matériel serveur |
| Temps de déploiement | De quelques jours à quelques semaines | Moins d'une heure |
| Haute disponibilité | Manuelle - deux serveurs plus réplication | Actif-actif multi-région, 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 mots de passe, intégration manuelle | En baisse de 80 % (données clients Purple) |
| Révocation des accès | De quelques heures à quelques jours via la synchronisation LDAP | Quelques secondes via SCIM |
Les équipes informatiques utilisant le Staff WiFi 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 mots de passe et de l'intégration manuelle des appareils. L'authentification par certificat répond également à l'exigence 8.3 de la norme PCI DSS pour une authentification forte et au contrôle A.9.4 de la norme ISO 27001 pour le contrôle d'accès aux systèmes et aux applications, allégeant ainsi la charge d'audit de votre équipe de sécurité.
Pour les entreprises du secteur 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 recommandée : Sécurité WiFi d'entreprise : le guide complet pour 2026 - Intégration du firmware personnalisé OpenWrt avec Purple WiFi
Définitions clés
802.1X
An IEEE standard (IEEE 802.1X-2020) for port-based network access control. It requires devices to authenticate before the access point grants network access, using an EAP exchange mediated by a RADIUS server.
IT teams use 802.1X to ensure only authorised users and devices connect to the corporate network. It provides per-user encryption, per-session keys, and a full audit trail of every connection event.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). A networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA) management for network access.
Access points forward every connection request to the RADIUS server, which decides whether to admit the device and which VLAN to assign it to. Cloud RADIUS replaces on-premises NPS or FreeRADIUS servers.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). An 802.1X authentication method that uses mutual X.509 certificate exchange instead of passwords.
EAP-TLS is the gold standard for managed device fleets. It is phishing-resistant, requires no password hash store, and is the only 802.1X method that satisfies CISA phishing-resistant MFA guidance.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2. A legacy 802.1X method that validates passwords against NTLM hashes stored in Active Directory.
PEAP-MSCHAPv2 fails in cloud-only environments because Entra ID does not store NTLM hashes. Organisations migrating from on-premises AD must replace PEAP with EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. A protocol used by MDM platforms to request and install digital certificates on devices automatically, without user interaction.
IT teams use SCEP with Intune or Jamf to silently provision WiFi certificates to employee devices. SCEP replaces the on-premises NDES (Network Device Enrollment Service) server in cloud-first deployments.
SCIM
System for Cross-domain Identity Management (RFC 7644). An open standard that automates the real-time exchange of user identity information between IT systems.
SCIM ensures that when an employee is disabled in Entra ID or Okta, that change is pushed to the cloud RADIUS service immediately, revoking WiFi access within seconds rather than hours.
NPS
Network Policy Server. Microsoft's RADIUS implementation, typically run on Windows Server as part of an on-premises Active Directory environment.
Cloud-first organisations are retiring NPS to eliminate Windows Server VMs, OS patching, and the dependency on on-premises Active Directory. Cloud RADIUS is the direct replacement.
RadSec
RADIUS over TLS (RFC 6614). A protocol that encrypts RADIUS authentication traffic using TLS, replacing the UDP-based cleartext transport used by traditional RADIUS.
RadSec is essential when using cloud RADIUS, as authentication traffic must traverse the public internet between the access point and the cloud service. Purple supports RadSec natively.
iPSK
Individual Pre-Shared Key. A variant of WPA2-Personal that assigns a unique pre-shared key to each device, rather than a single shared key for all devices.
iPSK is used for IoT devices, printers, and other hardware that cannot support 802.1X EAP-TLS. It provides per-device accountability and VLAN assignment without requiring certificate support.
Dynamic VLAN
A network segmentation technique where the RADIUS server returns a VLAN identifier in the Access-Accept response, and the access point places the device on that VLAN automatically.
Dynamic VLANs allow IT teams to segment staff, contractors, IoT devices, and guests onto separate network segments based on identity provider group membership, without manual firewall changes.
Exemples concrets
A 400-site retail chain needs to secure Staff WiFi across all locations. They run Cisco Meraki access points and use Microsoft Entra ID with Intune for device management. They currently use a shared WPA2-Personal PSK because they have no on-premises Active Directory to run NPS. A recent internal audit flagged the shared PSK as a PCI DSS compliance gap.
The chain deploys Purple's cloud RADIUS. First, they connect Purple to Entra ID via OAuth admin consent and configure SCIM provisioning. In Intune, they create a Trusted Certificate Profile for the Purple CA root and a SCEP certificate profile scoped to the 'Staff-Retail' device group. Intune silently pushes certificates to all managed point-of-sale terminals and staff tablets. In the Meraki dashboard, they update the Staff SSID to WPA2-Enterprise, enter the Purple cloud RADIUS primary and secondary endpoints, and enable dynamic VLAN assignment. When a device connects, it presents its Intune-issued certificate, Purple validates it against the CA and checks the Entra ID group, and the device is placed on VLAN 10 (staff network) or VLAN 20 (management network) based on group membership. The shared PSK is retired. Rollout across 400 sites takes one weekend, as no on-site hardware is deployed - only SSID configuration changes in Meraki.
A 15,000-student university uses Google Workspace as its primary identity provider. The IT team wants to provide secure WiFi for staff and students on a BYOD estate of MacBooks, Chromebooks, and Android phones. They have no on-premises Active Directory and no appetite to run servers.
The university integrates Purple's cloud RADIUS with Google Workspace. For managed Chromebooks, they use Google Admin to push a WiFi certificate profile via SCEP, silently enrolling each device. For BYOD MacBooks and Android phones, they deploy a lightweight onboarding application that authenticates the user with their Google credentials and installs a certificate on the device in a single tap. Subsequent connections use EAP-TLS silently. Purple maps Google Workspace Organisational Units to VLANs: staff land on VLAN 10, students on VLAN 20, and guest visitors on a captive portal SSID. When a student graduates and their Google account is suspended, SCIM pushes the change to Purple and their WiFi access is revoked within minutes.
Questions d'entraînement
Q1. Your organisation has fully migrated from on-premises Active Directory to Microsoft Entra ID. Your current Staff WiFi uses PEAP-MSCHAPv2 against an NPS server that was joined to the old domain. After decommissioning the domain controller, staff report they can no longer connect to the WiFi. What is the root cause, and what is the correct long-term fix?
Conseil : Consider what PEAP-MSCHAPv2 requires from the directory, and whether Entra ID provides it.
Voir la réponse type
The root cause is that PEAP-MSCHAPv2 requires the RADIUS server to validate the user's password against an NTLM hash stored in Active Directory. With the domain controller decommissioned, NPS has no directory to validate against. Entra ID does not store NTLM hashes, so NPS cannot be redirected to Entra ID. The correct long-term fix is to replace NPS with a cloud RADIUS service, migrate from PEAP-MSCHAPv2 to EAP-TLS, and use the MDM (Intune) to issue device certificates via SCEP. This eliminates the dependency on any on-premises directory.
Q2. You are deploying cloud RADIUS for a 200-device fleet of corporate MacBooks managed by Jamf Pro. Your identity provider is Okta. What is the most secure and operationally efficient way to provision the WiFi credentials to these devices?
Conseil : Look for a method that requires no user interaction, avoids passwords, and integrates with your existing MDM.
Voir la réponse type
Configure Jamf Pro to use SCEP to silently push device certificates to the MacBooks. Create a SCEP payload in a Jamf configuration profile, pointing at the CA managed by your cloud RADIUS provider. Scope the profile to the relevant device group. Jamf will push the certificate to each MacBook automatically, with no user interaction. Configure the WiFi profile in the same configuration profile to use EAP-TLS with the SCEP-issued certificate. Connect the cloud RADIUS service to Okta via SCIM to ensure that when an employee is disabled in Okta, their WiFi access is revoked immediately.
Q3. An employee is terminated at 9am on a Monday. Their Entra ID account is disabled by HR at 9:05am. At 9:30am, a security alert shows the employee's laptop is still connected to the corporate WiFi from the car park. What configuration is missing, and how do you fix it?
Conseil : How does the RADIUS server learn that the user's status has changed in the identity provider?
Voir la réponse type
The deployment is relying on periodic LDAP syncs rather than SCIM provisioning. The LDAP sync has not yet run since the account was disabled, so the cloud RADIUS service still considers the user active. The fix is to enable SCIM provisioning between Entra ID and the cloud RADIUS service. SCIM pushes user state changes in real time, so when the account is disabled in Entra ID at 9:05am, the RADIUS service receives the change immediately. The next time the device attempts to re-authenticate (controlled by the session timeout on the access point), it receives an Access-Reject. Setting a short session timeout (15 to 30 minutes) on the access point limits the maximum window between account disable and network eviction.
Q4. Your venue has 50 IoT devices - digital signage players, environmental sensors, and printers - that do not support 802.1X EAP-TLS. How do you secure these devices on the same WiFi infrastructure as your EAP-TLS staff network?
Conseil : Consider what authentication method provides per-device accountability without requiring certificate support.
Voir la réponse type
Use iPSK (individual pre-shared keys) for the IoT devices. Assign a unique pre-shared key to each device in the cloud RADIUS dashboard, along with a VLAN assignment. Each device authenticates with its unique key, which the RADIUS server validates and uses to place the device on the IoT VLAN, isolated from the staff network. If a device is compromised or decommissioned, you revoke only that device's key without affecting any other device. This approach provides per-device accountability and network segmentation without requiring 802.1X supplicant support on the IoT hardware.
Continuer la lecture de cette série
Intégration de CommScope Ruckus avec Purple WiFi : Guide d'installation et de configuration
Ce guide de référence technique fournit un manuel de configuration faisant autorité pour l'intégration des architectures CommScope Ruckus avec Purple WiFi. Il détaille les déploiements étape par étape pour les Captive Portals de WiFi invité, le WiFi personnel sécurisé via 802.1X et l'isolation réseau multi-locataire à l'aide de Ruckus Dynamic PSK.
Allied Telesis Access Points Integration with Purple WiFi
Ce guide fournit un manuel de configuration complet pour intégrer les points d'accès Allied Telesis de la série TQ avec Purple WiFi. Il couvre la redirection vers un Captive Portal externe, l'authentification RADIUS 802.1X et le routage dynamique des VLAN à l'aide de clés pré-partagées privées (PPSK) pour des déploiements multi-locataires sécurisés.
The Security Benefits of RADIUS as a Service for Hybrid Workforces
Ce guide de référence technique explique comment RADIUS as a Service sécurise l'accès au réseau pour les effectifs hybrides dans les sites distribués. Il couvre l'architecture, les avantages en matière de sécurité et les étapes de déploiement pour remplacer l'infrastructure RADIUS sur site par un service d'authentification géré dans le cloud. Pour les responsables informatiques et les architectes réseau des hôtels, des chaînes de vente au détail, des stades et des organisations du secteur public, ce guide fournit les preuves nécessaires pour évaluer et mettre en œuvre une migration vers le cloud RADIUS ce trimestre.