Attendibilità server per profilo WiFi Intune: elenco di controllo dei nomi dei server certificati e della CA radice per Entra ID

Per stabilire l'affidabilità del server per il profilo WiFi di Intune con l'integrazione di Microsoft Entra ID, fai corrispondere i nomi dei server dei certificati al certificato del tuo server RADIUS. L'implementazione di questo standard IEEE 802.1X in oltre 80.000 sedi richiede il collegamento di un profilo di certificato attendibile contenente la CA radice allo stesso gruppo di Entra ID per evitare errori di handshake di autenticazione.

Cosa fa effettivamente la convalida del server in un profilo WiFi di Intune?

Un profilo WiFi aziendale in Intune è composto da due parti. La parte client dimostra l'identità del dispositivo. La parte server dimostra che la rete appartiene a te. La maggior parte delle implementazioni bloccate fallisce nella parte server, quindi questa guida tratta solo quella metà.

Prima di tutto, alcune definizioni. Lo standard IEEE 802.1X è lo standard di controllo dell'accesso basato su porta. Mantiene un dispositivo fuori dalla rete fino a quando un server RADIUS (Remote Authentication Dial-In User Service) non lo approva. Il protocollo EAP-TLS (Extensible Authentication Protocol con Transport Layer Security, RFC 5216) autentica entrambe le parti tramite certificati. Il protocollo PEAP (Protected EAP) racchiude uno scambio di password all'interno di un tunnel TLS.

In entrambi i metodi, il server RADIUS presenta prima il proprio certificato. Il dispositivo decide se considerarlo attendibile prima di inviare un certificato o una password.

Controlli e decisioni

Il dispositivo esegue due test sul certificato del server RADIUS:

• Catena di attendibilità. Il certificato fa capo a un'autorità di certificazione (CA) radice indicata nel profilo? In Intune, tale radice arriva sul dispositivo sotto forma di profilo di certificato attendibile.
• Identità. Il nome sul certificato corrisponde al campo dei nomi dei server dei certificati? Su Windows, iOS e macOS il campo ha quel nome. Su Android Enterprise corrisponde al campo del nome del server Radius.

Entrambi i test devono essere superati. Un certificato proveniente da una CA attendibile ma con il nome errato fallisce. Anche il nome corretto proveniente da una CA non in elenco fallisce. Questa associazione blocca un access point non autorizzato che presenta un certificato valido per il dominio di qualcun altro. Questo attacco sottrae le credenziali PEAP ai dispositivi che saltano la convalida.

Perché i guasti rimangono nascosti

Intune segnala se un profilo ha raggiunto il dispositivo. Non segnala se il dispositivo accetta il tuo server RADIUS. Un profilo può risultare installato correttamente anche se ogni handshake fallisce a livello di access point. Ti accorgi del problema solo quando il personale segnala che la rete non si connette.

Di cosa hai bisogno prima di iniziare?

Raccogli questi elementi prima di aprire Intune:

• Il certificato del server RADIUS attivo. Registra il nome comune (CN) del soggetto, ogni voce DNS del nome alternativo del soggetto (SAN), la data di scadenza, l'autorità intermedia emittente e la CA radice.
• Il certificato di ogni server RADIUS. I server primari e secondari spesso contengono certificati diversi. I dispositivi devono convalidarli entrambi.
• Il file del certificato della CA radice. Esportalo come file .cer. Lo caricherai in un profilo di certificato attendibile.
• Infrastruttura di certificati client per EAP-TLS. È necessario un profilo di certificato SCEP (Simple Certificate Enrollment Protocol) o PKCS e la CA che lo emette. Intune richiede anche un profilo di certificato attendibile per tale CA.
• Progettazione dei gruppi Entra ID. Decidi se ogni piattaforma si rivolge a gruppi di utenti o a gruppi di dispositivi. Mantieni questa scelta identica per ogni profilo collegato.
• Access point configurati per WPA2-Enterprise o WPA3-Enterprise. L'SSID deve puntare al server RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet supportano tutti lo standard 802.1X.
• Un gruppo pilota. Includi almeno un dispositivo Windows, uno Apple e uno Android.

