Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Executive Summary

Per le sedi aziendali — che si tratti di un dinamico ambiente Hospitality , di un'operazione Retail multi-sito o di un moderno campus aziendale — affidarsi a chiavi precondivise o a Captive Portal di base per il WiFi del personale rappresenta una vulnerabilità di sicurezza e un collo di bottiglia operativo. La moderna architettura di rete richiede l'autenticazione 802.1X tramite EAP-TLS, garantendo che ogni dispositivo sia verificato crittograficamente prima di accedere alla rete.

Tuttavia, la sfida risiede nella distribuzione: come distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza sommergere l'helpdesk di ticket di supporto? Microsoft Intune risolve questo problema attraverso la gestione automatizzata del ciclo di vita dei certificati. Sfruttando i profili di certificato SCEP (Simple Certificate Enrollment Protocol) o PKCS (Public Key Cryptography Standards), i team IT possono distribuire silenziosamente certificati root e client attendibili agli endpoint gestiti.

Questa guida fornisce un modello architetturale definitivo e una strategia di implementazione dettagliata per la distribuzione dei certificati WiFi di Intune. Esploreremo le differenze cruciali tra SCEP e PKCS, analizzeremo l'esatta sequenza di distribuzione richiesta per il successo e delineeremo strategie di mitigazione del rischio reali per garantire che il Guest WiFi e le reti aziendali rimangano sicuri e performanti.

Ascolta il podcast di approfondimento associato:

Approfondimento Tecnico: SCEP vs. PKCS

Durante la progettazione della strategia di distribuzione dei certificati WiFi di Intune, la prima decisione architetturale riguarda la selezione del meccanismo di distribuzione dei certificati. Intune supporta sia SCEP che PKCS, ma operano in modo fondamentalmente diverso.

SCEP (Simple Certificate Enrollment Protocol)

SCEP è lo standard di settore per la registrazione dei dispositivi aziendali. In un flusso di lavoro SCEP, il servizio Intune indica all'endpoint di generare la propria coppia di chiavi privata/pubblica. Il dispositivo crea quindi una richiesta di firma del certificato (CSR) e la invia tramite un server NDES (Network Device Enrollment Service) alla Certificate Authority (CA). La CA firma la richiesta e restituisce il certificato pubblico al dispositivo.

Il vantaggio cruciale in termini di sicurezza di SCEP è che la chiave privata non lascia mai il dispositivo. Viene generata localmente, memorizzata nell'enclave sicura del dispositivo (come il TPM su Windows o il Secure Enclave su iOS) e non viene mai trasmessa sulla rete. Questo rende SCEP l'approccio fortemente raccomandato per l'autenticazione 802.1X.

PKCS (Public Key Cryptography Standards)

Al contrario, con PKCS, l'Autorità di Certificazione genera sia la chiave pubblica che quella privata a livello centrale. Il Microsoft Intune Certificate Connector esporta quindi in modo sicuro questa coppia di chiavi e la distribuisce al dispositivo di destinazione.

Sebbene PKCS elimini la necessità di distribuire e gestire un server NDES — semplificando l'impatto sull'infrastruttura — introduce un rischio di sicurezza teorico poiché la chiave privata viene trasmessa sulla rete. PKCS è generalmente più adatto per i casi d'uso in cui è richiesto il deposito della chiave (key escrow), come la crittografia e-mail S/MIME, piuttosto che per l'autenticazione di rete.

Guida all'implementazione: La sequenza di distribuzione

La corretta configurazione di un profilo WiFi Intune per 802.1X richiede il rispetto rigoroso di una specifica sequenza di distribuzione. Le dipendenze del profilo Intune impongono che la relazione di attendibilità venga stabilita prima che sia possibile configurare l'autenticazione.

Passaggio 1: Distribuire il profilo del certificato radice attendibile

Prima che un dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione emittente.

1. Esporta il certificato della CA radice (e gli eventuali certificati della CA intermedia) come file .cer.
2. Nel centro amministrativo di Microsoft Endpoint Manager, vai su Dispositivi > Profili di configurazione > Crea profilo.
3. Seleziona la piattaforma di destinazione (ad es. Windows 10 e versioni successive) e scegli il tipo di profilo Certificato attendibile.
4. Carica il file .cer e distribuisci questo profilo ai gruppi di dispositivi di destinazione.

Regola empirica: Indirizza sempre gli stessi gruppi (Utenti o Dispositivi) in tutti i profili correlati per evitare discrepanze nella distribuzione.

Passaggio 2: Configurare il profilo del certificato SCEP

Una volta stabilita la relazione di attendibilità, configura il profilo SCEP per istruire i dispositivi su come ottenere il proprio certificato client.

1. Crea un nuovo profilo di configurazione e seleziona Certificato SCEP.
2. Configura il Formato del nome del soggetto. Per l'autenticazione gestita dall'utente, lo standard è CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo, utilizza CN={{AAD_Device_ID}}.
3. Imposta l'Utilizzo della chiave su Firma digitale e Crittografia della chiave.
4. In Utilizzo chiavi avanzato, specifica Autenticazione client (OID: 1.3.6.1.5.5.7.3.2).
5. Collega questo profilo al profilo del certificato radice attendibile creato al Passaggio 1.
6. Fornisci l'URL esterno del tuo server NDES.

