Okta et RADIUS : Étendre votre fournisseur d'identité à l'authentification WiFi

Ce guide fournit une référence technique complète pour les administrateurs informatiques des organisations centrées sur Okta qui souhaitent étendre leur fournisseur d'identité cloud à l'authentification WiFi à l'aide de l'agent Okta RADIUS. Il couvre l'architecture d'authentification complète, les compromis liés à l'application de la MFA, l'attribution dynamique de VLAN via le mappage d'attributs RADIUS, et la décision cruciale entre l'EAP-TTLS basé sur mot de passe et l'EAP-TLS basé sur certificat. Les exploitants de sites et les équipes informatiques d'entreprise y trouveront des conseils de déploiement exploitables, des études de cas réels dans les secteurs de l'hôtellerie et du commerce de détail, ainsi qu'un cadre clair pour intégrer Okta RADIUS aux côtés de solutions dédiées de WiFi invité.

📖 11 min de lecture📝 2,672 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du podcast

Bienvenue dans le briefing technique de Purple. Aujourd'hui, nous plongeons dans un sujet situé au carrefour de l'architecture réseau et de la gestion des identités : Okta et RADIUS pour l'authentification WiFi. Si vous êtes responsable informatique, architecte réseau ou directeur des opérations d'un site, vous connaissez déjà le casse-tête de la gestion d'identifiants distincts pour l'accès au réseau. Vous disposez de votre annuaire Okta pour les applications cloud, mais votre WiFi repose peut-être encore sur un serveur Active Directory hérité, ou pire, sur un mot de passe WPA2 partagé et épinglé au mur de la salle de pause. Aujourd'hui, nous allons voir comment combler cet écart en utilisant l'agent RADIUS Okta. Nous aborderons l'architecture, la gestion de l'authentification multifacteur sur le WiFi, les compromis essentiels entre l'authentification par mot de passe et par certificat, et la façon de mapper les groupes Okta aux attributs RADIUS pour l'attribution dynamique de VLAN. Entrons dans le vif du sujet.

Commençons par l'architecture. Comment fonctionne concrètement l'agent RADIUS Okta ? L'agent RADIUS Okta est une application légère que vous déployez sur site — généralement sur un serveur Windows ou Linux — ou dans une machine virtuelle cloud. Il agit comme un proxy. Il se situe entre votre infrastructure réseau, comme vos points d'accès sans fil ou votre contrôleur LAN sans fil, et le cloud Okta. Lorsqu'un utilisateur tente de se connecter à votre WiFi d'entreprise 802.1X, son appareil envoie les identifiants au point d'accès. Le point d'accès, agissant comme ce que nous appelons l'authentificateur dans le modèle 802.1X, transmet une demande d'accès (Access-Request) RADIUS à l'agent RADIUS Okta via le port UDP 1812. L'agent prend cette demande et l'achemine de manière sécurisée vers le cloud Okta via un appel API HTTPS. Okta valide les identifiants, vérifie les politiques de connexion et renvoie une décision. L'agent traduit ensuite cette décision en un message RADIUS Access-Accept ou Access-Reject pour le point d'accès. C'est un moyen astucieux d'étendre votre fournisseur d'identité cloud jusqu'à la périphérie du réseau local sans exposer directement votre annuaire à Internet.

Maintenant, la grande question que tout le monde se pose : peut-on imposer la MFA Okta sur les connexions WiFi ? La réponse courte est oui, mais avec des réserves importantes. L'agent RADIUS d'Okta prend principalement en charge le protocole d'authentification par mot de passe (PAP). Étant donné que le protocole PAP transmet le mot de passe en clair, celui-ci est encapsulé et protégé par le tunnel TLS externe du protocole EAP (Extensible Authentication Protocol). Cette configuration permet à l'agent de gérer les demandes de MFA. Vous pouvez configurer Okta pour qu'il envoie une notification Okta Verify sur le téléphone de l'utilisateur, ou lui demander d'ajouter un code TOTP (Time-Based One-Time Password) à son mot de passe. C'est là, cependant, que l'expérience utilisateur se heurte à la sécurité. Imaginez demander à un vendeur en magasin de valider une notification push à chaque fois que son téléphone se reconnecte au WiFi du personnel lorsqu'il se déplace dans l'espace de vente. Cela génère des frictions. De plus, de nombreux appareils modernes interrompent la connexion WiFi si le processus de MFA prend trop de temps. Ainsi, bien que la MFA sur le WiFi soit techniquement possible et prise en charge par Okta, nous la recommandons généralement uniquement pour les accès hautement privilégiés, tels que les SSID d'administration informatique, plutôt que pour le WiFi général du personnel.

Cela nous amène au compromis crucial : le RADIUS basé sur mot de passe avec Okta par rapport à l'authentification par certificat, en particulier EAP-TLS. Lorsque vous utilisez l'agent RADIUS d'Okta avec EAP-TTLS ou PAP, vous vous appuyez sur des mots de passe. Les mots de passe peuvent être volés, hameçonnés ou partagés. De plus, comme nous venons de l'évoquer, l'ajout de la MFA au WiFi est laborieux en pratique. En revanche, EAP-TLS utilise des certificats numériques déployés sur l'appareil de l'utilisateur. Il assure une authentification mutuelle : l'appareil prouve son identité au réseau, et le réseau prouve son identité à l'appareil. Aucun mot de passe n'est à saisir, et cette méthode est extrêmement résistante au phishing. Le piège ? L'agent RADIUS d'Okta ne fonctionne pas nativement comme une autorité de certification. Si vous souhaitez utiliser EAP-TLS, vous avez besoin d'une infrastructure à clés publiques (PKI) — avec des solutions telles que SecureW2, Foxpass ou Microsoft Active Directory Certificate Services — ainsi que d'une solution de gestion des appareils mobiles (MDM) pour distribuer les certificats à vos terminaux. Okta peut toujours servir de fournisseur d'identité pour autoriser la délivrance des certificats, mais l'agent RADIUS lui-même ne prendra pas en charge la charge de travail d'EAP-TLS. Pour les environnements BYOD, le RADIUS Okta basé sur mot de passe est rapide et simple à déployer. Pour les appareils d'entreprise managés, EAP-TLS reste la référence absolue.

Passons maintenant à l'une des fonctionnalités les plus puissantes : l'attribution dynamique de VLAN. Dans un grand site — un hôtel, un stade, un centre de congrès — vous ne voulez pas que l'ensemble de votre personnel se trouve sur le même segment de réseau. Vous souhaitez que les terminaux de point de vente soient isolés des tablettes du personnel d'étage, et que l'équipe informatique soit sur un VLAN d'administration. Comment y parvenir avec Okta ? Tout repose sur le mappage des attributs RADIUS. Dans la console d'administration d'Okta, sous les paramètres de l'application RADIUS, vous pouvez activer une fonctionnalité appelée « Include groups in RADIUS response ». Vous spécifiez ainsi quels groupes Okta doivent être renvoyés dans la réponse d'authentification. Okta transmet cette appartenance de groupe à votre contrôleur réseau à l'aide d'attributs RADIUS standard — généralement l'Attribut 11 pour Filter-ID, ou l'Attribut 25 pour Class. Votre contrôleur WiFi ou votre système de contrôle d'accès réseau (NAC), tel qu'Aruba ClearPass ou Cisco ISE, reçoit ce nom de groupe. Vous configurez ensuite une politique locale sur le contrôleur qui stipule, par exemple, que si l'attribut RADIUS 25 est égal à Retail-POS, le client est affecté au VLAN 40. Le contrôleur envoie les attributs de tunnel standard — Tunnel-Type, Tunnel-Medium-Type et Tunnel-Private-Group-ID — au point d'accès, plaçant ainsi dynamiquement l'utilisateur dans le bon VLAN. C'est un moyen transparent d'appliquer la segmentation du réseau en se basant uniquement sur l'identité Okta, ce qui s'avère extrêmement puissant pour la conformité avec des normes telles que PCI DSS, qui exige une segmentation stricte du réseau autour des environnements de données de titulaires de cartes.