Una distinzione importante riguarda il caso in cui gli access point raggiungono il server RADIUS tramite RadSec (RADIUS su TLS, RFC 6614). L'access point esegue il proprio controllo del nome del certificato su quella tratta. La configurazione Juniper Mist di Purple per SecurePass imposta un nome server RadSec jolly sotto il dominio di Purple. Carica inoltre un certificato RadSec a livello di organizzazione. Questo controllo si colloca tra l'access point e il server. Intune non lo tocca mai. Mantieni i due livelli separati durante la risoluzione dei problemi.

Come si configurano i nomi dei server dei certificati e la CA radice in Intune?

La documentazione di Intune di Microsoft contiene i passaggi dettagliati clic per clic. Le decisioni seguenti sono quelle che determinano il corretto funzionamento di tali passaggi.

Passaggio 1: leggere i nomi dal certificato presentato dal server

Leggi il certificato che il tuo server RADIUS presenta attualmente. Non fare affidamento sulla richiesta di certificato o sulle note di un collega. Un bilanciatore di carico, un nuovo nodo o un rinnovo recente possono modificare ciò che i dispositivi ricevono.

Idealmente, il CN e la prima voce DNS del SAN sono identici, ad esempio radius.contoso.com. Se utilizzi due server, scegli tra questi modelli:

• Assegna a ciascun server un proprio nome ed elenca entrambi i nomi nel profilo.
• Assegna a entrambi i server nomi con un suffisso condiviso, come radius1.contoso.com e radius2.contoso.com.

Passaggio 2: creare un profilo di certificato attendibile per la radice del server

Crea un profilo di certificato attendibile per piattaforma: Windows, iOS e iPadOS, macOS e Android Enterprise. Ciascuno contiene la CA radice che ha emesso il certificato del server RADIUS.

Gli errori più comuni che si verificano qui sono:

• Caricamento della CA emittente del client. Se i certificati SCEP provengono da una CA diversa rispetto al certificato RADIUS, sono necessari profili di certificato attendibili separati. Il campo di convalida del server deve fare riferimento alla radice del server.
• Caricamento dell'intermedia anziché della radice. Carica la radice. Configura il server RADIUS per inviare i suoi certificati intermedi durante l'handshake TLS, in modo che i dispositivi possano creare la catena completa.

Passaggio 3: completare i campi di convalida del server per piattaforma

• Windows: Aggiungere ciascun nome di server RADIUS sotto i nomi dei server dei certificati. Selezionare il profilo del certificato attendibile sotto i certificati radice per la convalida del server. Windows accetta più di un profilo radice.
• iOS, iPadOS e macOS: Inserire il nome sotto i nomi dei server dei certificati. La documentazione di riferimento del profilo di configurazione di Apple descrive questo campo come un elenco di nomi comuni dei certificati del server accettati, e sono accettati caratteri jolly come *.contoso.com. Selezionare il profilo del certificato attendibile come radice per la convalida del server.
• Android Enterprise: Inserire il nome DNS o il suffisso sotto il nome del server Radius. Le linee guida di Microsoft indicano di inserire solo il suffisso condiviso quando più server lo condividono. Selezionare il certificato radice per la convalida del server.

Passaggio 4: assegnare ogni profilo collegato allo stesso gruppo

Assegnare il profilo del certificato attendibile, il profilo SCEP o PKCS e il profilo WiFi allo stesso gruppo Microsoft Entra ID. Non inviare un profilo a un gruppo di utenti e un altro a un gruppo di dispositivi. Se il profilo del certificato attendibile non raggiunge mai un dispositivo, il profilo WiFi dipendente fallisce o non si installa mai.

Per il lato identità di un roll-out di Microsoft Entra ID, vedere come abilitare il single sign on.

Come ogni piattaforma applica il campo

