Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication

Questa guida fornisce un riferimento tecnico completo per gli amministratori IT delle organizzazioni incentrate su Okta che desiderano estendere il proprio identity provider cloud all'autenticazione WiFi utilizzando l'agente RADIUS di Okta. Copre l'intera architettura di autenticazione, i compromessi nell'applicazione dell'MFA, l'assegnazione dinamica della VLAN tramite la mappatura degli attributi RADIUS e la decisione critica tra EAP-TTLS basato su password ed EAP-TLS basato su certificati. I gestori di sedi e i team IT aziendali troveranno linee guida di implementazione pronte all'uso, casi di studio reali provenienti dai settori hospitality e retail e un framework chiaro per l'integrazione di Okta RADIUS con soluzioni di guest WiFi dedicate.

📖 11 minuti di lettura📝 2,672 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Benvenuti al Technical Briefing di Purple. Oggi approfondiremo un argomento che si colloca esattamente all'intersezione tra l'architettura di rete e la gestione delle identità: Okta e RADIUS per l'autenticazione WiFi. Se siete responsabili IT, architetti di rete o direttori delle operazioni di una sede, conoscete già il mal di testa legato alla gestione di credenziali separate per l'accesso alla rete. Avete la vostra directory Okta per le applicazioni cloud, ma forse il vostro WiFi si affida ancora a un server Active Directory legacy o, peggio, a una password WPA2 condivisa e appesa al muro della sala relax. Oggi vedremo come colmare questo divario utilizzando l'agente Okta RADIUS. Analizzeremo l'architettura, come gestire la Multi-Factor Authentication sul WiFi, i compromessi critici tra l'autenticazione basata su password e quella basata su certificati, e come mappare i gruppi di Okta sugli attributi RADIUS per l'assegnazione dinamica delle VLAN. Cominciamo.

Partiamo dall'architettura. Come funziona effettivamente l'agente Okta RADIUS? L'agente Okta RADIUS è un'applicazione leggera che si distribuisce on-premises — solitamente su un server Windows o Linux — o in una macchina virtuale cloud. Funziona come un proxy. Si posiziona tra la vostra infrastruttura di rete, come gli access point wireless o il controller LAN wireless, e il cloud di Okta. Quando un utente tenta di connettersi al vostro WiFi aziendale 802.1X, il suo dispositivo invia le credenziali all'access point. L'access point, che funge da autenticatore nel modello 802.1X, inoltra una richiesta RADIUS Access-Request all'agente Okta RADIUS tramite la porta UDP 1812. L'agente prende la richiesta e la convoglia in modo sicuro verso il cloud di Okta tramite una chiamata API HTTPS. Okta convalida le credenziali, verifica i criteri di accesso e restituisce una decisione. L'agente traduce quindi tale risposta in un messaggio RADIUS Access-Accept o Access-Reject per l'access point. È un modo intelligente per estendere il vostro provider di identità cloud fino al perimetro della rete locale senza esporre direttamente la directory a Internet.

Ora, la grande domanda che tutti si pongono: è possibile imporre l'MFA di Okta sulle connessioni WiFi? La risposta breve è sì, ma con importanti riserve. L'agente RADIUS di Okta supporta principalmente il Password Authentication Protocol, o PAP. Poiché il PAP invia la password in chiaro, questa viene incapsulata e protetta dal tunnel TLS esterno del protocollo EAP (Extensible Authentication Protocol). Questa configurazione consente all'agente di gestire i controlli MFA. È possibile configurare Okta per inviare una notifica push di Okta Verify sul telefono dell'utente, o richiedere di aggiungere un codice TOTP (Time-Based One-Time Password) alla password. Tuttavia, è proprio qui che l'esperienza utente si scontra con la sicurezza. Immagina di chiedere a un addetto alle vendite di un negozio retail di approvare una notifica push ogni volta che il suo telefono si riconnette al WiFi dello staff mentre si sposta nel punto vendita. Questo crea notevoli attriti. Inoltre, molti dispositivi moderni interrompono la connessione WiFi se la risposta al controllo MFA richiede troppo tempo. Quindi, sebbene l'MFA su WiFi sia tecnicamente possibile e supportato da Okta, generalmente lo consigliamo solo per accessi con privilegi elevati, come gli SSID degli amministratori IT, piuttosto che per il WiFi del personale generico.

Questo ci porta al compromesso fondamentale: RADIUS basato su password con Okta rispetto all'autenticazione basata su certificati, in particolare EAP-TLS. Quando si utilizza l'agente RADIUS di Okta con EAP-TTLS o PAP, ci si affida alle password. Le password possono essere rubate, violate tramite phishing o condivise. Inoltre, come abbiamo appena visto, l'aggiunta dell'MFA al WiFi è poco pratica all'atto pratico. D'altra parte, EAP-TLS utilizza certificati digitali distribuiti sul dispositivo dell'utente. Fornisce un'autenticazione reciproca: il dispositivo dimostra la propria identità alla rete e la rete dimostra la propria identità al dispositivo. Non ci sono password da digitare ed è altamente resistente al phishing. Il punto debole? L'agente RADIUS di Okta non funge nativamente da Certificate Authority. Se si desidera EAP-TLS, è necessaria una Public Key Infrastructure, o PKI — soluzioni come SecureW2, Foxpass o Microsoft Active Directory Certificate Services — e una soluzione di Mobile Device Management per distribuire i certificati ai dispositivi aziendali. Okta può comunque fungere da identity provider che autorizza l'emissione dei certificati, ma l'agente RADIUS stesso non si occuperà del lavoro più impegnativo per EAP-TLS. Per gli ambienti BYOD, il RADIUS di Okta basato su password è rapido e facile da implementare. Per i dispositivi aziendali gestiti, EAP-TLS rappresenta il gold standard.

Passiamo ora a una delle funzionalità più potenti: l'assegnazione dinamica della VLAN. In una struttura di grandi dimensioni — come un hotel, uno stadio o un centro congressi — non si desidera che tutto il personale si trovi sullo stesso segmento di rete. Si vuole che i terminali dei punti vendita (POS) siano isolati dai tablet del servizio di pulizia e che il personale IT si trovi su una VLAN di gestione. Come si ottiene questo risultato con Okta? Tutto si basa sulla mappatura degli attributi RADIUS. Nella Console di amministrazione di Okta, nelle impostazioni dell'applicazione RADIUS, è possibile abilitare una funzionalità chiamata Include groups in RADIUS response. È possibile specificare quali gruppi Okta devono essere restituiti nella risposta di autenticazione. Okta trasmette l'appartenenza a questo gruppo al controller di rete utilizzando gli attributi RADIUS standard — in genere l'Attributo 11 per Filter-ID o l'Attributo 25 per Class. Il controller wireless o il sistema di Network Access Control, come Aruba ClearPass o Cisco ISE, riceve questo nome di gruppo. Successivamente, si configura una policy locale sul controller che stabilisce, ad esempio, che se l'Attributo RADIUS 25 è uguale a Retail-POS, il client viene assegnato alla VLAN 40. Il controller invia gli attributi del tunnel standard — Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID — all'access point, inserendo dinamicamente l'utente nella VLAN corretta. Si tratta di un modo fluido per applicare la segmentazione della rete basandosi esclusivamente sull'identità Okta, il che è straordinariamente efficace per la conformità a standard come il PCI DSS, che richiede una rigida segmentazione della rete intorno agli ambienti dei dati dei titolari di carta.