Examinons maintenant quelques scénarios de déploiement réels. Prenons l'exemple d'une chaîne hôtelière nationale possédant des établissements dans tout le Royaume-Uni. Chaque établissement dispose d'un mélange de personnel de réception, d'entretien, de restauration et de direction. Auparavant, chaque établissement gérait son propre serveur NPS avec un Active Directory local. L'équipe informatique passait un temps considérable à gérer les comptes locaux et à résoudre les pannes RADIUS. En déployant l'agent Okta RADIUS au sein d'une paire de machines virtuelles cloud redondantes, en centralisant tous les comptes d'utilisateurs dans Okta et en configurant l'affectation de VLAN basée sur les groupes, la chaîne a considérablement réduit ses frais informatiques par établissement. Le personnel de réception s'authentifie avec ses identifiants Okta et est automatiquement placé sur le VLAN des services aux clients. Le personnel de direction, qui fait partie d'un groupe Okta différent, se retrouve sur le VLAN de gestion avec un accès aux systèmes de gestion de l'établissement. L'ensemble de la configuration est géré depuis une console d'administration Okta unique, et le journal système d'Okta fournit une piste d'audit complète de chaque événement d'authentification dans tous les établissements.

Deuxième scénario : une grande chaîne de vente au détail comptant plus de 300 magasins. Chaque magasin dispose d'un réseau WiFi pour le personnel, utilisé pour la gestion des stocks, les terminaux de point de vente et les opérations de back-office. La conformité PCI DSS exige une segmentation stricte du réseau entre l'environnement des données des titulaires de cartes et l'accès général du personnel. En intégrant Okta RADIUS à son infrastructure sans fil existante, le détaillant associe les groupes Okta — POS-Staff, Inventory-Staff et Store-Management — à trois VLAN distincts. Lorsqu'un associé de magasin se connecte, son appareil est automatiquement placé dans le bon VLAN en fonction de son appartenance au groupe Okta. Si un employé change de rôle, la mise à jour de son appartenance au groupe Okta modifie immédiatement son accès réseau lors de sa prochaine connexion. Aucune règle de pare-feu à mettre à jour, aucune configuration VLAN à déployer dans les magasins individuels.

Abordons maintenant les recommandations de mise en œuvre et les pièges courants. Le premier piège, et le plus courant, consiste à ignorer les paramètres de délai d'attente (timeout). Les appels API Okta prennent du temps, en particulier si une notification push MFA est impliquée. Si le délai d'attente RADIUS de votre contrôleur sans fil est configuré sur les trois ou cinq secondes par défaut, la requête expirera avant que l'utilisateur ne puisse appuyer sur Approuver sur son téléphone. Vous devez augmenter le délai d'attente RADIUS sur votre WLC à au moins trente à soixante secondes. Il s'agit d'une modification de configuration côté réseau, et non dans Okta, qui est fréquemment négligée. La deuxième recommandation concerne la haute disponibilité. Ne déployez jamais un seul agent Okta RADIUS. Déployez au moins deux agents sur des serveurs distincts et configurez votre contrôleur sans fil pour répartir la charge entre eux. Si un serveur s'arrête pour une mise à jour, votre authentification WiFi reste active. Le troisième piège : attention au PEAP. L'agent Okta RADIUS ne prend pas en charge PEAP-MSCHAPv2, qui est le choix par défaut pour de nombreux environnements Windows plus anciens. Vous devez configurer vos clients pour utiliser EAP-TTLS avec PAP. Cela nécessite généralement le déploiement d'un profil sans fil via une stratégie de groupe ou un MDM, car Windows ne bascule pas facilement vers EAP-TTLS par défaut. Ne pas le faire est la première cause d'échec des déploiements.

Place à une session rapide de questions-réponses basées sur les interrogations fréquentes des clients. Première question : Pouvons-nous utiliser Okta RADIUS pour le WiFi invité ? Réponse : Non. Le tarif d'Okta est calculé par utilisateur et la solution est conçue pour l'identité des collaborateurs. Pour le WiFi invité, vous devez utiliser une solution de Captive Portal dédiée, qui gère les conditions d'utilisation, la connexion via les réseaux sociaux et les analyses sans consommer de licences Okta. Deuxième question : Est-ce qu'Okta RADIUS prend en charge les clés YubiKeys pour l'authentification WiFi ? Réponse : En règle générale, non. Les jetons matériels et WebAuthn ne se transposent pas bien sur le protocole RADIUS. Privilégiez les notifications push Okta Verify ou le TOTP si vous devez absolument utiliser le MFA sur le WiFi. Troisième question : Comment cela interagit-il avec un déploiement Purple ? Réponse : Très bien. Les entreprises clientes de Purple qui utilisent Okta comme fournisseur d'identité peuvent utiliser Okta RADIUS pour authentifier de manière sécurisée le WiFi du personnel, tout en utilisant le Captive Portal de Purple pour l'accès des invités sur un SSID distinct. Cela positionne Purple aux côtés d'Okta au sein d'une pile d'authentification moderne et unifiée : le personnel sur un SSID avec Okta RADIUS, les invités sur un autre avec le portail personnalisé de Purple.

Pour résumer le briefing d'aujourd'hui : l'agent Okta RADIUS est un outil puissant pour éliminer les annuaires locaux existants et unifier votre authentification WiFi au sein de votre fournisseur d'identité cloud. Il prend en charge l'attribution dynamique de VLAN pour une segmentation réseau robuste, ce qui est essentiel pour la conformité avec PCI DSS et d'autres réglementations. Cependant, veillez à l'expérience utilisateur si vous imposez le MFA sur le WiFi, et gardez à l'esprit que pour les appareils d'entreprise entièrement gérés, la migration vers l'EAP-TLS basé sur des certificats avec une PKI dédiée constitue la stratégie à long terme la plus sécurisée. L'agent Okta RADIUS est une excellente solution de transition, en particulier pour les organisations centrées sur Okta qui souhaitent étendre rapidement cet investissement d'identité à la couche réseau. C'est tout pour ce briefing. N'hésitez pas à consulter le guide de référence technique complet pour obtenir les étapes de configuration détaillées, les schémas d'architecture et des exemples pratiques. D'ici là, veillez à la sécurité de vos réseaux et restez connectés.

Points clés à retenir

