Vai al contenuto principale

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.

📖 8 minuti di lettura📝 1,860 parole🔧 2 esempi pratici3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
Benvenuto al Technical Briefing di Purple. Oggi affronteremo una decisione infrastrutturale critica per qualsiasi leader IT aziendale: come configurare un server RADIUS per l'autenticazione WiFi. Se gestisci un'installazione su larga scala — che si tratti di una catena alberghiera, di una rete retail o di un vasto campus universitario — affidarsi a una semplice chiave precondivisa rappresenta un rischio di sicurezza significativo. Abbiamo bisogno dello standard 802.1X, e questo significa che abbiamo bisogno di RADIUS. Iniziamo con il contesto. RADIUS, o Remote Authentication Dial-In User Service, funge da guardiano della tua rete. Quando un dispositivo tenta di connettersi a un access point WiFi, l'access point funge da autenticatore e inoltra le credenziali al server RADIUS. Il server verifica tali credenziali confrontandole con una directory — come Active Directory o un database LDAP — e quindi restituisce un messaggio di accettazione o rifiuto. È la base della sicurezza WiFi aziendale ed è il meccanismo che consente di applicare policy di accesso granulari su scala. Passiamo ora all'approfondimento tecnico. La prima grande decisione architetturale che ti troverai ad affrontare è la scelta tra un server RADIUS on-premise e una soluzione ospitata in cloud. Storicamente, le soluzioni on-premise come il Network Policy Server di Microsoft, o NPS, o l'open-source FreeRADIUS rappresentavano lo standard. Offrono un controllo completo sull'infrastruttura e non dipendono da una connessione internet esterna per l'autenticazione. Tuttavia, richiedono hardware dedicato, manutenzione continua e configurazione manuale della ridondanza. Se disponi di un singolo data center e di un team IT ben strutturato, questo è un approccio perfettamente valido. Dall'altro lato, le soluzioni cloud RADIUS sono diventate sempre più popolari, in particolare per ambienti distribuiti come catene retail o strutture ricettive. Il cloud RADIUS elimina completamente la gestione dell'hardware, offre un'alta affidabilità integrata e si integra perfettamente con i provider di identità cloud come Azure Active Directory o Okta. Il compromesso è che l'autenticazione richiede una connessione internet affidabile e comporta un costo di abbonamento ricorrente. Per un operatore che gestisce cinquanta o cento sedi, il risparmio operativo derivante dal non dover distribuire e mantenere server on-premise in ogni sito supererà quasi certamente tale costo. Durante la distribuzione di RADIUS, l'Extensible Authentication Protocol — EAP — è l'elemento cruciale. Definisce il modo in cui il client e il server negoziano ed eseguono l'autenticazione. EAP-TLS rappresenta il gold standard per la sicurezza perché utilizza certificati digitali sia sul client che sul server, eliminando completamente la necessità di password. Ciò significa che anche se un utente malintenzionato intercetta lo scambio di autenticazione, non ci sono credenziali da sottrarre. Tuttavia, la distribuzione dei certificati client può essere amministrativamente onerosa. È necessaria un'infrastruttura a chiave pubblica (PKI) e una soluzione MDM per inviare i certificati a ogni dispositivo. PEAP-MSCHAPv2 è l'alternativa più comune. Utilizza un certificato lato server per stabilire un tunnel TLS crittografato, all'interno del quale l'utente si autentica con nome utente e password. Questo è significativamente più semplice da distribuire rispetto a EAP-TLS perché è necessario gestire un solo certificato: quello del server. Tuttavia, e questo è fondamentale, se i client non sono configurati rigorosamente per convalidare il certificato del server, sono vulnerabili a rogue access point. Un utente malintenzionato può configurare un access point fittizio, presentare un certificato fraudolento e acquisire le credenziali. Questo non è un attacco teorico. Si tratta di una minaccia reale e ampiamente documentata. Parliamo di raccomandazioni di implementazione e potenziali errori. La prima raccomandazione è quella di imporre una convalida rigorosa del certificato su ogni dispositivo client. Utilizza i Group Policy Objects per i dispositivi Windows e i profili MDM (che si tratti di Intune, Jamf o un'altra soluzione) per macOS e dispositivi mobili. Il profilo deve specificare esattamente di quale Autorità di Certificazione fidarsi e qual è il nome del server previsto. Non lasciare che sia l'utente finale a configurarlo manualmente. La seconda raccomandazione è quella di implementare l'assegnazione dinamica delle VLAN. Invece di inserire tutti gli utenti autenticati sulla stessa rete piatta, configura il server RADIUS in modo che indichi all'access point di inserire l'utente su una VLAN specifica in base alla sua appartenenza al gruppo nella directory. Questo è essenziale per segmentare i dispositivi aziendali dai dispositivi BYOD o guest. Un membro del team finanziario dovrebbe trovarsi su un segmento di rete diverso rispetto a un consulente esterno in visita per la giornata. La terza raccomandazione riguarda l'accesso guest. Per le strutture che devono fornire il WiFi ai visitatori (hotel, negozi al dettaglio, centri congressi), l'integrazione dell'infrastruttura RADIUS con una soluzione di Captive Portal come la piattaforma Guest WiFi di Purple rappresenta una combinazione potente. Il personale e i dispositivi aziendali si autenticano silenziosamente tramite 802.1X, mentre gli ospiti vengono reindirizzati a un portale personalizzato con il brand per l'autenticazione. La piattaforma di Purple acquisisce quindi dati di prima parte e fornisce analisi sul comportamento dei visitatori, trasformando la tua rete da un centro di costo in una risorsa di business intelligence. Ora passiamo a una sessione di domande e risposte rapide. Prima domanda: ho bisogno di un server dedicato per RADIUS? Per le distribuzioni on-premise, sì, è altamente raccomandato eseguirlo su una macchina virtuale dedicata piuttosto che condividere le risorse con un controller di dominio. L'autenticazione è un'operazione sensibile alla latenza e la contesa delle risorse può causare guasti intermittenti molto difficili da diagnosticare. Seconda domanda: RADIUS può gestire l'autenticazione per dispositivi headless come stampanti o sensori IoT? Sì, tramite il MAC Authentication Bypass, o MAB. Questo consente ai dispositivi privi di funzionalità 802.1X di essere autenticati in base al loro indirizzo MAC. Tuttavia, poiché gli indirizzi MAC sono facilmente falsificabili, i dispositivi autenticati tramite MAB dovrebbero sempre essere inseriti in una VLAN altamente limitata. Terza domanda: come gestisco la ridondanza del server RADIUS? Distribuisci sempre almeno due server RADIUS: uno primario e uno secondario. Configura tutti gli access point per eseguire il failover sul secondario se il primario diventa irraggiungibile. Per il RADIUS in cloud, questa ridondanza è in genere integrata e gestita dal provider. Per riassumere i punti chiave del briefing di oggi. Le chiavi pre-condivise non sono accettabili per il WiFi aziendale. Implementa l'802.1X. Scegli il tuo modello di distribuzione — on-premise o cloud — in base alle tue risorse IT, al numero di sedi che stai gestendo e alla tua infrastruttura di identità esistente. Se la tua azienda è distribuita e orientata al cloud, il RADIUS in cloud è quasi certamente la risposta giusta. Imponi una rigida convalida dei certificati sui client. Questo non è negoziabile. Utilizza l'assegnazione dinamica della VLAN per segmentare la tua rete. E infine, valuta come la tua infrastruttura di autenticazione possa integrarsi con piattaforme più ampie per offrire valore aziendale oltre al semplice controllo degli accessi. Per ulteriori letture, consigliamo di esplorare le guide di Purple sulla configurazione dell'autenticazione WiFi 802.1X e sulla protezione della rete con solide policy DNS. Grazie per l'ascolto.

header_image.png

Executive Summary

For enterprise environments — whether a sprawling university campus, a high-density stadium, or a distributed retail chain — relying on a Pre-Shared Key (PSK) for WiFi access is a significant security liability. A single compromised credential exposes the entire network, and revoking access requires changing the password for every device on the estate. Implementing 802.1X authentication via a RADIUS (Remote Authentication Dial-In User Service) server eliminates this problem entirely: each user authenticates individually, access can be revoked instantly, and network segmentation is enforced dynamically.

This guide provides a definitive roadmap for IT managers and network architects to deploy RADIUS authentication. We cover the architectural trade-offs between on-premise and cloud-hosted deployments, the configuration of Extensible Authentication Protocol (EAP) methods, and the integration with directory services like Active Directory. We also demonstrate how a robust authentication layer integrates with Guest WiFi solutions to provide seamless access for visitors, while capturing the WiFi Analytics that turn your network into a business intelligence asset.


Technical Deep-Dive

The 802.1X Architecture

The IEEE 802.1X standard defines port-based Network Access Control (PNAC). In a wireless context, it involves three primary roles working in concert:

Role Component Responsibility
Supplicant Client device (laptop, smartphone) Presents credentials to request network access
Authenticator WiFi Access Point or Controller Enforces access control; relays EAP messages
Authentication Server RADIUS Server Validates credentials; returns accept/reject and policy attributes

When a supplicant associates with an access point, the AP blocks all data traffic except EAP (Extensible Authentication Protocol) messages. The AP encapsulates these EAP messages in RADIUS packets and forwards them to the RADIUS server. The server verifies the credentials against a backend database — typically LDAP or Active Directory — and returns an Access-Accept or Access-Reject message. If accepted, the AP unblocks the port and the client's traffic flows freely.

architecture_overview.png

Choosing an EAP Method

The security of your RADIUS deployment depends heavily on the EAP method selected. The two most prevalent in enterprise deployments are:

EAP-TLS (Transport Layer Security) is the gold standard. It requires digital certificates on both the RADIUS server and every client device, eliminating passwords entirely. Even if an attacker captures the full authentication exchange, there are no credentials to extract. The trade-off is administrative overhead: deploying and managing client certificates requires a functioning Public Key Infrastructure (PKI) and an MDM solution (e.g., Microsoft Intune, Jamf) to distribute certificates to endpoints.

PEAP-MSCHAPv2 (Protected EAP) is the most widely deployed method in practice. It uses a server-side certificate to establish an encrypted TLS tunnel, inside which the client authenticates with a username and password. This is significantly easier to deploy than EAP-TLS because only one certificate — the server's — needs to be managed. However, it carries a critical caveat: if client devices are not explicitly configured to validate the RADIUS server's certificate, they are vulnerable to Man-in-the-Middle (MitM) attacks via rogue access points.

> Critical Security Note: Failing to enforce strict certificate validation on client devices effectively nullifies the security benefits of PEAP-MSCHAPv2. An attacker can deploy a rogue AP, present a fraudulent certificate, and capture user credentials in plaintext. This is not a theoretical risk — it is a well-documented attack vector that has been exploited in real-world environments.


Implementation Guide

Step 1: Architectural Decision — On-Premise vs. Cloud RADIUS

The first decision is where to host the RADIUS infrastructure. This is primarily an operational and cost question, not a security one — both models can be deployed securely.

comparison_chart.png

On-Premise RADIUS (e.g., Microsoft NPS, FreeRADIUS, Cisco ISE) is suited for organisations with dedicated IT staff, existing on-premise directory infrastructure, and stringent data sovereignty or compliance requirements. It does not depend on internet connectivity for authentication, which is a meaningful advantage for environments where internet uptime cannot be guaranteed.

Cloud RADIUS is increasingly the preferred model for distributed environments — Retail chains, Hospitality groups, and Transport hubs where deploying servers at every location is operationally impractical. Cloud RADIUS integrates natively with cloud identity providers (Azure AD, Google Workspace, Okta) and provides built-in high availability and global scalability.

Step 2: Install and Configure the RADIUS Server

For an on-premise deployment using Microsoft NPS (the most common choice in Windows-centric environments):

  1. Install the Network Policy Server role via Server Manager.
  2. Register the NPS server in Active Directory to allow it to read user dial-in properties.
  3. Create a RADIUS Client entry for each access point or wireless controller, specifying the AP's IP address and a strong, unique Shared Secret.
  4. Configure a Network Policy defining the conditions (e.g., user group membership) and constraints (e.g., EAP method, session timeout) for access.
  5. Configure the Connection Request Policy to process requests locally.

For FreeRADIUS on Linux:

  1. Install via package manager: sudo apt-get install freeradius freeradius-ldap.
  2. Configure /etc/freeradius/3.0/clients.conf to define RADIUS clients (APs) and their shared secrets.
  3. Configure the LDAP module in /etc/freeradius/3.0/mods-available/ldap to point to your Active Directory or LDAP server.
  4. Enable the LDAP module: sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/.
  5. Define EAP methods in /etc/freeradius/3.0/mods-available/eap.

Step 3: Configure Access Points

On your wireless controller or individual access points:

  1. Define the RADIUS server IP address(es) and authentication port (default: UDP 1812).
  2. Configure the Shared Secret — use a minimum of 22 characters, mixing alphanumeric and special characters. Use a unique secret per location or AP group.
  3. Configure the SSID to use WPA2-Enterprise or WPA3-Enterprise security mode with 802.1X key management.
  4. Configure a secondary RADIUS server for failover.

Step 4: Directory Integration

For on-premise AD integration, the RADIUS server must be joined to the domain or have LDAP read access. Ensure service accounts used for LDAP binding have the minimum required permissions. For cloud RADIUS, configure the API-based synchronization or SAML/OIDC integration with your IdP.

Define clear user groups in your directory, as these will drive authorization policies. Recommended group structure:

Group VLAN Access Level
Corp_Staff VLAN 10 Full internal network
Corp_Contractors VLAN 20 Internet + specific internal resources
Corp_IoT VLAN 30 Isolated, device-specific ports only
Corp_Guests VLAN 100 Internet only via captive portal

Step 5: Client Configuration and Certificate Validation

This is the most operationally critical step. Use Group Policy (GPO) for Windows and MDM profiles for macOS/iOS/Android to push WiFi configurations silently to managed devices. The profile must specify:

  • The Root CA that issued the RADIUS server's certificate.
  • The expected server name (CN or SAN of the server certificate).
  • The EAP method and inner authentication protocol.

For unmanaged BYOD devices, provide clear self-service onboarding instructions, ideally via a Network Access Control (NAC) portal.

Step 6: Implement Dynamic VLAN Assignment

Configure the RADIUS server to return VLAN assignment attributes in the Access-Accept response:

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = IEEE-802 (6)
  • Tunnel-Private-Group-Id = ``

The access point reads these attributes and places the authenticated client on the specified VLAN — no manual reconfiguration required as users change roles or locations.


Best Practices

Redundancy is non-negotiable. Deploy a minimum of two RADIUS servers (primary and secondary) and configure all access points to fail over automatically. For on-premise deployments, consider placing the secondary server in a different physical location or availability zone. A RADIUS outage means nobody can authenticate, which is a complete network outage for 802.1X-protected SSIDs.

Monitor certificate expiry proactively. A RADIUS server certificate expiry is one of the most common causes of sudden, widespread authentication failures. Implement monitoring to alert administrators at least 30 days before expiry. This applies to both the server certificate and any intermediate CA certificates in the chain.

Treat the Shared Secret as a critical credential. The shared secret between the AP and the RADIUS server encrypts RADIUS packets. Use unique secrets per location or AP group, store them in a secrets manager, and rotate them periodically. See our guide on Protect Your Network with Strong DNS and Security for broader network security hygiene recommendations.

Align with compliance frameworks. For environments subject to PCI DSS (e.g., retail payment networks), 802.1X authentication directly supports requirements for network access control and audit logging. For GDPR compliance, RADIUS accounting logs (port 1813) provide a detailed audit trail of who accessed the network, from where, and when — valuable for incident response. For Healthcare environments, network segmentation via dynamic VLAN assignment supports HIPAA requirements for protecting electronic protected health information (ePHI).


Troubleshooting & Risk Mitigation

Failure Mode Symptom Resolution
Certificate expiry Sudden mass authentication failures Monitor expiry; renew and redeploy certificate
NTP desynchronisation Intermittent EAP-TLS failures Ensure RADIUS server and DCs sync to same NTP source
LDAP connectivity loss Authentication fails when AD is unreachable Deploy redundant DCs; configure RADIUS to cache recent authentications
Incorrect Shared Secret AP logs show RADIUS timeout or Bad authenticator Verify secret matches on both AP and RADIUS server
Client certificate mismatch EAP-TLS failures for specific devices Verify client cert is issued by trusted CA; check cert validity period
VLAN not assigned User authenticated but on wrong network segment Verify RADIUS attributes are correctly returned; check AP VLAN configuration

For a deeper dive into the 802.1X configuration process itself, the How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide provides granular, vendor-specific configuration walkthroughs.


ROI & Business Impact

Transitioning from PSK to RADIUS-backed 802.1X requires an initial investment in configuration, and potentially licensing for cloud solutions or hardware for on-premise deployments. The ROI case is straightforward:

Risk mitigation: The average cost of a data breach in the UK is in excess of £3 million (IBM Cost of a Data Breach Report). A compromised PSK can expose the entire network. 802.1X limits the blast radius to a single compromised user account, which can be disabled in seconds via the directory.

Operational efficiency: Dynamic VLAN assignment eliminates manual network reconfiguration as staff change roles. Onboarding a new employee means adding them to the correct AD group — the network access follows automatically.

Compliance posture: For organisations subject to PCI DSS, ISO 27001, or Cyber Essentials Plus, 802.1X is a direct control that auditors expect to see. Deploying it strengthens your compliance posture and reduces audit remediation costs.

Guest experience and analytics: For venue operators, integrating RADIUS for staff authentication with Purple's Guest WiFi platform for visitor access creates a unified, tiered access model. Staff authenticate silently via 802.1X; guests connect via a branded captive portal. Purple's WiFi Analytics platform then provides real-time visibility into visitor dwell times, repeat visit rates, and engagement metrics — data that directly informs marketing spend and venue operations decisions.


For further reading, see the Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo for Portuguese-language implementation guidance, and What Is a Leased Line? Dedicated Business Internet for guidance on ensuring the underlying connectivity meets enterprise requirements.

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.

Commento dell'esaminatore: Questo approccio risolve la vulnerabilità principale (la PSK condivisa) tenendo conto dei vincoli operativi (assenza di personale IT in filiale, ambiente Azure AD). Cloud RADIUS offre la scalabilità necessaria e si integra nativamente con l'identity provider esistente. L'uso dell'assegnazione dinamica della VLAN garantisce che, anche se il dispositivo di un appaltatore si trova in sede dopo la fine del contratto, la rimozione dal gruppo di directory sia l'unica azione richiesta per revocare l'accesso.

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.

Commento dell'esaminatore: Il modello a due SSID è l'approccio corretto in questo caso, piuttosto che un singolo SSID con un routing complesso delle policy. Offre una chiara separazione operativa e semplifica la risoluzione dei problemi. L'integrazione di Purple per l'SSID degli ospiti è la decisione commercialmente più intelligente: trasforma la rete ospiti da un centro di costo in un canale di acquisizione dati e marketing, con un ROI misurabile attraverso i tassi di visite ripetute e l'engagement tramite email marketing.

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

Server RADIUS: una guida completa per le aziende

Questa guida fornisce a IT manager, architetti di rete e CTO un riferimento tecnico definitivo sull'autenticazione tramite server RADIUS per il WiFi aziendale. Copre il framework AAA, l'architettura 802.1X, la selezione del metodo EAP, i compromessi tra implementazioni cloud e on-premises e l'assegnazione dinamica della VLAN. I gestori di location nei settori dell'ospitalità, del retail, degli eventi e del settore pubblico troveranno indicazioni pratiche per l'implementazione, casi di studio reali e i framework decisionali necessari per migrare da chiavi pre-condivise non sicure a un'architettura di controllo degli accessi alla rete sicura e basata sull'identità.

Leggi la guida →

Aruba ClearPass vs. Purple WiFi: Confronto delle Funzionalità e Co-implementazione

Una guida tecnica completa che dettaglia l'architettura di co-implementazione di Aruba ClearPass e Purple WiFi. Copre la configurazione del proxy RADIUS, l'assegnazione dinamica della VLAN e le best practice per fornire reti guest sicure e basate sull'analisi dei dati insieme al NAC aziendale.

Leggi la guida →

Cisco ISE vs. Purple WiFi: Come si Confrontano e Come Lavorano Insieme

Questa guida spiega come Cisco ISE e Purple WiFi ricoprano ruoli distinti ma complementari nelle reti aziendali. Spiega dettagliatamente come utilizzare Cisco ISE per l'accesso aziendale sicuro 802.1X, sfruttando al contempo Purple per il guest WiFi conforme al GDPR, l'analisi di marketing e l'integrazione CRM.

Leggi la guida →