Esaminiamo ora alcuni scenari di implementazione reali. Consideriamo una catena alberghiera nazionale con strutture in tutto il Regno Unito. Ogni struttura presenta un mix di personale della reception, delle pulizie, della ristorazione e del management. In precedenza, ogni struttura gestiva il proprio server NPS con un Active Directory locale. Il team IT dedicava molto tempo alla gestione degli account locali e alla risoluzione dei problemi relativi ai guasti RADIUS. Distribuendo l'agente RADIUS di Okta in una coppia di macchine virtuali cloud ridondanti, centralizzando tutti gli account utente in Okta e configurando l'assegnazione delle VLAN basata sui gruppi, la catena ha ridotto significativamente i costi di gestione IT per singola struttura. Il personale della reception esegue l'autenticazione con le proprie credenziali Okta e viene inserito automaticamente nella VLAN dei servizi per gli ospiti. Il personale di gestione, che fa parte di un gruppo Okta diverso, accede alla VLAN di gestione con accesso ai sistemi di gestione della proprietà. L'intera configurazione viene gestita da un'unica Console di amministrazione di Okta, e il registro di sistema di Okta fornisce un audit trail completo di ogni evento di autenticazione in tutte le strutture.

Un secondo scenario: una grande catena di vendita al dettaglio con oltre 300 negozi. Ogni negozio dispone di una rete WiFi per il personale utilizzata per la gestione dell'inventario, i terminali per i punti vendita e le operazioni di back-office. La conformità PCI DSS richiede una rigorosa segmentazione della rete tra l'ambiente dei dati dei titolari di carta e l'accesso generale del personale. Integrando Okta RADIUS con l'infrastruttura wireless esistente, il rivenditore mappa i gruppi Okta — POS-Staff, Inventory-Staff e Store-Management — su tre VLAN distinte. Quando un dipendente del negozio si connette, il suo dispositivo viene inserito automaticamente nella VLAN corretta in base alla sua appartenenza al gruppo Okta. Se un dipendente cambia ruolo, l'aggiornamento della sua appartenenza al gruppo Okta modifica immediatamente il suo accesso alla rete alla connessione successiva. Nessuna regola del firewall da aggiornare, nessuna configurazione VLAN da inviare ai singoli negozi.

Ora, esaminiamo le raccomandazioni di implementazione e gli errori più comuni. Il primo errore, e il più comune, consiste nel trascurare le impostazioni di timeout. Le chiamate API di Okta richiedono tempo, soprattutto se è coinvolto un push MFA. Se il timeout RADIUS del controller wireless è impostato sul valore predefinito di tre o cinque secondi, la richiesta andrà in timeout prima che l'utente possa toccare "Approva" sul proprio telefono. È necessario aumentare il timeout RADIUS sul WLC ad almeno trenta o sessanta secondi. Si tratta di una modifica di configurazione sul lato rete, non in Okta, e viene spesso trascurata. La seconda raccomandazione riguarda l'alta affidabilità. Non distribuire mai un solo agente Okta RADIUS. Distribuisci almeno due agenti su server separati e configura il controller wireless per il bilanciamento del carico tra di essi. Se un server si arresta per l'applicazione di patch, l'autenticazione WiFi rimane attiva. Il terzo errore: attenzione a PEAP. L'agente Okta RADIUS non supporta PEAP-MSCHAPv2, che è il valore predefinito per molti ambienti Windows più vecchi. È necessario configurare i client per l'utilizzo di EAP-TTLS con PAP. Ciò richiede in genere l'invio di un profilo wireless tramite Criteri di gruppo o MDM, poiché Windows non passa facilmente a EAP-TTLS come impostazione predefinita. La mancata esecuzione di questa operazione è la causa principale del fallimento delle distribuzioni.

È il momento di una sessione di domande e risposte rapide basata sulle domande più comuni dei clienti. Domanda uno: possiamo usare Okta RADIUS per il WiFi degli ospiti? Risposta: No. Okta ha un prezzo per utente ed è progettato per l'identità aziendale. Per il WiFi degli ospiti, dovresti usare una soluzione Captive Portal dedicata, che gestisce i termini di servizio, il login social e l'analitica senza consumare licenze Okta. Domanda due: Okta RADIUS supporta le YubiKey per l'autenticazione WiFi? Risposta: In genere no. I token hardware e WebAuthn non si integrano bene con il protocollo RADIUS. Rimani su Okta Verify push o TOTP se devi assolutamente usare l'MFA sul WiFi. Domanda tre: in che modo questo interagisce con un'implementazione Purple? Risposta: Molto bene. I clienti enterprise di Purple che utilizzano Okta come provider di identità possono usare Okta RADIUS per autenticare in modo sicuro il WiFi del personale, utilizzando al contempo il Captive Portal di Purple per l'accesso degli ospiti su un SSID separato. Questo posiziona Purple a fianco di Okta in uno stack di autenticazione moderno e unificato: il personale su un SSID con Okta RADIUS, gli ospiti su un altro con il portale personalizzato di Purple.

Per riassumere il briefing di oggi: l'agente Okta RADIUS è uno strumento potente per eliminare le directory legacy on-premises e unificare l'autenticazione WiFi nel tuo provider di identità cloud. Supporta l'assegnazione dinamica delle VLAN per una segmentazione robusta della rete, fondamentale per la conformità con PCI DSS e altri framework. Tuttavia, presta attenzione all'esperienza utente se imponi l'MFA sul WiFi, e ricorda che per i dispositivi aziendali completamente gestiti, la migrazione a EAP-TLS basato su certificati con una PKI dedicata rappresenta la strategia a lungo termine più sicura. L'agente Okta RADIUS è un'eccellente soluzione ponte, in particolare per le organizzazioni focalizzate su Okta che desiderano estendere rapidamente l'investimento sull'identità al livello di rete. Questo è tutto per il briefing di oggi. Assicurati di consultare la guida di riferimento tecnico completa per i passaggi dettagliati di configurazione, i diagrammi di architettura e gli esempi pratici. Alla prossima, mantieni le tue reti sicure e i tuoi utenti connessi.

Punti chiave

