Integrating RADIUS as a Service with Cloud Directories (Azure AD & Google Workspace)

Questa guida di riferimento tecnico descrive in dettaglio come integrare RADIUS as a Service con le directory cloud (Microsoft Entra ID e Google Workspace) per l'autenticazione WiFi aziendale. Copre il passaggio architetturale da NPS on-premise a RADIUS cloud-native, l'implementazione dell'autenticazione EAP-TLS basata su certificati e le migliori pratiche operative per proteggere l'accesso wireless nei settori dell'ospitalità, del retail e pubblico. Per i responsabili IT e gli architetti di rete che hanno già investito nell'identità cloud, questa guida colma il divario tra la gestione delle directory e la sicurezza della rete fisica.

📖 10 minuti di lettura📝 2,373 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Welcome to the Purple Technical Briefing. Today, we are covering a topic that sits at the intersection of cloud identity management and physical network security: integrating RADIUS as a Service with cloud directories, specifically Microsoft Entra ID and Google Workspace.

If you are managing enterprise WiFi across a hotel, a retail estate, a stadium, or a public-sector estate, this briefing is directly relevant to your next infrastructure decision.

Let us start with context. For the past two decades, WiFi authentication in enterprise environments relied on a fairly predictable stack. You had on-premise Active Directory, Windows Network Policy Server acting as the RADIUS server, and WPA2-Enterprise on the access points. It worked. But it required on-premise servers, manual certificate management, and a team with specialist knowledge to keep it running.

The problem is that most organisations are no longer on-premise first. They are cloud-first. Microsoft Entra ID and Google Workspace are now the directories of record for millions of organisations. And here is the gap: your wireless access points still speak RADIUS. They do not understand SAML. They do not understand OAuth. They speak RADIUS, and they always will.

So the question is: how do you bridge your cloud identity platform to your physical network infrastructure, without dragging an on-premise server back into the picture?

The answer is RADIUS as a Service. A cloud-hosted RADIUS server that integrates directly with your cloud directory, validates authentication requests in real time, and returns an access decision to your access point. No on-premise servers. No patching. No 2am certificate renewal emergencies.

The foundation is IEEE 802.1X. When a device tries to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point acts as an authenticator. It intercepts the connection attempt and forwards EAP packets to the RADIUS server. The RADIUS server validates the identity and returns either an Access-Accept or an Access-Reject. Only then does the access point grant network access.

Now, the most consequential technical decision in this entire deployment is your choice of EAP method.

PEAP-MSCHAPv2 is the old way. It uses usernames and passwords. It sounds secure. It is not. If a device does not strictly validate the RADIUS server certificate, an attacker can set up a rogue access point with your SSID, intercept the handshake, and capture the credentials. This is called an Evil Twin attack, and it is happening.

EAP-TLS is the right answer. It uses digital certificates on both the server and the client device for mutual authentication. There are no passwords involved. The device presents its certificate. The RADIUS server validates it against your cloud directory in real time. No credential theft possible. No phishing vector. No helpdesk tickets when someone changes their password.

Let us walk through a Microsoft Entra ID deployment.

Step one: licensing and PKI. You need Microsoft 365 E3 or E5 to access Intune and Conditional Access. Establish a cloud PKI using your Cloud RADIUS vendor's managed PKI or Microsoft's own Cloud PKI.

Step two: certificate deployment via Intune. Create a Trusted Certificate profile with your Root CA and deploy it to device groups. Then create a SCEP certificate profile. For user-based authentication, the subject name uses the User Principal Name.

Step three: Cloud RADIUS configuration. Grant the RADIUS service Microsoft Graph API permissions: User.Read.All and GroupMember.Read.All. Define your authentication policies: allow access if the certificate is issued by our trusted CA, the user is a member of the Corporate-WiFi-Users group in Entra ID, and the device is marked compliant in Intune.

Step four: wireless infrastructure. In your controller, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, add the Cloud RADIUS IP addresses and shared secrets. Set the RADIUS timeout to at least five seconds. Create your WPA3-Enterprise SSID.

Step five: WiFi profile deployment. Create a WiFi configuration profile in Intune. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, link the SCEP certificate profile. Devices silently receive the certificate and WiFi profile on their next sync. They connect automatically. No user interaction required.

Now let us look at the Google Workspace path, because it is architecturally different in one important way.

Google does not offer a native RADIUS service. There is no Google equivalent of Windows NPS. So you always need an intermediary: a Cloud RADIUS provider that connects to Google Workspace via Google Secure LDAP or via a SAML and OAuth integration.

Google Secure LDAP is available on Cloud Identity Premium and Google Workspace Enterprise editions. It provides a traditional LDAP interface to your cloud directory. Your Cloud RADIUS server connects to ldap.google.com on port 636 using client certificates that Google generates for you. From that point, the RADIUS server can query Google's directory to validate credentials or group memberships.

For managed Chromebooks, the deployment path uses the Google Admin Console. You configure a cloud PKI to issue certificates, push the Root CA and client certificates to the Chromebooks, and deploy a WiFi profile specifying EAP-TLS. The Chromebooks connect silently. For BYOD devices and guest access, you use a captive portal tied to Google Single Sign-On. That is the right separation: EAP-TLS for managed devices, captive portal for everything else.

