Vai al contenuto principale
Italiano

Okta e RADIUS: Estendere il Proprio Identity Provider all'Autenticazione WiFi

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 Okta RADIUS. Copre l'intera architettura di autenticazione, i compromessi sull'applicazione dell'MFA, l'assegnazione dinamica della VLAN tramite la mappatura degli attributi RADIUS e la decisione cruciale tra EAP-TTLS basato su password ed EAP-TLS basato su certificati. I gestori delle sedi e i team IT aziendali troveranno indicazioni operative per la distribuzione, casi di studio reali provenienti dai settori dell'ospitalità e della vendita al dettaglio e un quadro chiaro per l'integrazione di Okta RADIUS insieme a soluzioni dedicate per il WiFi ospiti.

Di Iain JewittPubblicato Aggiornato
📖 11 minuti di lettura2,883 parole2 esempi pratici3 domande di esercitazione10 definizioni chiave

Video overview

Ascolta questa guida

Visualizza trascrizione del podcast
Benvenuto al Technical Briefing di Purple. Oggi analizzeremo un argomento che si colloca esattamente all'intersezione tra architettura di rete e gestione delle identità: Okta e RADIUS per l'autenticazione WiFi. Se sei un IT manager, un progettista di reti o un direttore delle operazioni di una sede, conosci già il mal di testa legato alla gestione di credenziali separate per l'accesso alla rete. Hai la tua directory Okta per le applicazioni cloud, ma forse il tuo WiFi si affida ancora a un server Active Directory legacy o, peggio, a una password WPA2 condivisa e appesa alla parete dell'area relax. Oggi vedremo come colmare questo divario utilizzando l'agente Okta RADIUS. Tratteremo l'architettura, come gestire la Multi-Factor Authentication sul WiFi, i compromessi critici tra autenticazione basata su password e quella basata su certificati e come mappare i gruppi Okta sugli attributi RADIUS per l'assegnazione dinamica delle VLAN. Entriamo nel dettaglio. Iniziamo con l'architettura. Come funziona effettivamente l'agente Okta RADIUS? L'agente Okta RADIUS è un'applicazione leggera da distribuire on-premises - solitamente su un server Windows o Linux - o in una macchina virtuale nel cloud. Funge da proxy. Si posiziona tra la tua 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 tuo WiFi aziendale 802.1X, il suo dispositivo invia le credenziali all'access point. L'access point, che agisce come quello che definiamo l'autenticatore nel modello 802.1X, inoltra una richiesta RADIUS Access-Request all'agente Okta RADIUS tramite la porta UDP 1812. L'agente prende tale richiesta e la convoglia in modo sicuro verso il cloud di Okta tramite una chiamata API HTTPS. Okta convalida le credenziali, verifica le policy di accesso e restituisce una decisione. L'agente traduce quindi questo responso in un messaggio RADIUS Access-Accept o Access-Reject per l'access point. È un modo intelligente per estendere il tuo provider di identità cloud fino al perimetro della rete locale senza esporre direttamente la tua directory a Internet. Ora, la grande domanda che tutti si pongono: è possibile imporre Okta MFA sulle connessioni WiFi? La risposta breve è sì, ma con importanti avvertimenti. L'agente Okta RADIUS 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, che sta per Extensible Authentication Protocol. Questa configurazione consente all'agente di gestire le richieste MFA. È possibile configurare Okta per inviare una notifica Okta Verify sul telefono dell'utente o chiedere di aggiungere un codice TOTP - una Time-Based One-Time Password - alla propria password. Tuttavia, è proprio qui che l'esperienza utente si scontra con la sicurezza. Immagina di chiedere a un addetto di un negozio al dettaglio di approvare una notifica push ogni volta che il suo telefono si riconnette al WiFi del personale mentre cammina per il punto vendita. Questo crea attrito. Inoltre, molti dispositivi moderni interrompono la connessione WiFi se la richiesta MFA richiede troppo tempo. Quindi, sebbene l'MFA su WiFi sia tecnicamente possibile e supportato da Okta, generalmente lo consigliamo solo per accessi altamente privilegiati, 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 Okta RADIUS con EAP-TTLS o PAP, ci si affida alle password. Le password possono essere rubate, oggetto di phishing o condivise. Inoltre, come abbiamo appena visto, l'aggiunta di MFA al WiFi è macchinosa 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. L'inconveniente? L'agente Okta RADIUS 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 propri endpoint. Okta può comunque essere l'identity provider che autorizza l'emissione dei certificati, ma l'agente RADIUS stesso non si occuperà del lavoro pesante per EAP-TLS. Per gli ambienti BYOD, Okta RADIUS basato su password è rapido e facile da distribuire. 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 grande struttura - un hotel, uno stadio, un centro congressi - non vuoi che tutto il personale si trovi sullo stesso segmento di rete. Desideri che i terminali dei punti vendita siano isolati dai tablet del personale delle pulizie, e che il team IT si trovi su una VLAN di gestione. Come si ottiene questo risultato con Okta? È tutta una questione di mappatura degli attributi RADIUS. Nella Okta Admin Console, sotto le impostazioni dell'applicazione RADIUS, puoi abilitare una funzionalità chiamata Include groups in RADIUS response. Specifica quali gruppi Okta devono essere restituiti nella risposta di autenticazione. Okta passa questa appartenenza al gruppo al tuo controller di rete utilizzando gli attributi RADIUS standard - tipicamente l'Attributo 11 per Filter-ID, o l'Attributo 25 per Class. Il tuo controller wireless o sistema di Network Access Control, come Aruba ClearPass o Cisco ISE, riceve questo nome di gruppo. Configura quindi 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 tunnel standard - Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID - all'access point, inserendo dinamicamente l'utente nella VLAN corretta. È un modo fluido per imporre la segmentazione della rete basandosi esclusivamente sull'identità Okta, il che è enormemente potente per la conformità a standard come PCI-DSS, che richiede una rigorosa segmentazione della rete attorno agli ambienti dei dati dei titolari di carta. Ora esaminiamo alcuni scenari di implementazione reali. Prendi in considerazione una catena alberghiera nazionale con proprietà in tutto il Regno Unito. Ogni struttura ha un mix di personale di reception, pulizie, ristorazione e direzione. 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 Okta RADIUS in una coppia di macchine virtuali cloud ridondanti, centralizzando tutti gli account utente in Okta e configurando l'assegnazione della VLAN basata sui gruppi, la catena ha ridotto in modo significativo i costi operativi IT per ogni 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 direzione, che si trova in un gruppo Okta diverso, atterra sulla VLAN di gestione con accesso ai sistemi di gestione della struttura. L'intera configurazione viene gestita da una singola Okta Admin Console, e l'Okta System Log 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 dei 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 la propria infrastruttura wireless esistente, il rivenditore mappa i gruppi Okta - POS-Staff, Inventory-Staff e Store-Management - su tre VLAN distinte. Quando un addetto 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 sua successiva connessione. Nessuna regola del firewall da aggiornare, nessuna configurazione VLAN da inviare ai singoli negozi. Ora, esaminiamo le raccomandazioni per l'implementazione e gli errori comuni. Il primo e più comune errore è ignorare le impostazioni di timeout. Le chiamate API di Okta richiedono tempo, specialmente se è coinvolto un invio MFA. Se il timeout RADIUS del controller wireless è impostato sul valore predefinito di tre o cinque secondi, la richiesta scadrà prima che l'utente possa toccare Approva sul proprio telefono. È necessario aumentare il timeout RADIUS sul WLC ad almeno trenta-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 bilanciare il carico tra di essi. Se un server si arresta per l'applicazione di patch, l'autenticazione WiFi rimane attiva. Il terzo errore: fare attenzione con PEAP. L'agente Okta RADIUS non supporta PEAP-MSCHAPv2, che è l'impostazione predefinita per molti ambienti Windows più vecchi. È necessario configurare i client in modo che utilizzino EAP-TTLS con PAP. Ciò richiede in genere l'invio di un profilo wireless tramite Group Policy o MDM, poiché Windows non passa facilmente a EAP-TTLS per impostazione predefinita. La mancata esecuzione di questa operazione è il motivo principale dei fallimenti nelle distribuzioni. È il momento di una sessione di domande e risposte rapide basata sulle richieste più comuni dei clienti. Domanda uno: possiamo usare Okta RADIUS per il WiFi ospiti? Risposta: no. Okta ha un prezzo per utente ed è progettato per l'identità aziendale dei dipendenti. Per il WiFi ospiti, dovresti utilizzare una soluzione di captive portal dedicata, che gestisce i termini di servizio, l'accesso social e l'analisi senza consumare licenze Okta. Domanda due: Okta RADIUS supporta le YubiKeys per l'autenticazione WiFi? Risposta: in genere, no. I token hardware e WebAuthn non si convertono bene sul protocollo RADIUS. Rimani su Okta Verify push o TOTP se devi assolutamente utilizzare l'MFA sul WiFi. Domanda tre: come interagisce questo con un'installazione di Purple? Risposta: molto bene. I clienti aziendali 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 unificato e moderno - 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 della 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 questo briefing. Assicurati di consultare la guida tecnica di riferimento 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.

