Distribuzione dei certificati WiFi Microsoft Intune tramite SCEP e PKCS

Distribuzione del certificato WiFi di Intune utilizza tre profili: un certificato radice attendibile, un certificato client SCEP o PKCS e un profilo WiFi 802.1X impostato su EAP-TLS. Distribuirli in quest'ordine, tutti assegnati allo stesso gruppo Microsoft Entra ID. SCEP crea la chiave privata sul dispositivo, mentre PKCS la crea a livello centrale. Per il WiFi su Windows, iOS e Android, scegliere SCEP.

Cosa fa concretamente la distribuzione del certificato WiFi di Intune?

Intune assegna a ogni dispositivo gestito il proprio certificato di identità e le impostazioni WiFi per presentarlo. Il dispositivo si connette quindi alla rete del personale senza che nessuno debba digitare una password.

Il meccanismo è IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porte. In base a 802.1X, l'access point tiene il dispositivo fuori dalla rete finché un server di autenticazione non lo approva. Tale server è un server RADIUS, il servizio interrotta dai tuoi access point prima di far accedere un dispositivo.

Il metodo di autenticazione è EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definito in RFC 5216. Entrambe le parti dimostrano la propria identità tramite certificati:

• Il dispositivo presenta un certificato client.
• Il server RADIUS presenta un certificato server.
• Ciascuna parte verifica che il certificato dell'altra sia collegato a un'autorità di certificazione (CA) di cui si fida.

Nessuna password viene digitata, memorizzata o esposta al phishing.

Questo aspetto diventa ogni anno più importante. Microsoft documenta che Windows Defender Credential Guard blocca il single sign-on per i metodi 802.1X basati su password come PEAP-MSCHAPv2. PEAP (Protected EAP) invia una password all'interno di un tunnel crittografato. Credential Guard è attivo per impostazione predefinita sulle build recenti di Windows 11 Enterprise e Microsoft raccomanda invece l'autenticazione basata su certificati.

Intune fornisce il WiFi basato su certificati tramite tre profili di configurazione:

• Profilo certificato attendibile. Installa la CA radice ed eventuali CA intermedie. Il dispositivo può così fidarsi della propria catena di certificati e del server RADIUS.
• Profilo certificato SCEP o PKCS. Rilascia a ciascun dispositivo un certificato client univoco.
• Profilo WiFi. Imposta l'SSID (il nome della rete trasmesso), il tipo di sicurezza e il metodo EAP. Specifica inoltre il certificato da presentare e il server di cui fidarsi.

Per i gestori delle strutture, questa è la componente della rete dedicata al personale. Laptop, dispositivi portatili e tablet del personale in Hotels, Retail e Healthcare devono accedere a sistemi che ospiti, acquirenti e pazienti non devono mai raggiungere. Il tuo Guest WiFi mantiene la sua Captive Portal, la pagina di accesso visualizzata dai visitatori. I dispositivi del personale si autenticano in background su un SSID e una VLAN separati, un segmento di rete logicamente isolato.

SCEP o PKCS: quale profilo di certificato dovresti usare?

Entrambi i profili rilasciano un certificato client sul dispositivo. La differenza risiede nel luogo in cui viene creata la chiave privata.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) fa generare al dispositivo la propria coppia di chiavi. Il dispositivo invia una richiesta di firma del certificato tramite un server Network Device Enrolment Service (NDES) o tramite PKI di Microsoft Cloud. La CA firma la richiesta e restituisce il certificato. La chiave privata non lascia mai il dispositivo. Su Windows, il profilo SCEP può posizionare quella chiave nel Trusted Platform Module (TPM), il chip di sicurezza hardware.

I profili PKCS utilizzano il Connettore di certificati per Microsoft Intune per richiedere il certificato alla tua CA. La coppia di chiavi viene creata all'esterno del dispositivo. Intune consegna quindi il certificato e la chiave privata al dispositivo in forma crittografata. Si evita di eseguire NDES, ma la chiave privata è esistita in un luogo diverso dal dispositivo.