✓L'agent Okta RADIUS sert de proxy pour les demandes d'authentification WiFi 802.1X de l'infrastructure réseau vers le cloud Okta via HTTPS, permettant à l'identité cloud de régir l'accès réseau sans serveurs d'annuaire sur site.
✓L'agent prend en charge EAP-TTLS avec PAP et EAP-GTC, mais ne prend PAS en charge PEAP-MSCHAPv2 (le comportement par défaut de Windows) ou EAP-TLS — les supplicants clients doivent être reconfigurés via MDM ou GPO avant le déploiement.
✓Le MFA sur le WiFi est techniquement pris en charge (push Okta Verify, TOTP, SMS) mais nécessite d'augmenter le délai d'expiration RADIUS du WLC à 30-60 secondes ; il est préférable de le réserver aux SSIDs d'administration plutôt qu'au WiFi général du personnel en raison des frictions liées au roaming.
✓L'attribution dynamique de VLAN est réalisée en activant "Include groups in RADIUS response" dans Okta et en mappant la Class (Attribut 25) ou le Filter-Id (Attribut 11) retourné aux attributs de tunnel VLAN (64, 65, 81) sur le WLC ou l'appareil NAC.
✓Déployez toujours un minimum de deux instances de l'agent Okta RADIUS pour une haute disponibilité — un agent unique constitue un point de défaillance unique critique pour toute l'authentification WiFi sur l'ensemble du parc informatique.
✓Pour les environnements de terminaux entièrement gérés soumis à la norme PCI DSS ou à des exigences de sécurité élevées, l'EAP-TLS avec une PKI cloud est l'architecture à long terme supérieure ; Okta RADIUS avec EAP-TTLS/PAP est le choix pragmatique pour le BYOD ou les scénarios de déploiement rapide.
✓Okta RADIUS est un outil d'identité pour les collaborateurs — déployez une solution de Captive Portal WiFi dédiée aux invités pour l'accès des visiteurs afin d'éviter les coûts d'échelle des licences Okta et de maintenir une séparation claire entre l'accès réseau du personnel et celui des invités.

Résumé analytique

Pour les équipes informatiques d'entreprise gérant des sites distribués — des chaînes d'hôtels aux stades —, l'unification du contrôle d'accès réseau avec un fournisseur d'identité cloud est une étape cruciale vers le Zero Trust. L'agent Okta RADIUS comble le fossé entre l'identité cloud moderne et l'infrastructure WiFi 802.1X traditionnelle, permettant aux organisations de remplacer les anciens serveurs RADIUS sur site et l'infrastructure Active Directory pour l'authentification réseau.

Ce guide détaille comment déployer l'agent Okta RADIUS pour l'authentification WiFi d'entreprise, en couvrant l'architecture proxy, les mécanismes d'application de la MFA et les compromis entre l'EAP-TTLS basé sur mot de passe et l'EAP-TLS basé sur certificat. Il fournit également des conseils pratiques sur le mappage des appartenances aux groupes Okta vers les attributs RADIUS pour l'attribution dynamique de VLAN — une fonctionnalité qui prend directement en charge les exigences de segmentation réseau PCI DSS. En intégrant Okta pour l'authentification du personnel aux côtés des solutions de Guest WiFi , les exploitants de sites peuvent obtenir une couche d'accès unifiée, sécurisée et conforme sans dupliquer l'infrastructure d'identité.

Analyse technique approfondie

Fonctionnement de l'agent Okta RADIUS

L'agent Okta RADIUS est un service système léger qui agit comme un proxy entre les serveurs d'accès réseau (NAS) — tels que les points d'accès sans fil (WAP) ou les contrôleurs LAN sans fil (WLC) — et le cloud Okta. Il est généralement déployé sur un serveur Windows ou Linux sur site ou au sein d'un VPC cloud, et il est entièrement géré depuis la console d'administration Okta après l'installation initiale.