Parte della nostra serie principale: Guida alla Sicurezza Enterprise WiFi →

Okta e RADIUS: Estendere il Proprio Identity Provider all'Autenticazione WiFi

Executive Summary

Per i team IT aziendali che gestiscono sedi distribuite - dalle catene alberghiere agli stadi - unificare il controllo dell'accesso alla rete con un identity provider cloud è un passo fondamentale verso il modello Zero Trust. L'agente RADIUS di Okta 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 RADIUS di Okta per l'autenticazione WiFi aziendale, coprendo l'architettura proxy, i meccanismi di applicazione della 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 della VLAN - una funzionalità che supporta direttamente i requisiti di segmentazione della rete PCI-DSS. Integrando Okta per l'autenticazione del personale insieme alle soluzioni per Guest WiFi, i gestori delle sedi possono ottenere un livello di accesso unificato, sicuro e conforme senza duplicare l'infrastruttura di identità.

Approfondimento Tecnico

Come funziona l'agente RADIUS di Okta

L'agente RADIUS di Okta è 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 di Okta. Viene in genere distribuito su un server Windows o Linux on-premises o all'interno di un VPC cloud ed è gestito interamente dalla console di amministrazione di Okta 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 un Access-Request RADIUS all'agente RADIUS di Okta tramite la porta UDP 1812. L'agente incanala in modo sicuro questa richiesta verso il cloud di Okta tramite una chiamata API HTTPS, in cui il motore dei criteri di Okta valuta le credenziali rispetto alla directory degli utenti e a qualsiasi criterio di accesso configurato. Se l'autenticazione ha successo, l'agente restituisce un messaggio Access-Accept RADIUS all'authenticator, includendo opzionalmente attributi RADIUS per l'autorizzazione come l'assegnazione della VLAN. Se è richiesta la MFA, l'agente invia un messaggio Access-Challenge RADIUS al client, richiedendo un secondo fattore prima che venga restituita la decisione finale.