Comportamento	Windows 10 e 11	iOS, iPadOS e macOS	Android Enterprise
Nome del campo Intune	Nomi dei server dei certificati	Nomi dei server dei certificati	Nome del server Radius
Con cosa viene confrontato	Nome DNS sul certificato del server	Nome comune del certificato del server	Nome DNS o suffisso sul certificato del server
Supporto dei pattern	Inserire ciascun nome completo del server	Carattere jolly, ad esempio *.contoso.com	Suffisso, ad esempio contoso.com
Impostazione radice	Profili dei certificati attendibili	Un profilo di certificato attendibile	Un profilo di certificato attendibile
Se il campo del nome viene lasciato vuoto	Windows potrebbe chiedere al personale di considerare attendibile il server	Il dispositivo potrebbe chiedere al personale di considerare attendibile il server	Android 11 e versioni successive rimuovono l'opzione per saltare la convalida
Cosa vede il personale in caso di mancata corrispondenza	La connessione fallisce senza alcuna richiesta	Messaggio "Impossibile accedere" o una richiesta di attendibilità	Problema di autenticazione visualizzato sulla voce di rete
Dove leggere l'errore	Registro operativo WLAN-AutoConfig	Console macOS, processo eapolclient	adb logcat, righe TLS del supplicant

Come si verifica se la convalida del server funziona?

Eseguire questi controlli su ciascun dispositivo pilota prima di ampliare l'assegnazione:

1. Stato del profilo. Confermare in Intune che il certificato attendibile, il certificato client e i profili WiFi mostrino tutti un esito positivo sul dispositivo.
2. Connessione live. Connettersi al SSID. Su Windows, netsh wlan show interfaces conferma la connessione e il metodo di autenticazione.
3. Accettazione lato server. Controllare il registro RADIUS per un Access-Accept relativo a quel dispositivo o account.
4. Test negativo. Reindirizza un SSID di test verso un server RADIUS il cui certificato ha un nome diverso. Il dispositivo deve rifiutarlo. Questo dimostra che la convalida viene applicata e non bypassata da una richiesta di attendibilità.
5. Registrazione della scadenza. Prendi nota della data di scadenza del certificato RADIUS e della sua root. Pianifica il rinnovo con largo anticipo.

Il test negativo è il passaggio che i team spesso saltano. Senza di esso, non è possibile distinguere un profilo che esegue la convalida correttamente da uno che considera attendibile qualsiasi certificato.

Cosa va storto e come si risolve?

Pattern di errore comuni

• Il nome errato nel campo. I team inseriscono un indirizzo IP, un hostname breve o il nome del bilanciatore di carico. Inserisci il nome stampato sul certificato stesso.
• La root errata. Il profilo fa riferimento alla CA emittente del client o a un'entità intermedia. Fai riferimento alla root che ha firmato la catena del certificato del server.
• Assegnazione non corrispondente. Il profilo WiFi è destinato a gruppi di utenti, mentre il profilo del certificato attendibile è destinato a gruppi di dispositivi. Allineali.
• Un'entità intermedia mancante. Il server RADIUS invia solo il suo certificato foglia. I dispositivi non possono ricostruire la catena, quindi lo rifiutano. Installa l'entità intermedia sul server.
• Un CN che differisce dal SAN. Apple confronta il common name. Un certificato con il SAN corretto e un CN diverso può essere accettato su Android e non superare il controllo su iPhone. Mantienili identici.

In che modo un certificato RADIUS rinnovato interrompe silenziosamente le connessioni

Un rinnovo che mantiene la stessa root e gli stessi nomi non cambia nulla sui dispositivi. Le connessioni proseguono normalmente.

Un rinnovo interrompe le connessioni quando cambia uno di questi elementi:

• La CA root. Il tuo provider emette il nuovo certificato da una root diversa. Ogni dispositivo fa ancora riferimento alla vecchia root.
• La catena intermedia. La nuova catena richiede un'entità intermedia che il server non invia.
• Il nome. Qualcuno riemette il certificato con un nuovo hostname o elimina il vecchio SAN.
• Un server in una configurazione multi-server. Solo il server secondario cambia, quindi gli errori sembrano casuali e intermittenti.

