Autenticazione WiFi Enterprise senza Active Directory o server on-premise
Questa guida spiega come implementare una autenticazione WiFi WPA2/3-Enterprise sicura senza Active Directory on-premise, Windows NPS o server RADIUS. Copre la discrepanza di protocollo tra i provider di identità cloud e lo standard 802.1X, i vantaggi di EAP-TLS rispetto a PEAP-MSCHAPv2 e come implementare cloud RADIUS con certificati emessi da MDM per Microsoft Entra ID, Okta o Google Workspace. Scritta per i responsabili IT di organizzazioni cloud-first e ad alta densità di Mac/Chromebook pronte a dismettere le infrastrutture on-premise.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida alla sicurezza del WiFi Enterprise →
Sintesi per la direzione
La maggior parte delle organizzazioni ha spostato la propria identità sul cloud. Microsoft Entra ID, Okta e Google Workspace ora gestiscono utenti, gruppi e policy di accesso per e-mail, app SaaS e gestione dei dispositivi. Tuttavia, il WiFi aziendale non ha tenuto il passo. Gli access point si aspettano ancora un server RADIUS, e storicamente quel server RADIUS è stato Windows Network Policy Server (NPS) connesso a un domain controller Active Directory on-premises.
Questo disallineamento costringe i team IT a mantenere un'infrastruttura on-premises ridondante al solo scopo di tenere in funzione il WiFi. La soluzione è il cloud RADIUS: un servizio di autenticazione completamente gestito che comunica in RADIUS con i tuoi access point e in OAuth2, SCIM e SAML con il tuo provider di identità cloud. Associandolo alla distribuzione dei certificati EAP-TLS tramite il tuo MDM, otterrai un'implementazione 802.1X completa senza server on-premises, senza patch del sistema operativo e con revoca istantanea dell'accesso collegata direttamente alla tua directory cloud.
Purple gestisce il cloud RADIUS in oltre 80.000 sedi a livello globale, con un uptime del 99,999% (dati interni Purple, 2024) e integrazioni native con Microsoft Entra ID, Okta e Google Workspace. Puoi essere operativo sui tuoi access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet esistenti in meno di un'ora.
Approfondimento tecnico
Il disallineamento dei protocolli alla base del problema
La sfida fondamentale risiede nel fatto che i provider di identità cloud e gli access point WiFi parlano lingue completamente diverse. Microsoft Entra ID (precedentemente Azure AD) autentica gli utenti tramite SAML, OIDC e OAuth2 - i protocolli utilizzati dai browser e dalle app SaaS. Gli access point WiFi utilizzano RADIUS (Remote Authentication Dial-In User Service, RFC 2865), un protocollo basato su UDP progettato negli anni '90 per connessioni dial-up e VPN. Microsoft non ha mai rilasciato un endpoint RADIUS nativo per Entra ID. Non è possibile indirizzare un access point Meraki o Aruba direttamente ad Azure e aspettarsi che l'802.1X funzioni.
Questo è l'ostacolo contro cui si scontra ogni team IT cloud-first quando cerca di proteggere il WiFi del personale con WPA2-Enterprise o WPA3-Enterprise. Qualcosa deve colmare il divario tra l'access point e il provider di identità cloud. Quel qualcosa è il cloud RADIUS.
Perché PEAP-MSCHAPv2 fallisce senza Active Directory
Storicamente, le implementazioni 802.1X si affidavano a PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versione 2). L'utente inseriva il proprio nome utente e la password, l'access point inoltrava la richiesta al server RADIUS e il server RADIUS convalidava la password rispetto a un hash NTLM memorizzato in Active Directory.
Microsoft Entra ID does not store NTLM hashes. This is not a configuration gap - it is a deliberate architectural decision. Entra ID is a modern cloud identity provider, not a domain controller. Consequently, a RADIUS server pointed at Entra ID cannot validate a PEAP-MSCHAPv2 challenge. The only way to make PEAP work with Entra ID is to deploy Entra Domain Services, a paid managed Active Directory that synchronises from Entra ID, and then run NPS against that. This reintroduces most of what you were trying to eliminate: Windows Server VMs, OS patching, NTLM hash storage, and manual certificate management.
EAP-TLS: la risposta corretta per le organizzazioni cloud-first
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) sostituisce le password con certificati digitali X.509. Il dispositivo presenta un certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto a un'Autorità di Certificazione (CA) fidata. Poiché non vi è alcuna password nello scambio, il server RADIUS non ha bisogno di un archivio di hash NTLM. Deve solo considerare attendibile la CA e verificare l'appartenenza al gruppo dell'utente nell'identity provider per applicare la VLAN e i criteri di accesso corretti.
EAP-TLS è resistente al phishing per progettazione. Non ci sono credenziali da rubare. Soddisfa le linee guida CISA sull'autenticazione a più fattori resistente al phishing e si allinea ai requisiti PCI-DSS per l'autenticazione forte sulle reti che gestiscono i dati dei titolari di carta. È il metodo di autenticazione raccomandato da IEEE 802.1X per le flotte di dispositivi gestiti.
Architettura di autenticazione 802.1X cloud-first: i dispositivi si autenticano tramite EAP-TLS attraverso il cloud RADIUS di Purple, che convalida i certificati e applica criteri basati sui gruppi da Entra ID, Okta o Google Workspace.
Come l'MDM sostituisce la CA locale
In una distribuzione 802.1X tradizionale, i certificati venivano emessi da un'Autorità di Certificazione locale che eseguiva Active Directory Certificate Services (AD CS). In una distribuzione cloud-first, l'MDM assume questo ruolo utilizzando SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro e altre piattaforme MDM possono richiedere certificati a una CA ospitata nel cloud e distribuirli in modo invisibile ai dispositivi gestiti.
Il flusso funziona come segue. L'amministratore IT crea un profilo di certificato SCEP nell'MDM, limitato ai gruppi di dispositivi che richiedono l'accesso WiFi. L'MDM invia automaticamente il certificato ai dispositivi Windows, macOS, iOS, iPadOS, Android Enterprise e ChromeOS. L'utente non vede nulla. Il certificato è associato all'identità del dispositivo nell'MDM e si rinnova automaticamente prima della scadenza. Quando il dispositivo si connette al WiFi, presenta il certificato al server cloud RADIUS, che lo convalida rispetto alla CA e applica i criteri di rete corretti.
Per le organizzazioni che utilizzano Microsoft Intune, Microsoft Cloud PKI fornisce una CA completamente gestita che si integra direttamente con i profili SCEP di Intune, eliminando la necessità di un server NDES (Network Device Enrollment Service) locale. Per le flotte Mac e iOS gestite da Jamf, la CA integrata di Jamf o una CA cloud di terze parti svolgono lo stesso scopo.
SCIM e revoca immediata dell'accesso
Uno degli aspetti operativamente più importanti del cloud RADIUS è il provisioning SCIM (System for Cross-domain Identity Management). SCIM è uno standard aperto che invia le modifiche d'identità dall'origine dei dati - il vostro provider di identità cloud - ai sistemi dipendenti in tempo reale. Quando un dipendente viene disabilitato in Entra ID o Okta, SCIM invia immediatamente tale modifica al servizio cloud RADIUS. Al successivo tentativo di autenticazione del dispositivo, il server RADIUS restituisce un messaggio di Access-Reject. Con un breve timeout di sessione configurato sull'access point, il dispositivo viene rimosso dalla rete entro pochi minuti dalla disattivazione dell'account.
Questo rappresenta un miglioramento tangibile della sicurezza rispetto alle reti PSK condivise, dove l'unico modo per revocare l'accesso è cambiare la password su ogni dispositivo, e rispetto alle distribuzioni RADIUS legacy che si affidano a sincronizzazioni LDAP periodiche con intervalli di ore o giorni.
RadSec: proteggere il traffico RADIUS su internet
Il RADIUS tradizionale utilizza UDP e fornisce solo un'autenticazione di base dei messaggi. Quando il server RADIUS si trova nello stesso data center degli access point, questo è accettabile. Quando il server RADIUS è un servizio cloud, il traffico di autenticazione attraversa la rete internet pubblica. RadSec (RADIUS su TLS, RFC 6614) crittografa lo scambio RADIUS tramite TLS, garantendo riservatezza e integrità al traffico di autenticazione. Purple supporta RadSec nativamente, con fallback IPsec per gli access point che non supportano ancora RadSec.
-
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
La distribuzione di cloud RADIUS con EAP-TLS richiede quattro passaggi coordinati. Un SSID pilota può essere attivo in meno di un'ora se Entra ID e un MDM sono già configurati.
Passaggio 1: Connettere il cloud RADIUS al provider di identità
Connetti Purple al tuo provider di identità tramite il consenso dell'amministratore OAuth2 (per Entra ID) o tramite token API (per Okta e Google Workspace). Questo autorizza Purple a leggere utenti, gruppi e appartenenze ai gruppi dalla directory. Configura il provisioning SCIM per inviare le modifiche dello stato degli utenti a Purple in tempo reale. Nessuna credenziale di entità servizio viene memorizzata su disco. Le modifiche ai gruppi si propagano al successivo evento di autenticazione, non in base a una pianificazione di sincronizzazione.
Passaggio 2: Configurare l'MDM e il profilo SCEP
In Microsoft Intune, crea un Profilo Certificato Attendibile per la CA radice, quindi crea un profilo certificato SCEP che punti alla CA gestita da Purple. Associa entrambi i profili ai gruppi di dispositivi che richiedono l'accesso WiFi. Per Jamf, configura un payload SCEP in un profilo di configurazione. L'MDM distribuisce i certificati in modo invisibile. Verifica la consegna dei certificati nella dashboard di conformità MDM prima di procedere.
Passaggio 3: Definire i criteri di rete nella dashboard RADIUS in cloud
Creare criteri RADIUS che associno i gruppi dell'identity provider a VLAN specifiche e controlli di accesso. Ad esempio, associare il gruppo Entra ID "Staff-Finance" alla VLAN 20 con accesso completo a Internet, e associare "Staff-Contractors" alla VLAN 30 con accesso a tempo limitato che scade automaticamente. La dashboard di Purple applica questi criteri al momento dell'autenticazione, senza richiedere modifiche al firewall.
Passaggio 4: Aggiornare la configurazione degli access point
Aggiornare la configurazione del SSID sui vostri access point per utilizzare WPA2-Enterprise o WPA3-Enterprise con 802.1X. Inserire gli indirizzi IP o gli hostname degli endpoint primari e secondari del cloud RADIUS di Purple, insieme al shared secret. Configurare gli access point per utilizzare l'assegnazione dinamica delle VLAN in base agli attributi RADIUS restituiti da Purple. Eseguire un test con un singolo SSID su un sottoinsieme di access point prima di distribuirlo su tutta l'infrastruttura.
Cloud RADIUS vs RADIUS on-premises: un confronto diretto tra tempi di implementazione, dipendenza da Active Directory, disponibilità elevata, applicazione di patch del sistema operativo, integrazione dell'identità e gestione del ciclo di vita dei certificati.
Best practice
Questi consigli riflettono gli standard IEEE 802.1X, i requisiti PCI-DSS v4.0 e l'esperienza operativa maturata in oltre 80.000 sedi Purple.
Imporre EAP-TLS per i dispositivi gestiti. Le password sono vulnerabili al phishing e al credential stuffing. I certificati forniscono una prova crittografica dell'identità e della conformità del dispositivo. L'EAP-TLS è l'unico metodo 802.1X intrinsecamente resistente al phishing.
Utilizzare SCIM per la revoca istantanea. Le sincronizzazioni periodiche LDAP lasciano una finestra temporale in cui un dipendente licenziato mantiene l'accesso alla rete. Lo SCIM garantisce che l'accesso venga revocato nel momento stesso in cui l'account viene disabilitato nell'identity provider.
Implementare RADIUS multi-regione. Configurare gli access point con almeno due endpoint RADIUS in regioni geografiche diverse. Purple fornisce un failover multi-regione attivo-attivo per impostazione predefinita, con un ripristino che si completa in pochi secondi.
Segmentare il traffico con VLAN dinamiche. Utilizzare le appartenenze ai gruppi dell'identity provider per assegnare dinamicamente gli utenti a specifiche VLAN. In questo modo si isola il traffico sensibile e si limita la portata di un eventuale attacco a un dispositivo compromesso senza richiedere modifiche manuali al firewall.
Abilitare RadSec. Se gli access point supportano RadSec, abilitarlo per crittografare il traffico di autenticazione tra l'access point e il server cloud RADIUS. Questo è particolarmente importante per le filiali e le sedi in cui l'access point si trova su un segmento di rete non attendibile.
Monitorare il ciclo di vita dei certificati. Impostare il rinnovo automatico MDM all'80% della durata del certificato. Per un certificato di un anno, il rinnovo inizia al decimo mese. Attivare avvisi per i dispositivi che non si rinnovano prima della scadenza del certificato. Per una trattazione più ampia degli standard e dei framework di sicurezza per le reti WiFi aziendali, consulta la nostra Enterprise WiFi Security: A Complete Guide for 2026.
Risoluzione dei problemi e mitigazione dei rischi
Il passaggio a un RADIUS in cloud introduce nuove dipendenze. Preparati a gestire questi scenari di errore comuni prima che abbiano un impatto sull'ambiente di produzione.
Scadenza dei certificati. Se il certificato di un dispositivo scade prima che l'MDM lo rinnovi, l'autenticazione del dispositivo fallisce in modo silenzioso. L'utente visualizza un errore di connessione senza alcuna spiegazione. Mitiga questo rischio configurando il rinnovo automatico dell'MDM all'80% della durata del certificato e monitorando la dashboard di conformità dell'MDM per i dispositivi con certificati in scadenza.
Errori di sincronizzazione dell'MDM. Un dispositivo che non rispetta i requisiti di conformità dell'MDM o che non riesce a effettuare il check-in potrebbe non ricevere un certificato rinnovato. Implementa criteri di conformità che segnalino i dispositivi non integri e avvisino gli amministratori prima della scadenza del certificato.
Blocco del traffico RADIUS da parte del firewall. Gli access point devono poter raggiungere gli endpoint del RADIUS in cloud sulla porta UDP 1812 (autenticazione) e sulla porta UDP 1813 (accounting), oppure sulla porta TCP 2083 per RadSec. Le regole dei firewall in uscita presso le filiali bloccano frequentemente queste porte. Verifica la raggiungibilità dalla VLAN di gestione degli access point prima del deployment.
Errori di provisioning SCIM. Se la connessione SCIM tra l'identity provider e Purple viene interrotta, le variazioni dello stato degli utenti non verranno propagate. Monitora lo stato di sincronizzazione di SCIM sia nell'identity provider che nella dashboard di Purple. Configura gli avvisi per gli errori di sincronizzazione.
Dispositivi legacy senza supporto per i certificati. I dispositivi IoT, le stampanti e l'hardware più datato potrebbero non supportare EAP-TLS. Per questi dispositivi, utilizza iPSK (chiavi pre-condivise individuali) anziché una PSK condivisa. Purple supporta iPSK in modo nativo, assegnando una chiave univoca per dispositivo e inserendo ciascun dispositivo nella VLAN corretta senza richiedere il supporto del supplicant 802.1X.
ROI e impatto sul business
La migrazione da un RADIUS on-premises a un RADIUS in cloud offre un valore misurabile in termini di infrastruttura, operazioni e sicurezza.
| Dimensione | NPS on-premises | RADIUS in cloud (Purple) |
|---|---|---|
| Costo dell'infrastruttura | Licenze Windows Server, calcolo VM, storage | Abbonamento per AP, nessun hardware server |
| Tempo di implementazione | Da giorni a settimane | Meno di un'ora |
| Alta affidabilità | Manuale - due server più replica | Attiva-attiva multi-regione, predefinita |
| Patching del sistema operativo | Mensile, a carico del tuo team | Gestito dal vendor |
| Ticket di assistenza WiFi | Elevati - reimpostazione password, onboarding manuale | Ridotti dell'80% (dati dei clienti Purple) |
| Revoca dell'accesso | Da ore a giorni tramite sincronizzazione LDAP | Secondi tramite SCIM |
| I team IT che utilizzano la Staff WiFi di Purple registrano solitamente una riduzione dell'80% dei ticket di assistenza WiFi (dati interni Purple, 2024), grazie all'eliminazione delle reimpostazioni delle password e dell'onboarding manuale dei dispositivi. L'autenticazione basata su certificati soddisfa inoltre il requisito PCI-DSS 8.3 per l'autenticazione forte e il controllo ISO 27001 A.9.4 per il controllo degli accessi a sistemi e applicazioni, riducendo l'onere di audit per il team di sicurezza. |
Per le organizzazioni nei settori retail e hospitality, la possibilità di gestire la Staff WiFi e la Guest WiFi da un'unica dashboard cloud - con un livello di identità unificato - riduce la complessità operativa nei patrimoni multi-sito. Per gli operatori di trasporti e i fornitori di servizi sanitari, la funzionalità di revoca istantanea e il registro di audit completo soddisfano i requisiti normativi senza strumenti aggiuntivi.
Il livello di WiFi Analytics di Purple aggiunge dati sull'occupazione e sul lavoro ibrido all'infrastruttura di autenticazione, trasformando la Staff WiFi da un centro di costo in una fonte di intelligence operativa.
-
Letture correlate: Enterprise WiFi Security: A Complete Guide for 2026 - OpenWrt Custom Firmware Integration with Purple WiFi
Definizioni chiave
802.1X
Uno standard IEEE (IEEE 802.1X-2020) per il controllo dell'accesso alla rete basato su porte. Richiede che i dispositivi si autentichino prima che l'access point conceda l'accesso alla rete, utilizzando uno scambio EAP mediato da un server RADIUS.
I team IT utilizzano lo standard 802.1X per garantire che solo gli utenti e i dispositivi autorizzati si connettano alla rete aziendale. Fornisce crittografia per singolo utente, chiavi per singola sessione e una traccia di controllo completa di ogni evento di connessione.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Un protocollo di rete che fornisce la gestione centralizzata di autenticazione, autorizzazione e tracciamento (AAA) per l'accesso alla rete.
Gli access point inoltrano ogni richiesta di connessione al server RADIUS, che decide se ammettere il dispositivo e a quale VLAN assegnarlo. Cloud RADIUS sostituisce i server NPS o FreeRADIUS locali.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Un metodo di autenticazione 802.1X che utilizza lo scambio reciproco di certificati X.509 anziché le password.
EAP-TLS rappresenta il gold standard per le flotte di dispositivi gestiti. È resistente al phishing, non richiede un archivio di hash delle password ed è l'unico metodo 802.1X che soddisfa le linee guida CISA per l'MFA resistente al phishing.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versione 2. Un metodo legacy 802.1X che convalida le password confrontandole con gli hash NTLM memorizzati in Active Directory.
PEAP-MSCHAPv2 non funziona in ambienti esclusivamente cloud poiché Entra ID non memorizza gli hash NTLM. Le organizzazioni che migrano da AD locale devono sostituire PEAP con EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Un protocollo utilizzato dalle piattaforme MDM per richiedere e installare automaticamente certificati digitali sui dispositivi, senza alcuna interazione da parte dell'utente.
I team IT utilizzano SCEP con Intune o Jamf per distribuire in modo invisibile i certificati WiFi ai dispositivi dei dipendenti. SCEP sostituisce il server locale NDES (Network Device Enrollment Service) nelle distribuzioni cloud-first.
SCIM
System for Cross-domain Identity Management (RFC 7644). Uno standard aperto che automatizza lo scambio in tempo reale di informazioni sull'identità degli utenti tra i sistemi IT.
SCIM garantisce che quando un dipendente viene disabilitato in Entra ID o Okta, tale modifica venga immediatamente trasmessa al servizio cloud RADIUS, revocando l'accesso al WiFi nel giro di pochi secondi anziché di ore.
NPS
Network Policy Server. L'implementazione RADIUS di Microsoft, generalmente eseguita su Windows Server come parte di un ambiente Active Directory locale.
Le organizzazioni cloud-first stanno dismettendo NPS per eliminare le VM Windows Server, l'applicazione di patch al sistema operativo e la dipendenza da Active Directory locale. Cloud RADIUS rappresenta la sostituzione diretta.
RadSec
RADIUS su TLS (RFC 6614). Un protocollo che crittografa il traffico di autenticazione RADIUS utilizzando TLS, sostituendo il trasporto in testo chiaro basato su UDP utilizzato dal RADIUS tradizionale.
RadSec è fondamentale quando si utilizza il cloud RADIUS, poiché il traffico di autenticazione deve attraversare l'internet pubblica tra l'access point e il servizio cloud. Purple supporta RadSec in modo nativo.
iPSK
Individual Pre-Shared Key. Una variante di WPA2-Personal che assegna una chiave precondivisa univoca a ciascun dispositivo, anziché un'unica chiave condivisa per tutti i dispositivi.
iPSK viene utilizzato per dispositivi IoT, stampanti e altri componenti hardware che non possono supportare 802.1X EAP-TLS. Consente l'identificazione del singolo dispositivo e l'assegnazione della VLAN senza richiedere il supporto dei certificati.
Dynamic VLAN
Una tecnica di segmentazione della rete in cui il server RADIUS restituisce un identificatore VLAN nella risposta Access-Accept, e l'access point inserisce automaticamente il dispositivo in tale VLAN.
Le VLAN dinamiche consentono ai team IT di segmentare dipendenti, collaboratori esterni, dispositivi IoT e ospiti in segmenti di rete separati in base all'appartenenza ai gruppi del provider di identità, senza modifiche manuali al firewall.
Esempi pratici
Una catena di vendita al dettaglio con 400 punti vendita deve proteggere il WiFi del personale in tutte le sedi. Utilizzano access point Cisco Meraki e Microsoft Entra ID con Intune per la gestione dei dispositivi. Attualmente utilizzano una chiave condivisa WPA2-Personal PSK perché non dispongono di Active Directory on-premise per eseguire NPS. Un recente audit interno ha segnalato la PSK condivisa come una lacuna di conformità PCI-DSS.
La catena implementa il cloud RADIUS di Purple. Innanzitutto, collegano Purple a Entra ID tramite consenso amministratore OAuth e configurano il provisioning SCIM. In Intune, creano un Profilo Certificato Attendibile per la CA radice di Purple e un profilo certificato SCEP limitato al gruppo di dispositivi "Staff-Retail". Intune distribuisce in modo silenzioso i certificati a tutti i terminali POS gestiti e ai tablet del personale. Nel dashboard Meraki, aggiornano l'SSID del personale a WPA2-Enterprise, inseriscono gli endpoint primario e secondario del cloud RADIUS di Purple e abilitano l'assegnazione dinamica della VLAN. Quando un dispositivo si connette, presenta il certificato emesso da Intune, Purple lo convalida rispetto alla CA e verifica il gruppo Entra ID, e il dispositivo viene inserito nella VLAN 10 (rete personale) o nella VLAN 20 (rete di gestione) in base all'appartenenza al gruppo. La PSK condivisa viene dismessa. La distribuzione in tutti i 400 punti vendita richiede un solo fine settimana, poiché non viene distribuito hardware in loco - vengono effettuate solo modifiche alla configurazione dell'SSID in Meraki.
Un'università con 15.000 studenti utilizza Google Workspace come provider di identità principale. Il team IT desidera fornire un WiFi sicuro per il personale e gli studenti su un parco dispositivi BYOD composto da MacBook, Chromebook e telefoni Android. Non hanno Active Directory on-premise e non hanno intenzione di gestire server.
L'università integra il cloud RADIUS di Purple con Google Workspace. Per i Chromebook gestiti, utilizzano la Console di amministrazione Google per distribuire un profilo certificato WiFi tramite SCEP, registrando silenziosamente ogni dispositivo. Per i MacBook e i telefoni Android BYOD, distribuiscono un'applicazione di onboarding leggera che autentica l'utente con le sue credenziali Google e installa un certificato sul dispositivo con un solo tocco. Le connessioni successive utilizzano EAP-TLS in modo silenzioso. Purple mappa le Unità Organizzative di Google Workspace sulle VLAN: il personale atterra sulla VLAN 10, gli studenti sulla VLAN 20 e i visitatori ospiti su un SSID con Captive Portal. Quando uno studente si laurea e il suo account Google viene sospeso, SCIM invia la modifica a Purple e il suo accesso WiFi viene revocato in pochi minuti.
Domande di esercitazione
Q1. La tua organizzazione è migrata completamente da Active Directory on-premises a Microsoft Entra ID. Il tuo attuale WiFi per il personale utilizza PEAP-MSCHAPv2 con un server NPS associato al vecchio dominio. Dopo la disattivazione del controller di dominio, il personale segnala di non riuscire più a connettersi al WiFi. Qual è la causa principale e qual è la corretta soluzione a lungo termine?
Suggerimento: Considera ciò che PEAP-MSCHAPv2 richiede alla directory e se Entra ID è in grado di fornirlo.
Visualizza risposta modello
La causa principale è che PEAP-MSCHAPv2 richiede che il server RADIUS convalidi la password dell'utente rispetto a un hash NTLM memorizzato in Active Directory. Con il controller di dominio disattivato, NPS non ha un database rispetto al quale effettuare la convalida. Entra ID non memorizza gli hash NTLM, pertanto NPS non può essere reindirizzato a Entra ID. La corretta soluzione a lungo termine consiste nel sostituire NPS con un servizio cloud RADIUS, migrare da PEAP-MSCHAPv2 a EAP-TLS e utilizzare l'MDM (Intune) per emettere certificati del dispositivo tramite SCEP. Questo elimina la dipendenza da qualsiasi directory on-premises.
Q2. Stai implementando il cloud RADIUS per una flotta di 200 MacBook aziendali gestiti da Jamf Pro. Il tuo identity provider è Okta. Qual è il modo più sicuro ed efficiente dal punto di vista operativo per distribuire le credenziali WiFi a questi dispositivi?
Suggerimento: Cerca un metodo che non richieda l'interazione dell'utente, eviti le password e si integri con il tuo MDM esistente.
Visualizza risposta modello
Configura Jamf Pro per utilizzare SCEP per inviare silenziosamente i certificati del dispositivo ai MacBook. Crea un payload SCEP in un profilo di configurazione Jamf, puntando alla CA gestita dal tuo provider cloud RADIUS. Associa il profilo al gruppo di dispositivi pertinente. Jamf invierà automaticamente il certificato a ciascun MacBook, senza alcuna interazione da parte dell'utente. Configura il profilo WiFi nello stesso profilo di configurazione per utilizzare EAP-TLS con il certificato emesso tramite SCEP. Collega il servizio cloud RADIUS a Okta tramite SCIM per garantire che quando un dipendente viene disattivato in Okta, il suo accesso WiFi venga revocato immediatamente.
Q3. Un dipendente viene licenziato alle 9:00 di lunedì. Il suo account Entra ID viene disattivato dalle Risorse Umane alle 9:05. Alle 9:30, un avviso di sicurezza mostra che il laptop del dipendente è ancora connesso al WiFi aziendale dal parcheggio. Quale configurazione manca e come si risolve il problema?
Suggerimento: In che modo il server RADIUS viene a conoscenza del fatto che lo stato dell'utente è cambiato nell'identity provider?
Visualizza risposta modello
La configurazione si affida a sincronizzazioni LDAP periodiche anziché al provisioning SCIM. La sincronizzazione LDAP non è ancora stata eseguita da quando l'account è stato disattivato, quindi il servizio cloud RADIUS considera l'utente ancora attivo. La soluzione consiste nell'abilitare il provisioning SCIM tra Entra ID e il servizio cloud RADIUS. SCIM invia le modifiche dello stato dell'utente in tempo reale, quindi quando l'account viene disattivato in Entra ID alle 9:05, il servizio RADIUS riceve immediatamente la modifica. Al successivo tentativo di riautenticazione del dispositivo (controllato dal timeout della sessione sull'access point), questo riceverà un Access-Reject. L'impostazione di un timeout di sessione breve (da 15 a 30 minuti) sull'access point limita la finestra temporale massima tra la disattivazione dell'account e l'esclusione dalla rete.
Q4. La tua sede dispone di 50 dispositivi IoT - riproduttori di digital signage, sensori ambientali e stampanti - che non supportano 802.1X EAP-TLS. Come puoi proteggere questi dispositivi sulla stessa infrastruttura WiFi della rete del personale basata su EAP-TLS?
Suggerimento: Considera quale metodo di autenticazione garantisce la tracciabilità per singolo dispositivo senza richiedere il supporto per i certificati.
Visualizza risposta modello
Utilizza iPSK (chiavi pre-condivise individuali) per i dispositivi IoT. Assegna una chiave pre-condivisa univoca a ciascun dispositivo nella dashboard del cloud RADIUS, insieme a un'assegnazione VLAN. Ciascun dispositivo si autentica con la sua chiave univoca, che il server RADIUS convalida e utilizza per posizionare il dispositivo sulla VLAN IoT, isolata dalla rete del personale. Se un dispositivo viene compromesso o disattivato, revocherai solo la chiave di quel dispositivo senza influire su nessun altro. Questo approccio offre tracciabilità per singolo dispositivo e segmentazione di rete senza richiedere il supporto del supplicant 802.1X sull'hardware IoT.
Continua a leggere questa serie
Come revocare l'accesso WiFi quando un dipendente lascia l'azienda
Questa guida mostra ai team IT e di gestione delle sedi come rimuovere l'accesso WiFi del personale quando un dipendente lascia l'azienda, senza interrompere il lavoro degli altri collaboratori. Confronta la tecnologia 802.1X basata su certificati, l'iPSK specifico per l'identità e il deprovisioning guidato da SCIM, fornendo poi un runbook per il giorno stesso, un metodo di test e un modello di tracciabilità dei controlli.
WiFi BYOD sicuro: onboarding con certificati Passpoint vs xPSK (iPSK)
Una guida tecnica completa per i team IT su come proteggere i dispositivi non gestiti di dipendenti e studenti (BYOD) utilizzando certificati Passpoint EAP-TLS zero-touch rispetto a soluzioni xPSK specifiche del fornitore (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual è la differenza e quale dovresti usare?
Questa guida di riferimento tecnica fornisce un confronto autorevole tra gli standard di sicurezza wireless WPA2 Personal e WPA2 Enterprise. Dettaglia gli handshake crittografici sottostanti, i requisiti architetturali e le metodologie di implementazione necessarie ai leader IT per proteggere le reti aziendali. I lettori impareranno come passare da passphrase condivise a un'autenticazione individualizzata e basata su certificati per allinearsi ai framework di conformità e mitigare le minacce interne.
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.