Avete ereditato una sede nel Regno Unito in cui la password del WiFi aziendale è stampata in una cartella nel retroufficio, condivisa da reception, personale delle pulizie, appaltatori ed ex dipendenti. La rete ospiti è gestita separatamente, l'onboarding dei dispositivi dipende da istruzioni manuali e un auditor desidera sapere quale persona ha autorizzato ciascuna connessione. Nel frattempo, l'organizzazione ha spostato l'identità delle sue applicazioni su Microsoft Entra ID e si aspetta che il WiFi faccia lo stesso.
Questa aspettativa è comprensibile, ma l'architettura viene spesso descritta in modo errato. Entra ID non fornisce un servizio RADIUS nativo. La posizione documentata di Microsoft è che i dispositivi associati a Entra non possono utilizzare l'autenticazione RADIUS basata su un oggetto computer e un certificato locali, pertanto i progetti moderni si affidano invece a EAP-TLS, certificati emessi da Intune e un livello RADIUS separato (Guida di Microsoft Entra per RADIUS). Una volta chiarita questa distinzione, la distribuzione diventa molto più facile da progettare, testare e supportare.
Perché l'autenticazione WiFi con Microsoft Entra ID vale l'investimento
Una chiave pre-condivisa può funzionare al momento dell'apertura, per poi rimanere attiva dopo che un dipendente se ne va, un fornitore esterno la copia su un dispositivo personale o un ospite accede a una rete destinata al personale. La modifica di tale chiave crea un problema operativo non indifferente. Ogni laptop gestito, telefono, cassa, tablet e altro dispositivo deve ricevere il nuovo segreto, spesso tra hotel, ospedali e punti vendita.
L'autenticazione WiFi con Microsoft Entra ID sposta l'unità di attendibilità dalla password all'identità e al dispositivo. EAP-TLS utilizza una connessione supportata da certificato per identificare un utente o un dispositivo autorizzato. Intune controlla quali endpoint gestiti ricevono tale certificato e il profilo WiFi corrispondente. L'access point richiede ancora RADIUS, quindi Microsoft Entra ID funge da directory e origine delle policy, non da endpoint per l'autenticazione wireless. Questo divario architetturale è il dettaglio che molte guide semplificate omettono.
Regola pratica: Gestisci il WiFi come un servizio vincolato all'identità: richiedi un certificato e un ambito Intune, mai un copia e incolla di nome utente e password di Entra.
L'onboarding diventa ripetibile. Un profilo Intune configurato correttamente può impostare l'SSID, la catena di certificati attendibili e la selezione del certificato senza chiedere al personale di digitare o condividere una chiave. Anche l'offboarding ottiene un percorso di controllo definito. La disattivazione di un dispositivo può attivare azioni sul ciclo di vita del certificato, invece di lasciare che gli amministratori cerchino ogni posizione in cui era memorizzata una password condivisa.
Anche l'aspetto della conformità è altrettanto pratico. Le organizzazioni nel Regno Unito devono separare il personale, gli ospiti, i fornitori e i dispositivi non gestiti all'interno di locali condivisi e ambienti regolamentati. Una guida dedicata alla enterprise WiFi security guide fornisce un background utile, mentre il design di produzione richiede decisioni chiare: mantenere l'accesso degli ospiti separato dall'EAP-TLS del personale, registrare l'identità presentata a RADIUS e definire come viene rimosso l'accesso.
L'interfaccia di amministrazione di Entra non fornisce un unico interruttore per questa configurazione. Le impostazioni PKI, Intune, le policy RADIUS e le configurazioni wireless devono collaborare, e i dispositivi legacy Apple, Windows, Android e condivisi possono mostrare comportamenti diversi per quanto riguarda certificati o profili. Questo lavoro di integrazione è concreto, ma sostituisce un segreto condiviso fragile con un controllo ripetibile applicabile a un intero parco dispositivi nel Regno Unito.
I blocchi costruttivi fondamentali di cui hai bisogno
Una rete guest di un hotel, un reparto ospedaliero o una filiale retail possono riscontrare problemi al primo controllo del certificato anche se l'access point segnala un SSID attivo e funzionante. Evita questa confusione definendo l'architettura prima di avviare la procedura guidata di Intune. Quattro componenti devono concordare su un'unica catena di identità:
- Un'autorità di certificazione. Inizia con Microsoft PKI, AD CS o un provider di certificati gestiti. La CA deve emettere certificati con EKU di Client Authentication prima che la policy RADIUS venga ottimizzata, e il servizio RADIUS deve considerare attendibile la catena di emissione.
- Uno strato RADIUS. NPS, Aruba ClearPass, Cisco ISE o una piattaforma RADIUS-as-a-Service terminano lo scambio 802.1X dagli access point. Entra ID non ha una funzionalità RADIUS nativa. L'estensione NPS adatta le richieste RADIUS ai controlli basati su Entra, anziché trasformare Entra in un server RADIUS, come spiegato nelle Domande e risposte di Microsoft sulle limitazioni RADIUS.
- Intune. Intune distribuisce la radice attendibile, il profilo certificato SCEP o PKCS e la configurazione WiFi. Le sue assegnazioni controllano anche l'ambito del dispositivo, in modo che un profilo non completato non raggiunga l'intero parco macchine.
- Policy di rete. Il RADIUS deve definire ciò che un certificato andato a buon fine consente. Potrebbe trattarsi di una VLAN del personale, di un segmento clinico, di una rete retail limitata o di una ACL specifica per il dispositivo.
Costruire in ordine di dipendenza
Pubblica e convalida il modello CA prima di configurare il RADIUS. Controlla l'emittente, il subject o il SAN, la catena di certificati e l'EKU di Client Authentication. Altrimenti, gli handshake falliti possono sembrare un guasto RF o SSID quando in realtà il dispositivo non ha un certificato utilizzabile.
La fiducia deve funzionare in entrambe le direzioni. I dispositivi gestiti si fidano della CA che ha firmato il certificato del server RADIUS, mentre RADIUS si fida della CA che ha emesso il certificato client. Gli access point necessitano dell'indirizzo del server RADIUS e del shared secret. Non si autenticano direttamente contro Entra.
Decidere dove risiede la policy
NPS, ClearPass e ISE possono applicare policy wireless, ma i loro modelli di regole e la gestione degli attributi differiscono. Seleziona un'unica fonte di verità per la mappatura da SSID a VLAN, documentala ed evita che le dashboard degli AP e le regole RADIUS producano risultati contrastanti.
Un elenco del settore pubblico del Regno Unito descrive il supporto di Entra ID per l'autenticazione a chiave pubblica, inclusi i certificati client TLS, insieme alla federazione e all'autenticazione a due fattori (elenco Entra ID del settore pubblico del Regno Unito). Il modello di certificato dipende ancora dai componenti PKI e RADIUS separati.
Emissione di certificati e distribuzione dei profili WiFi tramite Intune
Per i dispositivi gestiti, il successo o il fallimento di EAP-TLS dipende dalla selezione del certificato. Intune può distribuire il profilo senza l'interazione dell'utente, ma non può compensare un modello di certificato a cui mancano l'utilizzo corretto, l'emittente o la mappatura del soggetto.
Stabilire il percorso del certificato
Distribuisci prima il profilo della CA radice attendibile. Con SCEP, crea un profilo certificato che punti al servizio NDES e utilizzi l'Intune Certificate Connector. Il profilo deve fare riferimento all'endpoint SCEP pubblicato, al modello di certificato corretto e a un meccanismo di verifica che impedisca richieste non autorizzate.
Il certificato stesso richiede Client Authentication nel suo utilizzo esteso della chiave. Decidi se il subject e il SAN identificano il dispositivo, l'utente o entrambi. Questa decisione influisce sulla mappatura RADIUS, sul comportamento dei dispositivi condivisi e sul modo in cui analizzerai un evento di autenticazione in seguito.
Un profilo PFX può funzionare laddove i certificati vengono generati e pacchettizzati tramite un flusso di lavoro approvato, ma SCEP è generalmente più facile da gestire su un parco dispositivi gestito e variegato perché il dispositivo può richiedere e rinnovare il proprio certificato. Il punto cruciale è la coerenza. Ogni piattaforma deve ricevere una catena e un certificato che la policy RADIUS sia in grado di comprendere.
Configurare il payload WiFi
Crea il profilo WiFi con l'esatto SSID, la modalità di sicurezza e il metodo EAP. Seleziona EAP-TLS, associa il profilo al certificato emesso dalla configurazione SCEP e abilita la convalida del certificato del server. Aggiungi i nomi esatti del server RADIUS in modo che un dispositivo non accetti un servizio simile durante la decisione di attendibilità. Le linee guida per la distribuzione nel Regno Unito allineate a Microsoft raccomandano una root attendibile, un profilo certificato client SCEP e nomi RADIUS precisi nel profilo WiFi (Guida alla configurazione WiFi con Entra ID).
Il campo che causa fallimenti ripetuti è la corrispondenza del certificato. Su Windows, macOS, iOS e Android, il profilo WiFi deve selezionare il certificato emesso dalla CA prevista e contenente l'EKU desiderato. Se il profilo viene distribuito ma il sistema operativo non riesce a selezionare tale certificato, il dispositivo potrebbe ripiegare su un metodo non idoneo o rifiutare la connessione.
Definisci l'ambito dei profili SCEP e WiFi per lo stesso gruppo di dispositivi pilota. Controlla i registri del dispositivo per l'installazione del certificato, conferma che la root sia attendibile, quindi ispeziona il certificato client selezionato prima di modificare la policy RADIUS. Un controllo dello stato del certificato, come questo SSL certificate checker, può aiutare a convalidare il lato del certificato pubblico, ma la risoluzione dei problemi EAP-TLS interna dipende ancora dai registri del dispositivo e di RADIUS.
Collegamento alla rete e al livello RADIUS
L'access point rileva un supplicant 802.1X. Non rileva Microsoft Entra ID. Il dispositivo presenta il suo certificato client, l'AP inoltra lo scambio EAP a RADIUS e il servizio RADIUS convalida la catena di certificati e applica la policy di rete.
Il flusso standard è:
- Il dispositivo si associa all'SSID enterprise.
- L'AP inoltra il traffico EAP-TLS a NPS, ClearPass, ISE o a un servizio RADIUS in hosting.
- Il RADIUS convalida il certificato client rispetto alla CA emittente fidata.
- Il motore dei criteri associa l'identità del certificato a un account, dispositivo o gruppo.
- La risposta RADIUS assegna la VLAN o la policy di accesso consentita.
Differenze di configurazione dei vendor
Le dashboard Meraki richiedono in genere i dettagli del server RADIUS, il shared secret e le impostazioni di validazione del certificato, con il controllo di override AAA utilizzato dove la risposta RADIUS controlla la segmentazione. Le implementazioni Aruba dipendono spesso da un gruppo di server RADIUS e da regole di derivazione del server. Ruckus SmartZone richiede la configurazione AAA con EAP-TLS selezionato, mentre i modelli WLAN di Juniper Mist puntano al cluster RADIUS. UniFi Network utilizza un profilo RADIUS e potrebbe richiedere una gestione attenta laddove il legacy EAP-TTLS coesiste con EAP-TLS.
Il servizio RADIUS-as-a-Service di Purple rappresenta un'opzione ospitata per le infrastrutture che desiderano un livello RADIUS separato senza gestire l'intera piattaforma server. NPS, ClearPass, ISE e i servizi ospitati possono essere tutti integrati, ma non interpreteranno ogni attributo del certificato o condizione della policy allo stesso modo.
| Fornitore | Server di autenticazione RADIUS | Tipo EAP | Attributo certificato | Errore comune |
|---|---|---|---|---|
| Meraki | NPS, ISE, ClearPass o RADIUS ospitato | EAP-TLS | Emittente e SAN | Il bypass AAA può inserire un utente valido nella VLAN errata |
| Aruba | NPS, ClearPass, ISE o RADIUS ospitato | EAP-TLS | SAN o UPN | L'ordine delle regole di derivazione del server può inviare il personale alla policy per gli ospiti |
| Ruckus | RADIUS connesso a SmartZone | EAP-TLS | Soggetto ed emittente | La mancata corrispondenza del tipo EAP è facile da trascurare nelle impostazioni AAA |
| Juniper Mist | Cluster RADIUS | EAP-TLS | SAN o identità mappata | Il modello WLAN potrebbe fare riferimento a un gruppo di server incompleto |
| UniFi | Profilo RADIUS dell'applicazione di rete | EAP-TLS o metodo legacy controllato | Identità del certificato | Metodi EAP misti possono oscurare il fallimento effettivo |
Su NPS, esamina le proprietà del certificato EAP-TLS e definisci se l'emittente, l'oggetto o il SAN fornisce la mappatura dell'account. Un errore frequente consiste nel presumere che il nome comune sia il nome utente quando il servizio RADIUS analizza il SAN come UPN. Ciò interrompe la mappatura degli utenti e può anche disturbare i flussi relativi ai soli dispositivi o ai dispositivi condivisi.
Utilizza un cluster RADIUS con bilanciamento del carico laddove l'infrastruttura richieda resilienza, e configura timer di failover sensibili per ogni SSID. Non dare per scontato che un servizio cloud RADIUS applichi la revoca in tempo reale. Alcune appliance ospitate non dispongono di una validazione CRL o OCSP raggiungibile, pertanto il certificato potrebbe continuare a essere accettato anche dopo la modifica di un account di directory.
Revoca istantanea e accesso condizionale per il WiFi del personale
La domanda difficile non è se un dispositivo possa registrarsi. È cosa succede dopo che le risorse umane disabilitano un account.
Il Conditional Access valuta gli accessi Entra supportati. Non interviene in una sessione 802.1X già stabilita per interromperla semplicemente perché lo stato della directory è cambiato. Un certificato già installato su un laptop può rimanere crittograficamente valido fino alla sua scadenza o fino a quando il servizio RADIUS non lo rifiuta tramite il controllo di revoca dei certificati. Questo rende il design di revoca più importante rispetto alla demo di registrazione.
Ridurre la finestra di validità del certificato
La prima misura di mitigazione è una durata breve del certificato. I profili Intune SCEP possono emettere certificati che si rinnovano regolarmente, limitando il tempo in cui un dispositivo dismesso può continuare a presentare una credenziale altrimenti valida. La finestra temporale appropriata dipende dal modello di minaccia, dalla disponibilità dei dispositivi e dalla tolleranza operativa. Una durata inferiore aumenta la dipendenza da un rinnovo affidabile, quindi è opportuno testare i dispositivi che trascorrono del tempo offline o che operano dietro reti limitate.
La seconda mitigazione è il controllo attivo della revoca. Pubblica una CRL raggiungibile o gestisci un OCSP, quindi conferma che i server RADIUS la consultino. Le configurazioni NPS e ClearPass possono sembrare funzionanti pur ignorando la revoca se il controllo è disabilitato o se il punto di distribuzione non è raggiungibile dalla rete RADIUS.
La misura operativa che conta è l'intervallo di tempo tra la disattivazione nella directory e il primo pacchetto wireless rifiutato.
I flussi di lavoro di disattivazione e cancellazione di Intune sono comunque preziosi, in particolare per i dispositivi smarriti o condivisi, ma non cancellano magicamente un certificato da un endpoint spento. Il certificato diventa inutilizzabile tramite scadenza, revoca o rimozione la volta successiva che il dispositivo riceve istruzioni di gestione. I team dovrebbero documentare questa finestra temporale e testarla durante le procedure di offboarding.
Entra Continuous Access Evaluation supporta decisioni di controllo rapide per scenari applicativi cloud selezionati. Al momento non rende l'EAP-TLS una transazione di Conditional Access in stile browser, quindi il WiFi dipende ancora dalla validità del certificato e dal comportamento di revoca RADIUS. Per i lettori che desiderano esaminare il modello di autenticazione più ampio, questa guida MFA per gli utenti di Edmonton fornisce un contesto utile su come una maggiore garanzia di accesso differisca dall'autenticazione tramite certificato di rete.
L'accesso guest richiede un proprio piano di controllo. Le pratiche del settore pubblico del Regno Unito, incluso GovWifi, confermano che i visitatori e l'accesso condiviso non dovrebbero essere forzati nello stesso flusso di lavoro dei certificati del personale (guida all'integrazione di Entra WiFi nel Regno Unito).
Test e risoluzione dei problemi relativi alle modalità di guasto comuni
Un test di laboratorio dimostra che un singolo dispositivo può connettersi. Un rollout di produzione dimostra che il dispositivo errato non può connettersi, che un certificato revocato viene rifiutato e che un ospite non può ereditare i criteri del personale.
Iniziare con il certificato
In caso di errore EAP-TLS, ispeziona il certificato client prima di modificare l'AP. Verifica la catena, l'emittente, il SAN, la scadenza e l'EKU di Client Authentication. Successivamente, controlla se il profilo WiFi seleziona tale certificato e se il dispositivo considera attendibile il certificato del server RADIUS.
I loop SCEP di solito indicano una mancata corrispondenza tra Intune, NDES e il modello di certificato. Verificare l'URL di verifica, confermare che l'account del connettore NDES disponga delle autorizzazioni del modello richieste e confrontare l'URI del profilo SCEP con l'URL NDES pubblicato, inclusa la barra finale. Un certificato emesso dal modello errato può sembrare una registrazione riuscita pur rimanendo inutilizzabile per il WiFi.
Testare il trust e la segmentazione
Un Evil Twin può trasmettere lo stesso SSID prima che avvenga la validazione del certificato. Configurate la validazione del certificato del server, specificate i nomi RADIUS previsti nel profilo WiFi di Intune e utilizzate le impostazioni di rete gestite in modo che il sistema operativo non si connetta liberamente a un impostore. Abilitate i Protected Management Frames dove i client e i dispositivi AP lo supportano, e utilizzate un SSID specifico dell'organizzazione anziché un nome generico.
Un certificato revocato che continua ad autenticarsi di solito indica un problema relativo al server RADIUS, non a Entra. Verifica che la validazione CRL sia abilitata, quindi conferma che la subnet RADIUS possa risolvere e raggiungere il punto di distribuzione. Se si utilizza OCSP, controlla il timeout e la raggiungibilità del responder anziché presumere che il servizio stia effettuando la verifica automaticamente.
La sovrapposizione tra reti guest e personale deriva spesso dall'ordine delle policy. Posiziona le regole EAP-TLS per il personale prima di quelle guest basate su PSK o MAC, quindi verifica gli attributi VLAN restituiti nel registro RADIUS. Un'autenticazione valida con una VLAN errata è un errore di policy, non un errore di registrazione.
Utilizzare un ordine di triage fisso
Le prime connessioni lente possono derivare dai tempi di rinnovo dei certificati, da endpoint di revoca non raggiungibili o dal sistema operativo che seleziona l'SSID errato. Non iniziare ricostruendo il profilo.
- Ispeziona il certificato del dispositivo: controlla catena, EKU, emittente, SAN e validità.
- Acquisisci lo scambio wireless: conferma che l'AP inoltri il traffico EAP alla destinazione RADIUS prevista.
- Leggi il registro degli eventi RADIUS: utilizza i registri NPS, i record degli eventi ISE o il tracciamento degli accessi ClearPass per identificare l'attributo rifiutato.
- Verifica lo stato di Intune: conferma che il dispositivo sia registrato, riceva i profili e rimanga all'interno del gruppo di assegnazione previsto.
- Verifica la policy restituita: conferma che le sessioni del personale e degli ospiti ricevano la VLAN e l'ACL corretti.
Questo ordine mantiene l'indagine guidata dalle prove. Modificare tre livelli contemporaneamente spesso nasconde il guasto originale.
Una checklist di implementazione in stile UK e i passi successivi
Gestite l'implementazione come una modifica controllata del servizio, non come un esperimento sui certificati. Iniziate con un piccolo gruppo di dispositivi rappresentativo dell'intera infrastruttura: un laptop Windows moderno, endpoint Apple, hardware Android, dispositivi condivisi e qualsiasi attrezzatura operativa che deve rimanere connessa. La reception di un hotel, il reparto di un ospedale e un negozio al dettaglio possono utilizzare tutti la stessa piattaforma di identità, ma avere requisiti di ripristino molto diversi.
La sequenza di implementazione
- Pianificazione del progetto pilota: Seleziona utenti, sedi e tipi di dispositivi rappresentativi, inclusi i siti con connettività debole o percorsi di gestione limitati.
- Idoneità della CA: Conferma la catena di emissione, i permessi del modello, l'EKU e gli endpoint di revoca prima di creare il profilo WiFi.
- Configurazione del profilo Intune: Crea la radice attendibile, il profilo certificato SCEP o PFX e il profilo WiFi EAP-TLS come set coordinato.
- Integrazione RADIUS: Aggiungi gli AP, i segreti condivisi, la fiducia dei certificati e le regole di mappatura delle identità alla piattaforma RADIUS selezionata.
- Ring-fencing dei dispositivi: Assegna i profili al gruppo pilota e mantieni il vecchio SSID disponibile come alternativa documentata.
- Rollout di massa: Espandi per sito o gruppo di dispositivi solo dopo il superamento dei test di emissione dei certificati, assegnazione della VLAN e offboarding.
- Frequenza di audit: Esamina le autenticazioni fallite, la scadenza dei certificati, la raggiungibilità della revoca e i risultati delle policy per il personale rispetto agli ospiti.
- Ritiro della PSK: Rimuovi gli SSID con chiave condivisa solo dopo che i team di supporto avranno un processo di emergenza testato e l'intero parco dispositivi sarà migrato.
I controlli specifici per il Regno Unito sono facili da trascurare. Conferma che i dispositivi BYOD Apple considerino attendibile la catena di emissione tramite il percorso di gestione previsto. Definisci come vengono ruotati i shared secret RADIUS, registra dove viene memorizzata la telemetria dei certificati per la revisione GDPR e allinea i log di autenticazione con i requisiti di audit PSN o specifici del settore dell'organizzazione. Gli ospedali e le proprietà condivise del settore pubblico necessitano inoltre di un SSID di emergenza documentato o di un processo di accesso alternativo che non si trasformi in una rete non gestita permanente.
Si prevede che le passkey diventeranno il metodo di autenticazione predefinito per l'accesso a Entra nel 2026, in base all'aggiornamento dell'ecosistema di Microsoft (Microsoft Entra passkeys update). Questo non rende inutile il lavoro svolto oggi su EAP-TLS. Le passkey gestiscono l'accesso interattivo all'identità, mentre il WiFi ha ancora bisogno di una credenziale di rete verificabile dalla macchina, di una decisione di policy e di uno scambio RADIUS. La CA, la gestione dei dispositivi e la disciplina delle policy create per i certificati rimangono fondamenta utili per il prossimo modello di identità.
Se la tua infrastruttura dipende ancora da una chiave condivisa o presuppone che Entra ID possa rispondere direttamente alle richieste RADIUS, documenta prima gli SSID correnti, l'autorità di certificazione, i gruppi di dispositivi e la policy RADIUS. Successivamente, avvia un progetto pilota di EAP-TLS con Intune su dispositivi rappresentativi del Regno Unito, testa la revoca prima di procedere all'estensione e mantieni l'accesso guest separato dall'identità del personale.
Purple fornisce una piattaforma RADIUS in cloud e WiFi basata sull'identità in grado di connettere l'accesso del personale supportato da Entra ID con le policy di rete in ambienti multi-vendor. Visita Purple per scoprire come le sue funzionalità di accesso guest e WiFi per il personale con certificati di livello enterprise possano adattarsi al tuo deployment nel Regno Unito.