L'errore è silenzioso perché nulla cambia in Intune. Il profilo risulta ancora riuscito e i dispositivi conservano ancora la vecchia root.

I rinnovi stanno per diventare più frequenti. La votazione SC-081 del CA/Browser Forum riduce la durata massima dei certificati TLS pubblicamente attendibili. Il limite scenderà in modo significativo nei prossimi anni. Un server RADIUS con un certificato di una CA pubblica dovrà essere rinnovato più volte all'anno.

Le soluzioni eliminano la maggior parte dei rischi:

• Emetti il certificato RADIUS da una CA privata sotto il tuo controllo. La sua root può durare più a lungo di molti certificati server. I rinnovi con la stessa root sono invisibili ai dispositivi.
• Prepara qualsiasi modifica della root prima del rinnovo. Distribuisci innanzitutto la nuova root come profilo di certificato attendibile aggiuntivo. I profili Windows possono fare riferimento a entrambe le root durante il periodo di sovrapposizione. Sostituisci il certificato del server solo dopo che i dispositivi hanno registrato il nuovo profilo.

Leggere gli errori su ciascuna piattaforma

• Windows: Aprire il registro operativo Microsoft-Windows-WLAN-AutoConfig in Visualizzatore eventi. Gli errori di connessione appaiono lì con una motivazione. netsh wlan show wlanreport genera un report HTML delle sessioni recenti.
• macOS: Filtrare Console sul processo eapolclient. Gli errori di attendibilità TLS indicano il certificato che è stato rifiutato.
• iOS e iPadOS: Il dispositivo mostra un messaggio "Impossibile accedere" o una richiesta di attendibilità. Verificare i contenuti del profilo in Intune, quindi riprodurre l'errore su un Mac con lo stesso profilo per leggere i log.
• Android: La voce della rete mostra un problema di autenticazione. Su un dispositivo di test, adb logcat mostra righe supplicant che indicano l'errore di verifica del certificato.
• Server RADIUS: Un interscambio EAP che si avvia e poi si interrompe senza risposta da parte del client indica solitamente che il dispositivo ha rifiutato il certificato.

Scenari reali

Scenario 1: una catena di vendita al dettaglio effettua il rinnovo su una nuova radice. Una catena retail utilizzava PEAP per i terminali portatili del personale e le casse Windows. La sua CA pubblica ha rinnovato il certificato RADIUS a partire da una CA radice più recente. Tutti i dispositivi puntavano ancora alla vecchia radice e il mattino successivo nessun negozio riusciva a connettersi. Il team ha distribuito un profilo di certificato attendibile per la nuova radice allo stesso gruppo di dispositivi, quindi ha forzato una sincronizzazione da Intune. I negozi si sono riconnessi entro un singolo ciclo di controllo di Intune e il team ha successivamente spostato i certificati RADIUS su una CA privata. I successivi rinnovi non hanno più generato errori di connessione. Le proprietà del settore Retail con palmari e casse condividono questo tipo di esposizione.

Scenario 2: un hotel e il common name Apple. Un hotel ha distribuito iPad per il servizio di pulizia e tablet Android su un unico SSID EAP-TLS. Il certificato RADIUS emesso nuovamente manteneva il SAN corretto, ma il suo CN è tornato a essere l'hostname breve del server. I tablet Android hanno trovato corrispondenza con il suffisso DNS e si sono connessi. Gli iPad hanno rifiutato la connessione. L'emissione di un nuovo certificato con CN e SAN identici ha ripristinato la connessione su tutti gli iPad senza bisogno di toccare Intune. Gli Hotel che gestiscono flotte miste dovrebbero mantenere CN e SAN sempre allineati come standard.