Let us talk about pitfalls, because this is where deployments go wrong.

The first and most common is blocked firewall ports. RADIUS authentication uses UDP port 1812. RADIUS accounting uses UDP port 1813. If those ports are not open outbound from your wireless infrastructure to the Cloud RADIUS service, nothing works. Check this first, every time.

The second pitfall is certificate expiry. If your RADIUS server certificate expires, every device on the network loses connectivity simultaneously. Set monitoring alerts at 90 days, 30 days, and 7 days before expiry. Automate renewal where possible.

The third is clock skew. EAP-TLS relies on accurate timekeeping for certificate validation. If a device's system clock is significantly out of sync, certificate validation fails. Ensure NTP is configured correctly across all devices and infrastructure.

The fourth, specific to PEAP deployments, is failing to enforce strict server certificate validation on client devices. Without it, devices will accept any certificate presented by any access point claiming to be yours. This is the single configuration decision that separates a secure deployment from a vulnerable one.

Now for a rapid-fire question and answer.

Can I use Cloud RADIUS for both staff and guest WiFi? Staff WiFi, yes, using EAP-TLS. Guest WiFi should use a separate captive portal. Mixing the two on a single SSID creates unnecessary complexity and security risk.

Does this work with WPA3? Yes. WPA3-Enterprise is fully supported and recommended for all new deployments.

What about compliance? EAP-TLS with Cloud RADIUS supports PCI DSS requirements for strong authentication on cardholder data networks. It also supports GDPR obligations by enabling precise access logging and instant revocation when an employee leaves.

How does this affect our analytics capabilities? Positively. By tying network access to a verified cloud identity, platforms like Purple's WiFi Analytics provide richer data on space utilisation. You move from anonymous MAC addresses to authenticated, named users, which transforms the quality of your insight.

To summarise the key takeaways.

One: Cloud RADIUS eliminates on-premise server dependencies. Your access points authenticate against a cloud-hosted service that integrates directly with Entra ID or Google Workspace.

Two: EAP-TLS is the right authentication method. Certificates replace passwords. No phishing vector, no credential theft, no helpdesk overhead from password resets.

Three: Microsoft Intune and Google Admin Console automate certificate deployment. Devices receive certificates and WiFi profiles silently, with no user interaction.

Four: Dynamic VLAN assignment via RADIUS attributes enables granular network segmentation based on directory group membership. This limits lateral movement and supports compliance.

Five: Always verify ports 1812 and 1813 are open, monitor certificate expiry, and enforce strict server certificate validation.

If you are planning a deployment this quarter, start with a pilot group of 20 to 50 devices. Validate the certificate deployment, the RADIUS authentication, and the VLAN assignment before rolling out globally. The investment in getting this right pays dividends in reduced helpdesk overhead, a stronger security posture, and the ability to use your network data for genuine business intelligence.

Thank you for listening to the Purple Technical Briefing. For detailed deployment steps, configuration examples, and worked scenarios, see the full technical reference guide at purple.ai.

Punti chiave

✓Cloud RADIUS eliminates on-premise NPS and FreeRADIUS servers. Your access points authenticate against a cloud-hosted service that integrates directly with Microsoft Entra ID or Google Workspace.
✓EAP-TLS is the correct authentication method for enterprise WiFi. It uses digital certificates instead of passwords, eliminating credential theft, phishing, and password-related helpdesk overhead.
✓Microsoft Intune and Google Admin Console automate certificate deployment to managed devices via SCEP profiles. Devices receive certificates and WiFi profiles silently, with no user interaction.
✓Google Workspace requires an intermediary for RADIUS integration. Google Secure LDAP (available on Cloud Identity Premium and Enterprise editions) provides the LDAP interface that Cloud RADIUS servers use to query the Google directory.
✓Dynamic VLAN assignment via RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) enables granular network segmentation based on directory group membership, supporting PCI DSS requirements.
✓Check UDP ports 1812 and 1813 first. Blocked firewall ports are the leading cause of initial deployment failure. Monitor certificate expiry at 90, 30, and 7 days. Enforce strict server certificate validation on all PEAP deployments.
✓Disabling a user in Entra ID or Google Workspace immediately revokes their WiFi access at all sites. This is the primary offboarding advantage over PSK-based networks and directly supports GDPR obligations.

Sintesi esecutiva

Per le aziende moderne che investono negli ecosistemi di identità cloud, collegare le directory cloud con le reti wireless fisiche è un imperativo di sicurezza fondamentale. Storicamente, l'autenticazione WiFi si basava su Active Directory Domain Services on-premise e Windows Network Policy Server (NPS). Con la migrazione delle organizzazioni a Microsoft Entra ID e Google Workspace, lo stack di autenticazione on-premise diventa un punto debole: costoso da mantenere, difficile da scalare e incompatibile con i modelli di sicurezza zero-trust.

RADIUS as a Service (RADIUSaaS) cambia le carte in tavola. Un server RADIUS ospitato nel cloud si integra direttamente con la directory cloud, convalida le richieste di autenticazione in tempo reale e restituisce le decisioni di accesso ai punti di accesso (access point), senza server on-premise, senza cicli di patch e senza singoli punti di vulnerabilità (single point of failure). Combinata con l'autenticazione basata su certificati EAP-TLS, questa architettura elimina il furto di credenziali, supporta la conformità PCI DSS e GDPR e offre un'esperienza fluida per il personale in ogni sede.

