Risoluzione dei problemi Android 802.1X ed EAP-TLS: una checklist di implementazione per Intune e Microsoft Entra ID

I telefoni Android gestiti di solito falliscono l'EAP-TLS per uno di quattro motivi. Il profilo WiFi non ha un certificato CA o un dominio, quindi Android rifiuta il server RADIUS. Il certificato client si trova in un profilo diverso. Il campo dei nomi del server RADIUS non corrisponde al certificato del server. Oppure il profilo root attendibile non ha mai raggiunto il dispositivo.

Che aspetto ha un fallimento EAP-TLS su Android?

L'EAP-TLS (Extensible Authentication Protocol con Transport Layer Security) autentica un dispositivo con un certificato invece che con una password. Funziona all'interno di IEEE 802.1X, lo standard di controllo dell'accesso basato su porta. L'802.1X affida l'autenticazione a un server RADIUS (Remote Authentication Dial-In User Service).

Quando questo processo fallisce su Android, in genere si nota uno di questi sintomi:

• La rete compare nell'elenco ma non supera mai lo stato "Connessione in corso", per poi tornare a "Salvata".
• Il dispositivo mostra un errore di autenticazione generico. La dicitura varia a seconda del produttore.
• La rete funziona sui telefoni Samsung ma non sui Google Pixel, o viceversa.
• La rete funziona sui telefoni aziendali ma fallisce sui dispositivi personali registrati con un profilo di lavoro.
• Non compare assolutamente nulla nei log del server RADIUS.

Quest'ultimo sintomo è il più importante. Un dispositivo che non raggiunge mai il server RADIUS presenta un problema di profilo, non un problema di autenticazione.

Cosa causa solitamente i fallimenti EAP-TLS su Android?

Validazione del server più severa nelle versioni recenti di Android

Le versioni recenti di Android hanno rimosso l'opzione "Non convalidare" per le nuove reti aziendali. Ora Android ha bisogno di due elementi prima di inviare il proprio certificato: un certificato CA da considerare attendibile e un dominio da verificare.

Senza entrambi, il dispositivo si rifiuta di completare l'handshake TLS. Profili che hanno funzionato per anni su build più vecchie possono fallire non appena un dispositivo riceve un aggiornamento del sistema operativo.

Certificato nel profilo di lavoro, connessione di rete avviata dal lato personale

Android Enterprise separa il profilo di lavoro da quello personale e ciascuno ha il proprio archivio certificati. Intune installa il certificato client e la root attendibile nel profilo di lavoro. Un dipendente che aggiunge manualmente l'SSID dalle impostazioni personali non può raggiungere tali certificati, di conseguenza l'autenticazione fallisce.

Il campo dei nomi del server RADIUS

Il profilo WiFi di Android Enterprise in Intune include un campo per i nomi del server RADIUS. La documentazione di Microsoft richiede il nome DNS presente nel certificato presentato dal server RADIUS. Android inserisce questo valore nel suo campo di dominio e lo confronta con il certificato del server. Se il campo è vuoto, contiene errori di ortografia o riporta un indirizzo IP, la convalida fallisce.

Il profilo root attendibile

Il profilo WiFi punta a un profilo di certificato attendibile di Intune separato. Tale profilo deve contenere la CA radice che ha emesso il certificato del server RADIUS. Un errore comune è quello di distribuire la root associata ai certificati client quando invece un'altra CA ha firmato il certificato del server. I due profili devono inoltre essere indirizzati agli stessi gruppi e allo stesso tipo di registrazione Android Enterprise.### Differenze tra i produttori

Samsung, Google Pixel e altri produttori etichettano e organizzano le impostazioni WiFi aziendali in modo diverso. Alcuni mostrano opzioni aggiuntive, come il controllo dello stato dei certificati online. Usa i dispositivi del tuo parco macchine come riferimento, non gli screenshot di un altro marchio.