Le flux d'authentification suit un modèle de proxy 802.1X standard. L'appareil d'un utilisateur (le suppliant) se connecte à un SSID d'entreprise et présente des identifiants. Le WAP ou WLC (l'authentificateur) transmet une requête Access-Request RADIUS à l'agent Okta RADIUS sur le port UDP 1812. L'agent tunnelise cette requête de manière sécurisée vers le cloud Okta via un appel API HTTPS, où le moteur de politique d'Okta évalue les identifiants par rapport à son annuaire d'utilisateurs et aux politiques de connexion configurées. Si l'authentification réussit, l'agent renvoie un message Access-Accept RADIUS à l'authentificateur, incluant éventuellement des attributs RADIUS pour l'autorisation, tels que l'attribution de VLAN. Si la MFA est requise, l'agent renvoie un Access-Challenge RADIUS au client, demandant un deuxième facteur avant que la décision finale ne soit renvoyée.

Ce modèle de proxy signifie que l'agent Okta RADIUS n'a pas besoin de stocker les identifiants des utilisateurs localement. Toute la logique d'authentification, l'évaluation des politiques et la journalisation d'audit se déroulent dans le cloud Okta, offrant aux administrateurs une interface unique pour la gouvernance des identités à la fois sur les applications cloud et l'accès réseau.

Protocoles EAP pris en charge et limitations critiques

Une contrainte architecturale fondamentale de l'agent Okta RADIUS est sa dépendance au Password Authentication Protocol (PAP) pour l'authentification principale. Bien que le PAP transmette les mots de passe en texte clair au niveau de la couche interne, cette transmission est encapsulée et protégée par le tunnel TLS externe de l'Extensible Authentication Protocol (EAP). Les protocoles externes pris en charge sont EAP-TTLS (avec PAP comme méthode interne) et EAP-GTC. Pour une comparaison plus approfondie des méthodes EAP, reportez-vous au guide de référence Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST .

Point critique, PEAP-MSCHAPv2 n'est pas pris en charge. Il s'agit du protocole 802.1X par défaut pour les clients Windows et de nombreux environnements d'entreprise hérités. Les organisations qui migrent depuis une configuration RADIUS NPS/Active Directory classique doivent reconfigurer les demandeurs (supplicants) de leurs clients pour utiliser EAP-TTLS avec PAP — un changement qui nécessite généralement le déploiement d'un profil sans fil via MDM ou une stratégie de groupe (GPO). Le fait de ne pas tenir compte de ce point est la cause la plus fréquente d'échec des déploiements Okta RADIUS.

EAP-TLS, qui repose entièrement sur une authentification mutuelle basée sur des certificats, n'est pas non plus pris en charge nativement par l'agent Okta RADIUS. Les organisations nécessitant EAP-TLS doivent déployer une PKI dédiée ou une solution cloud RADIUS qui s'intègre à Okta en tant qu'IdP via SAML ou OIDC, plutôt que d'utiliser directement l'agent Okta RADIUS.

Application de la MFA sur les connexions WiFi

L'agent Okta RADIUS prend en charge la MFA pour l'accès WiFi, mais cela introduit des défis en matière d'expérience utilisateur qui doivent être soigneusement étudiés avant le déploiement. Lorsqu'une politique MFA est déclenchée, l'agent envoie un Access-Challenge RADIUS au client. Okta prend en charge plusieurs facteurs pour les applications RADIUS :

Facteur MFA	PAP	EAP-TTLS	Notes
Okta Verify Push	Pris en charge	Pris en charge	Envoyé hors bande ; l'utilisateur appuie sur Approuver sur son mobile
TOTP (Okta Verify / Google Auth)	Pris en charge	Pris en charge	L'utilisateur ajoute l'OTP au mot de passe (ex. : `Pass123,456789`)
SMS / E-mail / Voix	Pris en charge	Pris en charge	L'utilisateur envoie d'abord une chaîne de déclenchement (SMS, EMAIL, CALL)
Duo Push / SMS / Code d'accès	Pris en charge	Pris en charge	Code d'accès Duo uniquement pour EAP-TTLS
YubiKey / U2F / Windows Hello	Non pris en charge	Non pris en charge	Jetons matériels incompatibles avec le protocole RADIUS

La contrainte pratique réside dans l'itinérance (roaming). Dans les environnements du secteur de l' Hôtellerie , la tablette d'un membre du personnel peut basculer d'un point d'accès à un autre des dizaines de fois par service, déclenchant une réauthentification à chaque fois. Exiger une approbation par notification push à chaque changement de point d'accès est ingérable sur le plan opérationnel. Pour le WiFi du personnel général, des politiques de mots de passe robustes associées aux politiques de confiance des appareils et de zones réseau d'Okta sont généralement préférées aux invites MFA actives. La MFA sur le WiFi doit être réservée aux SSID d'administration ou aux scénarios d'accès à privilèges élevés.

Authentification par mot de passe vs Authentification par certificat

Le choix entre le protocole RADIUS basé sur mot de passe (via l'agent Okta RADIUS) et l'EAP-TLS basé sur certificat est l'une des décisions les plus importantes lors du déploiement d'un réseau WiFi d'entreprise. Les compromis ne concernent pas uniquement la sécurité ; ils impliquent également la complexité du déploiement, la maturité de la gestion des appareils et la charge opérationnelle.

L'authentification par mot de passe via l'agent Okta RADIUS offre une voie rapide vers une identité unifiée. Si votre organisation gère déjà des utilisateurs dans Okta, le déploiement peut être finalisé en quelques heures plutôt qu'en plusieurs semaines. Il n'y a pas d'infrastructure PKI à concevoir, aucun certificat à distribuer, et aucune dépendance vis-à-vis d'un MDM. Le compromis réside dans le fait que les mots de passe restent l'identifiant principal, et l'absence d'authentification mutuelle signifie que le client ne peut pas vérifier par cryptographie l'identité du réseau — ce qui représente un vecteur d'attaques de type "evil twin" dans les environnements à haut risque.

L'EAP-TLS basé sur certificat élimine totalement les mots de passe de l'équation d'authentification WiFi. Le client présente un certificat d'appareil, et le serveur RADIUS présente un certificat de serveur, garantissant ainsi une authentification mutuelle. Il s'agit de la méthode recommandée pour l'IEEE 802.1X sur les réseaux WPA3-Enterprise, particulièrement dans les environnements soumis aux normes PCI DSS ou NCSC Cyber Essentials Plus. Le prérequis est une PKI fonctionnelle — soit un déploiement Microsoft ADCS sur site, soit un service PKI cloud — ainsi qu'une plateforme MDM capable de distribuer des certificats à tous les terminaux managés. Pour les environnements de Vente au détail disposant de centaines de terminaux de point de vente managés, cet investissement est largement justifié. Pour les environnements à forte proportion de BYOD ou pour les déploiements rapides, la solution Okta RADIUS avec EAP-TTLS constitue le choix le plus pragmatique.

Cartographie des Attributs RADIUS pour l'Assignation Dynamique de VLAN

L'assignation dynamique de VLAN est le domaine où l'intégration d'Okta RADIUS apporte sa valeur opérationnelle la plus concrète. En associant l'appartenance aux groupes Okta à des attributs RADIUS, les administrateurs réseau peuvent appliquer une segmentation réseau basée sur les rôles, sans avoir à gérer des politiques de VLAN distinctes par appareil ou par site.

Okta transmet les données d'appartenance de groupe dans le message RADIUS Access-Accept en utilisant l'un des trois attributs configurables dans les paramètres avancés RADIUS de l'application Okta :

Attribut 11 (Filter-Id) : Un attribut de chaîne contenant le nom du groupe. Largement pris en charge par l'ensemble des constructeurs.
Attribut 25 (Class) : Un attribut opaque utilisé pour l'autorisation. Pris en charge par Cisco ISE, Aruba ClearPass et Fortinet.
Attribut 26 (Vendor-Specific) : Permet d'intégrer des sous-attributs spécifiques aux constructeurs pour un contrôle plus granulaire.

Le contrôleur réseau (WLC, équipement NAC) reçoit le nom du groupe Okta dans l'attribut sélectionné et l'associe aux attributs de tunnel RADIUS standard requis pour l'assignation de VLAN :

Attribut RADIUS	Valeur	Objectif
64 (Tunnel-Type)	13 (VLAN)	Spécifie le tunneling VLAN
65 (Tunnel-Medium-Type)	6 (802)	Spécifie le support IEEE 802
81 (Tunnel-Private-Group-ID)	ex., `40`	L'ID du VLAN cible

Par exemple, un utilisateur appartenant au groupe Okta Retail-POS-Staff verrait l'attribut Class: Retail-POS-Staff renvoyé dans le Access-Accept. La politique du WLC mapperait cela à Tunnel-Private-Group-ID: 40, plaçant l'appareil sur le VLAN 40 — le réseau POS isolé. Un utilisateur dans Store-Management serait placé sur le VLAN 50. Cette logique est appliquée en périphérie du réseau, et non dans Okta, mais elle est entièrement dictée par l'appartenance au groupe Okta.

Guide d'implémentation

Étape 1 : Déployer l'agent Okta RADIUS (Haute Disponibilité)

Déployez l'agent Okta RADIUS sur un minimum de deux serveurs — soit sur site, soit dans un VPC cloud — afin de garantir une haute disponibilité. Les déploiements à agent unique représentent un risque critique : si le serveur est indisponible pour des correctifs ou subit une panne, toute l'authentification WiFi 802.1X échouera sur l'ensemble du parc. Configurez votre contrôleur WLC ou votre équipement NAC pour répartir la charge des requêtes RADIUS entre les deux agents.

Lors de l'installation, l'agent vous invitera à vous connecter en tant qu'administrateur Okta pour autoriser l'agent et le lier au locataire Okta. Une fois autorisé, l'agent apparaît dans la console d'administration Okta sous Paramètres > Téléchargements > État de l'agent RADIUS, où la santé et la connectivité peuvent être surveillées.

Étape 2 : Configurer l'application RADIUS dans Okta

Dans la console d'administration Okta, accédez à Applications > Applications et recherchez l'application RADIUS dans le catalogue d'applications.
Ajoutez l'application, attribuez-lui un nom descriptif (par exemple, Corporate-WiFi-Staff), puis cliquez sur Suivant.
Sous l'onglet Authentification, configurez le Port RADIUS (par défaut 1812) et générez un Secret partagé fort et aléatoire d'au moins 32 caractères.
Sous Paramètres RADIUS avancés, activez l'option Accepter le mot de passe et le jeton de sécurité dans la même demande de connexion si vous prévoyez de prendre en charge le TOTP ajouté aux mots de passe.
Activez éventuellement l'option Autoriser le push automatique pour les utilisateurs inscrits à Okta Verify pour une MFA fluide basée sur le push.
Attribuez l'application aux groupes Okta concernés représentant votre personnel.

Étape 3 : Configurer l'attribution de VLAN basée sur les groupes

Dans les paramètres d'Authentification de l'application RADIUS, cliquez sur Modifier dans la section Paramètres RADIUS avancés.
Cochez Inclure les groupes dans la réponse RADIUS.
Sélectionnez l'attribut RADIUS : 25 Class est recommandé pour les environnements Aruba et Cisco ; 11 Filter-Id pour Fortinet et d'autres.
Ajoutez les noms des groupes Okta spécifiques à inclure (par exemple, Retail-POS-Staff, Store-Management, IT-Admins).
Sur votre équipement WLC ou NAC, créez des politiques d'application qui associent chaque nom de groupe aux attributs de tunnel VLAN correspondants.

Étape 4 : Configurer les supplicants clients

PEAP-MSCHAPv2 n'étant pas pris en charge, les appareils clients doivent être configurés pour utiliser EAP-TTLS avec PAP comme méthode interne. Déployez un profil de réseau sans fil via votre plateforme MDM (par ex., Microsoft Intune, Jamf Pro) ou via des objets de stratégie de groupe (GPO) pour les appareils joints au domaine Windows. Le profil doit spécifier :

SSID : Votre nom de SSID d'entreprise
Sécurité : WPA2-Enterprise ou WPA3-Enterprise
Méthode EAP : EAP-TTLS
Authentification interne : PAP
Validation du certificat de serveur : Activé (associer au CN du certificat de serveur de votre agent RADIUS)

Étape 5 : Définir les délais d'attente RADIUS

Augmentez le délai d'expiration RADIUS sur votre WLC de la valeur par défaut de 3-5 secondes à 30-60 seconds. Cela est essentiel si des notifications push MFA sont utilisées, car l'utilisateur doit disposer de suffisamment de temps pour approuver la notification sur son appareil avant que le WLC n'abandonne la tentative d'authentification.

Bonnes pratiques

Le déploiement d'Okta RADIUS pour l'authentification WiFi est simple, mais plusieurs bonnes pratiques opérationnelles distinguent un déploiement de production résilient d'un projet pilote fragile.

Segmentez le trafic des invités et du personnel au niveau du SSID. Okta RADIUS est un outil d'identité pour les collaborateurs. Pour l'accès des visiteurs et des invités, déployez une solution de Captive Portal dédiée. Cela évite que les coûts de licence Okta ne s'échelonnent avec le volume d'invités et garantit une séparation claire des responsabilités. Les clients d'entreprise Purple peuvent déployer Guest WiFi sur un SSID distinct tout en utilisant Okta RADIUS pour l'authentification du personnel sur la même infrastructure physique.

Utilisez une appliance NAC pour les environnements de politiques complexes. Si votre environnement exige un accès conditionnel basé sur la conformité de l'appareil, le filtrage des adresses MAC ou le statut du certificat en plus de l'identité de l'utilisateur, déployez une appliance NAC intermédiaire (Aruba ClearPass, Cisco ISE ou Portnox) pour relayer les requêtes vers l'agent Okta RADIUS. L'appliance NAC peut enrichir la réponse RADIUS avec des attributs de tunnel supplémentaires que l'agent Okta seul ne peut pas générer.

Surveillez via l'Okta System Log. Chaque événement d'authentification — réussite, échec, demande de MFA et type de facteur — est enregistré dans l'Okta System Log. Configurez la diffusion des journaux vers votre SIEM pour obtenir des alertes en temps réel sur les anomalies d'authentification. Ceci est particulièrement précieux pour les organisations du secteur de la Santé et du secteur public soumises à des exigences d'audit.

Renouvelez les secrets partagés selon un calendrier précis. Le secret partagé entre l'application Okta RADIUS et votre NAS est un identifiant de sécurité critique. Mettez en œuvre un calendrier de rotation (trimestriel de préférence) et mettez à jour simultanément l'application Okta et la configuration WLC/NAC.

Restreignez les adresses de service RADIUS. Dans la configuration de l'agent Okta RADIUS, limitez les adresses IP autorisées à envoyer des requêtes RADIUS. Cela empêche les appareils NAS non autorisés de tenter de s'authentifier auprès de votre tenant Okta. Pour obtenir des conseils sur le contexte plus large de l'architecture réseau, consultez Les avantages clés du SD WAN pour les entreprises modernes et Définition des points d'accès sans fil : Votre guide ultime 2026 .

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

Le tableau suivant présente les cas de panne les plus fréquemment rencontrés lors des déploiements WiFi Okta RADIUS, ainsi que les solutions recommandées.

Mode de défaillance	Cause racine	Solution
Délais d'authentification dépassés	Délai RADIUS du WLC trop court pour la réponse de l'API Okta ou du MFA	Augmenter le délai RADIUS du WLC à 30-60 secondes
Clients Windows rejetés	Windows utilise par défaut PEAP-MSCHAPv2, qu'Okta RADIUS rejette	Déployer le profil sans fil EAP-TTLS/PAP via MDM ou GPO
Utilisateurs dans le mauvais VLAN	Incohérence du nom de groupe Okta ou attributs de tunnel manquants sur le WLC	Vérifier que le WLC associe `Class`/`Filter-Id` à `Tunnel-Private-Group-ID` ; vérifier les journaux système d'Okta
Agent inaccessible	Serveur hors ligne, jeton API expiré ou pare-feu bloquant le trafic HTTPS vers Okta	Déployer des agents redondants ; surveiller le statut de l'agent dans la console d'administration Okta ; vérifier le HTTPS sortant
Notification Push MFA non reçue	Utilisateur non inscrit à Okta Verify, ou appareil mobile hors ligne	Appliquer la politique d'inscription à Okta Verify ; envisager TOTP comme solution de secours
Erreurs de validation de certificat	Le client ne peut pas valider le certificat du serveur RADIUS	Épingler le CN du certificat serveur dans le profil sans fil du client ; s'assurer que la chaîne d'autorité de certification est approuvée
Attributs VLAN non envoyés	Groupe Okta non inclus dans la configuration de la réponse RADIUS	Vérifier que le groupe figure dans les paramètres RADIUS avancés ; confirmer que l'utilisateur est membre du groupe dans Okta

Pour les secteurs du Transport et public où la disponibilité du réseau est critique, mettez en œuvre une surveillance synthétique qui teste périodiquement l'authentification RADIUS de bout en bout et génère des alertes en cas de défaillance avant que les utilisateurs ne soient impactés.

ROI et impact commercial

L'analyse de rentabilité de l'authentification WiFi Okta RADIUS repose sur trois piliers : l'efficacité opérationnelle, l'amélioration de la posture de sécurité et la conformité.

Efficacité opérationnelle. La centralisation de l'authentification WiFi dans Okta élimine le besoin de maintenir une infrastructure RADIUS locale distincte (serveurs NPS, AD local) sur chaque site. Pour une chaîne hôtelière de 50 établissements, cela représente une réduction significative des coûts d'infrastructure par site et des frais de support informatique. Le provisionnement et le déprovisionnement des utilisateurs deviennent atomiques : l'ajout d'un utilisateur au bon groupe Okta lui accorde simultanément l'accès à l'application et au VLAN WiFi approprié. Lorsqu'un employé s'en va, la désactivation de son compte Okta révoque immédiatement son accès WiFi sur tous les sites.

Posture de sécurité. Le remplacement des mots de passe WiFi PSK partagés par une authentification 802.1X par utilisateur élimine le partage d'identifiants, un vecteur courant de menace interne et d'accès non autorisé. Combiné à l'attribution dynamique de VLAN, cela applique le principe du moindre privilège au niveau de la couche réseau. L'Okta System Log fournit une piste d'audit complète et inviolable de chaque événement d'authentification WiFi, ce qui est essentiel pour la réponse aux incidents.

Conformité. L'exigence 8.3 de la norme PCI DSS 4.0 impose la MFA pour tous les accès administratifs hors console. L'exigence 1.3 requiert une segmentation réseau entre l'environnement des données de titulaires de cartes et les autres réseaux. Okta RADIUS avec attribution de VLAN basée sur les groupes répond directement à ces deux exigences. Pour la conformité GDPR, l'Okta System Log fournit les registres d'accès requis pour démontrer les contrôles techniques appropriés sur les systèmes de traitement des données personnelles. Pour les établissements déployant des Modern Hospitality WiFi Solutions , cette approche unifiée de l'identité et de l'accès réseau est de plus en plus un prérequis pour les achats d'entreprise.

Les organisations qui ont réalisé cette intégration signalent généralement une réduction des tickets d'assistance informatique liés au WiFi (moins de demandes de réinitialisation de mot de passe, moins d'incidents de mauvaise configuration de VLAN) et une amélioration mesurable des scores d'audit de sécurité. L'investissement dans le déploiement et la configuration de l'agent Okta RADIUS — généralement mesuré en jours plutôt qu'en semaines pour un déploiement sur un site unique — génère des économies opérationnelles continues qui se cumulent sur l'ensemble d'un parc distribué.

Définitions clés

Agent Okta RADIUS

Un service proxy léger, sur site ou hébergé dans le cloud, qui traduit les requêtes d'authentification RADIUS provenant de l'infrastructure réseau (points d'accès, WLC) en appels API Okta, permettant ainsi au cloud Okta de servir de backend d'authentification pour le WiFi 802.1X.

Les équipes informatiques y sont confrontées lors du déploiement de l'authentification WiFi d'entreprise basée sur Okta. Il s'agit du composant de transition essentiel entre l'infrastructure réseau héritée basée sur RADIUS et l'identité moderne dans le cloud.

802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports (NAC) qui définit un cadre d'authentification pour les réseaux filaires et sans fil. Elle utilise le protocole d'authentification extensible (EAP) pour transporter les identifiants d'authentification entre le supplicant (appareil), l'authentificateur (AP/commutateur) et le serveur d'authentification (RADIUS).

Le protocole 802.1X est le fondement de la sécurité WiFi d'entreprise. Tout déploiement utilisant WPA2-Enterprise ou WPA3-Enterprise utilise le 802.1X. Les équipes informatiques doivent comprendre le modèle à trois parties (supplicant, authentificateur, serveur d'authentification) pour résoudre les problèmes de connectivité.

EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)

