Risoluzione dei problemi 802.1X su iOS e macOS: una checklist di distribuzione per Intune, Jamf e Microsoft Entra ID

I dispositivi Apple non superano l'autenticazione 802.1X per quattro motivi principali. I nomi dei server attendibili o i certificati root di attendibilità nel payload WiFi non corrispondono al certificato RADIUS. Il certificato di identità è mancante o si trova nel portachiavi sbagliato. Un profilo macOS viene eseguito nella modalità errata, oppure il profilo è destinato al gruppo Entra ID sbagliato. I log di eapolclient e RADIUS mostrano quale di questi sia il problema.

Come si presenta un errore 802.1X su un iPhone o Mac?

I dispositivi Apple raramente forniscono un errore preciso. Il sintomo stesso è il primo indizio, quindi registralo esattamente prima di modificare qualsiasi profilo.

• L'iPhone rifiuta di connettersi a una rete EAP-TLS e richiede un nome utente e una password che non dovrebbero mai essere necessari. Il dispositivo non dispone di un certificato di identità utilizzabile, quindi ricorre a una richiesta di credenziali.
• Il Mac mostra una finestra di dialogo di attendibilità del certificato che indica il server RADIUS. Il profilo non blocca l'attendibilità del server (pinning) o consente all'utente di ignorare una mancata corrispondenza.
• Il Mac si connette dopo l'accesso ma non nella schermata di login. Di conseguenza, gli account di rete e gli sblocchi di FileVault falliscono sulle macchine condivise.
• Alcuni dispositivi funzionano e altri non rilevano mai la rete. Questo di solito indica un problema di ambito del gruppo, non di crittografia.
• Tutto ha funzionato per mesi, poi ha smesso di funzionare in una sola mattina. Questo scenario segue quasi sempre il rinnovo di un certificato RADIUS.

Cosa causa solitamente il fallimento di EAP-TLS o PEAP su iPhone e Mac?

L'attendibilità del server non corrisponde al certificato RADIUS

Il payload WiFi di Apple definisce l'attendibilità del server in due punti. I nomi dei certificati del server attendibili devono corrispondere al nome presente sul certificato del server RADIUS. I certificati attendibili devono includere la CA radice che lo ha emesso. Se uno dei due elementi è errato, il dispositivo interrompe l'handshake TLS.

Questo è il motivo per cui macOS chiede di considerare attendibile il certificato RADIUS. Senza un certificato root di attendibilità nel profilo, Apple affida la decisione all'utente. Con l'attendibilità definita e una mancata corrispondenza, la connessione fallisce invece in modo invisibile. La guida sull'attendibilità del server dei profili WiFi di Intune descrive in dettaglio le regole di denominazione.

Il certificato di identità è mancante o si trova nel portachiavi sbagliato

EAP-TLS richiede un certificato client e la relativa chiave privata sul dispositivo. Il payload WiFi deve fare riferimento a quel certificato, distribuito tramite un payload SCEP o PKCS. Su macOS, un profilo a livello di dispositivo installa i certificati nel portachiavi di sistema. Un profilo a livello di utente li installa nel portachiavi di login. Una rete configurata a livello di dispositivo non può accedere a un certificato presente nel portachiavi di login.

Le modalità di sistema, schermata di login e utente di macOS sono confuse

macOS supporta tre contesti 802.1X. La modalità di sistema si connette prima che chiunque acceda, utilizzando un certificato del computer. La modalità schermata di login utilizza le credenziali digitate nella finestra di accesso. La modalità utente si connette solo dopo l'accesso, con credenziali o un certificato associato a quell'account. Scegli la modalità che corrisponde al momento in cui il Mac ha bisogno della rete.

I profili hanno come destinazione il gruppo Entra ID sbagliato

La documentazione di Microsoft Intune suggerisce di assegnare il certificato attendibile, SCEP o PKCS, e i profili WiFi agli stessi gruppi. Se si assegna uno a un gruppo di dispositivi e un altro a un gruppo di account del personale, alcuni dispositivi riceveranno solo metà della catena. Gli iPad e i Mac condivisi senza un account principale non ricevono mai i profili destinati alle persone.

PEAP con account Entra ID solo cloud

PEAP-MSCHAPv2 necessita di un server RADIUS in grado di convalidare la password. Entra ID non ha un servizio RADIUS nativo, quindi gli account solo cloud di solito non possono eseguire l'autenticazione in questo modo. La maggior parte delle infrastrutture Entra ID sposta i dispositivi Apple a EAP-TLS per questo motivo.