Come capire qual è la causa del problema?

Inizia dal dispositivo, poi conferma nei log RADIUS. Il pattern nei log di solito indica la causa.

Sintomo	Cosa mostra RADIUS	Causa probabile	Primo intervento
Nessun tentativo raggiunge RADIUS	Nessuna richiesta dal dispositivo	Profilo WiFi non applicato o mancata corrispondenza del nome SSID	Verifica lo stato del profilo per singolo dispositivo in Intune
L'handshake si interrompe dopo che il server ha inviato il certificato	Avviso TLS dal client, come "CA sconosciuta"	Root attendibile errata o mancante, oppure mancata corrispondenza del dominio	Distribuisci la CA radice del server e i nomi corretti del server RADIUS
L'handshake si completa lato server, poi fallisce	Nessun certificato client presentato	Certificato SCEP o PKCS mancante o nel profilo errato	Conferma che il profilo del certificato sia andato a buon fine per quel dispositivo
Certificato accettato, poi rifiutato	Access-Reject dopo la convalida del certificato	Mappatura dell'identità, revoca o regola di policy	Verifica il soggetto del certificato o il SAN rispetto all'identity provider
Fallisce solo sui dispositivi personali	Nessuna richiesta o nessun certificato client	Accesso all'SSID effettuato dal profilo personale	Distribuisci il profilo nel profilo di lavoro e blocca gli accessi manuali

Leggere l'errore sul dispositivo

Nel centro di amministrazione di Microsoft Intune, apri il dispositivo e verifica lo stato di ciascun profilo di configurazione. Un profilo WiFi mostrato come in attesa o in errore non ha mai raggiunto il dispositivo. Un profilo di certificato in errore significa che l'emissione SCEP (Simple Certificate Enrollment Protocol) o PKCS (Public Key Cryptography Standards) è fallita. Risolvi questo problema prima di intervenire sulla rete.

Sui dispositivi di laboratorio, i log di Android Debug Bridge provenienti dal supplicant WiFi mostrano l'esatto avviso TLS. Usa questo metodo per un telefono di test, non per l'intera flotta di produzione.

Leggere i log RADIUS

FreeRADIUS, Microsoft Network Policy Server e le piattaforme RADIUS in cloud registrano tutti il punto in cui lo scambio EAP si è interrotto. Cerca in base all'indirizzo MAC del dispositivo o all'identità del certificato. Un avviso TLS inviato dal client significa che il telefono ha rifiutato il tuo server. Un messaggio di Access-Reject dopo un certificato valido significa che il tuo server ha rifiutato il telefono.

Se i dispositivi si autenticano e poi si disconnettono mentre il personale si sposta tra i piani, la causa è diversa. Leggi Resolving Roaming Issues in Corporate WLANs. Le disconnessioni che coincidono con i cambi di canale indicano invece eventi radar. Consulta DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Come risolvere il problema in Intune e su ogni build Android?

In Intune

1. Aprire il profilo Android Enterprise WiFi che corrisponde al tipo di registrazione. I dispositivi con profilo di lavoro completamente gestiti, dedicati e di proprietà aziendale utilizzano un tipo di profilo. I dispositivi con profilo di lavoro di proprietà personale ne utilizzano un altro.
2. Impostare il tipo EAP su EAP-TLS.
3. Inserire il nome DNS del certificato del server RADIUS in Nomi server RADIUS. Il nome esatto riportato sul certificato è il valore più sicuro. Non inserire mai un indirizzo IP.
4. Selezionare il profilo del certificato attendibile che contiene la CA radice del server.
5. Selezionare il profilo SCEP o PKCS per l'autenticazione del client.
6. Assegnare tutti e tre i profili allo stesso gruppo.

Su build Samsung, Pixel e altre