Un terzo tipo, i certificati importati PKCS, consegna i certificati già in tuo possesso. Il suo compito abituale è la crittografia dell'email S/MIME, in cui le chiavi sono conservate in deposito fiduciario. È lo strumento sbagliato per il WiFi.

	SCEP tramite NDES e AD CS	SCEP tramite PKI di Microsoft Cloud	PKCS tramite connettore e AD CS
Dove viene creata la chiave privata	Sul dispositivo	Sul dispositivo	Fuori dal dispositivo, poi consegnata
Autorità di certificazione	La tua CA enterprise Active Directory Certificate Services (AD CS)	CA ospitate da Microsoft o la tua root	La tua CA enterprise AD CS
Server on-premise gestiti	CA, server NDES, Connettore di certificati	Nessuno	CA, Connettore di certificati
Componente esposto a Internet	URL NDES, pubblicato tramite il proxy di applicazione Microsoft Entra ID	Nessuno: Microsoft ospita l'endpoint SCEP	Nessuno: il connettore si collega solo in uscita
Licenza aggiuntiva	Nessuna oltre a Windows Server	Add-on Cloud PKI o Microsoft Intune Suite	Nessuna oltre a Windows Server
Impegno di configurazione	Più elevato: CA, NDES, connettore e pubblicazione proxy	Più basso: CA create nel centro di amministrazione Intune	Medio: CA e connettore, nessun NDES
A chi si adatta	Ambienti con AD CS che desiderano mantenere le chiavi sul dispositivo	Ambienti cloud-first senza PKI on-premise	Ambienti con AD CS che non possono pubblicare NDES

Per il WiFi, scegli SCEP a meno che tu non possa soddisfare i suoi requisiti di infrastruttura. Una chiave che non lascia mai il dispositivo non può essere copiata da un server o intercettata in transito. Scegli la PKI di Microsoft Cloud se non hai una PKI on-premise e non vuoi costruirne una. Scegli PKCS se utilizzi AD CS ma non puoi pubblicare un endpoint NDES su Internet.

Di cosa hai bisogno prima di distribuire i certificati WiFi con Intune?

Conferma ogni elemento prima di creare un singolo profilo. La maggior parte delle distribuzioni non riuscite è riconducibile a una mancanza in questo elenco.

• Licenze. Ogni persona necessita di una licenza Intune. Intune è incluso in Microsoft 365 E3, E5 e Business Premium, e in Enterprise Mobility + Security E3 ed E5.
• Dispositivi registrati. I dispositivi Windows sono associati a Microsoft Entra ID, spesso tramite Windows Autopilot. I dispositivi iOS e iPadOS sono registrati tramite la registrazione automatizzata dei dispositivi di Apple Business Manager. I dispositivi Android utilizzano Android Enterprise. Microsoft ha interrotto la gestione tramite amministratore del dispositivo per i dispositivi con Google Mobile Services, quindi pianifica l'uso di Android Enterprise.
• Un'autorità di certificazione (CA). Questo significa una CA enterprise AD CS, Microsoft Cloud PKI o una CA di terze parti supportata da Intune.
• Un modello di certificato. Su AD CS, pubblica un modello con l'Extended Key Usage Client Authentication.
• Infrastruttura dei connettori. SCEP su AD CS richiede un server NDES e il Certificate Connector for Microsoft Intune. PKCS richiede solo il connettore.
• Un server RADIUS che supporta EAP-TLS. Il suo certificato server deve fare capo a una radice che distribuirai. Registra il nome esatto presente su quel certificato, poiché il profilo WiFi ne ha bisogno.
• Revoca raggiungibile. Il tuo server RADIUS deve raggiungere la lista di revoca dei certificati (CRL) o un responder OCSP (Online Certificate Status Protocol). In caso contrario, l'autenticazione fallisce.
• SSID Enterprise. I tuoi access point devono trasmettere un SSID WPA2-Enterprise o WPA3-Enterprise puntato verso il tuo server RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet supportano tutti l'802.1X.
• Gruppi Entra ID. Crea un gruppo pilota e un gruppo di produzione. Decidi ora se conterranno utenti o dispositivi.
• Una rete di bootstrap. Un dispositivo ha bisogno di un accesso a Internet per raccogliere il suo certificato prima di potersi connettere all'SSID 802.1X. Configura un accesso cablato, dati mobili o un SSID di onboarding isolato. Gli operatori di Treni che distribuiscono tablet al personale di bordo dovrebbero configurarli in deposito, prima che i tablet entrino in servizio.