Scenario 3: un centro congressi con assegnazioni suddivise. Un centro congressi del settore pubblico ha distribuito EAP-TLS su laptop Windows per il personale degli eventi. Il profilo WiFi era indirizzato a un gruppo di utenti, mentre il certificato attendibile e i profili SCEP erano indirizzati a un gruppo di dispositivi. Alcuni laptop non hanno mai ricevuto il profilo WiFi. Reindirizzare i profili a un unico gruppo di dispositivi ha risolto il problema di distribuzione. I laptop si sono connessi al successivo controllo.

Una volta superata la convalida, le disconnessioni rimanenti sono solitamente dovute a problemi di segnale radio o di roaming. Consultare la guida sulla risoluzione dei problemi di roaming nelle reti WLAN aziendali. Per i cambi di canale in ambienti affollati, consultare Eventi radar DFS su Cisco Meraki, HPE Aruba e Ruckus: una checklist diagnostica per i cambi di canale.

Checklist per flotte registrate in Microsoft Entra ID

1. Leggere il CN e ogni voce SAN DNS dal certificato presentato da ciascun server RADIUS.
2. Rendi il CN identico al nome DNS SAN primario.
3. Conferma che ogni server RADIUS invii i suoi certificati intermedi nell'handshake TLS.
4. Esporta la CA root che ha emesso il certificato del server, non l'intermedio.
5. Crea un profilo di certificato attendibile per quella root su ogni piattaforma che gestisci.
6. Mantieni la CA emittente del client nel proprio profilo di certificato attendibile separato.
7. Inserisci i nomi esatti dei server su Windows, un carattere jolly su Apple e il suffisso DNS su Android.
8. Assegna il certificato attendibile, SCEP o PKCS, e i profili WiFi a un unico gruppo Entra ID.
9. Utilizza lo stesso tipo di gruppo, utente o dispositivo, per ogni profilo collegato su una piattaforma.
10. Esegui il test negativo con un certificato server non corrispondente su ciascuna piattaforma.
11. Registra la data di scadenza e la root di ogni certificato RADIUS e verificali con largo anticipo rispetto alla scadenza.
12. Prepara qualsiasi nuova root come profilo di certificato attendibile aggiuntivo prima di sostituire il certificato del server.

Quali sono i costi e quali i vantaggi?

Intune è incluso in Microsoft 365 E3, E5 e Business Premium. La maggior parte delle flotte aziendali collegate a Entra ID possiede già la licenza. Una CA privata può essere eseguita su Active Directory Certificate Services in Windows Server. Microsoft Cloud PKI è disponibile come componente aggiuntivo di Intune con licenza separata.

Il costo principale è il tempo del personale. Ogni rinnovo non riuscito porta un'ondata di ticket di supporto in tutte le sedi contemporaneamente. La checklist sopra richiede poche ore per piattaforma ed elimina quell'ondata ricorrente.

Il ritorno è una rete senza chiavi condivise che possano essere trapelate. Per revocare l'accesso basta disattivare l'account o revocare il certificato. EAP-TLS supporta anche il requisito PCI-DSS v4.0 4.2.1.2, che richiede una crittografia forte sulle reti wireless collegate all'ambiente dei dati dei titolari di carta. Le sedi del settore Sanità e gli operatori dei Treni che gestiscono i dispositivi del personale beneficiano dello stesso controllo.

Purple Staff WiFi porta le reti basate sull'identità e il cloud RADIUS in questo modello. Funziona con Microsoft Entra ID, Okta e Google Workspace, in modo che i nuovi assunti, i trasferimenti e le dimissioni aggiornino automaticamente l'accesso alla rete. È agnostico rispetto all'hardware su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Purple è attivo in oltre 80.000 sedi reali e possiede le certificazioni ISO 27001 e Cyber Essentials.

Domande frequenti

L'autenticazione tramite certificato WiFi di Intune funziona con gli access point che già possediamo?