Sintomo	Causa più probabile	Evidenza da cercare	Soluzione
Finestra di dialogo di attendibilità su Mac	Nessun ancoraggio del certificato attendibile nel profilo	eapolclient mostra un errore di valutazione dell'attendibilità	Aggiungi la root del RADIUS come payload del certificato attendibile
Errore silenzioso dopo il rinnovo del certificato	I nomi dei server attendibili non corrispondono più	RADIUS mostra l'avvio della sessione EAP, poi il client la abbandona	Aggiungi il nuovo nome del server e la root prima di effettuare la rotazione
Richiesta di password sulla rete EAP-TLS	Certificato di identità non consegnato	Nessun certificato client nel portachiavi	Assegna il profilo SCEP o PKCS allo stesso gruppo del profilo WiFi
Funziona dopo l'accesso, fallisce alla finestra di login	Profilo in modalità utente su un Mac condiviso	Il certificato si trova nel portachiavi di login	Distribuisci nuovamente a livello di dispositivo in modalità di sistema
Alcuni dispositivi non vedono mai la rete	Profili suddivisi tra gruppi di dispositivi e di account	Profilo mancante dall'elenco dei profili installati del dispositivo	Allinea tutti e tre i payload a un unico gruppo
Rifiuto del RADIUS che indica il certificato client	Il RADIUS non si fida della CA emittente	Il motivo del rifiuto cita la catena del client	Aggiungi la CA emittente all'elenco di attendibilità del RADIUS

Come capire qual è la causa del problema?

Procedi dal dispositivo verso l'esterno, in questo ordine.

1. Conferma che i profili siano arrivati. Controlla l'elenco dei profili installati sul dispositivo. Su un Mac, il comando sudo profiles show li elenca dal Terminale.
2. Conferma il certificato e la chiave privata. Apri Accesso Portachiavi su Mac e controlla il portachiavi di Sistema o di login in base al livello del profilo.
3. Leggi il log di eapolclient. Questo ti dice se il dispositivo ha rifiutato il server.
4. Leggi il log del RADIUS. Questo ti dice se il server ha rifiutato il dispositivo.

Dove si trovano i log 802.1X su macOS?

macOS affida il protocollo 802.1X a un processo chiamato eapolclient. Apri Console, seleziona il Mac, avvia lo streaming e filtra per il nome del processo eapolclient. Quindi riproduci l'errore. Da Terminale, il comando log show --predicate 'process == "eapolclient"' --last 1h estrae le stesse voci.

Cerca tre elementi: l'identità esterna inviata, il certificato del server presentato e il risultato della valutazione di attendibilità. Un errore di attendibilità in questa fase indica che il problema risiede nel payload WiFi. Per un iPhone o iPad, collegalo a un Mac e avvia lo streaming del suo log tramite Console.

Cosa mostra il log del RADIUS

Il log del RADIUS rappresenta l'altra metà della conversazione.

• Nessuna richiesta inviata. Il profilo non è presente, il nome SSID è errato o il dispositivo non ha mai raggiunto l'access point.
• La sessione EAP inizia ma non si completa mai. Il dispositivo ha rifiutato il certificato del server. Torna alle impostazioni di attendibilità.
• Un rifiuto esplicito. Il server ha rifiutato il dispositivo. Il motivo solitamente indica una catena client non attendibile, un account sconosciuto o una mancata corrispondenza dei criteri.

Come risolvere il problema in Intune e Jamf?

Entrambe le piattaforme forniscono i medesimi tre payload Apple, ma differiscono nel modo in cui ne definiscono l'ambito e il livello.

Attività	Microsoft Intune	Jamf Pro
Autorità di certificazione radice attendibile	Profilo certificato attendibile	Payload certificato nel profilo di configurazione
Certificato di identità	Profilo certificato SCEP o PKCS	SCEP o Payload certificato
Impostazioni di rete	Profilo WiFi (enterprise)	Payload WiFi (dispositivi mobili) o Payload di rete (computer)
Scelta del portachiavi Mac	Canale di distribuzione: portachiavi utente o dispositivo	Livello del profilo: computer o utente
Connessione alla finestra di login	Canale dispositivo con certificato computer	Profilo a livello di computer impostato per l'uso nella finestra di login
Destinatari	Gruppi Entra ID	Gruppi smart e gruppi statici

