Integrazione di RADIUS as a Service con directory cloud (Azure AD e Google Workspace)
Questa guida tecnica di riferimento 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 negli ambienti dell'ospitalità, della vendita al dettaglio e del settore 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.
Ascolta questa guida
Visualizza trascrizione del podcast
Executive summary
Per le aziende moderne che investono in ecosistemi di identità cloud, collegare le directory cloud alle 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 regole del gioco. 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, senza server on-premise, senza cicli di patch e senza singoli punti di vulnerabilità. 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 illustra 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 A Guide to Your Network Access Control System .
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 tranne i 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 di 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 è cambiato fondamentalmente dalla sua introduzione. Ciò che è cambiato è dove risiede il server RADIUS e come 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 Microsoft Graph API, oppure con Google Workspace tramite Google Secure LDAP o SAML/OAuth. L'autenticazione avviene interamente nel cloud. Questo si allinea con i principi di zero-trust network access e riduce significativamente i costi operativi.
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 via LDAP/Kerberos | Entra ID o Google Workspace via API |
| Autorità di certificazione | ADCS on-premise + Intune Connector | Cloud PKI del vendor o Microsoft |
| Alta disponibilità | HA manuale e bilanciamento del carico | Scalabilità automatica del provider |
| Tempo di configurazione | Da giorni a settimane | Ore |
| Ideale per | AD ibrido, dispositivi legacy | Organizzazioni cloud-first gestite da MDM |
| Complessità operativa | Maggiore complessità iniziale e continua | Minori costi operativi |
EAP-TLS vs. PEAP-MSCHAPv2: la scelta cruciale
La scelta del metodo EAP è la decisione di sicurezza più importante 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 fittizio con il tuo SSID, intercettare l'handshake EAP e catturare le credenziali. Questo è un 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 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à a 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 in un aspetto importante per l'integrazione RADIUS. Microsoft NPS si integra nativamente con Active Directory e i provider Cloud RADIUS si connettono a Entra ID tramite Microsoft Graph API. 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 generati da Google. Da quel momento, il server RADIUS interroga la directory di Google per convalidare le credenziali o l'appartenenza ai gruppi, esattamente 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 dell'identità, della gestione dei dispositivi e dell'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: verificare che il tenant disponga delle 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: confermare di disporre di Cloud Identity Premium o Google Workspace Enterprise per accedere a Google Secure LDAP. Se si prevede di utilizzare EAP-TLS sui Chromebook gestiti, assicurarsi che la Google Admin Console sia configurata per gestire i certificati dei dispositivi.
Stabilire la Public Key Infrastructure (PKI). Per le nuove distribuzioni, si raccomanda vivamente una PKI cloud-native fornita dal fornitore Cloud RADIUS. Le alternative includono Microsoft Cloud PKI (disponibile con la 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: nell'interfaccia di amministrazione di Intune, creare un profilo di configurazione Trusted Certificate. Caricare il certificato della Root CA e distribuirlo ai gruppi di dispositivi di destinazione. Questo garantisce che i dispositivi client considerino attendibile il certificato presentato dal server RADIUS durante l'handshake TLS. Successivamente, creare un profilo SCEP Certificate. Per l'autenticazione basata sull'utente, impostare il Subject Name su CN={{UserPrincipalName}}. Per l'autenticazione basata sul dispositivo, utilizzare CN={{DeviceName}}. Impostare il Subject Alternative Name per includere l'User Principal Name o l'ID del dispositivo.
Percorso Google Admin Console: accedere a Dispositivi, quindi Reti, infine Certificati. Caricare la Root CA. Configurare un meccanismo di emissione dei certificati: una PKI cloud che supporti l'integrazione SCEP con Google Workspace, oppure il Google Cloud Certificate Connector che funge da proxy per le richieste a una Microsoft Certificate Authority on-premise. Distribuire 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 i permessi API necessari nel tenant della tua directory. Per Entra ID, questo 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 sul servizio RADIUS.
Definisci le tue policy di autenticazione all'interno del portale di gestione Cloud RADIUS. Una policy ben strutturata per un ambiente aziendale: "Consenti l'accesso se il certificato è rilasciato da [Trusted CA] E l'utente è un membro del gruppo [Corporate-WiFi-Users] E il dispositivo è contrassegnato come Conforme in Intune". Questo impone simultaneamente l'identità, l'appartenenza al gruppo e lo stato di salute 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 l'SSID aziendale si trovi su una VLAN separata da qualsiasi rete Guest WiFi . Per gli ambienti Retail , valuta la possibilità di distribuire l'SSID aziendale solo nelle aree riservate al personale.
Fase 5: distribuire il profilo WiFi tramite MDM
Microsoft Intune: crea un profilo di configurazione WiFi. Imposta l'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 CA radice attendibile. Assegna questo profilo WiFi agli stessi gruppi di dispositivi che hanno ricevuto i profili dei certificati. I dispositivi ricevono silenziosamente il certificato e la configurazione WiFi durante la successiva sincronizzazione con Intune.
Google Admin Console: vai su Dispositivi, poi su Reti, quindi su Wi-Fi. Crea un nuovo profilo di rete WiFi. Imposta l'SSID, seleziona WPA3-Enterprise, scegli EAP-TLS e invia il certificato della CA radice attendibile ai dispositivi. Applica questo profilo alle tue Unità Organizzative. I Chromebook si connettono in modo silenzioso e sicuro.
Best practice
Imponi 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 con i 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 di 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 controllare l'appartenenza ai gruppi dell'utente in Entra ID o Google Workspace e assegnarli dinamicamente a diverse VLAN. Il server RADIUS restituisce l'attributo Tunnel-Private-Group-Id all'access point, che posiziona il client sulla VLAN corretta. Ciò limita il movimento laterale in caso di violazione e supporta i requisiti di segmentazione della rete PCI DSS.
Separa l'autenticazione aziendale da quella degli ospiti. Utilizza EAP-TLS per i dispositivi gestiti dall'azienda. Utilizza 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.
Monitora la scadenza dei certificati in modo proattivo. Imposta il monitoraggio e gli avvisi a 90 giorni, 30 giorni e sette giorni prima della scadenza del certificato. Se il certificato del tuo server RADIUS scade, tutti i dispositivi perdono la connettività contemporaneamente. Automatizza il rinnovo laddove la tua PKI lo supporti.
Verifica le impostazioni di timeout RADIUS. Cloud RADIUS introduce una latenza di rete di andata e ritorno che l'NPS on-premise non presenta. Imposta il timeout RADIUS sui tuoi 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 della distribuzione iniziale. L'autenticazione RADIUS richiede la porta UDP 1812 in uscita dalla tua infrastruttura wireless verso il servizio Cloud RADIUS. L'accounting RADIUS richiede la porta UDP 1813. Verifica che queste porte siano aperte prima di procedere con qualsiasi altra risoluzione dei problemi.
I fallimenti della convalida del certificato si presentano come rifiuti di autenticazione senza una causa evidente. Controlla 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 della 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. Verifica che il provider Cloud RADIUS disponga delle autorizzazioni API corrette per leggere le appartenenze ai gruppi. In Entra ID, conferma che il service principal disponga di GroupMember.Read.All. In Google Workspace, conferma che il client Secure LDAP disponga dell'autorizzazione per leggere le informazioni sui gruppi.
L'assegnazione della VLAN non funziona indica in genere una mancata corrispondenza tra i valori degli attributi RADIUS e gli ID VLAN configurati sull'infrastruttura wireless. Verificare 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 dei certificati del dispositivo nell'interfaccia di amministrazione 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 affidabilità, l'applicazione continua di patch al sistema operativo, la gestione dei certificati e il tempo di tecnici specializzati. Il tempo dedicato da un singolo ingegnere alla manutenzione del RADIUS in un anno supera in genere il costo annuale di un abbonamento a Cloud RADIUS.
I vantaggi aziendali vanno 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 al WiFi. Ciò supporta direttamente gli obblighi del GDPR in materia di diritti di accesso ai dati.
Analisi più approfondite. Piattaforme come WiFi Analytics di Purple offrono 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, il che trasforma la qualità delle informazioni a disposizione dei team operativi e di marketing.
Prove di conformità. L'autenticazione EAP-TLS genera registri di accesso dettagliati: chi si è connesso, da quale dispositivo, in quale luogo e a che ora. Questo percorso di audit supporta il requisito 10 del PCI DSS (registrazione e monitoraggio) e gli obblighi di responsabilità 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 punti di accesso 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 è fondamentale dal punto di vista operativo, 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 approfondire argomenti correlati, consulta WAN Computer Definition: A Practical Guide for 2026 e World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide .
Definizioni chiave
RADIUS (Remote Authentication Dial-In User Service)
Un protocollo di rete definito nella RFC 2865 che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento (AAA) per gli utenti che si connettono a un servizio di rete. Il server RADIUS funge da motore decisionale tra i punti di accesso e la directory delle identità.
Ogni rete WiFi aziendale WPA2-Enterprise o WPA3-Enterprise dipende da un server RADIUS. Senza di esso, l'autenticazione IEEE 802.1X non funziona.
RADIUS as a Service (RADIUSaaS)
Un'implementazione RADIUS ospitata in cloud e fornita come servizio gestito. Il provider gestisce l'infrastruttura, le patch, l'alta affidabilità e le integrazioni con i provider di identità. L'utente configura i criteri di autenticazione e indirizza i punti di accesso verso gli IP del RADIUS in cloud.
RADIUSaaS elimina la necessità di server NPS o FreeRADIUS on-premise, rimuovendo l'hardware associato, l'applicazione di patch al sistema operativo e i costi di manutenzione specialistica.
IEEE 802.1X
Uno standard IEEE per il controllo dell'accesso alla rete basato su porte. Definisce il modello di autenticazione a tre parti: il supplicant (dispositivo client), l'authenticator (punto di accesso o switch) e l'authentication server (server RADIUS). L'authenticator blocca tutto il traffico finché il server RADIUS non concede l'accesso.
Lo standard fondamentale per l'autenticazione WiFi aziendale. Sia WPA2-Enterprise che WPA3-Enterprise si basano su 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un metodo di autenticazione definito nella RFC 5216 che utilizza certificati digitali sia sul server RADIUS che sul dispositivo client per l'autenticazione reciproca. Nessuna delle due parti invia una password. Il client presenta il proprio certificato; il server lo convalida rispetto alla directory in tempo reale.
Il gold standard per la sicurezza del WiFi aziendale. Elimina il furto di credenziali, il phishing e i costi di helpdesk legati alle password. Richiesto per la conformità PCI DSS sulle reti di dati dei titolari di carta.
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
Un metodo di autenticazione che crea un tunnel TLS crittografato e invia al suo interno il nome utente e la password dell'utente. Vulnerabile agli attacchi Evil Twin se il client non convalida rigorosamente il certificato del server RADIUS.
L'impostazione predefinita legacy per il WiFi aziendale. Ancora ampiamente distribuito, ma dovrebbe essere migrato a EAP-TLS in tutte le nuove ed esistenti distribuzioni, ove possibile.
Microsoft Entra ID
Il servizio di gestione delle identità e degli accessi basato su cloud di Microsoft, precedentemente noto come Azure Active Directory (Azure AD). Gestisce le identità degli utenti, le appartenenze ai gruppi, la conformità dei dispositivi e i criteri di accesso condizionale.
La fonte di identità primaria per Cloud RADIUS negli ambienti incentrati su Microsoft. I provider Cloud RADIUS si connettono a Entra ID tramite Microsoft Graph API.
Google Secure LDAP
Un servizio gestito disponibile sulle edizioni Cloud Identity Premium e Google Workspace Enterprise che fornisce un'interfaccia LDAP tradizionale alla directory cloud di Google. I server RADIUS si connettono a ldap.google.com sulla porta 636 utilizzando certificati client.
Il percorso di integrazione primario per connettere un server Cloud RADIUS a Google Workspace. Google non offre un servizio RADIUS nativo, quindi Secure LDAP funge da ponte.
PKI (Public Key Infrastructure)
L'insieme di ruoli, criteri, hardware, software e procedure necessari per creare, gestire, distribuire, utilizzare, memorizzare e revocare certificati digitali. Una PKI è necessaria per emettere i certificati client e server utilizzati nell'autenticazione EAP-TLS.
Le opzioni PKI cloud-native dei fornitori RADIUS o di Microsoft (Cloud PKI) eliminano la necessità di Active Directory Certificate Services (ADCS) on-premise.
SCEP (Simple Certificate Enrollment Protocol)
Un protocollo che consente ai dispositivi di richiedere e ricevere automaticamente certificati digitali da un'Autorità di Certificazione. Utilizzato da Microsoft Intune e Google Admin Console per distribuire certificati client ai dispositivi gestiti senza l'interazione dell'utente.
I profili SCEP in Intune sono il meccanismo attraverso il quale i dispositivi aziendali ricevono in modo silenzioso i certificati client necessari per l'autenticazione EAP-TLS.
Dynamic VLAN assignment
Una funzionalità RADIUS che restituisce gli attributi di assegnazione della VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) al punto di accesso in base all'appartenenza al gruppo di directory dell'utente autenticato. L'AP inserisce automaticamente il client nella VLAN specificata.
Consente una segmentazione granulare della rete senza configurazione manuale delle VLAN per dispositivo. Il personale con ruoli o reparti diversi accede a segmenti di rete differenti, limitando i movimenti laterali e supportando i requisiti di segmentazione PCI DSS.
Esempi pratici
Un hotel da 200 camere sta migrando la rete del personale di back-of-house da un server NPS on-premise obsoleto a una soluzione cloud-native. L'hotel è passato di recente a Microsoft Entra ID e Microsoft 365 E5. I dispositivi del personale sono laptop Windows gestiti da Intune. L'infrastruttura wireless è Cisco Meraki. L'hotel richiede che il personale si connetta automaticamente senza richieste di password e necessita di una revoca istantanea quando un membro del personale lascia l'azienda.
Implementare una soluzione Cloud RADIUS con integrazione Entra ID. Passaggio 1: concedere al provider Cloud RADIUS le autorizzazioni Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) nel tenant Entra ID. Passaggio 2: in Intune, creare un profilo Certificato attendibile con la CA radice di Cloud RADIUS e distribuirlo al gruppo "Tutti i dispositivi aziendali". Passaggio 3: creare un profilo Certificato SCEP con Nome soggetto CN={{UserPrincipalName}} e distribuirlo allo stesso gruppo. Passaggio 4: configurare il criterio di autenticazione Cloud RADIUS: consentire l'accesso se il certificato è emesso da [CA attendibile] E l'utente è membro del gruppo Entra ID [Hotel-Staff-WiFi] E il dispositivo è conforme a Intune. Passaggio 5: nella dashboard di Cisco Meraki, aggiungere gli IP primario e secondario di Cloud RADIUS come server RADIUS sull'SSID di back-of-house. Impostare il timeout RADIUS a 5 secondi. Passaggio 6: in Intune, creare un profilo WiFi WPA3-Enterprise per l'SSID di back-of-house, specificando EAP-TLS e collegando il profilo del certificato SCEP. Distribuire al gruppo "Tutti i dispositivi aziendali". I dispositivi ricevono silenziosamente il certificato e il profilo WiFi alla successiva sincronizzazione di Intune e si connettono automaticamente. Quando un membro del personale lascia l'azienda, la disattivazione del suo account Entra ID revoca immediatamente l'accesso alla rete in tutte le sedi.
Una catena di negozi con 50 punti vendita utilizza Google Workspace e gestisce una flotta di 500 Chromebook utilizzati dagli addetti alla vendita per le operazioni di inventario e punto vendita. Attualmente utilizzano una chiave WPA2 PSK condivisa per la rete operativa dei negozi, il che comporta un rischio per la sicurezza in caso di smarrimento o furto dei dispositivi. Desiderano passare all'autenticazione 802.1X senza implementare server locali in ciascun negozio. La loro infrastruttura wireless è HPE Aruba.
Implementare una soluzione Cloud RADIUS con integrazione Google Workspace tramite Google Secure LDAP. Passaggio 1: nella Console di amministrazione Google, accedere ad App, quindi a LDAP e aggiungere un nuovo client LDAP per il servizio Cloud RADIUS. Configurare le autorizzazioni di lettura per le informazioni utente e l'appartenenza ai gruppi. Scaricare il certificato client e la chiave generati. Passaggio 2: configurare il servizio Cloud RADIUS con le credenziali Google Secure LDAP. Passaggio 3: configurare una PKI cloud per emettere certificati per i Chromebook. Nella Console di amministrazione Google, accedere a Dispositivi, quindi a Reti, quindi a Certificati e caricare la CA radice. Configurare il profilo di emissione del certificato e applicarlo all'Unità organizzativa Store-Associates. Passaggio 4: nella Console di amministrazione Google, creare un profilo WiFi WPA3-Enterprise per l'SSID operativo del negozio. Impostare EAP-TLS, collegare la CA radice e applicare all'UO Store-Associates. I Chromebook ricevono il certificato e il profilo WiFi alla successiva sincronizzazione della Console di amministrazione. Passaggio 5: in HPE Aruba Central, configurare l'SSID operativo del negozio con WPA3-Enterprise e aggiungere gli IP primario e secondario di Cloud RADIUS. Impostare il timeout RADIUS a 5 secondi. Configurare l'assegnazione dinamica della VLAN per inserire gli addetti alla vendita sulla VLAN 20 (operazioni del negozio) in base alla loro appartenenza al gruppo Google Workspace. Quando un Chromebook viene smarrito o rubato, la sua rimozione dall'UO Store-Associates revoca immediatamente il suo accesso alla rete.
Domande di esercitazione
Q1. La tua organizzazione sta migrando da Active Directory on-premise a Microsoft Entra ID. Attualmente utilizzi PEAP-MSCHAPv2 per l'autenticazione WiFi su 300 laptop aziendali gestiti da Intune. Disponi di licenze Microsoft 365 E5. Qual è il percorso più sicuro ed efficiente dal punto di vista operativo per migrare l'autenticazione WiFi a un'architettura cloud-native?
Suggerimento: Considera le vulnerabilità dell'autenticazione basata su credenziali, le funzionalità di Microsoft Intune per la distribuzione dei certificati e la necessità di evitare dipendenze da infrastrutture on-premise.
Visualizza risposta modello
Distribuisci una soluzione Cloud RADIUS integrata con Entra ID. Utilizza Microsoft Intune per distribuire un profilo di certificato attendibile (Root CA) e un profilo di certificato SCEP ai 300 laptop. Configura i criteri di autenticazione Cloud RADIUS per richiedere un certificato valido dalla CA attendibile e l'appartenenza al gruppo Entra ID Corporate-WiFi-Users. Crea un profilo WiFi WPA3-Enterprise in Intune specificando EAP-TLS e collegalo al profilo del certificato SCEP. I dispositivi riceveranno in modo trasparente il certificato e la configurazione WiFi al successivo ciclo di sincronizzazione di Intune. Questo elimina il rischio di furto di credenziali PEAP-MSCHAPv2, rimuove la dipendenza da NPS on-premise e garantisce la revoca immediata quando un account Entra ID viene disabilitato.
Q2. Un utente del tuo hotel riferisce di non riuscire a connettersi alla WiFi riservata al personale di servizio dopo essere rientrato da due settimane di ferie. Gli altri dipendenti si connettono senza problemi. La rete utilizza EAP-TLS con certificati distribuiti tramite Intune. Quali sono le tre cause più probabili, in ordine di probabilità?
Suggerimento: EAP-TLS si basa su risorse crittografiche sensibili al fattore tempo e su ricerche in tempo reale nella directory.
Visualizza risposta modello
- Il certificato client dell'utente è scaduto. I certificati hanno un periodo di validità definito e, se il dispositivo era offline durante la finestra di rinnovo, il profilo SCEP potrebbe non averlo rinnovato. Verifica la data di scadenza del certificato nell'archivio certificati del dispositivo in Intune. 2. L'orologio di sistema del dispositivo è notevolmente fuori sincronizzazione (disallineamento temporale), impedendo la convalida del certificato. EAP-TLS convalida i timestamp dei certificati; un orologio sfasato di oltre cinque minuti causerà errori di autenticazione. 3. L'account Entra ID dell'utente è stato inserito in un gruppo diverso durante la sua assenza (ad esempio, spostato dal personale attivo a una OU diversa) e i criteri di autenticazione RADIUS non corrispondono più alla sua appartenenza al gruppo. Verifica le appartenenze ai gruppi dell'utente in Entra ID rispetto ai criteri RADIUS.
Q3. Sei l'IT manager di una catena di vendita al dettaglio con 80 negozi. Utilizzi Google Workspace e gestisci 400 Chromebook tramite Google Admin Console. Desideri sostituire l'attuale chiave WPA2 PSK condivisa sulla rete operativa dei negozi con l'autenticazione 802.1X. Non disponi di server on-premise in nessuna delle sedi dei negozi. Quale architettura decidi di implementare e qual è il principale vantaggio in termini di sicurezza rispetto all'attuale approccio PSK?
Suggerimento: Considera cosa accade quando un Chromebook viene smarrito o rubato in ciascun modello di autenticazione.
Visualizza risposta modello
Distribuisci un servizio Cloud RADIUS integrato con Google Secure LDAP. Configura una PKI cloud per emettere certificati per i Chromebook. Nella Google Admin Console, distribuisci la Root CA e un profilo di certificato client SCEP all'Unità Organizzativa Store-Associates. Crea un profilo WiFi WPA3-Enterprise specificando EAP-TLS e distribuiscilo alla stessa OU. Configura gli access point HPE Aruba (o equivalenti) in ciascun negozio per puntare al servizio Cloud RADIUS. Il principale vantaggio in termini di sicurezza: con l'attuale PSK condivisa, un Chromebook smarrito o rubato mantiene l'accesso alla WiFi fino a quando la PSK non viene modificata in tutti gli 80 negozi, un processo complesso e dispendioso in termini di tempo. Con EAP-TLS, la rimozione del dispositivo dall'OU Store-Associates nella Google Admin Console revoca immediatamente il suo certificato e l'accesso alla rete, senza alcun impatto sugli altri dispositivi.
Q4. Durante la distribuzione di Cloud RADIUS, configuri l'SSID sugli access point Cisco Meraki e distribuisci il profilo WiFi di Intune a un gruppo pilota di 20 dispositivi. Nessuno dei dispositivi riesce a connettersi. Lo stato del dispositivo in Intune mostra che il certificato e il profilo WiFi sono stati distribuiti correttamente. Qual è la prima cosa da verificare?
Suggerimento: La causa più comune del fallimento di una distribuzione iniziale non è un errore di configurazione nei criteri RADIUS o nel certificato.
Visualizza risposta modello
Verifica che le porte UDP 1812 e 1813 siano aperte in uscita dagli access point Cisco Meraki (o dall'infrastruttura cloud Meraki) verso gli indirizzi IP del server Cloud RADIUS. Le porte bloccate sul firewall sono la causa principale del fallimento delle distribuzioni iniziali. Il fatto che i certificati e i profili WiFi siano stati distribuiti correttamente esclude problemi di configurazione di Intune. Le verifiche successive sono: mancata corrispondenza della chiave segreta condivisa RADIUS tra Meraki e il servizio Cloud RADIUS; timeout RADIUS impostato su un valore troppo basso (aumentalo ad almeno 5 secondi); e se gli IP del server Cloud RADIUS sono inseriti correttamente nella configurazione dell'SSID Meraki.
Continua a leggere questa serie
I vantaggi in termini di sicurezza di RADIUS as a Service per la forza lavoro ibrida
Questa guida di riferimento tecnico spiega come RADIUS as a Service protegga l'accesso alla rete per la forza lavoro ibrida all'interno di sedi distribuite. Copre l'architettura, i vantaggi in termini di sicurezza e i passaggi 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 servizio RADIUS cloud in questo trimestre.
Come implementare l'autenticazione 802.1X con Cloud RADIUS
Questa guida di riferimento tecnico fornisce un framework completo per l'implementazione dell'autenticazione 802.1X con Cloud RADIUS in infrastrutture aziendali distribuite. 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 i costi operativi dell'infrastruttura on-premises.
Cos'è Cloud RADIUS? Una guida completa a RADIUS as a Service
Questa guida completa esplora Cloud RADIUS (RADIUS as a Service), descrivendone in dettaglio l'architettura, i metodi EAP e le strategie di implementazione. Fornisce ai responsabili IT informazioni utili per migrare dai server on-premise a un modello di autenticazione basato su cloud scalabile, sicuro e conforme.