Questa guida tratta la scelta architetturale tra NPS on-premise e RADIUS cloud-native, l'implementazione di EAP-TLS tramite Microsoft Intune e Google Admin Console e le migliori pratiche operative per proteggere l'accesso wireless in hotel, punti vendita, stadi e spazi del settore pubblico. Per un'introduzione più ampia al controllo dell'accesso alla rete, consulta Guida al sistema di controllo dell'accesso alla rete .

Approfondimento tecnico: architettura e standard

Il ruolo di RADIUS e IEEE 802.1X

La base di una rete WiFi aziendale sicura è lo standard IEEE 802.1X, che fornisce il controllo dell'accesso alla rete basato su porte. Quando un dispositivo client (il supplicant) tenta di connettersi a una rete WPA2-Enterprise o WPA3-Enterprise, l'access point wireless (l'authenticator) blocca tutto il traffico ad eccezione dei pacchetti EAP (Extensible Authentication Protocol). L'AP inoltra questi pacchetti a un server RADIUS. Il server RADIUS convalida l'identità rispetto a un servizio di directory e restituisce un messaggio Access-Accept o Access-Reject. Solo a quel punto l'AP concede l'accesso alla rete.

Questo modello a tre parti (supplicant, authenticator, authentication server) è il pilastro della sicurezza wireless aziendale ed è definito nello standard IEEE 802.1X. Non ha subito modifiche sostanziali dalla sua introduzione. Ciò che è cambiato è la posizione del server RADIUS e il modo in cui comunica con la directory.

Architettura RADIUS cloud-native

Un'architettura RADIUS cloud-native elimina la necessità di server NPS o FreeRADIUS on-premise. Un provider Cloud RADIUS di terze parti si integra direttamente con Microsoft Entra ID tramite l'API Microsoft Graph, o con Google Workspace tramite Google Secure LDAP o SAML/OAuth. L'autenticazione avviene interamente nel cloud. Questo si allinea con i principi di accesso alla rete zero-trust e riduce significativamente i costi operativi di gestione.

La tabella seguente confronta i due principali approcci architetturali:

Dimensione	Ibrido on-premise (NPS)	Cloud-native (RADIUSaaS)
Infrastruttura	Richiesta VM Windows Server o bare metal	Nessun server on-premise
Origine identità	AD DS tramite LDAP/Kerberos	Entra ID o Google Workspace tramite API
Autorità di certificazione	ADCS on-premise + Intune Connector	Cloud PKI del fornitore o Microsoft
Alta disponibilità	HA manuale e bilanciamento del carico	Scalabilità automatica del provider
Tempi di configurazione	Da giorni a settimane	Ore
Ideale per	AD ibrido, dispositivi legacy	Organizzazioni cloud-first gestite tramite MDM
Complessità operativa	Maggiore, sia iniziale che continua	Minori costi operativi di gestione

EAP-TLS vs. PEAP-MSCHAPv2: la scelta cruciale

La scelta del metodo EAP è la decisione di sicurezza più determinante in questa implementazione. PEAP-MSCHAPv2 si basa sull'inserimento delle credenziali di dominio da parte degli utenti. Questo metodo è vulnerabile al furto di credenziali e agli attacchi man-in-the-middle. Se un dispositivo client non convalida rigorosamente il certificato del server RADIUS (e molti non lo fanno per impostazione predefinita), un utente malintenzionato può distribuire un access point non autorizzato (rogue AP) con il tuo SSID, intercettare l'handshake EAP e acquisire le credenziali. Questo è noto come attacco Evil Twin ed è ampiamente documentato.

EAP-TLS (Transport Layer Security) utilizza certificati digitali installati sul dispositivo client per l'autenticazione reciproca. Sia il client che il server dimostrano la propria identità in modo crittografico. Non ci sono password da digitare o rubare. In un ambiente Microsoft, i certificati vengono distribuiti in modo invisibile all'utente tramite Microsoft Intune utilizzando profili SCEP (Simple Certificate Enrollment Protocol) o PKCS. Questo è il percorso consigliato per tutte le nuove implementazioni ed è essenziale per la conformità ai requisiti di PCI DSS v4.0 (Requisito 8.3 sull'autenticazione forte) e agli obblighi di protezione dei dati del GDPR.

Google Workspace: la differenza architetturale

Microsoft Entra ID e Google Workspace differiscono per un aspetto importante per quanto riguarda l'integrazione RADIUS. Microsoft NPS si integra nativamente con Active Directory, e i provider Cloud RADIUS si connettono a Entra ID tramite l'API Microsoft Graph. Google, tuttavia, non offre un servizio RADIUS nativo. È sempre necessario un intermediario.

Google Secure LDAP è il percorso di integrazione principale. Disponibile nelle edizioni Cloud Identity Premium e Google Workspace Enterprise, fornisce un'interfaccia LDAP tradizionale alla directory cloud. Il server Cloud RADIUS si connette a ldap.google.com sulla porta 636 utilizzando i certificati client che Google generper te. Da quel momento, il server RADIUS interroga la directory di Google per convalidare le credenziali o l'appartenenza ai gruppi, proprio come farebbe con un Active Directory on-premise.

Un percorso alternativo utilizza l'integrazione basata su SAML, in cui il provider Cloud RADIUS si registra come applicazione SAML nella Google Admin Console ed esegue una ricerca OAuth al momento dell'autenticazione per verificare l'identità dell'utente e l'appartenenza ai gruppi in tempo reale.

Guida all'implementazione

L'implementazione di RADIUSaaS con EAP-TLS richiede il coordinamento di identità, gestione dei dispositivi e infrastruttura di rete. Il seguente approccio in cinque fasi si applica sia agli ambienti Microsoft Entra ID che Google Workspace.

Fase 1: preparare l'infrastruttura di gestione delle identità e dei dispositivi

Per Microsoft Entra ID: verifica che il tuo tenant disponga di licenze Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Questo include Microsoft Intune e l'Accesso Condizionale. Senza Intune, la distribuzione automatizzata dei certificati non è possibile.

Per Google Workspace: conferma di disporre di Cloud Identity Premium o Google Workspace Enterprise per accedere a Google Secure LDAP. Se pianifichi di utilizzare EAP-TLS su Chromebook gestiti, assicurati che la Google Admin Console sia configurata per gestire i certificati dei dispositivi.

Stabilisci la tua Public Key Infrastructure (PKI). Per le nuove distribuzioni, si raccomanda vivamente una PKI cloud-native fornita dal tuo fornitore Cloud RADIUS. Le alternative includono Microsoft Cloud PKI (disponibile con licenza Intune Suite) o una distribuzione ADCS on-premise esistente collegata tramite il Microsoft Intune Certificate Connector.

Fase 2: configurare la distribuzione dei certificati

Percorso Microsoft Intune: nel centro di amministrazione di Intune, crea un profilo di configurazione Trusted Certificate (Certificato attendibile). Carica il certificato della Root CA e distribuiscilo ai gruppi di dispositivi di destinazione. Questo assicura che i dispositivi client considerino attendibile il certificato presentato dal server RADIUS durante l'handshake TLS. Successivamente, crea un profilo SCEP Certificate (Certificato SCEP). Per l'autenticazione basata sull'utente, imposta il Subject Name su CN={{UserPrincipalName}}. Per l'autenticazione basata sul dispositivo, usa CN={{DeviceName}}. Imposta il Subject Alternative Name per includere lo User Principal Name o l'ID del dispositivo.

Percorso Google Admin Console: naviga su Dispositivi, poi Reti, quindi Certificati. Carica la tua Root CA. Configura un meccanismo di emissione dei certificati, che può essere una PKI cloud che supporta l'integrazione SCEP con Google Workspace, oppure il Google Cloud Certificate Connector che fa da proxy per le richieste a una Microsoft Certificate Authority on-premise. Distribuisci la Root CA e i profili dei certificati client alle Unità Organizzative appropriate.

Fase 3: configurare l'integrazione Cloud RADIUS

Concedi al tuo provider Cloud RADIUS le autorizzazioni API necessarie nel tenant della tua directory. Per Entra ID, ciò richiede come minimo User.Read.All e GroupMember.Read.All tramite Microsoft Graph API. Alcuni provider richiedono anche Device.Read.All per i controlli di conformità dei dispositivi. Per Google Workspace tramite Secure LDAP, scarica il certificato client e la chiave dalla Google Admin Console e installali nel servizio RADIUS.

Definisci i tuoi criteri di autenticazione all'interno del portale di gestione Cloud RADIUS. Un criterio ben strutturato per un ambiente aziendale: "Consenti l'accesso se il certificato è emesso da [Trusted CA] E l'utente è membro del gruppo [Corporate-WiFi-Users] E il dispositivo è contrassegnato come Conforme in Intune." Questo applica simultaneamente l'identità, l'appartenenza al gruppo e lo stato di integrità del dispositivo.

Fase 4: configurare l'infrastruttura wireless

Nel controller LAN wireless o nella dashboard di gestione cloud (Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet), aggiungi gli indirizzi IP del server Cloud RADIUS e i segreti condivisi come server di autenticazione RADIUS. Configura i server primario e secondario per la ridondanza. Imposta il timeout RADIUS a un minimo di cinque secondi per gestire la latenza di andata e ritorno del cloud.

Crea un nuovo SSID configurato per WPA2-Enterprise o WPA3-Enterprise. Per le distribuzioni nel settore Hospitality , assicurati che lo SSID aziendale si trovi su una VLAN separata rispetto a qualsiasi rete Guest WiFi . Per gli ambienti Retail , valuta la possibilità di distribuire lo SSID aziendale solo nelle aree retrostanti (back-of-house).

Fase 5: distribuire il profilo WiFi tramite MDM

Microsoft Intune: crea un profilo di configurazione WiFi. Imposta lo SSID in modo che corrisponda esattamente alla configurazione della tua infrastruttura. Seleziona WPA2-Enterprise o WPA3-Enterprise. Nelle impostazioni EAP, seleziona EAP-TLS. Collega il profilo del certificato SCEP come certificato client e specifica il profilo della Trusted Root CA. Assegna questo profilo WiFi agli stessi gruppi di dispositivi che hanno ricevuto i profili dei certificati. I dispositivi riceveranno in modo silenzioso il certificato e la configurazione WiFi durante la successiva sincronizzazione con Intune.

Google Admin Console: naviga su Dispositivi, poi Reti, quindi Wi-Fi. Crea un nuovo profilo di rete WiFi. Imposta lo SSID, seleziona WPA3-Enterprise, scegli EAP-TLS e invia il certificato della Root CA attendibile ai dispositivi. Applica questo profilo alle tue Unità Organizzative. I Chromebook si connetteranno in modo silenzioso e sicuro.

Best practice

Imponi l'uso di EAP-TLS in tutte le nuove distribuzioni. Non distribuire nuove reti utilizzando PEAP-MSCHAPv2. I rischi per la sicurezza sono ampiamente documentati e il percorso di migrazione è semplice grazie ai moderni strumenti MDM.

Imponi una convalida rigorosa del certificato del server. Se devi utilizzare PEAP per i dispositivi legacy, configura i dispositivi per convalidare il certificato del server RADIUS. Nel profilo WiFi di Intune e nel profilo WiFi della Google Admin Console, è presente un campo per specificare la CA attendibile per la convalida del server. Non lasciare questo campo vuoto. Questa singola decisione di configurazione fa la differenza tra una distribuzione sicura e una vulnerabile.

Segmenta la tua rete con l'assegnazione dinamica della VLAN. Utilizza il tuo server RADIUS per esaminare l'appartenenza al gruppo dell'utente in Entra ID o Google Workspace e assegnarlo dinamicamente a VLAN diverse. Il server RADIUS restituisce il Tunnel-Private-Group-Id all'access point, che inserisce il client nella VLAN corretta. Questo limita il movimento laterale in caso di compromissione e supporta i requisiti di segmentazione della rete PCI DSS.

Separare l'autenticazione aziendale e quella degli ospiti. Utilizzare EAP-TLS per i dispositivi gestiti dall'azienda. Utilizzare un Captive Portal con SSO per i dispositivi BYOD e degli ospiti. Cercare di configurare manualmente EAP-TLS su dispositivi non gestiti crea un sovraccarico di supporto eccessivo. La piattaforma Guest WiFi di Purple gestisce l'onboarding degli ospiti separatamente, mantenendo una netta separazione tra il traffico del personale e quello dei visitatori.

Monitorare la scadenza dei certificati in modo proattivo. Impostare il monitoraggio e gli avvisi a 90 giorni, 30 giorni e sette giorni prima della scadenza del certificato. Se il certificato del server RADIUS scade, tutti i dispositivi perdono la connettività contemporaneamente. Automatizzare il rinnovo dove supportato dalla PKI.

Testare le impostazioni di timeout RADIUS. Cloud RADIUS introduce una latenza di rete di andata e ritorno che l'NPS on-premise non presenta. Impostare il timeout RADIUS sugli access point ad almeno cinque secondi. Un timeout di due secondi, comune nelle configurazioni predefinite, causerà errori di autenticazione intermittenti.

Risoluzione dei problemi e mitigazione dei rischi

Le porte del firewall bloccate sono la causa principale del fallimento dell'implementazione iniziale. L'autenticazione RADIUS richiede la porta UDP 1812 in uscita dall'infrastruttura wireless al servizio Cloud RADIUS. L'accounting RADIUS richiede la porta UDP 1813. Verificare che queste porte siano aperte prima di qualsiasi altra risoluzione dei problemi.

I fallimenti della convalida del certificato si presentano come rifiuti di autenticazione senza una causa evidente. Verificare nell'ordine: la scadenza del certificato sia sul client che sul server RADIUS; il disallineamento dell'orologio (clock skew) tra il dispositivo client e il server RADIUS (EAP-TLS si basa su una misurazione precisa del tempo); e se il certificato Root CA è stato distribuito correttamente sul dispositivo tramite MDM.

La mancata applicazione dell'appartenenza ai gruppi è un problema comune quando le policy RADIUS fanno riferimento ai gruppi di Entra ID o Google Workspace. Verificare che il provider Cloud RADIUS disponga delle autorizzazioni API corrette per leggere le appartenenze ai gruppi. In Entra ID, confermare che il service principal disponga di GroupMember.Read.All. In Google Workspace, confermare che il client Secure LDAP disponga dell'autorizzazione per leggere le informazioni sui gruppi.

L'assegnazione della VLAN non funzionante indica in genere una mancata corrispondenza tra i valori degli attributi RADIUS e gli ID VLAN configurati sull'infrastruttura wireless. Confermare che Tunnel-Type sia impostato su VLAN (valore 13), Tunnel-Medium-Type sia impostato su 802 (valore 6) e Tunnel-Private-Group-Id corrisponda all'ID VLAN configurato sullo switch o sul controller.

I dispositivi BYOD che falliscono l'EAP-TLS indicano solitamente che il certificato client non è stato distribuito correttamente. Per i dispositivi gestiti da Intune, controllare l'archivio certificati del dispositivo nel centro amministrativo di Intune. Per i Chromebook gestiti da Google, verificare che il profilo del certificato sia assegnato all'Unità Organizzativa corretta e che il dispositivo si sia sincronizzato di recente.

ROI e impatto aziendale

Il passaggio a Cloud RADIUS offre risparmi operativi misurabili. Il RADIUS on-premise richiede come minimo due server per l'alta disponibilità, l'applicazione continua di patch del sistema operativo, la gestione dei certificati e il tempo di un tecnico specializzato. Il tempo dedicato da un singolo tecnico alla manutenzione del RADIUS in un anno supera in genere il costo annuale di un abbonamento a Cloud RADIUS.

Il business case va oltre la riduzione dei costi. Collegando l'accesso alla rete a identità cloud verificate, si ottiene:

Offboarding istantaneo. La disattivazione di un utente in Entra ID o Google Workspace revoca immediatamente il suo accesso alla rete in tutte le sedi. Non ci sono ritardi, processi manuali o rischi che un ex dipendente mantenga l'accesso WiFi. Questo supporta direttamente gli obblighi del GDPR relativi ai diritti di accesso ai dati.

Analisi più approfondite. Piattaforme come WiFi Analytics di Purple forniscono dati più ricchi sull'utilizzo dello spazio e sui percorsi dei visitatori quando l'accesso alla rete è legato a identità autenticate. Si passa da indirizzi MAC anonimi a utenti nominativi e autenticati, trasformando la qualità dei dati a disposizione dei team operativi e di marketing.

Prove di conformità. L'autenticazione EAP-TLS genera log di accesso dettagliati: chi si è connesso, da quale dispositivo, in quale luogo e a che ora. Questo audit trail supporta il Requisito 10 di PCI DSS (registrazione e monitoraggio) e gli obblighi di accountability del GDPR.

Coerenza multi-sede. Un unico servizio Cloud RADIUS autentica tutte le sedi con policy coerenti, gestite da un'unica dashboard. Aggiungere un nuovo hotel, negozio o locale significa aggiungere i relativi access point alla configurazione RADIUS, non spedire e configurare un altro server. Per le organizzazioni che gestiscono grandi patrimoni immobiliari, questo rappresenta un vantaggio operativo significativo.

Per gli operatori del settore Trasporti e le strutture Sanitarie in cui il tempo di attività della rete è di fondamentale importanza operativa, i provider Cloud RADIUS offrono in genere SLA di uptime del 99,999% con failover multi-regione integrato. Purple opera con un uptime del 99,999% in oltre 80.000 sedi attive, con 440 milioni di accessi elaborati nel 2024 (dati interni Purple, 2024).

Per ulteriori letture su argomenti correlati, vedere Definizione di computer WAN: una guida pratica per il 2026 e Giornata mondiale del WiFi 2026: come la tua struttura può contribuire a colmare il divario digitale .

Definizioni chiave

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service. The RADIUS server acts as the decision engine between your access points and your identity directory.

Every enterprise WPA2-Enterprise or WPA3-Enterprise WiFi network depends on a RADIUS server. Without it, IEEE 802.1X authentication does not function.

RADIUS as a Service (RADIUSaaS)

A cloud-hosted RADIUS implementation delivered as a managed service. The provider maintains the infrastructure, patching, high availability, and identity provider integrations. You configure authentication policies and point your access points to the cloud RADIUS IPs.

RADIUSaaS eliminates the need for on-premise NPS or FreeRADIUS servers, removing the associated hardware, OS patching, and specialist maintenance overhead.

IEEE 802.1X

An IEEE standard for port-based Network Access Control. It defines the three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS server). The authenticator blocks all traffic until the RADIUS server grants access.

The foundational standard for enterprise WiFi authentication. WPA2-Enterprise and WPA3-Enterprise both rely on 802.1X.

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

An authentication method defined in RFC 5216 that uses digital certificates on both the RADIUS server and the client device for mutual authentication. Neither party sends a password. The client presents its certificate; the server validates it against the directory in real time.

The gold standard for enterprise WiFi security. Eliminates credential theft, phishing, and password-related helpdesk overhead. Required for PCI DSS compliance on cardholder data networks.

PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)