Une méthode EAP qui établit un tunnel TLS en utilisant uniquement un certificat côté serveur, puis transporte un protocole d'authentification interne plus simple (tel que PAP) à l'intérieur du tunnel. Cela protège les identifiants internes contre l'interception tout en ne nécessitant qu'une infrastructure de certificats côté serveur.

EAP-TTLS avec PAP est le protocole recommandé pour l'authentification WiFi Okta RADIUS. Il est plus sécurisé que le PAP simple mais ne nécessite pas de certificats côté client, ce qui le rend pratique pour les environnements BYOD et d'appareils mixtes.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Une méthode EAP qui utilise une authentification mutuelle basée sur des certificats — le client et le serveur présentent tous deux des certificats numériques. C'est la méthode 802.1X la plus sécurisée, offrant une authentification sans mot de passe et résistante au phishing.

EAP-TLS est la référence absolue pour les environnements d'appareils d'entreprise gérés. Il nécessite une infrastructure PKI et un MDM pour la distribution des certificats. L'agent Okta RADIUS ne prend pas en charge nativement EAP-TLS ; un service PKI ou RADIUS cloud dédié est requis.

PAP (Password Authentication Protocol)

Un protocole d'authentification simple qui transmet les noms d'utilisateur et les mots de passe en clair. Dans le contexte du 802.1X, PAP est utilisé comme méthode d'authentification interne au sein d'un tunnel EAP-TTLS, où la couche TLS externe assure le chiffrement.