✓L'agente Okta RADIUS inoltra le richieste di autenticazione WiFi 802.1X dall'infrastruttura di rete al cloud Okta tramite HTTPS, consentendo all'identità cloud di governare l'accesso alla rete senza server di directory on-premises.
✓L'agente supporta EAP-TTLS con PAP ed EAP-GTC, ma NON supporta PEAP-MSCHAPv2 (l'impostazione predefinita di Windows) o EAP-TLS — i supplicant client devono essere riconfigurati tramite MDM o GPO prima della distribuzione.
✓L'MFA su WiFi è tecnicamente supportata (push Okta Verify, TOTP, SMS) ma richiede l'aumento del timeout RADIUS del WLC a 30-60 secondi; è preferibile riservarla agli SSID amministrativi piuttosto che alla rete WiFi del personale generico a causa dell'attrito durante il roaming.
✓L'assegnazione dinamica della VLAN si ottiene abilitando "Includi gruppi nella risposta RADIUS" in Okta e mappando la classe restituita (Attributo 25) o il Filter-Id (Attributo 11) agli attributi del tunnel VLAN (64, 65, 81) sul WLC o sull'appliance NAC.
✓Distribuisci sempre un minimo di due istanze dell'agente Okta RADIUS per l'alta affidabilità — un singolo agente rappresenta un singolo punto di errore critico per tutta l'autenticazione WiFi nell'intera infrastruttura.
✓Per ambienti di dispositivi completamente gestiti soggetti a PCI DSS o a requisiti di alta sicurezza, EAP-TLS con una PKI cloud è l'architettura a lungo termine superiore; Okta RADIUS con EAP-TTLS/PAP è la scelta pragmatica per scenari BYOD o distribuzioni rapide.
✓Okta RADIUS è uno strumento di identità aziendale — distribuisci una soluzione di Captive Portal WiFi per ospiti dedicata per l'accesso dei visitatori, per evitare costi di scalabilità delle licenze Okta e mantenere una netta separazione tra l'accesso alla rete del personale e quello degli ospiti.

Executive Summary

Per i team IT aziendali che gestiscono sedi distribuite — dalle catene alberghiere agli stadi — l'unificazione del controllo degli accessi alla rete con un provider di identità cloud è un passo fondamentale verso il modello Zero Trust. L'agente Okta RADIUS colma il divario tra la moderna identità cloud e l'infrastruttura WiFi 802.1X tradizionale, consentendo alle organizzazioni di eliminare i server RADIUS on-premises legacy e l'infrastruttura Active Directory per l'autenticazione di rete.

Questa guida illustra in dettaglio come distribuire l'agente Okta RADIUS per l'autenticazione WiFi aziendale, coprendo l'architettura proxy, i meccanismi di applicazione dell'MFA e i compromessi tra EAP-TTLS basato su password ed EAP-TLS basato su certificati. Fornisce inoltre indicazioni pratiche sulla mappatura delle appartenenze ai gruppi Okta agli attributi RADIUS per l'assegnazione dinamica delle VLAN — una funzionalità che supporta direttamente i requisiti di segmentazione della rete PCI DSS. Integrando Okta per l'autenticazione del personale insieme alle soluzioni Guest WiFi , i gestori delle sedi possono ottenere un livello di accesso unificato, sicuro e conforme senza duplicare l'infrastruttura di identità.

Technical Deep-Dive

Come funziona l'agente Okta RADIUS

L'agente Okta RADIUS è un servizio di sistema leggero che funge da proxy tra i Network Access Server (NAS) — come gli access point wireless (WAP) o i controller LAN wireless (WLC) — e il cloud Okta. Di solito viene distribuito su un server Windows o Linux on-premises o all'interno di un VPC cloud, e viene gestito interamente dall'Okta Admin Console dopo l'installazione iniziale.