An authentication method that creates an encrypted TLS tunnel and then sends the user's username and password through it. Vulnerable to Evil Twin attacks if the client does not strictly validate the RADIUS server certificate.

The legacy default for enterprise WiFi. Still widely deployed but should be migrated to EAP-TLS in all new and existing deployments where possible.

Microsoft Entra ID

Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory (Azure AD). Manages user identities, group memberships, device compliance, and Conditional Access policies.

The primary identity source for Cloud RADIUS in Microsoft-centric environments. Cloud RADIUS providers connect to Entra ID via Microsoft Graph API.

Google Secure LDAP

A managed service available on Cloud Identity Premium and Google Workspace Enterprise editions that provides a traditional LDAP interface to Google's cloud directory. RADIUS servers connect to ldap.google.com on port 636 using client certificates.

The primary integration path for connecting a Cloud RADIUS server to Google Workspace. Google does not offer a native RADIUS service, so Secure LDAP acts as the bridge.

PKI (Public Key Infrastructure)

The set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. A PKI is required to issue the client and server certificates used in EAP-TLS authentication.

Cloud-native PKI options from RADIUS vendors or Microsoft (Cloud PKI) eliminate the need for on-premise Active Directory Certificate Services (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

A protocol that enables devices to request and receive digital certificates from a Certificate Authority automatically. Used by Microsoft Intune and Google Admin Console to deploy client certificates to managed devices without user interaction.

SCEP profiles in Intune are the mechanism by which corporate devices silently receive the client certificates needed for EAP-TLS authentication.

Dynamic VLAN assignment

A RADIUS feature that returns VLAN assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) to the access point based on the authenticated user's directory group membership. The AP places the client on the specified VLAN automatically.