PAP est le principal mécanisme d'authentification pris en charge par l'agent Okta RADIUS. Les équipes informatiques doivent comprendre que PAP seul n'est pas sécurisé, mais que PAP dans EAP-TTLS est acceptable pour le WiFi d'entreprise lorsque le certificat du serveur est correctement validé.

Dynamic VLAN Assignment

Une technique de contrôle d'accès réseau dans laquelle un serveur RADIUS renvoie des attributs d'attribution de VLAN dans le message Access-Accept, incitant le contrôleur sans fil ou le commutateur à placer le client authentifié sur un VLAN spécifique en fonction de son identité ou de son appartenance à un groupe, plutôt que sur un VLAN statique par SSID.

L'attribution dynamique de VLAN est essentielle pour la segmentation du réseau dans les environnements multi-rôles (par exemple, pour séparer les terminaux de point de vente des appareils du personnel général). Elle est configurée en renvoyant les attributs RADIUS 64, 65 et 81 dans le message Access-Accept.

Attribut RADIUS 25 (Class)

Un attribut RADIUS standard utilisé pour transmettre des données d'autorisation arbitraires du serveur d'authentification au NAS. Okta utilise cet attribut pour renvoyer les informations d'appartenance aux groupes Okta au contrôleur sans fil, qui peut ensuite les utiliser pour l'attribution de VLAN ou les décisions de politique d'accès.

Les équipes informatiques qui configurent l'attribution de VLAN basée sur les groupes Okta configureront le WLC pour lire la valeur de l'attribut Class et la mapper à un ID de VLAN. L'attribut exact à utiliser (11, 25 ou 26) dépend de la documentation du fournisseur du WLC.

NAS (Network Access Server)

Dans la terminologie RADIUS, le NAS est l'équipement réseau qui reçoit la demande de connexion de l'utilisateur et la transmet au serveur RADIUS pour authentification. Dans les déploiements WiFi, le NAS est généralement le point d'accès sans fil ou le contrôleur LAN sans fil.

Le NAS est l'authentificateur dans le modèle 802.1X. Les équipes informatiques doivent configurer le NAS avec l'adresse IP, le port et le secret partagé du serveur RADIUS. L'adresse IP du NAS doit être mise sur liste blanche dans la configuration de filtrage d'adresses de service de l'agent Okta RADIUS.

Shared Secret

Un mot de passe pré-partagé utilisé pour authentifier les messages RADIUS entre le NAS (WLC/AP) et le serveur RADIUS (agent Okta RADIUS). Il est utilisé pour calculer un hachage Message-Authenticator qui vérifie l'intégrité des paquets RADIUS.