Okta e RADIUS: Estendere il Proprio Identity Provider all'Autenticazione WiFi - architecture overview

Questo modello proxy implica che l'agente RADIUS di Okta non ha bisogno di memorizzare le credenziali dell'utente localmente. Tutta la logica di autenticazione, la valutazione dei criteri e la registrazione dei log di audit avvengono nel cloud di Okta, offrendo agli amministratori un unico pannello di controllo per la governance dell'identità sia per le applicazioni cloud sia per l'accesso alla rete.

Protocolli EAP supportati e limitazioni critiche

Un vincolo architetturale fondamentale dell'agente RADIUS Okta è la sua dipendenza dal Password Authentication Protocol (PAP) per l'autenticazione primaria. Sebbene PAP trasmetta le password in testo non crittografato nel livello interno, questo viene incapsulato e protetto 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, vedere 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 tradizionale NPS/Active Directory devono riconfigurare i propri supplicant client per utilizzare EAP-TTLS con PAP - una modifica che in genere richiede la distribuzione di un profilo wireless tramite MDM o criteri di gruppo. La mancata considerazione di questo aspetto è la causa più comune di fallimento delle distribuzioni RADIUS di Okta.

EAP-TLS, che si basa interamente sull'autenticazione reciproca basata su certificati, non è supportato nativamente dall'agente RADIUS Okta. 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 RADIUS Okta.

Applicazione dell'MFA sulle connessioni WiFi