Il flusso di autenticazione segue un modello proxy 802.1X standard. Il dispositivo di un utente (il supplicant) si connette a un SSID aziendale e presenta le credenziali. Il WAP o il WLC (l'authenticator) inoltra una richiesta RADIUS Access-Request all'agente Okta RADIUS tramite la porta UDP 1812. L'agente incanala in modo sicuro questa richiesta al cloud Okta tramite una chiamata API HTTPS, dove il motore di policy di Okta valuta le credenziali rispetto alla sua directory utente e alle policy di accesso configurate. Se l'autenticazione ha successo, l'agente restituisce un messaggio RADIUS Access-Accept all'authenticator, includendo facoltativamente attributi RADIUS per l'autorizzazione come l'assegnazione della VLAN. Se è richiesto l'MFA, l'agente invia una richiesta RADIUS Access-Challenge al client, richiedendo un secondo fattore prima che venga restituita la decisione finale.

Questo modello proxy significa che l'agente Okta RADIUS non ha bisogno di memorizzare localmente le credenziali utente. Tutta la logica di autenticazione, la valutazione delle policy e la registrazione dei log di controllo avvengono nel cloud Okta, offrendo agli amministratori un'unica console di gestione per la governance delle identità sia per le applicazioni cloud che per l'accesso alla rete.

Protocolli EAP supportati e limitazioni critiche

Un vincolo architetturale fondamentale dell'agente Okta RADIUS è la sua dipendenza dal Password Authentication Protocol (PAP) per l'autenticazione primaria. Sebbene il PAP trasmetta le password in chiaro nel livello interno, queste vengono incapsulate e protette dal tunnel TLS esterno dell'Extensible Authentication Protocol (EAP). I protocolli esterni supportati sono EAP-TTLS (con PAP come metodo interno) ed EAP-GTC. Per un confronto più approfondito dei metodi EAP, consultare la guida di riferimento Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST .

In particolare, PEAP-MSCHAPv2 non è supportato. Questo è il protocollo 802.1X predefinito per i client Windows e molti ambienti aziendali legacy. Le organizzazioni che migrano da una configurazione RADIUS NPS/Active Directory tradizionale devono riconfigurare i supplicant dei propri client per utilizzare EAP-TTLS con PAP — una modifica che in genere richiede la distribuzione di un profilo wireless tramite MDM o Group Policy. La mancata considerazione di questo aspetto è la causa più comune di fallimento delle implementazioni di Okta RADIUS.

EAP-TLS, che si basa interamente sull'autenticazione reciproca basata su certificati, non è supportato nativamente dall'agente Okta RADIUS. Le organizzazioni che richiedono EAP-TLS devono implementare una PKI dedicata o una soluzione RADIUS cloud che si integri con Okta come IdP tramite SAML o OIDC, anziché utilizzare direttamente l'agente Okta RADIUS.

Forzare la MFA sulle connessioni WiFi

L'agente Okta RADIUS supporta la MFA per l'accesso WiFi, ma introduce sfide relative all'esperienza utente che devono essere attentamente valutate prima della distribuzione. Quando viene attivata una policy MFA, l'agente invia un Access-Challenge RADIUS al client. Okta supporta diversi fattori per le applicazioni RADIUS:

Fattore MFA	PAP	EAP-TTLS	Note
Okta Verify Push	Supportato	Supportato	Inviato fuori banda; l'utente tocca Approva sul dispositivo mobile
TOTP (Okta Verify / Google Auth)	Supportato	Supportato	L'utente aggiunge la OTP alla password (es. `Pass123,456789`)
SMS / Email / Voice	Supportato	Supportato	L'utente invia prima la stringa di attivazione (SMS, EMAIL, CALL)
Duo Push / SMS / Passcode	Supportato	Supportato	Passcode Duo solo per EAP-TTLS
YubiKey / U2F / Windows Hello	Non supportato	Non supportato	Token hardware incompatibili con il protocollo RADIUS

Il vincolo pratico è il roaming. Negli ambienti Hospitality , il tablet di un addetto alle pulizie può effettuare il roaming tra i punti di accesso dozzine di volte per turno, attivando ogni volta la riautenticazione. Richiedere l'approvazione di una notifica push a ogni roaming è insostenibile dal punto di vista operativo. Per il WiFi del personale generico, le policy relative a password complesse, combinate con le policy di trust del dispositivo e delle zone di rete di Okta, sono in genere preferibili ai prompt MFA attivi. La MFA su WiFi dovrebbe essere riservata a SSID amministrativi o scenari di accesso ad alto privilegio.

Autenticazione basata su password rispetto a quella basata su certificati

La scelta tra RADIUS basato su password (tramite l'agente Okta RADIUS) ed EAP-TLS basato su certificati è una delle decisioni di maggior impatto in un'implementazione WiFi aziendale. I compromessi non riguardano semplicemente la sicurezza; coinvolgono la complessità dell'implementazione, la maturità della gestione dei dispositivi e i costi operativi.

L'autenticazione basata su password tramite l'agente Okta RADIUS offre un percorso rapido verso un'identità unificata. Se la tua organizzazione gestisce già gli utenti in Okta, l'implementazione può essere completata in poche ore anziché in settimane. Non c'è alcuna PKI da creare, nessun certificato da distribuire e nessuna dipendenza da MDM. Il compromesso è che le password rimangono la credenziale principale e l'assenza di autenticazione reciproca significa che il client non può verificare crittograficamente l'identità della rete — un vettore per attacchi evil twin in ambienti ad alto rischio.

EAP-TLS basato su certificati elimina completamente le password dall'equazione di autenticazione WiFi. Il client presenta un certificato del dispositivo e il server RADIUS presenta un certificato del server, fornendo un'autenticazione reciproca. Questo è l'approccio consigliato per IEEE 802.1X sulle reti WPA3-Enterprise, in particolare negli ambienti soggetti a PCI DSS o NCSC Cyber Essentials Plus. Il prerequisito è una PKI funzionante — un'implementazione Microsoft ADCS on-premise o un servizio PKI in cloud — e una piattaforma MDM in grado di distribuire certificati a tutti gli endpoint gestiti. Per gli ambienti Retail con centinaia di dispositivi point-of-sale gestiti, questo investimento è ampiamente giustificato. Per gli ambienti ad alta densità di dispositivi BYOD o per implementazioni rapide, Okta RADIUS con EAP-TTLS è la scelta pragmatica.

Mappatura degli attributi RADIUS per l'assegnazione dinamica delle VLAN

L'assegnazione dinamica delle VLAN è l'ambito in cui l'integrazione di Okta RADIUS offre il suo valore operativo più tangibile. Mappando l'appartenenza ai gruppi di Okta con gli attributi RADIUS, gli amministratori di rete possono applicare la segmentazione della rete basata sui ruoli senza dover mantenere policy VLAN separate per dispositivo o per sede.

Okta trasmette i dati sull'appartenenza ai gruppi nel messaggio Access-Accept di RADIUS utilizzando uno dei tre attributi, configurabili nelle Impostazioni RADIUS Avanzate dell'applicazione Okta:

Attributo 11 (Filter-Id): Un attributo stringa contenente il nome del gruppo. Ampiamente supportato da vari fornitori.
Attributo 25 (Class): Un attributo opaco utilizzato per l'autorizzazione. Supportato da Cisco ISE, Aruba ClearPass e Fortinet.
Attributo 26 (Vendor-Specific): Consente sotto-attributi specifici del fornitore per un controllo più granulare.

Il controller di rete (WLC, appliance NAC) riceve il nome del gruppo Okta nell'attributo scelto e lo mappa con gli attributi di tunnel RADIUS standard richiesti per l'assegnazione della VLAN:

Attributo RADIUS	Valore	Scopo
64 (Tunnel-Type)	13 (VLAN)	Specifica il tunnelling VLAN
65 (Tunnel-Medium-Type)	6 (802)	Specifica il mezzo IEEE 802
81 (Tunnel-Private-Group-ID)	ad es., `40`	L'ID VLAN di destinazione

Ad esempio, un utente nel gruppo Okta Retail-POS-Staff riceverebbe Class: Retail-POS-Staff restituito nell' Access-Accept. La policy del WLC mapperebbe questo valore su Tunnel-Private-Group-ID: 40, posizionando il dispositivo sulla VLAN 40, ovvero la rete POS isolata. Un utente in Store-Management verrebbe invece posizionato sulla VLAN 50. Questa logica viene applicata all'edge della rete, non in Okta, ma è guidata interamente dall'appartenenza al gruppo Okta.

Guida all'implementazione

Passaggio 1: Distribuire l'Okta RADIUS Agent (Alta Disponibilità)

Distribuisci l'agente RADIUS di Okta su un minimo di due server, on-premises o in un VPC cloud, per garantire l'alta disponibilità. Le distribuzioni con un singolo agente rappresentano un rischio critico: se il server non è disponibile per l'applicazione di patch o subisce un guasto, l'intera autenticazione WiFi 802.1X fallirà in tutta l'infrastruttura. Configura il tuo WLC o la tua appliance NAC per bilanciare il carico delle richieste RADIUS tra i due agenti.

Durante l'installazione, l'agente richiederà l'accesso di un amministratore Okta per autorizzare l'agente e collegarlo al tenant Okta. Una volta autorizzato, l'agente appare nella Console di Amministrazione Okta in Settings > Downloads > RADIUS Agent Status, dove è possibile monitorarne lo stato e la connettività.

Passaggio 2: Configurare l'applicazione RADIUS in Okta

Nella Console di Amministrazione Okta, naviga su Applications > Applications e cerca nel catalogo delle app RADIUS Application.
Aggiungi l'applicazione, assegnale un nome descrittivo (ad es. Corporate-WiFi-Staff) e fai clic su Next.
Nella scheda Sign On, configura la RADIUS Port (predefinita 1812) e genera un Shared Secret sicuro, generato casualmente, di almeno 32 caratteri.
In Advanced RADIUS Settings, abilita Accept password and security token in the same login request se intendi supportare il TOTP aggiunto alle password.
Facoltativamente, abilita Permit Automatic Push for Okta Verify Enrolled Users per un'MFA basata su push trasparente.
Assegna l'applicazione ai gruppi Okta pertinenti che rappresentano il tuo personale.

Passaggio 3: Configurare l'assegnazione della VLAN basata sui gruppi

Nelle impostazioni di Sign On dell'applicazione RADIUS, fai clic su Edit nella sezione Advanced RADIUS Settings.
Spunta Include groups in RADIUS response.
Seleziona l'attributo RADIUS: si consiglia 25 Class per gli ambienti Aruba e Cisco; 11 Filter-Id per Fortinet e altri.
Aggiungi i nomi dei gruppi Okta specifici da includere (ad es., Retail-POS-Staff, Store-Management, IT-Admins).
Sul tuo WLC o sulla tua appliance NAC, crea policy di enforcement che mappano ciascun nome di gruppo ai corrispondenti attributi del tunnel VLAN.

Passaggio 4: Configurare i Supplicant dei Client

Poiché PEAP-MSCHAPv2 non è supportato, i dispositivi client devono essere configurati per utilizzare EAP-TTLS con PAP come metodo interno. Distribuisci un profilo di rete wireless tramite la tua piattaforma MDM (ad es. Microsoft Intune, Jamf Pro) o tramite Group Policy Objects (GPO) per i dispositivi Windows associati al dominio. Il profilo deve specificare:

SSID: Il nome del tuo SSID aziendale
Sicurezza: WPA2-Enterprise o WPA3-Enterprise
Metodo EAP: EAP-TTLS
Autenticazione interna: PAP
Validazione del certificato del server: Abilitata (associa al CN del certificato del server del tuo agente RADIUS)

Passaggio 5: Configura i timeout RADIUS

Aumenta il timeout RADIUS sul tuo WLC dal valore predefinito di 3-5 secondi a 30-60 secondi. Questo passaggio è fondamentale se si utilizzano le notifiche push MFA, poiché l'utente deve disporre di tempo sufficiente per approvare la notifica sul proprio dispositivo prima che il WLC abbandoni il tentativo di autenticazione.

Best Practice

La distribuzione di Okta RADIUS per l'autenticazione WiFi è semplice, ma diverse best practice operative distinguono un'implementazione di produzione resiliente da un proof-of-concept fragile.

Segmenta il traffico di ospiti e personale a livello di SSID. Okta RADIUS è uno strumento di identità aziendale. Per l'accesso di visitatori e ospiti, distribuisci una soluzione di Captive Portal dedicata. Ciò evita che i costi delle licenze Okta aumentino con il volume degli ospiti e garantisce una netta separazione delle competenze. I clienti Purple di livello enterprise possono distribuire Guest WiFi su un SSID separato, utilizzando al contempo Okta RADIUS per l'autenticazione del personale sulla stessa infrastruttura fisica.

Utilizza una soluzione NAC per ambienti con policy complesse. Se il tuo ambiente richiede l'accesso condizionale basato sullo stato del dispositivo, sul filtraggio degli indirizzi MAC o sullo stato del certificato insieme all'identità dell'utente, distribuisci un'appliance NAC intermedia (Aruba ClearPass, Cisco ISE o Portnox) per inoltrare le richieste all'agente Okta RADIUS. L'appliance NAC può arricchire la risposta RADIUS con attributi tunnel aggiuntivi che l'agente Okta da solo non è in grado di generare.

Monitora tramite il registro di sistema di Okta. Ogni evento di autenticazione — successo, fallimento, richiesta MFA e tipo di fattore — viene registrato nel registro di sistema di Okta. Configura lo streaming dei log verso il tuo SIEM per ricevere avvisi in tempo reale sulle anomalie di autenticazione. Questo è particolarmente prezioso per le organizzazioni del settore Healthcare e del settore pubblico soggette a requisiti di audit.

Ruota i segreti condivisi secondo un calendario. Il segreto condiviso tra l'applicazione Okta RADIUS e il tuo NAS è una credenziale di sicurezza critica. Implementa un programma di rotazione (si consiglia trimestrale) e aggiorna contemporaneamente sia l'applicazione Okta sia la configurazione WLC/NAC.

Limita gli indirizzi del servizio RADIUS. Nella configurazione dell'agente Okta RADIUS, limita gli indirizzi IP autorizzati a inviare richieste RADIUS. Ciò impedisce ai dispositivi NAS non autorizzati di tentare l'autenticazione con il tuo tenant Okta.

Per una guida sul contesto più ampio dell'architettura di rete, consulta I vantaggi principali di SD WAN per le aziende moderne e Definizione di Access Point Wireless: La tua guida definitiva per il 2026 .

Risoluzione dei problemi e mitigazione dei rischi

La tabella seguente riassume le modalità di guasto più comuni riscontrate nelle distribuzioni WiFi Okta RADIUS e le relative mitigazioni raccomandate.

Modalità di guasto	Causa principale	Mitigazione
Timeout di autenticazione	Timeout RADIUS del WLC troppo breve per l'API di Okta o la risposta MFA	Aumentare il timeout RADIUS del WLC a 30-60 secondi
Client Windows rifiutati	Windows utilizza come impostazione predefinita PEAP-MSCHAPv2, che Okta RADIUS rifiuta	Distribuire il profilo wireless EAP-TTLS/PAP tramite MDM o GPO
Utenti nella VLAN errata	Mancata corrispondenza del nome del gruppo Okta o attributi del tunnel mancanti sul WLC	Verificare che il WLC mappi `Class`/`Filter-Id` su `Tunnel-Private-Group-ID`; controllare il registro di sistema di Okta
Agente non raggiungibile	Server offline, token API scaduto o firewall che blocca HTTPS verso Okta	Distribuire agenti ridondanti; monitorare lo stato degli agenti nella Console di amministrazione di Okta; verificare l'HTTPS in uscita
Notifica Push MFA non recapitata	Utente non registrato in Okta Verify o dispositivo mobile offline	Applicare la policy di registrazione a Okta Verify; considerare TOTP come alternativa
Errori di validazione del certificato	Il client non riesce a validare il certificato del server RADIUS	Bloccare il CN del certificato del server nel profilo wireless del client; assicurarsi che la catena CA sia attendibile
Attributi VLAN non inviati	Gruppo Okta non incluso nella configurazione della risposta RADIUS	Verificare che il gruppo sia elencato nelle Impostazioni RADIUS Avanzate; confermare che l'utente sia un membro del gruppo in Okta

Per il settore dei Trasporti e gli ambienti del settore pubblico in cui il tempo di attività della rete è fondamentale, implementare un monitoraggio sintetico che verifichi periodicamente l'autenticazione RADIUS end-to-end e invii avvisi in caso di errore prima che gli utenti ne risentano.

ROI e impatto aziendale

Il business case per l'autenticazione WiFi Okta RADIUS si basa su tre pilastri: efficienza operativa, miglioramento della sicurezza e conformità normativa.

Efficienza operativa. Consolidare l'autenticazione WiFi in Okta elimina la necessità di mantenere un'infrastruttura RADIUS on-premises separata (server NPS, AD locale) in ogni sede o sito. Per una catena alberghiera con 50 proprietà, ciò può rappresentare una riduzione significativa dei costi infrastrutturali per sito e dei costi di gestione del supporto IT. Il provisioning e il deprovisioning degli utenti diventano immediati: l'aggiunta di un utente al gruppo Okta corretto garantisce contemporaneamente l'accesso all'applicazione e l'accesso alla VLAN WiFi appropriata. Quando un dipendente se ne va, la disattivazione del suo account Okta revoca immediatamente l'accesso al WiFi in tutti i siti.

Sicurezza della rete. Sostituire le password WiFi PSK condivise con l'autenticazione 802.1X per singolo utente elimina la condivisione delle credenziali, un vettore comune di minacce interne e accessi non autorizzati. In combinazione con l'assegnazione dinamica delle VLAN, questo approccio applica il principio del privilegio minimo a livello di rete. L'Okta System Log fornisce un registro di audit completo e a prova di manomissione per ogni evento di autenticazione WiFi, fondamentale per la gestione degli incidenti.

Conformità normativa. Il requisito 8.3 dello standard PCI DSS 4.0 impone l'MFA per tutti gli accessi amministrativi non da console. Il requisito 1.3 richiede la segmentazione della rete tra l'ambiente dei dati dei titolari di carta e le altre reti. Okta RADIUS con assegnazione di VLAN basata su gruppi risponde direttamente a entrambi i requisiti. Per la conformità al GDPR, l'Okta System Log fornisce i record di accesso necessari per dimostrare l'adozione di controlli tecnici adeguati sui sistemi di trattamento dei dati personali. Per le strutture che implementano Modern Hospitality WiFi Solutions , questo approccio unificato all'identità e all'accesso alla rete è sempre più un prerequisito per gli acquisti di livello enterprise.

Le organizzazioni che hanno completato questa integrazione registrano in genere una riduzione dei ticket di supporto IT relativi al WiFi (meno richieste di reimpostazione della password, meno incidenti di configurazione errata delle VLAN) e un miglioramento misurabile nei punteggi di audit di sicurezza. L'investimento per l'implementazione e la configurazione dell'agente Okta RADIUS, solitamente quantificabile in giorni anziché in settimane per una distribuzione su un singolo sito, offre risparmi operativi continui che si moltiplicano in una rete distribuita.

Definizioni chiave

Okta RADIUS Agent

Un servizio proxy leggero, on-premises o ospitato in cloud, che traduce le richieste di autenticazione RADIUS provenienti dall'infrastruttura di rete (access point, WLC) in chiamate API di Okta, consentendo al cloud di Okta di fungere da backend di autenticazione per il WiFi 802.1X.

I team IT incontrano questo elemento quando distribuiscono l'autenticazione WiFi aziendale supportata da Okta. È il componente di bridging critico tra l'infrastruttura di rete legacy basata su RADIUS e la moderna identità cloud.

802.1X

Uno standard IEEE per il controllo dell'accesso alla rete basato su porta (NAC) che definisce un framework di autenticazione per reti cablate e wireless. Utilizza l'Extensible Authentication Protocol (EAP) per trasmettere le credenziali di autenticazione tra il supplicant (dispositivo), l'authenticator (AP/switch) e l'authentication server (RADIUS).

802.1X è il fondamento della sicurezza WiFi aziendale. Qualsiasi implementazione che utilizzi WPA2-Enterprise o WPA3-Enterprise si avvale di 802.1X. I team IT devono comprendere il modello a tre parti (supplicant, authenticator, authentication server) per risolvere i problemi di connettività.

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

Un metodo EAP che stabilisce un tunnel TLS utilizzando solo un certificato lato server, quindi trasporta un protocollo di autenticazione interno più semplice (come PAP) all'interno del tunnel. Questo protegge le credenziali interne dalle intercettazioni, richiedendo solo l'infrastruttura dei certificati lato server.

EAP-TTLS con PAP è il protocollo consigliato per l'autenticazione WiFi Okta RADIUS. È più sicuro del semplice PAP ma non richiede certificati lato client, il che lo rende pratico per ambienti BYOD e con dispositivi misti.

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

Un metodo EAP che utilizza l'autenticazione reciproca basata su certificati: sia il client che il server presentano certificati digitali. È il metodo 802.1X più sicuro, in grado di fornire un'autenticazione senza password e resistente al phishing.

EAP-TLS è il gold standard per gli ambienti con dispositivi aziendali gestiti. Richiede un'infrastruttura PKI e un MDM per la distribuzione dei certificati. L'agente Okta RADIUS non supporta nativamente EAP-TLS; è necessario un servizio cloud PKI o RADIUS dedicato.

PAP (Password Authentication Protocol)

Un protocollo di autenticazione semplice che trasmette nomi utente e password in chiaro. Nel contesto di 802.1X, PAP viene utilizzato come metodo di autenticazione interno all'interno di un tunnel EAP-TTLS, in cui il livello TLS esterno fornisce la crittografia.

PAP è il principale meccanismo di autenticazione supportato dall'agente Okta RADIUS. I team IT devono comprendere che il solo PAP non è sicuro, ma PAP all'interno di EAP-TTLS è accettabile per il WiFi aziendale quando il certificato del server è correttamente convalidato.

Dynamic VLAN Assignment

Una tecnica di controllo dell'accesso alla rete in cui un server RADIUS restituisce gli attributi di assegnazione della VLAN nel messaggio Access-Accept, inducendo il controller wireless o lo switch a posizionare il client autenticato su una VLAN specifica in base alla sua identità o appartenenza a un gruppo, anziché su una VLAN statica per SSID.

L'assegnazione dinamica della VLAN è essenziale per la segmentazione della rete in ambienti con più ruoli (ad esempio, per separare i terminali POS dai dispositivi del personale generico). Si configura restituendo gli attributi RADIUS 64, 65 e 81 nel messaggio Access-Accept.

RADIUS Attribute 25 (Class)

Un attributo RADIUS standard utilizzato per trasmettere dati di autorizzazione arbitrari dal server di autenticazione al NAS. Okta utilizza questo attributo per restituire le informazioni sull'appartenenza al gruppo Okta al controller wireless, che può quindi utilizzarle per l'assegnazione della VLAN o per le decisioni sui criteri di accesso.

I team IT che configurano l'assegnazione della VLAN basata sui gruppi di Okta configureranno il WLC per leggere il valore dell'attributo Class e mapparlo su un ID VLAN. L'attributo esatto da utilizzare (11, 25 o 26) dipende dalla documentazione del fornitore del WLC.

NAS (Network Access Server)

Nella terminologia RADIUS, il NAS è il dispositivo di rete che riceve la richiesta di connessione dell'utente e la inoltra al server RADIUS per l'autenticazione. Nelle distribuzioni WiFi, il NAS è in genere l'access point wireless o il controller LAN wireless.

Il NAS è l'authenticator nel modello 802.1X. I team IT devono configurare il NAS con l'indirizzo IP del server RADIUS, la porta e il shared secret. L'indirizzo IP del NAS deve essere inserito nella whitelist nella configurazione del filtraggio degli indirizzi di servizio dell'agente Okta RADIUS.

Shared Secret

Una password precondivisa utilizzata per autenticare i messaggi RADIUS tra il NAS (WLC/AP) e il server RADIUS (agente Okta RADIUS). Viene utilizzata per calcolare un hash Message-Authenticator che verifica l'integrità dei pacchetti RADIUS.

Il shared secret deve essere identico sia nella configurazione dell'applicazione Okta RADIUS che nella voce del server RADIUS del WLC/NAC. Deve essere lungo almeno 32 caratteri, generato casualmente e ruotato regolarmente. Una mancata corrispondenza è una causa comune di errori di autenticazione RADIUS.

MFA Challenge (RADIUS Access-Challenge)

Un tipo di messaggio RADIUS inviato dal server di autenticazione al NAS quando sono richiesti fattori di autenticazione aggiuntivi. Il NAS trasmette la richiesta al client, che deve rispondere con il fattore appropriato (ad esempio, OTP, approvazione push) prima che l'autenticazione possa essere completata.

Il meccanismo di Access-Challenge è il modo in qual Okta applica l'MFA tramite RADIUS. I team IT devono assicurarsi che il WLC supporti lo scambio di challenge-response e che il timeout RADIUS sia sufficientemente lungo da consentire all'utente di completare il passaggio MFA.

Esempi pratici

Una catena alberghiera di 150 strutture utilizza attualmente server NPS on-premises in ciascuna proprietà per l'autenticazione WiFi del personale tramite 802.1X. Ogni server NPS è associato a un dominio Active Directory locale. Il team IT desidera centralizzare la gestione delle identità in Okta ed eliminare l'infrastruttura NPS per singola struttura. Come dovrebbero affrontare la migrazione?

L'approccio consigliato è una migrazione a fasi che utilizza l'agente Okta RADIUS distribuito in un VPC cloud centralizzato anziché in ciascuna struttura. Fase 1: distribuire due istanze dell'agente Okta RADIUS in un VPC cloud (ad esempio, AWS o Azure) nella stessa area geografica in cui si trova la maggior parte delle strutture. Configurare gli agenti per l'ascolto sulla porta UDP 1812. Fase 2: per ogni struttura, aggiungere gli IP dell'agente Okta RADIUS come server RADIUS secondari sul WLC, mantenendo l'NPS esistente come primario. Ciò consente il funzionamento parallelo e i test senza interrompere l'autenticazione attiva. Fase 3: migrare gli utenti da AD locale a Okta. Utilizzare l'agente AD di Okta per sincronizzare inizialmente gli account esistenti, quindi passare progressivamente a Okta come origine autorevole. Fase 4: per ciascuna struttura, configurare il WLC per l'utilizzo di EAP-TTLS/PAP e distribuire il nuovo profilo wireless ai dispositivi del personale tramite MDM. Fase 5: una volta confermati tutti i dispositivi su EAP-TTLS, impostare la priorità RADIUS del WLC sugli agenti Okta come primari e dismettere i server NPS. Configurare i gruppi Okta (Front-Desk, Housekeeping, F&B, Management, IT-Admins) e abilitare l'assegnazione VLAN basata su gruppo utilizzando l'attributo 25 (Class). Mappare ciascun gruppo sulla VLAN appropriata sul WLC. Aumentare il timeout RADIUS del WLC a 45 secondi per compensare la latenza delle API di Okta.

Commento dell'esaminatore: Questo approccio a fasi è preferibile perché elimina il rischio di un passaggio drastico e simultaneo su 150 strutture. L'esecuzione in parallelo di NPS e Okta RADIUS durante il periodo di transizione consente di rilevare e correggere eventuali errori di configurazione senza impattare sugli utenti attivi. La distribuzione degli agenti RADIUS nel VPC cloud è architetturalmente superiore rispetto a quella per singola struttura, poiché centralizza la gestione, riduce l'ingombro dell'infrastruttura e garantisce l'applicazione coerente delle policy indipendentemente dalla struttura da cui l'utente si autentica. Il rischio principale da mitigare è la latenza WAN tra la struttura e il VPC cloud: l'autenticazione RADIUS dovrebbe completarsi in meno di 2 secondi per garantire una buona esperienza utente, pertanto la scelta dell'area geografica del VPC deve ridurre al minimo il tempo di andata e ritorno (RTT).

Una catena di vendita al dettaglio nazionale con 320 negozi deve ottenere la conformità PCI DSS 4.0 per il proprio staff WiFi. Gli addetti ai negozi utilizzano dispositivi palmari per la gestione dell'inventario e un set separato di dispositivi gestisce le transazioni dei punti vendita (POS). La catena utilizza Okta per la gestione di tutte le identità aziendali. In che modo implementano la segmentazione VLAN utilizzando Okta RADIUS per soddisfare i requisiti di segmentazione della rete PCI DSS?

Creare tre gruppi Okta: POS-Staff (per i dipendenti che utilizzano i terminali POS), Inventory-Staff (per gli addetti al magazzino e al punto vendita) e Store-Management. Nell'applicazione Okta RADIUS, abilitare l'opzione "Include groups in RADIUS response" e selezionare l'Attributo 25 (Class). Aggiungere tutti e tre i gruppi alla configurazione della risposta. Sul controller wireless di ciascun negozio (o centralmente tramite un WLC cloud), creare tre policy di applicazione: (1) Se Class = POS-Staff, assegnare Tunnel-Private-Group-ID = 40 (la VLAN POS, che rientra nell'ambito PCI DSS e presenta regole firewall che limitano l'accesso al solo elaboratore di pagamento). (2) Se Class = Inventory-Staff, assegnare Tunnel-Private-Group-ID = 50 (la VLAN di inventario, esclusa dall'ambito PCI). (3) Se Class = Store-Management, assegnare Tunnel-Private-Group-ID = 60 (la VLAN di gestione con accesso ai sistemi di gestione del negozio). I dispositivi che si connettono con le credenziali di un utente del gruppo POS-Staff vengono inseriti automaticamente nella VLAN 40. Se il ruolo di un addetto al negozio cambia, l'aggiornamento della sua appartenenza al gruppo Okta modifica immediatamente l'assegnazione della VLAN alla connessione successiva, senza richiedere alcuna riconfigurazione del WLC. Documentare la mappatura da gruppo Okta a VLAN nel diagramma di segmentazione della rete per l'audit del QSA PCI DSS.

Commento dell'esaminatore: Questa implementazione soddisfa direttamente il requisito 1.3 (segmentazione della rete) e il requisito 7 (controllo degli accessi basato sulle esigenze aziendali) del PCI DSS 4.0. L'aspetto cruciale è che l'assegnazione della VLAN è guidata dall'identità, non dall'indirizzo MAC del dispositivo o da una configurazione VLAN statica; ciò significa che è scalabile su 320 negozi senza la manutenzione delle policy VLAN per singolo punto vendita. Il QSA richiederà prove del fatto che la VLAN POS sia realmente isolata dagli altri segmenti di rete, pertanto le configurazioni del WLC e del firewall devono rispecchiare i limiti della VLAN. Il registro di sistema di Okta fornisce la traccia di controllo dell'autenticazione richiesta dal requisito 10 del PCI DSS (registrazione e monitoraggio). Un avvertimento importante: se i dispositivi POS non sono gestiti o sono condivisi (ovvero non assegnati a un utente specifico), considerare l'utilizzo del MAC Authentication Bypass (MAB) per tali dispositivi anziché l'802.1X, riservando Okta RADIUS solo per i dispositivi autenticati dall'utente.

Domande di esercitazione

Q1. Un centro congressi di medie dimensioni utilizza Okta per la gestione delle identità di tutto il personale. Desidera distribuire il WiFi 802.1X per il personale utilizzando gli access point Cisco Meraki esistenti. I loro laptop Windows sono gestiti tramite Microsoft Intune. Il responsabile IT desidera imporre l'MFA push di Okta Verify per tutte le connessioni WiFi. Quali sono i tre passaggi di configurazione più critici da completare e quale sarebbe la modalità di errore più probabile se si saltasse uno di essi?

Suggerimento: Considera la compatibilità del protocollo EAP tra Okta RADIUS e i valori predefiniti di Windows, l'impostazione del timeout RADIUS e la configurazione del profilo wireless del client.

Visualizza risposta modello

I tre passaggi fondamentali sono: (1) Distribuire un profilo wireless tramite Intune che configuri i client Windows per l'uso di EAP-TTLS con PAP come metodo interno — Windows utilizza di default PEAP-MSCHAPv2, che l'agente Okta RADIUS non supporta, causando il rifiuto di tutti i tentativi di autenticazione. (2) Aumentare il timeout RADIUS di Cisco Meraki dal valore predefinito di 5 secondi ad almeno 45-60 secondi — senza questo accorgimento, la richiesta di autenticazione andrà in timeout prima che l'utente possa approvare la notifica push di Okta Verify. (3) Abilitare 'Permit Automatic Push for Okta Verify Enrolled Users' nelle impostazioni avanzate RADIUS dell'applicazione Okta RADIUS — in caso contrario, agli utenti potrebbe essere richiesto di selezionare manualmente il proprio fattore MFA anziché ricevere una notifica push automatica. La modalità di errore più probabile se si salta il passaggio 1 è un fallimento totale dell'autenticazione per tutti i dispositivi Windows. Se si salta il passaggio 2, l'autenticazione fallirà in modo intermittente per gli utenti che impiegano più di 5 secondi ad approvare la notifica push. Se si salta il passaggio 3, gli utenti visualizzeranno una richiesta di verifica complessa anziché una notifica push fluida.

Q2. Il team di sicurezza di una grande catena di vendita al dettaglio ha segnalato che l'attuale distribuzione di Okta RADIUS WiFi utilizza un singolo server agente RADIUS. Durante una recente finestra di manutenzione per l'applicazione delle patch, il server è rimasto offline per 45 minuti, causando il blocco dell'autenticazione WiFi in tutti gli 80 negozi. Quali modifiche architetturali dovrebbe implementare il team IT per evitare che ciò accada e quali sono le due opzioni di distribuzione per gli agenti?

Suggerimento: Considera sia la topologia di distribuzione degli agenti sia la configurazione del WLC necessaria per supportare la ridondanza.

Visualizza risposta modello

Il team IT dovrebbe distribuire almeno due istanze dell'agente Okta RADIUS e configurare il WLC in ogni negozio per utilizzare entrambi gli agenti. Esistono due opzioni di distribuzione: Opzione A (VM cloud centralizzate) — distribuire entrambi gli agenti in un VPC cloud (ad esempio, AWS o Azure), idealmente in diverse zone di disponibilità. Il WLC in ogni negozio punta a entrambi gli IP cloud, con uno come primario e uno come secondario (o con il bilanciamento del carico abilitato). Ciò riduce al minimo l'infrastruttura per sito, ma introduce una dipendenza dalla rete WAN. Opzione B (Coppia ridondante on-premises) — distribuire due server agente presso un data center centrale o una struttura di co-location, con il WLC che utilizza il failover RADIUS. Sul WLC, configurare il server RADIUS primario come Agente 1 e quello secondario come Agente 2, con un timeout di failover di 3-5 secondi. Abilitare 'Dead Server Detection' se supportato dal fornitore del WLC. Inoltre, il team IT dovrebbe configurare il monitoraggio dello stato nella console di amministrazione di Okta e impostare avvisi in caso di disconnessione di un agente. Per i negozi con server locali, un agente locale può fungere da terzo livello di fallback per garantire la resilienza contro le interruzioni della WAN.

Q3. Un'organizzazione aziendale sta valutando se utilizzare l'agente Okta RADIUS con EAP-TTLS/PAP o investire in una soluzione PKI cloud per EAP-TLS per il WiFi aziendale. Hanno 2.000 dispositivi gestiti Windows e macOS registrati in Microsoft Intune e sono soggetti a PCI DSS 4.0. Qual è l'approccio consigliato e qual è la principale giustificazione in termini di sicurezza?

Suggerimento: Considera i requisiti GDPR e PCI DSS, la maturità della gestione dei dispositivi (tutti i dispositivi sono registrati in un MDM) e le proprietà di sicurezza di ciascun metodo di autenticazione.

Visualizza risposta modello

L'approccio consigliato è investire in EAP-TLS con una soluzione PKI cloud. La principale giustificazione di sicurezza è l'autenticazione reciproca: EAP-TLS richiede che sia il client sia il server RADIUS presentino certificati digitali, il che significa che il dispositivo dimostra crittograficamente la propria identità alla rete e la rete dimostra la propria identità al dispositivo. Ciò elimina il rischio di attacchi "evil twin" (in cui un AP canaglia impersona l'SSID aziendale) e rimuove completamente le password dall'equazione di autenticazione WiFi, azzerando il furto di credenziali e il phishing come vettori di attacco. Per PCI DSS 4.0, EAP-TLS soddisfa implicitamente il Requisito 8.3 (MFA per l'accesso amministrativo non da console) tramite l'autenticazione basata su certificato e supporta la modalità WPA3-Enterprise a 192 bit (Requisito 4.2.1 per la crittografia avanzata). Il prerequisito — tutti i 2.000 dispositivi registrati in Intune — è già soddisfatto, rendendo semplice la distribuzione dei certificati tramite i profili SCEP di Intune. L'agente Okta RADIUS con EAP-TTLS/PAP sarebbe una soluzione temporanea accettabile durante la creazione della PKI, ma considerando l'ambito PCI DSS e il parco dispositivi completamente gestito, EAP-TLS rappresenta l'architettura corretta a lungo termine. L'investimento aggiuntivo in un servizio PKI cloud (solitamente 3-8 dollari per dispositivo all'anno) è giustificato dal miglioramento della sicurezza e dalla riduzione dei costi di gestione delle credenziali.

Continua a leggere questa serie

Integrazione di CommScope Ruckus con Purple WiFi: Guida alla Configurazione e all'Installazione

Questa guida di riferimento tecnico fornisce un manuale di configurazione autorevole per l'integrazione delle architetture CommScope Ruckus con Purple WiFi. Dettaglia passo dopo passo le implementazioni per i Captive Portal per Guest WiFi, il WiFi aziendale sicuro per il personale tramite 802.1X e l'isolamento di rete Multi-Tenant utilizzando Ruckus Dynamic PSK.

Integrazione degli Access Point Allied Telesis con Purple WiFi

Questa guida fornisce un playbook di configurazione completo per integrare gli access point Allied Telesis serie TQ con Purple WiFi. Copre il reindirizzamento al Captive Portal esterno, l'autenticazione RADIUS 802.1X e lo steering dinamico delle VLAN utilizzando le chiavi PPSK (Private Pre-Shared Keys) per implementazioni multi-tenant sicure.

Integrazione degli Access Point Grandstream GWN con Purple WiFi

Questa guida tecnica di riferimento dettagliata spiega come integrare gli access point Grandstream GWN con la piattaforma di Guest WiFi e analytics di Purple. Copre la configurazione del Captive Portal Grandstream, le impostazioni RADIUS AAA, la configurazione del walled garden, l'autenticazione sicura del personale tramite 802.1X con instradamento VLAN dinamico e la segmentazione PPSK multi-tenant, offrendo una guida pratica e passo dopo passo per MSP e team IT che implementano WiFi per ospiti e personale su larga scala.