Come si configurano i certificati WiFi SCEP o PKCS in Intune?

La documentazione Intune di Microsoft contiene la procedura dettagliata campo per campo per ciascuna piattaforma. La sequenza e le decisioni riportate di seguito sono ciò che determina il successo. Crea un set di profili per ciascuna piattaforma: Windows, iOS/iPadOS e Android Enterprise.

Passaggio 1: distribuire il profilo del certificato radice attendibile

Esporta il certificato della tua CA radice come file .cer. Crea un profilo certificato attendibile che lo contenga. Ogni profilo certificato attendibile contiene un solo certificato, quindi crea profili distinti per la radice e per ciascuna CA intermedia.

Su Windows, invia la radice nell'archivio radice del computer e i certificati intermedi nell'archivio intermedio. Se una CA diversa ha firmato il certificato del tuo server RADIUS, distribuisci anche quella radice. Senza di essa, i dispositivi non possono convalidare il server.

Passaggio 2: distribuire il profilo del certificato SCEP o PKCS

Inizia con il tipo di certificato, poiché determina tutto il resto.

• I certificati dispositivo si adattano a dispositivi portatili condivisi, kiosk e laptop che devono connettersi alla schermata di accesso di Windows. Utilizza un Subject Name basato sull'identificatore del dispositivo, come CN={{AAD_Device_ID}}.
• I certificati basati sulla persona sono adatti a telefoni e laptop assegnati a un singolo membro dello staff. Utilizza CN={{UserPrincipalName}} nel soggetto. Aggiungi lo stesso valore come nome alternativo del soggetto, poiché molti server RADIUS leggono l'identità da lì.

Quindi imposta i campi rimanenti:

• Utilizzo chiave: firma digitale e cifratura chiave.
• Utilizzo chiave avanzato: Autenticazione client, OID 1.3.6.1.5.5.7.3.2.
• Dimensione chiave: minimo 2048 bit.
• Validità: non superiore a quanto consentito dal modello della CA.
• Soglia di rinnovo: il valore predefinito di Microsoft è il 20% della durata residua del certificato.
• Certificato radice: seleziona il profilo del certificato attendibile dal passaggio 1.
• Archiviazione chiavi su Windows: scegli l'opzione TPM per le chiavi supportate da hardware.

Per SCEP, inserisci l'URL NDES esterno o l'URI SCEP della tua PKI Cloud. Per PKCS, inserisci invece il nome della CA e il nome del modello.

Se utilizzi Microsoft NPS (Network Policy Server) con identità ibride, consulta l'articolo KB5014754 di Microsoft sulla mappatura forte dei certificati. Microsoft documenta un URI per il nome alternativo del soggetto che trasporta l'identificatore di sicurezza on-premises esattamente per questo caso.

Passaggio 3: distribuire il profilo WiFi 802.1X

Crea un profilo WiFi enterprise con queste impostazioni:

• Inserisci lo SSID esattamente come trasmesso dai tuoi access point.
• Imposta il tipo di sicurezza su WPA2-Enterprise, oppure WPA3-Enterprise dove i tuoi access point e la piattaforma lo supportano.
• Imposta il tipo EAP su EAP-TLS.
• Inserisci i nomi dei server dei certificati che corrispondono al nome presente sul certificato del tuo server RADIUS. Questo impedisce ai dispositivi di inviare la propria identità a un access point contraffatto.
• Seleziona il profilo del passaggio 1 come certificato radice per la convalida del server.
• Seleziona il profilo del passaggio 2 come certificato di autenticazione client.

Quali sono le differenze tra Windows, iOS e Android?

• Windows si connette con un certificato dispositivo prima dell'accesso di chiunque. Un certificato basato sulla persona si connette solo dopo l'accesso, interrompendo il primo accesso sui laptop condivisi.
• iOS e iPadOS considerano attendibile il server RADIUS facendo corrispondere i nomi dei server dei certificati inseriti. Una mancata corrispondenza genera un errore di attendibilità, non un ripiegamento silenzioso.
• Android Enterprise richiede un nome di dominio del server RADIUS e un certificato radice per la convalida. Le ultime versioni di Android hanno rimosso l'opzione per ignorare la convalida del server.

Cosa succede quando si registra un nuovo dispositivo?

Questa è la sequenza di distribuzione del certificato su un dispositivo appena registrato:

1. Il dispositivo si registra e viene inserito nel gruppo Microsoft Entra ID assegnato.
2. Intune fornisce i profili radice e intermedi attendibili.
3. Il dispositivo richiede il proprio certificato client. Con SCEP, genera una coppia di chiavi e invia una richiesta di firma con una challenge monouso. Il connettore convalida tale challenge con Intune prima che la CA emetta qualsiasi elemento. Con PKCS, il connettore richiede il certificato e Intune lo consegna.
4. Il dispositivo segnala il certificato installato a Intune.
5. Viene applicato il profilo WiFi, che dipende da entrambi i profili del certificato.
6. Il dispositivo presenta il suo certificato all'SSID. RADIUS convalida la catena, verifica la revoca e accetta il dispositivo. Può quindi assegnare una VLAN tramite gli attributi RADIUS.
7. Intune rinnova il certificato quando raggiunge la soglia di rinnovo. Intune lo revoca quando si dismette o si cancella il dispositivo, a condizione che il connettore detenga i diritti di revoca sulla CA.

Come verificare che i certificati WiFi di Intune funzionino?

Esegui un test con un pilota da 10 a 20 dispositivi per piattaforma prima di estendere le assegnazioni. Controlla quattro punti.

1. Stato del profilo Intune. Ciascuno dei tre profili deve riportare Riuscito per ogni dispositivo pilota. Uno stato di In attesa, Errore o Non applicabile su uno qualsiasi di essi blocca il profilo WiFi.
2. Il dispositivo stesso. Su Windows, apri l'archivio dei certificati personali e conferma la finalità Autenticazione client e la CA emittente. Su iOS e Android, conferma che il certificato e il profilo WiFi appaiano nel profilo di gestione e nelle credenziali del profilo di lavoro.
3. Log RADIUS. Cerca le autenticazioni EAP-TLS riuscite con il nome oggetto previsto. Su NPS, l'ID evento 6272 registra l'accesso garantito e l'ID 6273 registra l'accesso negato, con un codice motivo.
4. Log del connettore e NDES. Il Certificate Connector scrive nel registro eventi di Windows. Le richieste NDES appaiono nei log IIS.

Successivamente, testa la revoca intenzionalmente. Dismetti un dispositivo pilota in Intune e conferma che il certificato risulti revocato sulla CA. Pubblica la CRL e conferma che RADIUS neghi l'autenticazione successiva.

Cosa non funziona nei profili WiFi di Intune e come rimediare?

Il profilo WiFi mostra Errore o Non applicabile