L'agente RADIUS Okta supporta l'MFA per l'accesso WiFi, ma introduce sfide per l'esperienza utente che devono essere attentamente valutate prima della distribuzione. Quando viene attivata una policy MFA, l'agente invia una richiesta RADIUS Access-Challenge 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 cellulare
TOTP (Okta Verify / Google Auth) Supportato Supportato L'utente aggiunge l'OTP alla password (es. Pass123,456789)
SMS / Email / Voce 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ò spostarsi tra i punti di accesso dozzine di volte per turno, attivando ogni volta la riautenticazione. Richiedere l'approvazione di una notifica push a ogni spostamento è operativamente insostenibile. Per il WiFi del personale generale, si preferiscono in genere solide policy sulle password combinate con il trust dei dispositivi e le policy sulle zone di rete di Okta rispetto ai prompt MFA attivi. L'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 più importanti in una distribuzione WiFi aziendale. I compromessi non riguardano semplicemente la sicurezza; coinvolgono la complessità di implementazione, la maturità della gestione dei dispositivi e i costi operativi.

Okta e RADIUS: Estendere il Proprio Identity Provider all'Autenticazione WiFi - comparison chart

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.

L'autenticazione EAP-TLS basata su certificati elimina completamente le password dall'equazione dell'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 lo standard 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 locale o un servizio PKI 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 ambienti ad alta densità BYOD o implementazioni rapide, Okta RADIUS con EAP-TTLS rappresenta 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 di rete basata sui ruoli senza dover gestire criteri VLAN separati per dispositivo o per sede.

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

  • Attribute 11 (Filter-Id): Un attributo stringa contenente il nome del gruppo. Ampiamente supportato da diversi fornitori.
  • Attribute 25 (Class): Un attributo opaco utilizzato per l'autorizzazione. Supportato da Cisco ISE, Aruba ClearPass e Fortinet.
  • Attribute 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 negli attributi tunnel RADIUS standard richiesti per l'assegnazione della VLAN:

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

Ad esempio, un utente nel gruppo Okta Retail-POS-Staff riceverà Class: Retail-POS-Staff come risposta in Access-Accept. La policy del WLC mapperà questo valore su Tunnel-Private-Group-ID: 40, posizionando il dispositivo sulla VLAN 40 - la rete POS isolata. Un utente in Store-Management verrà inserito nella VLAN 50. Questa logica viene applicata all'edge della rete, non in Okta, ma è guidata interamente dall'appartenenza ai gruppi di Okta.

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

Guida all'implementazione

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

Distribuire l'Okta RADIUS agent su almeno due server - on-premises o in un VPC cloud - per garantire l'alta affidabilità. Le distribuzioni con un singolo agent rappresentano un rischio critico: se il server non è disponibile per l'applicazione di patch o subisce un guasto, tutte le autenticazioni WiFi 802.1X falliranno in tutta l'infrastruttura. Configurare il WLC o l'appliance NAC per bilanciare il carico delle richieste RADIUS tra i due agent.

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

Passaggio 2: Configurare l'applicazione RADIUS in Okta

  1. Nella Okta Admin Console, accedere a Applications > Applications e cercare nel catalogo delle app RADIUS Application.
  2. Aggiungere l'applicazione, assegnarle un nome descrittivo (es. Corporate-WiFi-Staff) e fare clic su Next.
  3. Nella scheda Sign On, configurare la RADIUS Port (predefinita 1812) e generare una Shared Secret complessa e casuale di almeno 32 caratteri.
  4. In Advanced RADIUS Settings, abilitare Accept password and security token in the same login request se si desidera supportare il TOTP aggiunto alle password.
  5. Abilitare opzionalmente Permit Automatic Push for Okta Verify Enrolled Users per un'MFA push fluida.
  6. Assegnare l'applicazione ai gruppi Okta pertinenti che rappresentano il personale.

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

  1. Nelle impostazioni Sign On dell'applicazione RADIUS, fare clic su Edit nella sezione Advanced RADIUS Settings.
  2. Selezionare Include groups in RADIUS response.
  3. Selezionare l'attributo RADIUS: si consiglia 25 Class per gli ambienti Aruba e Cisco; 11 Filter-Id per Fortinet e altri.
  4. Aggiungere i nomi specifici dei gruppi Okta da includere (es. Retail-POS-Staff, Store-Management, IT-Admins).
  5. Sul WLC o sull'appliance NAC, creare policy di applicazione che mappino ogni 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: Imposta i timeout RADIUS