Sì. La convalida del server avviene tra il dispositivo e il server RADIUS, quindi l'access point deve solo supportare WPA2-Enterprise o WPA3-Enterprise. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet supportano tutti lo standard 802.1X. Purple Staff WiFi è indipendente dall'hardware e funziona come overlay cloud sulla struttura esistente. Non è necessario sostituire l'hardware per far passare il personale all'autenticazione basata su certificati.

Abbiamo bisogno di licenze Microsoft extra per distribuire i profili WiFi di Intune?

No, se possiedi già Microsoft 365 E3, E5 o Business Premium. Queste suite includono Intune, che copre i profili WiFi, i certificati attendibili e i profili SCEP o PKCS. Potrebbe essere necessario pagare separatamente per un'autorità di certificazione. Active Directory Certificate Services viene eseguito su Windows Server. Microsoft Cloud PKI è un componente aggiuntivo di Intune con licenza separata. Il server RADIUS rappresenta un costo separato, sia che si utilizzi Network Policy Server sia un servizio RADIUS in cloud.

Il certificato del server RADIUS deve provenire da una CA pubblica o privata?

Una CA privata è la scelta più sicura per la maggior parte dei parchi dispositivi. Ne controlli la root, quindi i rinnovi sotto tale root non interrompono mai l'attendibilità dei dispositivi. I certificati delle CA pubbliche si stanno accorciando in base al voto SC-081 del CA/Browser Forum. Ogni rinnovo pubblico comporta il rischio di una modifica della root o dell'intermedio che i dispositivi rifiuteranno fino a quando non avrai ridistribuito il profilo di attendibilità.

Possiamo migrare dalle password PEAP a EAP-TLS senza interrompere l'attività del personale?

Sì. Distribuisci il profilo del certificato SCEP o PKCS e il nuovo profilo WiFi EAP-TLS insieme al profilo PEAP esistente. Avvia un progetto pilota per un gruppo per piattaforma e conferma le connessioni nei registri RADIUS. Rimuovi il profilo PEAP una volta che ciascun gruppo si connette in modo affidabile. Le impostazioni di convalida del server, i nomi e la root, possono rimanere gli stessi per entrambi i metodi. Questo elimina la variabile più rischiosa dalla migrazione.

Cosa succede ai profili WiFi di Intune quando viene rinnovato il certificato RADIUS?

Nulla, a condizione che il certificato rinnovato mantenga la stessa CA root e gli stessi nomi. I dispositivi continuano a connettersi. Se la root, la catena intermedia, il CN o il SAN cambiano, i dispositivi rifiutano il server anche se Intune segnala ancora che il profilo ha avuto successo. Configura prima qualsiasi nuova root come profilo di certificato attendibile aggiuntivo. Conferma che i dispositivi l'abbiano ricevuta, quindi installa il certificato rinnovato sul server RADIUS.

Il WiFi per il personale basato su certificati aiuta con i requisiti PCI-DSS e GDPR?

Sì. Il requisito 4.2.1.2 di PCI-DSS v4.0 richiede una crittografia forte per le reti wireless connesse all'ambiente dei dati dei titolari di carta. EAP-TLS con convalida del server soddisfa questo requisito senza una chiave condivisa. Per il GDPR, l'autenticazione tramite certificato associa ogni sessione a un'identità nota, il che supporta la registrazione degli accessi e la revoca tempestiva. Purple possiede la certificazione ISO 27001 e Cyber Essentials, e la sua piattaforma è conforme al GDPR.

Quanto tempo occorre affinché le modifiche ai profili raggiungano i dispositivi?

La maggior parte dei dispositivi registrati riceve le modifiche al successivo controllo di Intune. Per i dispositivi Windows, iOS e Android, questo controllo viene eseguito periodicamente durante il giorno. È possibile forzare una sincronizzazione immediata da Intune o dal dispositivo stesso. Pianifica le modifiche alla root almeno con un intero ciclo di controllo di anticipo rispetto alla sostituzione del certificato RADIUS. I dispositivi spenti riceveranno l'aggiornamento al successivo controllo.