Enables granular network segmentation without manual VLAN configuration per device. Staff in different roles or departments land on different network segments, limiting lateral movement and supporting PCI DSS segmentation requirements.

Esempi pratici

A 200-room hotel is migrating its back-of-house staff network from an ageing on-premise NPS server to a cloud-native solution. The hotel has recently moved to Microsoft Entra ID and Microsoft 365 E5. Staff devices are Windows laptops managed by Intune. The wireless infrastructure is Cisco Meraki. The hotel needs staff to connect automatically without password prompts, and needs instant revocation when a member of staff leaves.

Deploy a Cloud RADIUS solution with Entra ID integration. Step 1: grant the Cloud RADIUS provider Microsoft Graph API permissions (User.Read.All, GroupMember.Read.All, Device.Read.All) in the Entra ID tenant. Step 2: in Intune, create a Trusted Certificate profile with the Cloud RADIUS Root CA and deploy it to the 'All Corporate Devices' group. Step 3: create a SCEP Certificate profile with Subject Name CN={{UserPrincipalName}} and deploy it to the same group. Step 4: configure the Cloud RADIUS authentication policy: allow access if certificate is issued by [Trusted CA] AND user is member of [Hotel-Staff-WiFi] Entra ID group AND device is Intune-compliant. Step 5: in Cisco Meraki dashboard, add the Cloud RADIUS primary and secondary IPs as RADIUS servers on the back-of-house SSID. Set RADIUS timeout to 5 seconds. Step 6: in Intune, create a WPA3-Enterprise WiFi profile for the back-of-house SSID, specifying EAP-TLS and linking the SCEP certificate profile. Deploy to the 'All Corporate Devices' group. Devices silently receive the certificate and WiFi profile on next Intune sync and connect automatically. When a staff member leaves, disabling their Entra ID account immediately revokes network access at all sites.