Intune

Verifica che il certificato attendibile, il certificato e i profili WiFi siano tutti destinati allo stesso gruppo Entra ID. Su macOS, imposta ogni profilo sullo stesso canale di distribuzione. Mischiare i portachiavi utente e dispositivo interrompe il riferimento al certificato. Nel profilo WiFi, inserisci ogni nome del server RADIUS nei nomi dei server dei certificati e seleziona la radice corrispondente. La guida alla distribuzione di Microsoft documenta dettagliatamente ciascun campo.

Jamf Pro

Integra i payload del certificato e di rete in un unico profilo a livello di computer per i Mac condivisi. Utilizza i profili a livello di utente solo quando il Mac appartiene a un singolo utente. Reindirizza l'impostazione del certificato di identità al payload SCEP o al payload del certificato nello stesso profilo. Per i dispositivi mobili, il payload WiFi offre i medesimi campi per i nomi dei server attendibili e per i certificati attendibili.

Specifiche per iPhone e iPad

iOS e iPadOS non dispongono di una modalità finestra di login. I problemi più comuni riguardano le mancate corrispondenze di attendibilità e l'assenza di certificati di identità. Gli iPad condivisi e senza utente richiedono una destinazione basata su gruppi di dispositivi, altrimenti non riceveranno mai il certificato.

Scenari reali

Un hotel da 200 camere dopo il rinnovo di un certificato RADIUS

Situazione. Un hotel da 200 camere ha distribuito iPhone gestiti tramite Intune al personale della reception e delle pulizie. Il certificato RADIUS è stato rinnovato con un nuovo nome host. Il mattino seguente, tutti gli iPhone del personale si sono disconnessi dalla rete.

Soluzione. I log equivalenti a eapolclient estratti da un iPhone collegato hanno mostrato che il dispositivo interrompeva l'handshake. I log di RADIUS hanno confermato sessioni avviate e mai completate. Il team ha aggiunto il nuovo nome host ai nomi dei server dei certificati e ha assegnato la nuova radice allo stesso gruppo. Risultato. I dispositivi si sono riconnessi man mano che ognuno sincronizzava il profilo aggiornato, e le autenticazioni fallite sull'SSID del personale sono scese a zero quel giorno stesso. Ora il team pubblica le modifiche attendibili una settimana prima di qualsiasi rinnovo. Scopri come gli hotel gestiscono le reti per il personale e gli ospiti sulla nostra pagina dedicata agli Hotel.

Un servizio bibliotecario comunale con Mac condivisi

Situazione. Un servizio bibliotecario del settore pubblico gestiva 60 Mac condivisi tramite Jamf Pro. Il profilo WiFi era a livello utente, quindi il certificato finiva nel portachiavi di login. Il nuovo personale non riusciva affatto ad accedere, perché i loro account di rete avevano bisogno prima della rete.

Cosa è stato fatto. Il team ha ricreato il profilo a livello di computer in modalità di sistema, con un certificato della macchina nel portachiavi di sistema.

Risultato. I Mac hanno effettuato l'accesso alla rete direttamente dalla finestra di login e i fallimenti al primo accesso sono cessati su tutte le 60 macchine. La stessa modifica ha sbloccato l'applicazione delle patch notturne, che in precedenza dipendeva anch'essa da una sessione con accesso già effettuato.

Come evitare che accada di nuovo?

La maggior parte delle interruzioni di rete Apple 802.1X sono autoindotte durante le modifiche. Una semplice disciplina previene quasi tutte.

• Definisci l'attendibilità in modo mirato. Specifica sempre i nomi dei server attendibili e una root attendibile, in modo che un eventuale disallineamento generi un errore evidente in fase di test anziché richiedere l'intervento del personale.
• Pianifica la rotazione dei certificati. Aggiungi il nuovo nome del server e la root al profilo prima di rinnovare il certificato RADIUS. Rimuovi quelli vecchi successivamente.
• Mantieni la catena in un unico gruppo. Il certificato attendibile, il certificato di identità e il profilo WiFi dovrebbero condividere sempre la stessa destinazione.
• Adatta la modalità al dispositivo. I Mac condivisi utilizzano la modalità di sistema. I Mac assegnati personalmente possono utilizzare la modalità utente.
• Effettua prima un progetto pilota. Distribuisci le modifiche al profilo a un piccolo gruppo di test di iPhone e Mac, e controlla i log di eapolclient e RADIUS prima del rilascio su larga scala.
• Automatizza la gestione di chi entra, cambia ruolo o esce. La revoca del certificato dovrebbe seguire la directory, non una coda di ticket.