I certificati sono arrivati, ma il profilo WiFi ha riscontrato un errore. La causa consueta è il targeting a gruppi misti. Ad esempio, il profilo SCEP è assegnato a un gruppo di persone mentre il profilo WiFi si rivolge a un gruppo di dispositivi. Intune non riesce a risolvere la dipendenza. La soluzione consiste nell'assegnare tutti e tre i profili allo stesso gruppo, o almeno allo stesso tipo di gruppo.

Il certificato SCEP non arriva mai

I log IIS NDES mostrano risposte HTTP 403 o 500. Verifica che l'account di servizio del connettore disponga delle autorizzazioni di Lettura e Iscrizione sul modello di certificato. Controlla che il firewall, il reverse proxy o l'application proxy non stiano rimuovendo le stringhe di query SCEP come operation=GetCACaps. Quindi conferma che l'URL NDES esterno sia risolvibile dall'esterno della rete.

Il dispositivo possiede un certificato, ma RADIUS lo rifiuta

Analizza quattro possibili cause in ordine:

1. I nomi dei server dei certificati nel profilo WiFi non corrispondono al certificato del server RADIUS.
2. Il server RADIUS non considera attendibile la CA che ha emesso il certificato client.
3. Il server RADIUS non riesce a scaricare una CRL aggiornata.
4. L'applicazione della mappatura forte NPS ai sensi della KB5014754 rifiuta i certificati privi di una mappatura forte.

Il codice motivo NPS indicherà quella corretta.

Le verifiche di revoca causano un'interruzione del servizio

Se il punto di distribuzione CRL va offline o la CRL scade, i server RADIUS restrittivi rifiutano qualsiasi certificato. Pubblica le CRL su una posizione HTTP ad alta disponibilità che il tuo server RADIUS possa raggiungere. Monitora l'ora di aggiornamento successivo della CRL.

I dispositivi continuano a connettersi alla vecchia rete

Un profilo legacy con chiave precondivisa o PEAP ancora presente sul dispositivo ha la priorità. Rimuovi il vecchio profilo tramite Intune una volta che quello nuovo segnala il successo, quindi dismetti il vecchio SSID.

Come funziona il WiFi basato su certificati Intune in una struttura reale?

I due scenari seguenti sono esempi pratici basati sul comportamento documentato da Microsoft. Descrivono tipologie di strutture, non distribuzioni specifiche.

Un gruppo di 12 hotel che elimina una password condivisa per il personale

Situazione. Un gruppo di 12 hotel, ciascuno di circa 200 camere, gestisce un unico SSID per il personale tramite chiave precondivisa. La chiave è condivisa da 840 dispositivi: PC della reception, iPhone del personale pulizie e palmari Android nel settore food & beverage. La rete è collegata all'ambiente dei dati dei titolari di carta. Il requisito PCI DSS v4.0 2.3.2 richiede quindi di modificare la chiave ogni volta che una persona che la conosce lascia l'azienda. Con il turnover del personale di reception, ogni rotazione blocca i dispositivi finché qualcuno non reinserisce la chiave.

Azione intrapresa. Il team distribuisce SCEP tramite NDES, pubblicato con il proxy applicativo di Microsoft Entra ID. I PC della reception ricevono certificati di dispositivo in modo da connettersi nella schermata di accesso. I telefoni ricevono certificati basati sulla persona. Un progetto pilota su 20 dispositivi viene eseguito in un hotel per due settimane. Successivamente, un hotel passa al nuovo sistema ogni settimana, mantenendo il vecchio SSID in parallelo.

Risultato misurabile. Dopo 12 settimane, tutti gli 840 dispositivi si autenticano con EAP-TLS e l'SSID con chiave precondivisa viene disattivato. Il numero di chiavi condivise da ruotare scende da una su 12 sedi a zero. L'accesso di chi lascia l'azienda ora termina con il ritiro del dispositivo e la ripubblicazione della CRL, anziché alla successiva rotazione della chiave.