Commento dell'esaminatore: This approach eliminates the on-premise NPS dependency entirely. EAP-TLS removes the phishing vector of credential-based authentication. Intune automates certificate lifecycle management, removing the manual overhead that caused the previous NPS deployment to fall behind on certificate renewals. The Entra ID group policy means that when HR disables an account, network access is revoked in real time - no manual RADIUS policy update required. The Cisco Meraki integration is straightforward: Cloud RADIUS is hardware-agnostic and works with any 802.1X-capable infrastructure.

A retail chain with 50 stores uses Google Workspace and manages a fleet of 500 Chromebooks used by store associates for inventory and point-of-sale operations. They currently use a shared WPA2 PSK for the store operations network, which creates a security risk when devices are lost or stolen. They want to move to 802.1X authentication without deploying local servers at each store. Their wireless infrastructure is HPE Aruba.

Deploy a Cloud RADIUS solution with Google Workspace integration via Google Secure LDAP. Step 1: in Google Admin Console, navigate to Apps, then LDAP, and add a new LDAP client for the Cloud RADIUS service. Configure read permissions for user information and group membership. Download the generated client certificate and key. Step 2: configure the Cloud RADIUS service with the Google Secure LDAP credentials. Step 3: configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, navigate to Devices, then Networks, then Certificates, and upload the Root CA. Configure the certificate issuance profile and apply it to the Store-Associates Organisational Unit. Step 4: in Google Admin Console, create a WPA3-Enterprise WiFi profile for the store operations SSID. Set EAP-TLS, link the Root CA, and apply to the Store-Associates OU. Chromebooks receive the certificate and WiFi profile on next Admin Console sync. Step 5: in HPE Aruba Central, configure the store operations SSID with WPA3-Enterprise and add the Cloud RADIUS primary and secondary IPs. Set RADIUS timeout to 5 seconds. Configure dynamic VLAN assignment to place store associates on VLAN 20 (store operations) based on their Google Workspace group membership. When a Chromebook is lost or stolen, removing it from the Store-Associates OU immediately revokes its network access.