Aumenta il timeout RADIUS sul tuo WLC dal valore predefinito di 3 - 5 secondi a 30 - 60 secondi. Questo è fondamentale se sono in uso le notifiche push MFA, poiché l'utente deve avere il 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 una distribuzione di produzione resiliente da un proof of concept fragile.

Segmenta il traffico di ospiti e dipendenti a livello di SSID. Okta RADIUS è uno strumento di identità aziendale per i dipendenti. 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 aziendali Purple possono distribuire la soluzione Guest WiFi su un SSID separato, utilizzando al contempo Okta RADIUS per l'autenticazione del personale sulla stessa infrastruttura fisica.

Utilizza un'appliance NAC per ambienti con policy complesse. Se il tuo ambiente richiede un 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 fare da proxy per le richieste verso l'agente Okta RADIUS. L'appliance NAC può arricchire la risposta RADIUS con attributi di tunnel aggiuntivi che l'agente Okta da solo non è in grado di generare.

Monitora tramite il log di sistema di Okta. Ogni evento di autenticazione - successo, fallimento, richiesta MFA e tipo di fattore - viene registrato nel log 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 una pianificazione. Il segreto condiviso tra l'applicazione Okta RADIUS e il tuo NAS è una credenziale di sicurezza fondamentale. Implementa un programma di rotazione (si consiglia trimestrale) e aggiorna contemporaneamente sia l'applicazione Okta che 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 sul tuo tenant Okta. Per una guida sul contesto più ampio dell'architettura di rete, vedi The Core SD WAN Benefits for Modern Businesses e Wireless Access Points Definition Your Ultimate 2026 Guide.

Risoluzione dei problemi e mitigazione dei rischi

La tabella seguente riassume le modalità di guasto più comuni riscontrate nelle distribuzioni Okta RADIUS WiFi 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 di default 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 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 l'HTTPS verso Okta Distribuire agenti ridondanti; monitorare lo stato degli agenti nella console di amministrazione di Okta; verificare l'HTTPS in uscita
Push MFA non recapitato Utente non registrato in Okta Verify o dispositivo mobile offline Applicare la policy di registrazione a Okta Verify; considerare il TOTP come alternativa
Errori di validazione del certificato Il client non può convalidare il certificato del server RADIUS Configurare 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 avanzate di RADIUS; confermare che l'utente sia membro del gruppo in Okta

Per i settori dei Trasporti e della pubblica amministrazione in cui il tempo di attività della rete è cruciale per la missione, implementare un monitoraggio sintetico che verifichi periodicamente l'autenticazione RADIUS end-to-end e segnali i guasti prima che gli utenti ne risentano.

ROI e impatto aziendale

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

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

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

Prerequisiti di Conformità. Il requisito 8.3 di 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 della VLAN basata su gruppi risponde direttamente a entrambi i requisiti. Per la conformità GDPR, l'Okta System Log fornisce i registri di accesso necessari per dimostrare controlli tecnici adeguati sui sistemi di trattamento dei dati personali. Per le strutture che distribuiscono soluzioni WiFi per l'ospitalità moderna, questo approccio unificato all'identità e all'accesso alla rete è sempre più un prerequisito per il procurement aziendale.

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 dei punteggi degli audit di sicurezza. L'investimento nella distribuzione e configurazione dell'agente Okta RADIUS - tipicamente misurato in giorni piuttosto che in settimane per una distribuzione in un singolo sito - offre risparmi operativi continui che si accumulano su una proprietà distribuita.

Definizioni chiave

Okta RADIUS Agent

Un servizio proxy leggero, installato 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 si confrontano con questo elemento quando distribuiscono l'autenticazione WiFi aziendale supportata da Okta. Rappresenta il componente ponte fondamentale tra l'infrastruttura di rete legacy basata su RADIUS e la moderna identità in 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).

Lo standard 802.1X è la base della sicurezza del WiFi aziendale. Qualsiasi implementazione che utilizzi WPA2-Enterprise o WPA3-Enterprise impiega 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, per poi trasmettere un protocollo di autenticazione interno più semplice (come PAP) all'interno del tunnel. Questo protegge le credenziali interne dall'intercettazione, richiedendo al contempo solo l'infrastruttura per i certificati lato server.

Il protocollo EAP-TTLS con PAP è quello raccomandato per l'autenticazione WiFi Okta RADIUS. Risulta più sicuro rispetto al 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 priva di password e resistente al phishing.