Passaggio 3: Distribuire il profilo WiFi 802.1X

Il passaggio finale consiste nell'inviare la configurazione WiFi che associa i certificati al SSID di rete.

1. Crea un profilo di configurazione Wi-Fi.
2. Inserisci il Nome della rete (SSID) esattamente come viene trasmesso dai tuoi Wireless Access Points .
3. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza.
4. Imposta il Tipo EAP su EAP-TLS.
5. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato nel Passaggio 2 come certificato di autenticazione client.
6. Specifica il certificato Trusted Root per la convalida del server per garantire che il dispositivo si connetta esclusivamente al tuo server RADIUS legittimo.

Best Practice e Standard di Settore

Durante l'implementazione della distribuzione dei certificati Wi-Fi con Intune, attieniti alle seguenti best practice indipendenti dal fornitore per garantire conformità e affidabilità.

Posizionamento e Sicurezza del Server NDES

Il server NDES deve essere accessibile da Internet per consentire ai dispositivi remoti di eseguire il provisioning dei certificati prima di arrivare in sede. Tuttavia, esporre direttamente un server interno a Internet rappresenta un rischio di sicurezza significativo.

Raccomandazione: Pubblica l'URL NDES utilizzando Azure AD Application Proxy. Questo fornisce un accesso remoto sicuro senza aprire porte in entrata nel firewall e consente di applicare criteri di Accesso Condizionale al flusso di registrazione.

RADIUS e Controllo CRL

La distribuzione dei certificati è solo metà dell'equazione di sicurezza; la revoca è altrettanto fondamentale. Se un dipendente viene licenziato, la disattivazione del suo account Active Directory potrebbe non revocare immediatamente il suo accesso Wi-Fi se il suo certificato client rimane valido e il server RADIUS non controlla rigorosamente la Certificate Revocation List (CRL).

Raccomandazione: Configura il tuo Network Policy Server (NPS) o server RADIUS per imporre un controllo CRL rigoroso. Assicurati che i tuoi CRL Distribution Points (CDP) siano altamente disponibili; se il server RADIUS non riesce a raggiungere la CRL, l'autenticazione fallirà, causando un'interruzione diffusa del servizio.

Per ulteriori approfondimenti sulla progettazione di reti sicure, ti consigliamo di consultare The Core SD WAN Benefits for Modern Businesses .

Risoluzione dei Problemi e Mitigazione dei Rischi

Anche con una pianificazione meticolosa, la distribuzione dei certificati può riscontrare problemi. Di seguito sono riportati i casi di errore più comuni e le relative strategie di mitigazione.

Problema: Impossibile Applicare il Profilo Wi-Fi

Sintomo: Il dispositivo riceve i certificati Trusted Root e SCEP, ma il profilo Wi-Fi viene visualizzato come 'Errore' o 'Non applicabile' in Intune.

Causa principale: Questo problema è quasi sempre causato da una mancata corrispondenza nel targeting dei gruppi. Se il profilo SCEP è assegnato a un Gruppo Utenti, ma il profilo Wi-Fi è assegnato a un Gruppo Dispositivi, Intune non può risolvere la dipendenza.

Mitigazione: Verifica le tue assegnazioni. Assicurati che i profili Trusted Root, SCEP e Wi-Fi siano tutti distribuiti esattamente allo stesso gruppo Azure AD.

Problema: Errori NDES 403 Forbidden

Sintomo: I dispositivi non riescono a recuperare il certificato SCEP e i log IIS di NDES mostrano errori HTTP 403.

Causa principale: L'account di servizio Intune Certificate Connector non dispone delle autorizzazioni necessarie sul modello di certificato, oppure il filtraggio degli URL sul firewall sta bloccando i parametri specifici della stringa di query utilizzati da SCEP. Mitigation: Verificare che l'account del connettore disponga delle autorizzazioni 'Read' e 'Enroll' sul modello di CA. Controllare i log del firewall per assicurarsi che gli URL contenenti ?operation=GetCACaps non vengano bloccati.

ROI & Business Impact

Il passaggio alla distribuzione dei certificati Microsoft Intune 802.1X offre ritorni misurabili in termini di sicurezza e operatività.

1. Riduzione dei ticket di assistenza: Il WiFi basato su password genera un volume significativo di ticket di supporto (scadenze delle password, blocchi, errori di digitazione). L'autenticazione basata su certificati è invisibile all'utente, riducendo in genere il volume dell'helpdesk relativo al WiFi del 70-80%.
2. Miglioramento della sicurezza: EAP-TLS elimina il rischio di raccolta delle credenziali e di attacchi Man-in-the-Middle (MitM). Questo è fondamentale per la conformità a framework come PCI DSS e GDPR, in particolare negli ambienti Healthcare e retail.
3. Onboarding fluido: Per le organizzazioni che gestiscono grandi flotte di dispositivi Apple insieme a Windows, l'integrazione di Intune con i flussi di lavoro MDM esistenti (vedere la nostra guida su Jamf and RADIUS: Certificate-Based WiFi Authentication for Apple Device Fleets ) garantisce un'esperienza di provisioning unificata e zero-touch fin dal primo giorno.