Una catena di retail di 150 negozi con palmari condivisi

Situazione. Ogni negozio utilizza quattro palmari Android condivisi e due laptop Windows per il back-office, per un totale di 900 dispositivi. I palmari passano tra i membri del personale ad ogni turno, rendendo i certificati basati sulla persona privi di senso. Il servizio RADIUS cloud della catena non può raggiungere una CRL pubblicata solo sulla rete interna.

Azione intrapresa. La catena registra i palmari come dispositivi dedicati Android Enterprise e rilascia certificati di dispositivo tramite SCEP. Un solo profilo WiFi per piattaforma serve ogni negozio, poiché l'SSID è identico ovunque. La CRL viene spostata su un punto di distribuzione HTTP raggiungibile da Internet.

Risultato misurabile. Nessun palmare condiviso contiene una password WiFi. Il personale del negozio smette di chiedere la chiave dopo ogni modifica. Un palmare smarrito viene disattivato ritirandolo in Intune e il suo certificato fallisce all'autenticazione successiva non appena la CRL si aggiorna.

Quanto costa la distribuzione dei certificati WiFi con Intune e qual è il ritorno dell'investimento?

I costi

• Licenze. La maggior parte delle aziende possiede già Intune tramite Microsoft 365 o Enterprise Mobility + Security, quindi non ci sono nuovi costi per utente.
• Server. AD CS, NDES e NPS sono ruoli di Windows Server che non richiedono alcuna licenza separata oltre a Windows Server.
• PKI Cloud. Microsoft Cloud PKI è un componente aggiuntivo a pagamento, incluso anche in Microsoft Intune Suite. Valuta il suo costo rispetto alla creazione e alla manutenzione di una CA e NDES on-premise.
• Impegno. Il lavoro risiede nella progettazione della PKI, nella pubblicazione di NDES e nella fase pilota. I tre profili richiedono poche ore, non settimane.

Cosa ottieni in cambio

• Nessuna chiave WiFi condivisa. Ciò elimina la rotazione delle chiavi imposta dal requisito 2.3.2 del PCI-DSS sulle reti wireless connesse all'ambiente dei dati dei titolari di carta.
• Accesso revocabile per chi lascia l'azienda. La disattivazione di un dispositivo in Intune può revocarne il certificato, in modo che l'accesso WiFi segua il processo di gestione delle risorse umane (joiners, movers, leavers).
• Compatibilità con Credential Guard. EAP-TLS continua a funzionare dove Windows blocca il single sign-on 802.1X basato su password.
• Nessuna credenziale soggetta a phishing. Un certificato associato a un TPM non può essere digitato in una pagina di login falsa.
• Nessuna scadenza della password. I certificati si rinnovano automaticamente prima di scadere, eliminando il ripristino delle password come causa di ticket di supporto per il WiFi.

Pianifica la gestione del GDPR fin dall'inizio. I soggetti del certificato contenenti il nome di accesso di un dipendente costituiscono dati personali nei log RADIUS. Imposta un periodo di conservazione e limita l'accesso a tali log.

Purple gestisce il WiFi per il personale e il WiFi per gli ospiti affiancati in oltre 80.000 sedi attive (dati Purple). La piattaforma è indipendente dall'hardware ed è compatibile con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Purple è in possesso della certificazione ISO 27001. Le nostre reti basate sull'identità funzionano con Microsoft Entra ID, Okta e Google Workspace, in modo che l'accesso del personale segua la stessa fonte di identità della tua infrastruttura Intune. Per quanto riguarda i visitatori, le analisi WiFi forniscono report sulle connessioni degli ospiti separatamente dal traffico del personale.

Domande frequenti

Sono necessarie licenze aggiuntive per distribuire i certificati WiFi tramite Intune?