EAP-TLS è il gold standard per gli ambienti di dispositivi aziendali gestiti. Richiede un'infrastruttura PKI e un MDM per la distribuzione dei certificati. L'agente RADIUS di Okta non supporta nativamente EAP-TLS; è necessario un servizio PKI cloud 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 dentro un tunnel EAP-TTLS, in cui lo strato TLS esterno fornisce la crittografia.

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

Dynamic VLAN Assignment

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

L'assegnazione dinamica delle VLAN è essenziale per la segmentazione della rete in ambienti multi-ruolo (ad es. separando i terminali POS dai dispositivi del personale generale). Si configura restituendo gli attributi RADIUS 64, 65 e 81 nel messaggio di Access-Accept.

Attributo RADIUS 25 (Class)

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

I team IT che configurano l'assegnazione 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 implementazioni WiFi, il NAS è tipicamente l'access point wireless o il controller LAN wireless.

Il NAS è l'autenticatore 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 della configurazione del filtro degli indirizzi di servizio dell'agente RADIUS di Okta.

Shared Secret

Una password precondivisa utilizzata per autenticare i messaggi RADIUS tra il NAS (WLC/AP) e il server RADIUS (agente RADIUS di Okta). 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 sia nella voce del server RADIUS del WLC/NAC. Dovrebbe essere composto da almeno 32 caratteri, generato in modo casuale e ruotato regolarmente. Una mancata corrispondenza è una causa comune di errori di autenticazione RADIUS.

Richiesta MFA (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 es. OTP, approvazione push) prima che l'autenticazione possa essere completata.

Il meccanismo di Access-Challenge è il modo in cui Okta impone 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 proprietà utilizza attualmente server NPS on-premises in ciascuna struttura per l'autenticazione WiFi del personale tramite 802.1X. Ciascun server NPS è aggiunto a un dominio Active Directory locale. Il team IT desidera centralizzare la gestione delle identità in Okta ed eliminare l'infrastruttura NPS per singola proprietà. Come dovrebbero affrontare la migrazione?

L'approccio consigliato è una migrazione graduale che utilizza l'agente Okta RADIUS distribuito in un VPC cloud centralizzato anziché in ciascuna proprietà. Fase 1: Distribuire due istanze dell'agente Okta RADIUS in un VPC cloud (ad esempio, AWS o Azure) nella stessa area geografica della maggior parte delle proprietà. Configurare gli agenti per l'ascolto sulla porta UDP 1812. Fase 2: Per ciascuna proprietà, 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 proprietà, configurare il WLC per l'utilizzo di EAP-TTLS/PAP e inviare 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 della 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 gestire la latenza delle API di Okta.

Commento dell'esaminatore: Questo approccio graduale è preferibile poiché elimina il rischio di un passaggio radicale e simultaneo su 150 proprietà. L'esecuzione in parallelo di NPS e Okta RADIUS durante il periodo di transizione consente di rilevare e correggere qualsiasi configurazione errata senza influire sugli utenti attivi. La distribuzione degli agenti RADIUS nel VPC cloud è architetturalmente superiore alla distribuzione per singola proprietà, poiché centralizza la gestione, riduce l'ingombro dell'infrastruttura e garantisce l'applicazione coerente delle policy indipendentemente dalla proprietà da cui l'utente si autentica. Il rischio principale da mitigare è la latenza WAN tra la proprietà e il VPC cloud - l'autenticazione RADIUS dovrebbe completarsi in meno di 2 secondi per una buona esperienza utente, pertanto la selezione dell'area geografica del VPC dovrebbe ridurre al minimo il tempo di andata e ritorno.