Commento dell'esaminatore: This deployment eliminates the shared PSK risk. A lost or stolen Chromebook with a shared PSK gives an attacker persistent network access until the PSK is rotated across all 50 stores. With EAP-TLS, the certificate on the lost device can be revoked immediately. The Google Secure LDAP integration is the correct path for Google Workspace environments - it provides a stable, standards-based interface that the Cloud RADIUS service can query without requiring a custom API integration. Dynamic VLAN assignment ensures store associates land on the correct network segment, supporting PCI DSS network segmentation requirements for retail environments.

Domande di esercitazione

Q1. Your organisation is migrating from on-premise Active Directory to Microsoft Entra ID. You currently use PEAP-MSCHAPv2 for WiFi authentication on 300 corporate laptops managed by Intune. You have Microsoft 365 E5 licensing. What is the most secure and operationally efficient path to migrate WiFi authentication to a cloud-native architecture?

Suggerimento: Consider the vulnerabilities of credential-based authentication, the capabilities of Microsoft Intune for certificate deployment, and the need to avoid on-premise infrastructure dependencies.

Visualizza risposta modello

Deploy a Cloud RADIUS solution with Entra ID integration. Use Microsoft Intune to deploy a Trusted Certificate profile (Root CA) and a SCEP Certificate profile to the 300 laptops. Configure the Cloud RADIUS authentication policy to require a valid certificate from the trusted CA and membership of the Corporate-WiFi-Users Entra ID group. Create a WPA3-Enterprise WiFi profile in Intune specifying EAP-TLS and link the SCEP certificate profile. Devices silently receive the certificate and WiFi configuration on next Intune sync. This eliminates PEAP-MSCHAPv2 credential theft risk, removes the on-premise NPS dependency, and provides instant revocation when an Entra ID account is disabled.