Le secret partagé doit être identique dans la configuration de l'application Okta RADIUS et dans l'entrée du serveur RADIUS du WLC/NAC. Il doit comporter au moins 32 caractères, être généré de manière aléatoire et faire l'objet d'une rotation régulière. Une incompatibilité est une cause fréquente d'échec de l'authentification RADIUS.

MFA Challenge (RADIUS Access-Challenge)

Un type de message RADIUS envoyé par le serveur d'authentification au NAS lorsque des facteurs d'authentification supplémentaires sont requis. Le NAS transmet le défi au client, qui doit répondre avec le facteur approprié (par exemple, OTP, approbation push) avant que l'authentification puisse être finalisée.

Le mécanisme Access-Challenge est la manière dont Okta applique l'authentification multifacteur (MFA) via RADIUS. Les équipes informatiques doivent s'assurer que le WLC prend en charge l'échange défi-réponse et que le délai d'expiration de RADIUS est suffisamment long pour que l'utilisateur puisse terminer l'étape MFA.

Exemples concrets

Une chaîne hôtelière de 150 établissements utilise actuellement des serveurs NPS sur site dans chaque établissement pour l'authentification WiFi du personnel via 802.1X. Chaque serveur NPS est rattaché à un domaine Active Directory local. L'équipe informatique souhaite centraliser la gestion des identités dans Okta et éliminer l'infrastructure NPS par établissement. Comment doivent-ils aborder la migration ?

L'approche recommandée est une migration progressive utilisant l'agent Okta RADIUS déployé dans un VPC cloud centralisé plutôt que dans chaque établissement. Étape 1 : Déployer deux instances de l'agent Okta RADIUS dans un VPC cloud (par exemple, AWS ou Azure) dans la même région que la majorité des établissements. Configurer les agents pour écouter sur le port UDP 1812. Étape 2 : Pour chaque établissement, ajouter les adresses IP de l'agent Okta RADIUS comme serveurs RADIUS secondaires sur le contrôleur WiFi (WLC), en conservant le NPS existant comme serveur principal. Cela permet un fonctionnement et des tests en parallèle sans perturber l'authentification en direct. Étape 3 : Migrer les utilisateurs de l'AD local vers Okta. Utiliser l'agent AD d'Okta pour synchroniser initialement les comptes existants, puis passer progressivement à Okta comme source faisant foi. Étape 4 : Pour chaque établissement, configurer le WLC pour utiliser EAP-TTLS/PAP et déployer le nouveau profil sans fil sur les appareils du personnel via un MDM. Étape 5 : Une fois que tous les appareils sont confirmés sur EAP-TTLS, basculer la priorité RADIUS du WLC vers les agents Okta en tant que serveurs principaux et démanteler les serveurs NPS. Configurer les groupes Okta (Front-Desk, Housekeeping, F&B, Management, IT-Admins) et activer l'attribution de VLAN basée sur les groupes à l'aide de l'attribut 25 (Class). Associer chaque groupe au VLAN approprié sur le WLC. Augmenter le délai d'expiration (timeout) RADIUS du WLC à 45 secondes pour tenir compte de la latence de l'API Okta.

Commentaire de l'examinateur : Cette approche progressive est privilégiée car elle élimine le risque d'une transition brutale simultanée sur 150 établissements. Le fonctionnement en parallèle de NPS et d'Okta RADIUS pendant la période de transition permet de détecter et de corriger toute mauvaise configuration sans impact pour les utilisateurs actifs. Le déploiement des agents RADIUS dans un VPC cloud est architecturalement supérieur à un déploiement par établissement car il centralise la gestion, réduit l'empreinte de l'infrastructure et garantit l'application cohérente des politiques, quel que soit l'établissement depuis lequel un utilisateur s'authentifie. Le principal risque à atténuer est la latence WAN entre l'établissement et le VPC cloud — l'authentification RADIUS doit s'effectuer en moins de 2 secondes pour offrir une bonne expérience utilisateur, le choix de la région du VPC doit donc minimiser le temps d'aller-retour.

Une chaîne de vente au détail nationale comptant 320 magasins doit se conformer à la norme PCI DSS 4.0 pour le WiFi de son personnel. Les vendeurs utilisent des terminaux portables pour la gestion des stocks, et un autre ensemble d'appareils gère les transactions aux points de vente. La chaîne utilise Okta pour l'ensemble des identités de ses collaborateurs. Comment mettre en œuvre la segmentation VLAN à l'aide d'Okta RADIUS pour répondre aux exigences de segmentation réseau de la norme PCI DSS ?

Créer trois groupes Okta : POS-Staff (pour les employés utilisant les terminaux de point de vente), Inventory-Staff (pour les collaborateurs des entrepôts et des surfaces de vente) et Store-Management. Dans l'application Okta RADIUS, activer "Include groups in RADIUS response" et sélectionner l'attribut 25 (Class). Ajouter les trois groupes à la configuration de la réponse. Sur le contrôleur sans fil de chaque magasin (ou centralisé via un WLC cloud), créer trois politiques d'application : (1) Si Class = POS-Staff, attribuer Tunnel-Private-Group-ID = 40 (le VLAN POS, qui entre dans le champ d'application de la norme PCI DSS et dispose de règles de pare-feu limitant l'accès au seul processeur de paiement). (2) Si Class = Inventory-Staff, attribuer Tunnel-Private-Group-ID = 50 (le VLAN d'inventaire, hors du champ d'application PCI). (3) Si Class = Store-Management, attribuer Tunnel-Private-Group-ID = 60 (le VLAN d'administration ayant accès aux systèmes de gestion du magasin). Les appareils se connectant avec les identifiants d'un utilisateur du groupe POS-Staff sont automatiquement placés sur le VLAN 40. Si le rôle d'un vendeur change, la mise à jour de son appartenance aux groupes Okta modifie immédiatement son attribution de VLAN lors de sa prochaine connexion — aucune reconfiguration du WLC n'est requise. Documenter la correspondance entre les groupes Okta et les VLAN dans le schéma de segmentation réseau pour l'audit QSA PCI DSS.

Commentaire de l'examinateur : Cette mise en œuvre répond directement à l'exigence 1.3 de la norme PCI DSS 4.0 (segmentation réseau) et à l'exigence 7 (contrôle d'accès basé sur les besoins de l'entreprise). L'élément clé est que l'attribution du VLAN est dictée par l'identité, et non par l'adresse MAC de l'appareil ou une configuration VLAN statique — ce qui signifie qu'elle s'adapte à l'échelle des 320 magasins sans maintenance de politique VLAN par magasin. L'auditeur QSA voudra s'assurer que le VLAN POS est réellement isolé des autres segments réseau, les configurations du WLC et du pare-feu doivent donc refléter les limites du VLAN. Le journal système (System Log) d'Okta fournit la piste d'audit d'authentification requise par l'exigence 10 de la norme PCI DSS (journalisation et surveillance). Une mise en garde importante : si les terminaux de point de vente ne sont pas gérés ou sont partagés (c'est-à-dire non attribués à un utilisateur spécifique), envisagez d'utiliser le bypass d'authentification MAC (MAB) pour ces appareils plutôt que le 802.1X, Okta RADIUS n'étant alors utilisé que pour les appareils authentifiés par l'utilisateur.

Questions d'entraînement