Una catena di vendita al dettaglio nazionale con 320 negozi deve ottenere la conformità PCI-DSS 4.0 per il WiFi del proprio personale. Gli addetti del negozio utilizzano dispositivi palmari per la gestione dell'inventario, mentre un set separato di dispositivi gestisce le transazioni dei punti vendita. La catena utilizza Okta per tutte le identità aziendali. In che modo implementano la segmentazione VLAN utilizzando Okta RADIUS per soddisfare i requisiti di segmentazione di 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 '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 in cloud), creare tre criteri di applicazione: (1) Se Class = POS-Staff, assegnare Tunnel-Private-Group-ID = 40 (la VLAN dei POS, che rientra nell'ambito PCI DSS e ha regole di firewall che limitano l'accesso al solo processore di pagamento). (2) Se Class = Inventory-Staff, assegnare Tunnel-Private-Group-ID = 50 (la VLAN di inventario, fuori 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 PCI DSS QSA.

Commento dell'esaminatore: Questa implementazione soddisfa direttamente il Requisito 1.3 (segmentazione della rete) e il Requisito 7 (controllo degli accessi in base alle esigenze aziendali) di 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 - il che significa che è scalabile su 320 negozi senza dover gestire i criteri VLAN per singolo punto vendita. Il QSA vorrà verificare che la VLAN dei POS sia realmente isolata dagli altri segmenti di rete, pertanto le configurazioni del WLC e del firewall devono riflettere i limiti della VLAN. Il System Log di Okta fornisce la traccia di controllo richiesta dal Requisito 10 di 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'uso del MAC Authentication Bypass (MAB) per tali dispositivi anziché l'802.1X, utilizzando Okta RADIUS solo per i dispositivi autenticati tramite utente.

Domande di esercitazione

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

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 critici 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 per impostazione predefinita PEAP-MSCHAPv2, che l'agente RADIUS di Okta 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 questa modifica, 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 RADIUS avanzate dell'applicazione RADIUS di Okta - senza questa opzione, agli utenti potrebbe essere richiesto di selezionare manualmente il fattore MFA invece di 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é ricevere una notifica push fluida.

Q2. Il team di sicurezza di una grande catena di vendita al dettaglio ha segnalato che l'attuale implementazione WiFi Okta RADIUS utilizza un singolo server agente RADIUS. Durante una recente finestra di manutenzione per l'applicazione di 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 questo problema e quali sono le due opzioni di distribuzione per gli agenti?

Suggerimento: Considera sia la topologia di implementazione dell'agente sia la configurazione del WLC necessaria per supportare la ridondanza.

Visualizza risposta modello

Il team IT dovrebbe distribuire un minimo di due istanze dell'agente RADIUS di Okta e configurare il WLC di ciascun 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 es. AWS o Azure), idealmente in zone di disponibilità diverse. Il WLC di ciascun negozio punta a entrambi gli IP cloud, configurandone uno come primario e uno come secondario (o con il bilanciamento del carico abilitato). Ciò riduce al minimo l'infrastruttura per singolo sito ma introduce una dipendenza dalla rete WAN. Opzione B (Coppia ridondante on-premises) - distribuire due server agente presso un data center centralizzato 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 il "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 dotati di 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 RADIUS di Okta 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 alla conformità PCI DSS 4.0. Qual è l'approccio consigliato e quale è la principale giustificazione di sicurezza?

Suggerimento: Considera i requisiti PCI DSS, il livello di maturità della gestione dei dispositivi (tutti i dispositivi sono registrati nell'MDM) e le proprietà di sicurezza di ciascun metodo di autenticazione.

Visualizza risposta modello

L'approccio consigliato consiste nell'investire in EAP-TLS con una soluzione cloud PKI. La principale giustificazione di sicurezza è la mutua autenticazione: 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. Questo elimina il rischio di attacchi evil twin (in cui un AP canaglia imita l'SSID aziendale) e rimuove completamente le password dall'equazione di autenticazione WiFi, eliminando il furto di credenziali e il phishing come vettori di attacco. Per lo standard PCI DSS 4.0, EAP-TLS soddisfa implicitamente il Requisito 8.3 (MFA per l'accesso amministrativo non-console) tramite l'autenticazione basata su certificati e supporta la modalità WPA3-Enterprise a 192 bit (Requisito 4.2.1 per la crittografia forte). Il prerequisito - tutti i 2.000 dispositivi registrati in Intune - è già soddisfatto, rendendo semplice la distribuzione dei certificati tramite i profili Intune SCEP. L'agente Okta RADIUS con EAP-TTLS/PAP sarebbe una soluzione provvisoria 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 cloud PKI (in genere 3-8 dollari per dispositivo all'anno) è giustificato dal miglioramento della sicurezza e dalla riduzione dei costi di gestione delle credenziali.

Domande frequenti

Posso connettere Okta direttamente al WiFi aziendale senza un server RADIUS intermedio?

No. Gli access point e i controller wireless aziendali autenticano i client utilizzando il protocollo 802.1X, che si basa su RADIUS (Remote Authentication Dial-In User Service). Poiché Okta è un identity provider cloud che opera tramite API REST, SAML o OIDC, non può comunicare direttamente con il protocollo RADIUS sulle porte UDP 1812 e 1813. È necessario distribuire l'agente server RADIUS Okta on-premises o un servizio cloud RADIUS che converta le richieste di autenticazione di rete in chiamate API di Okta.

Qual è la differenza tra l'agente RADIUS Okta on-premise e Cloud RADIUS?

L'agente RADIUS Okta è un servizio ospitato su una macchina virtuale interna Windows o Linux. Riceve le richieste RADIUS dai controller wireless e le inoltra tramite proxy alle API di Okta. Cloud RADIUS è un servizio cloud interamente gestito e multi-regione che non richiede macchine virtuali on-premise, offre un'integrazione PKI nativa per i certificati client EAP-TLS e scala a livello globale con failover automatizzato.

Quale protocollo di autenticazione EAP deve essere utilizzato con l'agente RADIUS Okta?

Okta raccomanda l'uso di EAP-TTLS (Tunneled Transport Layer Security) con PAP come metodo di autenticazione interno quando si utilizza l'agente RADIUS Okta. Il protocollo EAP-TTLS stabilisce un tunnel TLS crittografato utilizzando un certificato lato server sull'agente RADIUS, proteggendo le credenziali dell'utente in transito e consentendo a Okta di convalidare le password direttamente rispetto alla sua directory cloud senza richiedere certificati lato client.

Come funziona l'assegnazione dinamica della VLAN tra Okta e i controller wireless?

L'assegnazione dinamica della VLAN consente al controller LAN wireless di collocare gli utenti in segmenti di rete specifici in base alla loro appartenenza ai gruppi di Okta. Durante l'autenticazione 802.1X, il server RADIUS restituisce attributi standard nella risposta Access-Accept: Tunnel-Type (Attributo 64 = VLAN), Tunnel-Medium-Type (Attributo 65 = 802) e Tunnel-Private-Group-ID (Attributo 81 = ID o nome della VLAN). Il controller assegna il client a quel tag VLAN al momento della connessione.

Quali impostazioni di timeout RADIUS sono necessarie quando si utilizza la MFA push di Okta Verify per il WiFi?

I timeout RADIUS standard da 3 a 5 secondi sono troppo brevi per le notifiche push interattive, causando l'interruzione delle connessioni da parte del controller wireless prima che l'utente possa approvare la richiesta sul proprio telefono. Quando si abilitano le notifiche push di Okta Verify per l'accesso WiFi, è necessario aumentare il timeout di ritrasmissione RADIUS del controller wireless ad almeno 30 o 60 secondi e impostare i tentativi di riprova a 1 o 2 per evitare notifiche push duplicate.

Continua a leggere questa serie

Sophos Firewall e guest WiFi: configurazione del Captive Portal con Purple

Come il cloud guest WiFi di Purple funziona con Sophos Firewall e i suoi access point attraverso un Captive Portal esterno standard e RADIUS, e dove verificare il supporto e trovare i passaggi.

Leggi la guida →

Aruba Central e Purple WiFi: integrazione gestita in cloud

Una guida di riferimento tecnico completa per integrare Aruba Central con la piattaforma cloud di guest WiFi intelligence di Purple. Questa guida copre l'architettura, la configurazione dettagliata di Captive Portal esterni e RADIUS, e le strategie di implementazione multi-sito per i team IT aziendali.

Leggi la guida →

Autenticazione WiFi con Microsoft Entra ID (Azure AD): Guida all'integrazione enterprise

Questa guida tecnica offre a ingegneri di rete, architetti IT e amministratori di sistema un modello autorevole per l'integrazione di Microsoft Entra ID (precedentemente Azure AD) con un'infrastruttura WiFi enterprise 802.1X. Scopri come eliminare i server RADIUS on-premises, distribuire certificati EAP-TLS passwordless tramite Microsoft Intune SCEP e Cloud PKI, e automatizzare l'assegnazione dinamica della VLAN utilizzando i gruppi di sicurezza di Entra ID.

Leggi la guida →

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.