No, non per SCEP tramite NDES o per PKCS. Intune è incluso in Microsoft 365 E3, E5 e Business Premium, oltre che in Enterprise Mobility + Security E3 ed E5. Active Directory Certificate Services e NDES sono ruoli di Windows Server, pertanto richiedono solo le licenze Windows Server esistenti. L'unica eccezione è Microsoft Cloud PKI, un componente aggiuntivo a pagamento incluso anche in Microsoft Intune Suite. Includilo nel budget solo se desideri evitare la gestione di una CA on-premise.

Il WiFi basato su certificati di Intune funzionerà con gli access point esistenti?

Sì, a condizione che gli access point possano trasmettere un SSID WPA2-Enterprise o WPA3-Enterprise. EAP-TLS viene eseguito tra il dispositivo e il server RADIUS, mentre l'access point si limita a inoltrarlo secondo lo standard IEEE 802.1X. Purple è indipendente dall'hardware e funziona su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Mantieni l'hardware già in tuo possesso e modifichi solo le impostazioni di sicurezza dell'SSID.

È possibile passare da PEAP o da una password condivisa a EAP-TLS senza tempi di inattività?

Sì. Esegui il nuovo SSID 802.1X insieme a quello vecchio, oppure configura il tuo server RADIUS per accettare sia PEAP che EAP-TLS durante la transizione. Distribuisci prima i tre profili Intune a un gruppo pilota. Conferma le autenticazioni EAP-TLS riuscite nei log RADIUS, quindi amplia l'assegnazione a scaglioni. Rimuovi il profilo WiFi legacy solo dopo che quello nuovo segnala l'esito positivo, quindi dismetti il vecchio SSID.

È meglio scegliere SCEP o PKCS per il WiFi del personale?

Scegli SCEP. Con SCEP il dispositivo genera la propria chiave privata, che non lo lascia mai, e Windows può memorizzare tale chiave nel TPM. PKCS crea la chiave all'esterno del dispositivo e la distribuisce. Questo elimina il server NDES ma amplia i luoghi in cui la chiave è esistita. Scegli PKCS solo quando utilizzi Active Directory Certificate Services e non puoi pubblicare NDES, oppure utilizza Microsoft Cloud PKI per SCEP senza NDES.

È ancora necessario un server NDES?

Solo per SCEP con una CA Active Directory Certificate Services on-premise. Microsoft Cloud PKI fornisce un endpoint SCEP ospitato, quindi non è necessario eseguire alcun server NDES, connettore o CA on-premise. Anche i profili PKCS evitano NDES, poiché Certificate Connector for Microsoft Intune richiede certificati dalla CA tramite connessioni in uscita. Anche le autorità di certificazione di terze parti supportate da Intune possono emettere certificati SCEP senza NDES.

Con quale rapidità termina l'accesso WiFi quando qualcuno se ne va?

Con la rapidità consentita dalla tua pipeline di revoca. Quando dismetti o cancelli un dispositivo in Intune, Certificate Connector può revocare il relativo certificato sulla tua CA. L'accesso termina quando il server RADIUS rileva tale revoca, tramite una CRL aggiornata o un controllo OCSP. Riduci l'intervallo di pubblicazione della CRL o utilizza OCSP se la rimozione nell'arco della stessa ora è fondamentale. La sola disabilitazione dell'account potrebbe non bloccare un certificato valido a meno che RADIUS non verifichi anche la directory.

Il WiFi basato su certificati aiuta con PCI-DSS e GDPR?

Sì. Il requisito 2.3.2 di PCI-DSS v4.0 richiede che le chiavi wireless sulle reti connesse al cardholder data environment vengano modificate ogni volta che qualcuno che le conosce se ne va. I certificati per singolo dispositivo indicano che non esiste alcuna chiave condivisa da ruotare. Per il GDPR, tratta i soggetti dei certificati che contengono il nome di accesso di un dipendente come dati personali. Imposta un periodo di conservazione per i log RADIUS, limita l'accesso agli stessi e registra il trattamento.