Non chiedere al personale di modificare manualmente le impostazioni aziendali su nessun marchio. Le modifiche manuali aggirano Intune e finiscono sul lato sbagliato del profilo di lavoro. Se un produttore non riesce e un altro funziona, confrontare prima lo stato del profilo. Successivamente, testare il valore del dominio rispetto a quella build nel proprio laboratorio.

Lato RADIUS

Confermare che il certificato del server contenga il nome DNS inserito in Intune. Confermare che la sua catena porti alla radice distribuita. Se si utilizza Purple Staff WiFi, Purple fornisce il servizio cloud RADIUS e si connette ai punti di accesso tramite RadSec, ovvero RADIUS trasportato all'interno di TLS. I passaggi per la configurazione del fornitore sono disponibili negli articoli di supporto di Purple, ad esempio Staff WiFi - Ubiquiti UniFi. Verificare i requisiti dei punti di accesso in Security and Hardware Compatibility.

Scenari reali

Un hotel da 200 camere dopo un aggiornamento Android

Si consideri un hotel da 200 camere con 60 dispositivi portatili di proprietà aziendale per il servizio di pulizia e manutenzione. Dopo un aggiornamento mensile, 40 dispositivi hanno smesso di connettersi al SSID del personale. I log di RADIUS mostravano avvisi TLS inviati dal client.

Il profilo WiFi non presentava alcun valore per i nomi dei server RADIUS, cosa che le build più vecchie tolleravano. Il team IT ha aggiunto il nome DNS del certificato del server e ha ridistribuito il profilo. Tutti i 60 dispositivi si sono connessi dopo il successivo controllo di Intune, senza necessità di ripristini di fabbrica. Gli operatori alberghieri possono trovare maggiori informazioni sulla connettività del personale sulla nostra pagina dedicata agli Hotel.

Una catena di vendita al dettaglio con 120 negozi e dispositivi personali

Si consideri una catena di retail con 120 negozi in cui i direttori dei punti vendita utilizzano telefoni personali registrati con un profilo di lavoro. I ticket di assistenza mostravano che i telefoni in molti negozi non raggiungevano mai il server RADIUS.

I direttori avevano aggiunto l'SSID del negozio dalle impostazioni personali, dove non esiste alcun certificato. Il team ha assegnato il profilo WiFi per i profili di lavoro di proprietà personale e ha istruito i direttori a rimuovere le voci manuali. I tentativi di connessione falliti sono cessati non appena ciascun telefono ha ricevuto il profilo gestito.

Un operatore ferroviario che rinnova il certificato del proprio server

Si consideri un operatore ferroviario che gestisce la WiFi per il personale a bordo e nei depositi (Treni). L'operatore ha rinnovato il certificato del server RADIUS da una nuova CA emittente. Tutti i dispositivi Android hanno smesso di funzionare durante la notte con avvisi di "CA sconosciuta". Il caricamento della nuova root nel profilo del certificato attendibile prima del passaggio avrebbe evitato il disservizio. Ora l'operatore programma le modifiche della root con due settimane di anticipo.

Come evitare che accada di nuovo?

Elenco di controllo per il roll-out delle flotte Android in Intune ed Entra ID

• Mappare le identità. Decidere se i certificati devono contenere l'ID del dispositivo o l'UPN del membro del personale, ovvero il nome di accesso di Microsoft Entra ID. Configurare il RADIUS in modo che corrisponda a quel campo.
• Separare per tipo di registrazione. Creare un set di profili per i dispositivi di proprietà aziendale e uno per i dispositivi con profilo di lavoro personale.
• Associare i profili. La root attendibile, il certificato client e i profili WiFi devono condividere lo stesso gruppo di assegnazione.
• Usare la root corretta. Distribuire la CA che ha firmato il certificato del server RADIUS.
• Compilare i nomi dei server RADIUS. Utilizzare il nome DNS presente nel certificato del server, mai un indirizzo IP.
• Effettuare un progetto pilota tra i vari produttori. Testare almeno un telefono Samsung e uno Pixel, oltre a qualsiasi altro marchio presente nella flotta.
• Vietare le connessioni manuali. Indicare al personale di non aggiungere mai l'SSID manualmente.
• Pianificare i rinnovi dei certificati. Distribuire le nuove root prima che il certificato del server cambi.
• Monitorare entrambi i lati. Verificare settimanalmente lo stato del profilo Intune e i rifiuti RADIUS durante il roll-out.