Q1. Un centre de conférences de taille moyenne utilise Okta pour la gestion des identités de tout son personnel. Il souhaite déployer un réseau WiFi 802.1X pour le personnel en utilisant ses points d'accès Cisco Meraki existants. Leurs ordinateurs portables Windows sont gérés via Microsoft Intune. Le responsable informatique souhaite imposer l'authentification MFA par notification push Okta Verify pour toutes les connexions WiFi. Quelles sont les trois étapes de configuration les plus critiques qu'ils doivent effectuer, et quel est le mode de défaillance le plus probable s'ils omettent l'une d'entre elles ?

Conseil : Considérez la compatibilité du protocole EAP entre Okta RADIUS et les paramètres par défaut de Windows, le paramètre de timeout RADIUS et la configuration du profil sans fil du client.

Voir la réponse type

Les trois étapes critiques sont : (1) Déployer un profil sans fil via Intune qui configure les clients Windows pour utiliser EAP-TTLS avec PAP comme méthode interne — Windows utilise par défaut PEAP-MSCHAPv2, qui n'est pas pris en charge par l'agent Okta RADIUS, ce qui entraînerait le rejet de toutes les tentatives d'authentification. (2) Augmenter le timeout RADIUS de Cisco Meraki de la valeur par défaut de 5 secondes à au moins 45-60 secondes — sans cela, la demande d'authentification expirera avant que l'utilisateur ne puisse approuver la notification push Okta Verify. (3) Activer 'Permit Automatic Push for Okta Verify Enrolled Users' dans les paramètres RADIUS avancés de l'application Okta RADIUS — sans cela, les utilisateurs risquent d'être invités à sélectionner manuellement leur facteur MFA plutôt que de recevoir une notification push automatique. Le mode de défaillance le plus probable si l'étape 1 est omise est un échec complet d'authentification pour tous les appareils Windows. Si l'étape 2 est omise, l'authentification échouera par intermittence pour les utilisateurs qui mettent plus de 5 secondes à approuver la notification push. Si l'étape 3 est omise, les utilisateurs seront confrontés à une invite de vérification confuse plutôt qu'à une notification push fluide.

Q2. L'équipe de sécurité d'une grande chaîne de vente au détail a signalé que son déploiement WiFi Okta RADIUS actuel utilise un seul serveur d'agent RADIUS. Lors d'une récente période de maintenance, le serveur a été hors ligne pendant 45 minutes, entraînant l'échec de l'authentification WiFi dans les 80 magasins. Quels changements d'architecture l'équipe informatique doit-elle mettre en œuvre pour éviter cela, et quelles sont les deux options de déploiement pour les agents ?

Conseil : Considérez à la fois la topologie de déploiement de l'agent et la configuration du WLC requise pour assurer la redondance.

Voir la réponse type

L'équipe informatique doit déployer au minimum deux instances d'agent Okta RADIUS et configurer le WLC de chaque magasin pour utiliser les deux agents. Il existe deux options de déploiement : Option A (VMs Cloud centralisées) — déployer les deux agents dans un VPC cloud (par exemple, AWS ou Azure), idéalement dans des zones de disponibilité différentes. Le WLC de chaque magasin pointe vers les deux adresses IP cloud, l'une comme principale et l'autre comme secondaire (ou avec l'équilibrage de charge activé). Cela minimise l'infrastructure par site mais introduit une dépendance au réseau WAN. Option B (Paire redondante sur site) — déployer deux serveurs d'agent dans un centre de données central ou un site d'hébergement, le WLC utilisant le basculement RADIUS. Sur le WLC, configurez le serveur RADIUS principal comme Agent 1 et le secondaire comme Agent 2, avec un timeout de basculement de 3 à 5 secondes. Activez la détection de serveur défaillant ('Dead Server Detection') si elle est prise en charge par le fournisseur du WLC. De plus, l'équipe informatique doit configurer la surveillance de l'état dans la console d'administration Okta et configurer des alertes si un agent passe hors ligne. Pour les magasins disposant de serveurs locaux, un agent local peut servir de secours tertiaire pour assurer la résilience face aux pannes WAN.

Q3. Une entreprise évalue s'il convient d'utiliser l'agent Okta RADIUS avec EAP-TTLS/PAP ou d'investir dans une solution PKI cloud pour EAP-TLS pour leur WiFi d'entreprise. Elle dispose de 2 000 appareils Windows et macOS gérés, enregistrés dans Microsoft Intune, et est soumise à la norme PCI DSS 4.0. Quelle est l'approche recommandée et quelle est la principale justification de sécurité ?

Conseil : Considérez les exigences de la norme PCI DSS, la maturité de la gestion des appareils (tous les appareils sont enregistrés dans un MDM) et les propriétés de sécurité de chaque méthode d'authentification.

Voir la réponse type

L'approche recommandée est d'investir dans EAP-TLS avec une solution PKI cloud. La principale justification de sécurité est l'authentification mutuelle : EAP-TLS exige que le client et le serveur RADIUS présentent tous deux des certificats numériques, ce qui signifie que l'appareil prouve son identité de manière cryptographique au réseau et que le réseau prouve son identité à l'appareil. Cela élimine le risque d'attaques de type « evil twin » (où un point d'accès frauduleux usurpe l'SSID de l'entreprise) et supprime totalement les mots de passe de l'équation d'authentification WiFi, éliminant ainsi le vol d'identifiants et le phishing comme vecteurs d'attaque. Pour PCI DSS 4.0, EAP-TLS satisfait implicitement à l'exigence 8.3 (MFA pour l'accès administrateur hors console) grâce à l'authentification par certificat, et prend en charge le mode WPA3-Enterprise 192 bits (exigence 4.2.1 pour une cryptographie forte). Le prérequis — tous les 2 000 appareils enregistrés dans Intune — est déjà rempli, ce qui simplifie la distribution des certificats via les profils SCEP d'Intune. L'agent Okta RADIUS avec EAP-TTLS/PAP serait une solution temporaire acceptable pendant la phase de construction de la PKI, mais compte tenu du périmètre PCI DSS et du parc d'appareils entièrement gérés, EAP-TLS est la bonne architecture à long terme. L'investissement supplémentaire dans un service PKI cloud (généralement de 3 à 8 $ par appareil et par an) est justifié par l'amélioration de la sécurité et la réduction de la charge de gestion des identifiants.

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.

Intégration des points d'accès Allied Telesis avec Purple WiFi

Ce guide fournit un manuel de configuration complet pour l'intégration des points d'accès Allied Telesis de la série TQ avec Purple WiFi. Il traite de la redirection vers le Captive Portal externe, de l'authentification RADIUS 802.1X et de l'orientation VLAN dynamique à l'aide de clés prépartagées privées (PPSK) pour des déploiements multi-locataires sécurisés.

Intégration des points d'accès Grandstream GWN avec Purple WiFi

Ce guide de référence technique officiel détaille comment intégrer les points d'accès Grandstream GWN avec le Guest WiFi de Purple et sa plateforme d'analyse. Il couvre la configuration du Captive Portal Grandstream, les paramètres RADIUS AAA, la configuration du walled garden, l'authentification sécurisée du personnel en 802.1X avec routage dynamique des VLAN, et la segmentation PPSK multi-tenant - offrant ainsi des instructions étape par étape directement exploitables pour les MSP et les équipes informatiques déployant du WiFi invités et personnel à grande échelle.