Q2. A user at your hotel reports they cannot connect to the back-of-house staff WiFi after returning from a two-week holiday. Other staff are connecting without issue. The network uses EAP-TLS with certificates deployed via Intune. What are the three most likely causes, in order of likelihood?

Suggerimento: EAP-TLS relies on time-sensitive cryptographic assets and real-time directory lookups.

Visualizza risposta modello

The user's client certificate has expired. Certificates have a defined validity period, and if the device was offline during the renewal window, the SCEP profile may not have renewed it. Check the certificate expiry date in the Intune device certificate store. 2. The device's system clock is significantly out of sync (clock skew), causing certificate validation to fail. EAP-TLS validates certificate timestamps; a clock more than five minutes out of sync will cause authentication failures. 3. The user's Entra ID account was placed in a different group during their absence (for example, moved from active staff to a different OU), and the RADIUS authentication policy no longer matches their group membership. Check the user's group memberships in Entra ID against the RADIUS policy.

Q3. You are the IT manager for a retail chain with 80 stores. You use Google Workspace and manage 400 Chromebooks via Google Admin Console. You want to replace the current shared WPA2 PSK on the store operations network with 802.1X authentication. You have no on-premise servers at any store location. What architecture do you deploy, and what is the primary security benefit over the current PSK approach?

Suggerimento: Consider what happens when a Chromebook is lost or stolen under each authentication model.

Visualizza risposta modello

Deploy a Cloud RADIUS service with Google Secure LDAP integration. Configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, deploy the Root CA and a SCEP client certificate profile to the Store-Associates Organisational Unit. Create a WPA3-Enterprise WiFi profile specifying EAP-TLS and deploy it to the same OU. Configure HPE Aruba (or equivalent) access points at each store to point to the Cloud RADIUS service. The primary security benefit: under the current shared PSK, a lost or stolen Chromebook retains WiFi access until the PSK is rotated across all 80 stores - a disruptive, time-consuming process. With EAP-TLS, removing the device from the Store-Associates OU in Google Admin Console immediately revokes its certificate and network access, with no impact on any other device.

Q4. During a Cloud RADIUS deployment, you configure the SSID on Cisco Meraki access points and deploy the Intune WiFi profile to a pilot group of 20 devices. None of the devices can connect. The Intune device status shows the certificate and WiFi profile as successfully deployed. What is the first thing you check?

Suggerimento: The most common cause of initial deployment failure is not a configuration error in the RADIUS policy or the certificate.

Visualizza risposta modello

Check that UDP ports 1812 and 1813 are open outbound from the Cisco Meraki access points (or the Meraki cloud infrastructure) to the Cloud RADIUS server IP addresses. Blocked firewall ports are the leading cause of initial deployment failure. The fact that certificates and WiFi profiles are successfully deployed rules out Intune configuration issues. The next checks are: RADIUS shared secret mismatch between Meraki and the Cloud RADIUS service; RADIUS timeout set too low (increase to at least 5 seconds); and whether the Cloud RADIUS server IPs are correctly entered in the Meraki SSID configuration.

Continua a leggere questa serie

The Security Benefits of RADIUS as a Service for Hybrid Workforces

Questa guida di riferimento tecnico spiega come RADIUS as a Service protegga l'accesso alla rete per la forza lavoro ibrida in sedi distribuite. Copre l'architettura, i vantaggi in termini di sicurezza e le fasi di implementazione per sostituire l'infrastruttura RADIUS on-premise con un servizio di autenticazione gestito in cloud. Per i responsabili IT e gli architetti di rete di hotel, catene di vendita al dettaglio, stadi e organizzazioni del settore pubblico, questa guida fornisce gli elementi necessari per valutare e avviare la migrazione a un RADIUS in cloud in questo trimestre.

How to Implement 802.1X Authentication with Cloud RADIUS

Questa guida di riferimento tecnica fornisce un quadro completo per l'implementazione dell'autenticazione 802.1X con Cloud RADIUS in ambienti aziendali distribuiti. Descrive in dettaglio l'architettura, la selezione del metodo EAP, la sequenza di implementazione e le strategie di mitigazione del rischio necessarie per proteggere l'accesso alla rete, eliminando al contempo il sovraccarico operativo dell'infrastruttura on-premises.

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Questa guida completa esplora Cloud RADIUS (RADIUS as a Service), dettagliandone l'architettura, i metodi EAP e le strategie di implementazione. Fornisce ai leader IT approfondimenti pratici sulla migrazione da server on-premises a un modello di autenticazione basato su cloud scalabile, sicuro e conforme.