Per l'integrazione con l'identity provider, consultare Come abilitare il Single Sign On.

Domande frequenti

Purple Staff WiFi funziona con i dispositivi Android gestiti in Intune?

Sì. Purple Staff WiFi autentica i dispositivi Android gestiti con 802.1X basato su certificato rispetto al cloud RADIUS di Purple. Si continua a utilizzare Intune per la distribuzione del certificato e del profilo WiFi. Purple si collega a Microsoft Entra ID, Okta e Google Workspace per l'identità. I profili Intune puntano al certificato del server RADIUS di Purple anziché a un server locale. Le regole lato Android contenute in questa guida rimangono valide: sono necessari una root attendibile e un dominio corrispondente.

Ho bisogno di nuovi access point per eseguire EAP-TLS con Purple?

No. Purple è indipendente dall'hardware e funziona come overlay cloud sugli access point già in uso. Tra i vendor supportati figurano Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Ogni vendor richiede una configurazione RADIUS che punti a Purple. I passaggi per la configurazione si trovano negli articoli di supporto di Purple. Verificare i requisiti a livello di modello nell'articolo sulla compatibilità hardware e di sicurezza prima di iniziare.

Posso passare da un NPS locale al cloud RADIUS senza registrare nuovamente i dispositivi Android?

Sì, nella maggior parte dei casi è possibile. I dispositivi mantengono i certificati client esistenti se il nuovo servizio RADIUS considera attendibile la CA emittente. È sufficiente aggiornare il profilo root attendibile e i nomi dei server RADIUS in Intune per farli corrispondere al nuovo certificato del server. Configura queste modifiche al profilo prima di cambiare la destinazione RADIUS dell'SSID. In questo modo si eviteranno gli errori di "CA sconosciuta" descritti in questa guida durante la notte.

EAP-TLS è migliore di PEAP o iPSK per i dispositivi del personale?

Sì, per le flotte di dispositivi gestiti. EAP-TLS utilizza un certificato per dispositivo o identità, quindi non ci sono password condivise che possono essere trapelate. PEAP (Protected EAP) si affida a un nome utente e a una password all'interno di un tunnel TLS. iPSK (identity pre-shared key) fornisce a ciascun dispositivo o gruppo la propria chiave. iPSK è ideale per i dispositivi non gestiti che non possono contenere certificati. EAP-TLS è ideale per i telefoni gestiti tramite Intune.

Quali standard di conformità soddisfa Purple per i dati di autenticazione del personale?

Purple è certificato ISO 27001 e Cyber Essentials, ed è conforme a GDPR e CCPA. Lo standard 802.1X basato su certificati supporta il controllo degli accessi rigoroso richiesto da PCI-DSS sulle reti vicine ai dati dei titolari di carta. Purple possiede anche la certificazione B Corp. Se il tuo processo di approvvigionamento richiede copie dei certificati attuali, chiedi al tuo team di account.

Quanto tempo richiede l'implementazione di Android EAP-TLS?

La maggior parte del lavoro si concentrerà sulla PKI e su Intune, non sugli access point. Reindirizzare un SSID verso il RADIUS di Purple richiede solo una breve checklist del fornitore disponibile nel centro di supporto. La creazione di profili SCEP o PKCS, profili root attendibili e profili WiFi per ciascun tipo di registrazione richiede più tempo. Pianifica il tempo necessario per un progetto pilota che copra ogni produttore della tua flotta prima dell'implementazione su scala più ampia.