Come configurare un server RADIUS per l'autenticazione WiFi
Questa guida autorevole fornisce ai responsabili IT e agli architetti di rete un progetto completo per l'implementazione di un server RADIUS per l'autenticazione WiFi aziendale. Copre i compromessi architetturali tra implementazioni on-premise e in cloud, la selezione del metodo EAP, l'integrazione con Active Directory e l'assegnazione dinamica delle VLAN. I gestori di sedi e i team IT troveranno passaggi di implementazione pratici, casi di studio reali e strategie di mitigazione del rischio per passare da un ambiente PSK non sicuro a una solida infrastruttura 802.1X entro questo trimestre.
Ascolta questa guida
Visualizza trascrizione del podcast
Executive Summary
Per gli ambienti aziendali — che si tratti di un vasto campus universitario, di uno stadio ad alta densità o di una catena di vendita al dettaglio distribuita — affidarsi a una chiave precondivisa (PSK) per l'accesso WiFi rappresenta un rischio significativo per la sicurezza. Una singola credenziale compromessa espone l'intera rete e la revoca dell'accesso richiede la modifica della password per ogni dispositivo presente nell'infrastruttura. L'implementazione dell'autenticazione 802.1X tramite un server RADIUS (Remote Authentication Dial-In User Service) elimina completamente questo problema: ogni utente si autentica individualmente, l'accesso può essere revocato istantaneamente e la segmentazione della rete viene applicata in modo dinamico.
Questa guida fornisce una roadmap definitiva per i responsabili IT e gli architetti di rete per implementare l'autenticazione RADIUS. Copriamo i compromessi architetturali tra implementazioni on-premise e cloud-hosted, la configurazione dei metodi EAP (Extensible Authentication Protocol) e l'integrazione con i servizi di directory come Active Directory. Dimostriamo inoltre come un solido livello di autenticazione si integri con le soluzioni di Guest WiFi per fornire un accesso fluido ai visitatori, acquisendo al contempo i dati di WiFi Analytics che trasformano la tua rete in una risorsa di business intelligence.
Approfondimento Tecnico
L'Architettura 802.1X
Lo standard IEEE 802.1X definisce il controllo dell'accesso alla rete basato su porta (PNAC). In un contesto wireless, coinvolge tre ruoli principali che lavorano in sinergia:
| Ruolo | Componente | Responsabilità |
|---|---|---|
| Supplicant | Dispositivo client (laptop, smartphone) | Presenta le credenziali per richiedere l'accesso alla rete |
| Authenticator | Access Point o Controller WiFi | Applica il controllo degli accessi; inoltra i messaggi EAP |
| Authentication Server | Server RADIUS | Convalida le credenziali; restituisce messaggi di accettazione/rifiuto e attributi di policy |
Quando un supplicant si associa a un access point, l'AP blocca tutto il traffico dati ad eccezione dei messaggi EAP (Extensible Authentication Protocol). L'AP incapsula questi messaggi EAP in pacchetti RADIUS e li inoltra al server RADIUS. Il server verifica le credenziali rispetto a un database backend — in genere LDAP o Active Directory — e restituisce un messaggio Access-Accept o Access-Reject. Se accettato, l'AP sblocca la porta e il traffico del client scorre liberamente.
Scelta di un Metodo EAP
La sicurezza della tua implementazione RADIUS dipende fortemente dal metodo EAP selezionato. I due più diffusi nelle implementazioni aziendali sono:
EAP-TLS (Transport Layer Security) è lo standard di riferimento. Richiede certificati digitali sia sul server RADIUS che su ogni dispositivo client, eliminando completamente le password. Anche se un utente malintenzionato intercettasse l'intero scambio di autenticazione, non ci sarebbero credenziali da estrarre. Il compromesso è il sovraccarico amministrativo: l'implementazione e la gestione dei certificati client richiedono un'infrastruttura a chiave pubblica (PKI) funzionante e una soluzione MDM (ad es. Microsoft Intune, Jamf) per distribuire i certificati agli endpoint.
PEAP-MSCHAPv2 (Protected EAP) è il metodo più ampiamente utilizzato nella pratica. Utilizza un certificato lato server per stabilire un tunnel TLS crittografato, all'interno del quale il client si autentica con nome utente e password. Questo è significativamente più facile da implementare rispetto a EAP-TLS perché è necessario gestire un solo certificato, quello del server. Tuttavia, comporta un avvertimento fondamentale: se i dispositivi client non sono configurati esplicitamente per convalidare il certificato del server RADIUS, sono vulnerabili ad attacchi Man-in-the-Middle (MitM) tramite access point non autorizzati.
> Nota di Sicurezza Critica: La mancata applicazione di una rigida convalida del certificato sui dispositivi client annulla di fatto i vantaggi in termini di sicurezza di PEAP-MSCHAPv2. Un utente malintenzionato può implementare un AP non autorizzato, presentare un certificato fraudolento e catturare le credenziali dell'utente in testo non crittografato. Questo non è un rischio teorico: è un vettore di attacco ampiamente documentato che è stato sfruttato in ambienti reali.
Guida all'Implementazione
Passaggio 1: Decisione Architetturale — RADIUS On-Premise vs. Cloud
La prima decisione riguarda dove ospitare l'infrastruttura RADIUS. Si tratta principalmente di una questione operativa e di costi, non di sicurezza: entrambi i modelli possono essere implementati in modo sicuro.
RADIUS On-Premise (ad es. Microsoft NPS, FreeRADIUS, Cisco ISE) è adatto per organizzazioni con personale IT dedicato, infrastruttura di directory on-premise esistente e requisiti stringenti di sovranità dei dati o conformità. Non dipende dalla connettività Internet per l'autenticazione, il che rappresenta un vantaggio significativo per gli ambienti in cui non è possibile garantire il tempo di attività di Internet.
Cloud RADIUS è sempre più il modello preferito per gli ambienti distribuiti: catene di Retail , gruppi di Hospitality e hub di Transport in cui l'implementazione di server in ogni sede è operativamente impraticabile. Cloud RADIUS si integra nativamente con i provider di identità cloud (Azure AD, Google Workspace, Okta) e offre alta disponibilità integrata e scalabilità globale.
Passaggio 2: Installare e Configurare il Server RADIUS
Per un'implementazione on-premise che utilizza Microsoft NPS (la scelta più comune in ambienti incentrati su Windows):
- Installare il ruolo Network Policy Server tramite Server Manager.
- Registra il server NPS in Active Directory per consentirgli di leggere le proprietà di connessione degli utenti.
- Crea una voce RADIUS Client per ogni access point o controller wireless, specificando l'indirizzo IP dell'AP e un Shared Secret forte e univoco.
- Configura una Network Policy definendo le condizioni (ad es. appartenenza a gruppi di utenti) e i vincoli (ad es. metodo EAP, timeout della sessione) per l'accesso.
- Configura la Connection Request Policy per elaborare le richieste localmente.
Per FreeRADIUS su Linux:
- Installa tramite il gestore pacchetti:
sudo apt-get install freeradius freeradius-ldap. - Configura
/etc/freeradius/3.0/clients.confper definire i client RADIUS (AP) e i relativi shared secret. - Configura il modulo LDAP in
/etc/freeradius/3.0/mods-available/ldapper puntare al tuo Active Directory o server LDAP. - Abilita il modulo LDAP:
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/. - Definisci i metodi EAP in
/etc/freeradius/3.0/mods-available/eap.
Step 3: Configura gli Access Point
Sul tuo controller wireless o sui singoli access point:
- Definisci l'indirizzo o gli indirizzi IP del server RADIUS e la porta di autenticazione (predefinita: UDP 1812).
- Configura lo Shared Secret — utilizza un minimo di 22 caratteri, combinando caratteri alfanumerici e speciali. Utilizza un segreto univoco per sede o gruppo di AP.
- Configura l'SSID per utilizzare la modalità di sicurezza WPA2-Enterprise o WPA3-Enterprise con gestione delle chiavi 802.1X.
- Configura un server RADIUS secondario per il failover.
Step 4: Integrazione della Directory
Per l'integrazione con AD on-premise, il server RADIUS deve essere aggiunto al dominio o disporre dell'accesso in lettura LDAP. Assicurati che gli account di servizio utilizzati per il binding LDAP abbiano i permessi minimi richiesti. Per il RADIUS in cloud, configura la sincronizzazione basata su API o l'integrazione SAML/OIDC con il tuo IdP.
Definisci gruppi di utenti chiari nella tua directory, poiché questi guideranno le policy di autorizzazione. Struttura dei gruppi consigliata:
| Gruppo | VLAN | Livello di Accesso |
|---|---|---|
Corp_Staff |
VLAN 10 | Rete interna completa |
Corp_Contractors |
VLAN 20 | Internet + risorse interne specifiche |
Corp_IoT |
VLAN 30 | Solo porte isolate e specifiche per dispositivo |
Corp_Guests |
VLAN 100 | Solo Internet tramite Captive Portal |
Step 5: Configurazione dei Client e Validazione dei Certificati
Questo è il passaggio più critico a livello operativo. Utilizza le Group Policy (GPO) per Windows e i profili MDM per macOS/iOS/Android per distribuire silenziosamente le configurazioni WiFi ai dispositivi gestiti. Il profilo deve specificare:
- La Root CA che ha emesso il certificato del server RADIUS.
- Il nome del server previsto (CN o SAN del certificato del server).
- Il metodo EAP e il protocollo di autenticazione interno.
Per i dispositivi BYOD non gestiti, fornisci istruzioni chiare per l'onboarding in modalità self-service, idealmente tramite un portale di Network Access Control (NAC).
Step 6: Implementa l'Assegnazione Dinamica della VLAN
Configura il server RADIUS per restituire gli attributi di assegnazione della VLAN nella risposta Access-Accept:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id= ``
L'access point legge questi attributi e inserisce il client autenticato nella VLAN specificata, senza richiedere alcuna riconfigurazione manuale quando gli utenti cambiano ruolo o posizione.
Best Practice
La ridondanza non è negoziabile. Distribuisci un minimo di due server RADIUS (primario e secondario) e configura tutti gli access point per il failover automatico. Per le distribuzioni on-premise, considera di posizionare il server secondario in una posizione fisica o in una zona di disponibilità diversa. Un'interruzione del servizio RADIUS significa che nessuno può autenticarsi, il che si traduce in un'interruzione totale della rete per gli SSID protetti da 802.1X.
Monitora la scadenza dei certificati in modo proattivo. La scadenza di un certificato del server RADIUS è una delle cause più comuni di improvvisi e diffusi errori di autenticazione. Implementa un sistema di monitoraggio per avvisare gli amministratori almeno 30 giorni prima della scadenza. Questo vale sia per il certificato del server sia per qualsiasi certificato CA intermedio nella catena.
Tratta il Segreto Condiviso come una credenziale critica. Il segreto condiviso tra l'AP e il server RADIUS crittografa i pacchetti RADIUS. Utilizza segreti univoci per posizione o gruppo di AP, memorizzali in un gestore di segreti e ruotali periodicamente. Consulta la nostra guida su Proteggere la rete con DNS e sicurezza avanzati per raccomandazioni più ampie sull'igiene della sicurezza di rete.
Allineati con i framework di conformità. Per gli ambienti soggetti a PCI DSS (ad esempio, reti di pagamento al dettaglio), l'autenticazione 802.1X supporta direttamente i requisiti per il controllo dell'accesso alla rete e la registrazione dei log di controllo. Per la conformità al GDPR, i log di accounting RADIUS (porta 1813) forniscono una traccia di controllo dettagliata di chi ha effettuato l'accesso alla rete, da dove e quando, un elemento prezioso per la risposta agli incidenti. Per gli ambienti del settore Sanitario , la segmentazione della rete tramite l'assegnazione dinamica della VLAN supporta i requisiti HIPAA per la protezione delle informazioni sanitarie protette elettroniche (ePHI).
Risoluzione dei problemi e mitigazione dei rischi
| Modalità di guasto | Sintomo | Risoluzione |
|---|---|---|
| Scadenza del certificato | Improvvisi errori di autenticazione di massa | Monitora la scadenza; rinnova e ridistribuisci il certificato |
| Desincronizzazione NTP | Errori EAP-TLS intermittenti | Assicurati che il server RADIUS e i DC si sincronizzino con la stessa sorgente NTP |
| Perdita di connettività LDAP | L'autenticazione fallisce quando AD non è raggiungibile | Distribuisci DC ridondanti; configura RADIUS per memorizzare nella cache le autenticazioni recenti |
| Segreto Condiviso errato | I log dell'AP mostrano RADIUS timeout o Bad authenticator |
Verifica che il segreto corrisponda sia sull'AP sia sul server RADIUS |
| Mancata corrispondenza del certificato client | Errori EAP-TLS per dispositivi specifici | Verifica che il certificato client sia emesso da una CA attendibile; controlla il periodo di validità del certificato |
| VLAN non assegnata | Utente autenticato ma sul segmento di rete errato | Verifica che gli attributi RADIUS vengano restituiti correttamente; controlla la configurazione della VLAN dell'AP |
Per un approfondimento sul processo di configurazione di 802.1X, la guida How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide fornisce procedure dettagliate e specifiche per i diversi vendor.
ROI e Impatto Aziendale
Il passaggio da PSK a 802.1X basato su RADIUS richiede un investimento iniziale nella configurazione e, potenzialmente, licenze per soluzioni cloud o hardware per implementazioni on-premise. Il calcolo del ROI è immediato:
Mitigazione del rischio: Il costo medio di una violazione dei dati nel Regno Unito supera i 3 milioni di sterline (IBM Cost of a Data Breach Report). Una PSK compromessa può esporre l'intera rete. Lo standard 802.1X limita l'area di impatto a un singolo account utente compromesso, che può essere disabilitato in pochi secondi tramite la directory.
Efficienza operativa: L'assegnazione dinamica delle VLAN elimina la riconfigurazione manuale della rete quando il personale cambia ruolo. L'onboarding di un nuovo dipendente consiste semplicemente nell'aggiungerlo al gruppo AD corretto: l'accesso alla rete segue automaticamente.
Conformità normativa: Per le organizzazioni soggette a PCI DSS, ISO 27001 o Cyber Essentials Plus, lo standard 802.1X rappresenta un controllo diretto che i revisori si aspettano di trovare. L'implementazione rafforza la conformità e riduce i costi di risoluzione delle non conformità in fase di audit.
Esperienza degli ospiti e analytics: Per i gestori di sedi fisiche, l'integrazione di RADIUS per l'autenticazione del personale con la piattaforma Guest WiFi di Purple per l'accesso dei visitatori crea un modello di accesso unificato e multilivello. Il personale si autentica in modo trasparente tramite 802.1X; gli ospiti si connettono tramite un Captive Portal personalizzato. La piattaforma WiFi Analytics di Purple fornisce quindi visibilità in tempo reale sui tempi di permanenza dei visitatori, sui tassi di ritorno e sulle metriche di coinvolgimento: dati che informano direttamente le decisioni di spesa marketing e la gestione operativa della sede.
Per ulteriori letture, consulta Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo per la guida all'implementazione in lingua portoghese, e What Is a Leased Line? Dedicated Business Internet per indicazioni su come garantire che la connettività sottostante soddisfi i requisiti aziendali.
Definizioni chiave
RADIUS (Remote Authentication Dial-In User Service)
Un protocollo di rete che fornisce una gestione centralizzata di Authentication, Authorization, e Accounting (AAA) per gli utenti che si connettono a un servizio di rete. Definito in RFC 2865.
Il componente server principale che convalida le credenziali dell'utente rispetto a una directory prima di concedere l'accesso WiFi. Ogni implementazione WiFi aziendale che utilizza 802.1X richiede un server RADIUS.
802.1X
Uno standard IEEE per il controllo dell'accesso alla rete basato su porta (PNAC). Fornisce un meccanismo di autenticazione ai dispositivi che desiderano connettersi a una LAN o WLAN, bloccando tutto il traffico non EAP fino al completamento dell'autenticazione.
Lo standard quadro generale che definisce il modo in cui il Supplicant, l'Authenticator e l'Authentication Server comunicano. Quando i team IT si riferiscono alla "sicurezza WiFi aziendale", di solito intendono WPA2/WPA3-Enterprise con 802.1X.
Supplicant
Il dispositivo client — o più precisamente, lo stack software 802.1X su tale dispositivo — che avvia il processo di autenticazione presentando le credenziali alla rete.
Su Windows, il supplicant integrato è il servizio Wireless AutoConfig. Su macOS e iOS, è nativo del sistema operativo. Assicurarsi che il supplicant sia configurato correttamente (specialmente per la convalida dei certificati) è la causa più comune di problemi di implementazione.
Authenticator
Il dispositivo di rete — tipicamente un access point WiFi o un controller wireless — che funge da intermediario tra il Supplicant e il server RADIUS, applicando il controllo degli accessi in base al risultato dell'autenticazione.
L'AP blocca tutto il traffico dati sulla porta finché non riceve un Access-Accept dal server RADIUS. Legge anche gli attributi RADIUS (ad es. l'assegnazione della VLAN) dalla risposta Access-Accept e li applica alla sessione.
EAP (Extensible Authentication Protocol)
Un framework di autenticazione definito in RFC 3748 che fornisce un meccanismo di trasporto standardizzato per vari metodi di autenticazione (TLS, PEAP, TTLS, ecc.) tra il Supplicant e l'Authentication Server.
L'EAP è la "lingua" parlata tra il client e il server RADIUS. La scelta del metodo EAP (EAP-TLS rispetto a PEAP) determina il livello di sicurezza e la complessità di implementazione del sistema di autenticazione.
PEAP (Protected EAP)
Un metodo EAP che stabilisce prima un tunnel TLS utilizzando il certificato del server, quindi esegue un'autenticazione secondaria (tipicamente MSCHAPv2 con nome utente/password) all'interno di quel tunnel crittografato.
Il metodo di autenticazione WiFi aziendale più comune grazie al suo equilibrio tra sicurezza e semplicità di implementazione. Richiede solo un certificato lato server, rendendolo molto più facile da implementare rispetto a EAP-TLS.
Dynamic VLAN Assignment
Una funzionalità RADIUS in cui il server include attributi specifici della VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) nella risposta Access-Accept, istruendo l'AP a inserire il client autenticato su una VLAN specifica.
Consente a un singolo SSID di servire più popolazioni di utenti con requisiti di sicurezza diversi. Elimina la necessità di trasmettere più SSID per diversi gruppi di utenti, riducendo il sovraccarico RF e semplificando l'esperienza utente.
Shared Secret
Una stringa di testo preconfigurata nota solo all'Authenticator (AP) e al server RADIUS, utilizzata per firmare e crittografare i pacchetti RADIUS, garantendo l'integrità e l'autenticità della comunicazione.
Un elemento critico di configurazione della sicurezza. Se la shared secret è debole o compromessa, un utente malintenzionato potrebbe falsificare le risposte RADIUS Access-Accept, concedendo un accesso non autorizzato alla rete. Utilizza chiavi segrete univoche per ogni sede e conservale in un gestore di segreti.
MAC Authentication Bypass (MAB)
Un meccanismo di autenticazione di fallback in cui l'indirizzo MAC di un dispositivo viene utilizzato come credenziale di identità, consentendo l'accesso alla rete per i dispositivi che non supportano i supplicant 802.1X.
Utilizzato per dispositivi headless (stampanti, sensori IoT, telecamere IP). Poiché gli indirizzi MAC sono visibili pubblicamente e facilmente falsificabili, il MAB fornisce l'identificazione del dispositivo anziché una forte autenticazione. Associalo sempre a un'assegnazione VLAN restrittiva.
Esempi pratici
Una catena di vendita al dettaglio nazionale con 500 punti vendita deve implementare un WiFi sicuro per i tablet dei direttori di negozio e i terminali POS. Attualmente utilizzano una singola PSK in tutti i negozi, che viene spesso condivisa con personale e appaltatori non autorizzati. Utilizzano Azure AD per la gestione delle identità e non hanno personale IT dedicato nelle filiali.
Implementare una soluzione Cloud RADIUS integrata direttamente con Azure AD. Ciò elimina la necessità di distribuire e gestire server RADIUS on-premise in 500 sedi. Il team IT utilizza Microsoft Intune per inviare un profilo WiFi a tutti i tablet dei direttori di negozio e ai terminali POS configurati per PEAP-MSCHAPv2, imponendo rigorosamente la convalida del certificato del server Cloud RADIUS. La policy di Cloud RADIUS verifica l'appartenenza al gruppo Azure AD dell'utente prima di concedere l'accesso: il gruppo "Store_Managers" riceve la VLAN 10 (accesso completo a POS e back-office), il gruppo "Contractors" riceve la VLAN 20 (solo internet). Al termine del contratto di un collaboratore esterno, la sua rimozione dal gruppo Azure AD revoca immediatamente l'accesso WiFi in tutte le 500 sedi contemporaneamente, senza richiedere alcuna modifica della PSK.
Un hotel in centro città con 400 camere deve fornire un WiFi sicuro sia per il personale (reception, pulizie, direzione) che per gli ospiti. Il personale richiede l'accesso al sistema di gestione della proprietà (PMS) e ai server interni. Gli ospiti richiedono solo l'accesso a internet. L'hotel dispone di un unico ambiente Windows Server on-premise.
Implementare Microsoft NPS su una VM Windows Server dedicata. Configurare due SSID sull'infrastruttura wireless: "Hotel_Staff" (WPA2-Enterprise, 802.1X) e "Hotel_Guest" (aperto o WPA2-Personal, con reindirizzamento a un Captive Portal). Per l'SSID del personale, NPS convalida le credenziali rispetto ad Active Directory e restituisce assegnazioni dinamiche di VLAN: gruppo AD "Management" → VLAN 10 (accesso completo), "FrontDesk" → VLAN 20 (accesso PMS), "Housekeeping" → VLAN 30 (solo internet + app di pianificazione). Per gli ospiti, integrare il Captive Portal con la piattaforma Guest WiFi di Purple per offrire un'esperienza di accesso personalizzata con il brand, raccogliere dati di prima parte (e-mail, consenso al marketing) e ottenere analisi sui tempi di permanenza e sulle visite ripetute. Il modello a due SSID mantiene il traffico del personale e quello degli ospiti completamente separati a livello di rete.
Domande di esercitazione
Q1. La tua organizzazione sta migrando 2.000 laptop Windows da una PSK condivisa a 802.1X con PEAP-MSCHAPv2. Il team di sicurezza segnala che il PEAP è vulnerabile al credential harvesting tramite access point canaglia. Qual è il singolo passaggio di configurazione più importante per mitigare questo rischio e come lo distribuisci su scala?
Suggerimento: Considera cosa impedisce a un client di fidarsi di un server RADIUS fraudolento che presenta un certificato autofirmato.
Visualizza risposta modello
Il passaggio fondamentale consiste nell'imporre una convalida rigorosa del certificato del server su ogni dispositivo client. Utilizzando i Group Policy Objects (GPO), distribuisci un profilo WiFi a tutti i 2.000 laptop che specifichi: (1) l'esatto certificato della Root CA che ha emesso il certificato del server RADIUS, (2) il nome del server previsto (CN/SAN) e (3) che il client non deve chiedere all'utente di considerare attendibili nuovi certificati. Ciò garantisce che, anche se un utente malintenzionato distribuisce un AP canaglia con un certificato fraudolento, il client rifiuterà l'handshake TLS e si rifiuterà di inviare le credenziali. Senza questa configurazione, il PEAP non fornisce alcuna protezione significativa contro gli attacchi da AP canaglia.
Q2. Il direttore IT di un ospedale deve fornire l'accesso alla rete a 300 dispositivi IoT medici (pompe d'infusione, apparecchiature di monitoraggio) che non supportano l'802.1X. Questi dispositivi si trovano accanto alle workstation del personale sulla stessa infrastruttura wireless. In che modo l'infrastruttura RADIUS dovrebbe gestire questi dispositivi e quali controlli di rete devono essere implementati?
Suggerimento: Pensa al metodo di autenticazione disponibile per i dispositivi headless e a come compensare la sua intrinseca debolezza.
Visualizza risposta modello
Configura il MAC Authentication Bypass (MAB) sul server RADIUS per questi dispositivi specifici. Registra l'indirizzo MAC di ciascun dispositivo in un gruppo Active Directory dedicato o nel database RADIUS. Poiché gli indirizzi MAC sono facilmente falsificabili, il server RADIUS deve utilizzare il Dynamic VLAN Assignment per inserire tutti i dispositivi autenticati tramite MAB in una VLAN dedicata e altamente limitata (ad esempio, VLAN 30 - IoT). Questa VLAN deve essere protetta da firewall per consentire la comunicazione solo con indirizzi IP di server medici specifici e bloccare tutto l'altro traffico, inclusi l'accesso a Internet e i movimenti laterali verso le VLAN del personale. Le workstation del personale si autenticano tramite 802.1X e vengono collocate su una VLAN separata. Questa architettura soddisfa i requisiti di segmentazione della rete GDPR e HIPAA per i dispositivi adiacenti a dati sensibili.
Q3. Sei l'architetto di rete di una catena di ristoranti con 50 sedi. L'autenticazione funziona correttamente in 49 sedi che utilizzano Cloud RADIUS, ma una sede specifica segnala che tutti i dispositivi non riescono a autenticarsi. Il portale di gestione di Cloud RADIUS mostra zero richieste di autenticazione provenienti da quella sede. Qual è il tuo approccio diagnostico?
Suggerimento: Se il server RADIUS non riceve alcuna richiesta, il problema risiede nel percorso di comunicazione tra l'Authenticator e il server, non nella logica di autenticazione stessa.
Visualizza risposta modello
Poiché il server RADIUS riceve zero richieste da questa sede, il guasto risiede tra gli access point e il server Cloud RADIUS. Passaggi diagnostici in ordine: (1) Verifica l'indirizzo IP del server RADIUS e la porta (UDP 1812) configurati sugli AP o sul controller wireless della sede: un errore di battitura qui è la causa più comune. (2) Controlla le regole del firewall locale o del router in quella sede per confermare che il traffico UDP 1812 in uscita sia consentito verso l'intervallo IP di Cloud RADIUS. (3) Verifica che il Shared Secret configurato sugli AP corrisponda al segreto configurato per quella sede nel portale Cloud RADIUS: una mancata corrispondenza fa sì che il server RADIUS scarti i pacchetti in modo silenzioso. (4) Verifica se la connessione Internet della sede è funzionante: Cloud RADIUS richiede una connettività Internet affidabile. L'esecuzione di un packet capture sull'AP o sul router a monte confermerà se i pacchetti RADIUS vengono inviati e se le risposte vengono ricevute.
Continua a leggere questa serie
PSK per dispositivo per fornitore: confronto tra iPSK, DPSK, MPSK e PPSK (e supporto WPA3)
Un confronto completo delle implementazioni PSK per dispositivo tra Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Scopri come WPA3-SAE influisce sulle strategie delle chiavi per dispositivo e quando distribuire le modalità di transizione rispetto al passaggio a 802.1X.
Metodi di autenticazione del Captive Portal a confronto
Questa guida di riferimento tecnico autorevole valuta i compromessi architetturali, operativi e di conformità di cinque metodi di autenticazione principali per captive portal. Fornisce ad architetti di rete, direttori IT e marketing manager i dati quantitativi e i framework decisionali necessari per bilanciare l'attrito nell'onboarding degli ospiti con i requisiti di raccolta dati all'interno delle sedi aziendali.
Cos'è l'autenticazione tramite indirizzo MAC? Quando usarla e quando evitarla
Questa guida tecnica di riferimento autorevole copre l'autenticazione tramite indirizzo MAC negli ambienti WiFi aziendali: come funziona l'autenticazione MAC basata su RADIUS a livello Layer 2, le sue vulnerabilità di sicurezza intrinseche (incluso il MAC spoofing e l'impatto della randomizzazione MAC a livello di sistema operativo) e i precisi contesti operativi in cui rimane uno strumento valido per la gestione di dispositivi IoT e headless. Fornisce linee guida di implementazione pratiche per responsabili IT e architetti di rete nei settori dell'ospitalità, del retail, della sanità e dei luoghi pubblici, con esempi pratici reali, framework decisionali e contesti di integrazione per la piattaforma di guest WiFi e analytics di Purple.