Purple Staff WiFi offre tutto questo attraverso reti basate sull'identità (Identity-Based Networks). Il nostro cloud RADIUS collega l'accesso alla rete a Microsoft Entra ID, Okta o Google Workspace, in modo che l'accesso segua l'appartenenza ai gruppi. Purple è indipendente dall'hardware. Funziona su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Purple è certificato ISO 27001 e serve oltre 80.000 sedi attive (dati interni di Purple). Lo stesso approccio basato sull'identità si applica ai settori Retail, Sanità e Trasporti ferroviari.

Per le flotte Android, la lista di controllo per la risoluzione dei problemi di Android 802.1X ed EAP-TLS copre le verifiche equivalenti. Per l'accesso tramite directory, leggi Come abilitare il Single Sign-On.

Domande frequenti

Purple Staff WiFi funziona con i dispositivi gestiti da Intune e Jamf?

Sì, Purple Staff WiFi autentica i dispositivi Apple che ricevono i propri profili WiFi e certificati da Intune o Jamf Pro. La tua piattaforma di gestione dei dispositivi distribuisce i payload e il cloud RADIUS di Purple convalida la connessione rispetto a Microsoft Entra ID, Okta o Google Workspace. Mantieni i tuoi strumenti di gestione dei dispositivi esistenti. Purple gestisce l'autenticazione e lega l'accesso all'appartenenza ai gruppi, in modo che chi lascia l'azienda perda l'accesso quando il suo account di directory viene disabilitato.

Abbiamo bisogno di nuovi access point per gestire il WiFi del personale basato su certificati?

No, Purple è agnostico rispetto all'hardware e si posiziona sopra la tua rete esistente. Purple supporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. I tuoi access point devono supportare WPA2-Enterprise o WPA3-Enterprise e puntare a un server RADIUS esterno. Per SecurePass, verifica i requisiti Passpoint nel nostro articolo sulla Compatibilità dell'hardware e della sicurezza.

Dovremmo usare EAP-TLS o PEAP per iPhone e Mac su Entra ID?

Usa EAP-TLS. PEAP-MSCHAPv2 richiede un server RADIUS in grado di convalidare la password e Entra ID non ha un servizio RADIUS nativo per gli account solo cloud. EAP-TLS esegue l'autenticazione con un certificato che Intune o Jamf distribuiscono automaticamente, quindi nessuno deve digitare una password. Inoltre, elimina le richieste di credenziali, che sono una delle fonti più comuni di ticket di supporto 802.1X per Apple.

Possiamo migrare da una chiave pre-condivisa senza interrompere il lavoro del personale?

Sì, puoi eseguire il nuovo SSID 802.1X insieme alla tua rete con chiave pre-condivisa esistente durante la migrazione. Distribuisci prima il certificato attendibile, il certificato di identità e i profili WiFi a un gruppo pilota. Controlla i registri di eapolclient e RADIUS, quindi amplia la portata in fasi successive. Disattiva la rete con chiave pre-condivisa solo quando il RADIUS mostra che ogni gruppo di dispositivi si autentica con successo.

In che modo il WiFi basato su certificati influisce sul GDPR e sul trattamento dei dati?

Il WiFi basato su certificati riduce i dati personali che transitano sulla rete, poiché non viene trasmessa alcuna password. L'autenticazione si basa su un certificato del dispositivo e sull'appartenenza a un gruppo di directory. Purple è conforme al GDPR e possiede le certificazioni ISO 27001, Cyber Essentials e B Corp. Dovresti comunque registrare i log RADIUS conservati e il loro periodo di conservazione nella tua documentazione sulla protezione dei dati.

SecurePass sostituisce lo standard 802.1X per i dispositivi del personale?

No, SecurePass è progettato per i visitatori, non per i dispositivi aziendali del personale. Sostituisce i ripetuti accessi al captive portal con un profilo WiFi firmato digitalmente installato una sola volta in circa 30 secondi, utilizzando WPA2 o WPA3-Enterprise. Funziona insieme al tuo portale esistente. I dispositivi del personale dovrebbero utilizzare lo Staff WiFi con certificati distribuiti da Intune o Jamf. Consulta le FAQ di SecurePass per maggiori dettagli.