Microsoft Cloud PKI per WiFi: deployment dei certificati EAP-TLS con Intune e Entra ID

Sì. Microsoft Cloud PKI, l'autorità di certificazione ospitata nella suite Intune, emette certificati WiFi EAP-TLS per i dispositivi gestiti da Intune. Un profilo di certificato SCEP li richiede direttamente, quindi non è necessario alcun server NDES, connettore di certificati o CA on-premise. Il server RADIUS si fida della root Cloud PKI importata e verifica ogni certificato rispetto alla CRL pubblicata dal servizio.

Che cosa fa Microsoft Cloud PKI per l'autenticazione WiFi?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) è il metodo 802.1X in cui entrambe le parti dimostrano la propria identità tramite certificati. IEEE 802.1X è lo standard di controllo dell'accesso basato su porta alla base di WPA2 e WPA3-Enterprise. Il punto di accesso trasmette ogni tentativo di connessione a un server RADIUS, il server di autenticazione che accetta o rifiuta il dispositivo. Con EAP-TLS non c'è alcuna password da sottoporre a phishing né alcuna chiave condivisa da trafugare. Ogni dispositivo possiede la propria chiave privata e il proprio certificato.

La parte complessa è sempre stata la PKI (public key infrastructure) sottostante. Per distribuire i certificati sui dispositivi gestiti da Intune, tradizionalmente erano necessari quattro elementi:

• una CA di emissione Active Directory Certificate Services (AD CS)
• un server NDES (Network Device Enrollment Service)
• l'Intune Certificate Connector
• un reverse proxy o un proxy applicativo Microsoft Entra ID per pubblicare NDES su Internet

Ciascuno di questi elementi richiede patch, backup e monitoraggio.

Microsoft Cloud PKI sostituisce questo stack con un'autorità di certificazione ospitata nel tenant Intune. I dispositivi richiedono i certificati tramite SCEP (Simple Certificate Enrollment Protocol) e Cloud PKI risponde direttamente a tali richieste. Convalida ogni richiesta rispetto a Intune, firma il certificato e lo restituisce. Il dispositivo genera la propria chiave privata a livello locale e la chiave non lascia mai il dispositivo.

Per le flotte con l'addizione a Entra ID, questo elimina l'ultima dipendenza on-premise nella catena di certificazione. I dispositivi che non hanno mai visto un domain controller possono comunque ottenere un certificato WiFi.

Come funziona la gerarchia CA di Cloud PKI

Cloud PKI utilizza una gerarchia a due livelli. Una CA root firma una o più CA di emissione, e la CA di emissione firma i certificati dei dispositivi. Microsoft conserva le chiavi di firma della CA in moduli di sicurezza hardware (HSM), consentendo di non dover mai gestire direttamente il materiale delle chiavi.

È possibile scegliere tra due tipologie di ancoraggio:

• Cloud PKI root. Microsoft ospita sia la root che la CA di emissione nel tenant. Questa è l'opzione più semplice per un ambiente Entra ID nuovo.
• Bring your own CA (BYOCA). Si crea una CA di emissione Cloud PKI, si scarica la relativa richiesta di firma del certificato e la si firma con la CA root privata esistente, ad esempio una root AD CS. Qualsiasi elemento che già si fida di quella root si fiderà automaticamente della catena della nuova CA di emissione.

Imposti gli utilizzi chiave estesi (EKU) quando crei ciascuna CA. I certificati client WiFi richiedono l'EKU di autenticazione client, quindi includilo in entrambi i livelli. Pianifica attentamente questo passaggio, poiché gli EKU vengono fissati al momento della creazione della CA.

Un limite è importante per la progettazione. Cloud PKI rilascia certificati ai dispositivi gestiti da Intune tramite SCEP. Non è strutturato per rilasciare il certificato del tuo server RADIUS, quindi tale certificato proviene normalmente da una CA pubblica o dalla tua PKI esistente.

Confronto tra Cloud PKI, SCEP con NDES e PKCS

	Cloud PKI (SCEP)	SCEP con NDES	PKCS
Hosting CA	Ospitato da Microsoft nel tuo tenant Intune	La tua AD CS o CA di terze parti	La tua AD CS o CA di terze parti
Server on-premise	Nessuno	CA emittente, server NDES, host del connettore	CA emittente, host del connettore
Componente pubblicato su Internet	Nessuno	NDES, tramite reverse proxy o proxy applicativo	Nessuno
Dove viene generata la chiave privata	Sul dispositivo	Sul dispositivo	Lato CA, consegnata al dispositivo come PFX
Adatto ad ambienti solo Microsoft Entra ID	Nativo	Funziona, ma mantiene le dipendenze on-premise	Funziona, ma mantiene le dipendenze on-premise
Revoca	Revoca nell'Intune admin centre, pubblicata tramite CRL	Tramite il connettore e la CRL della tua CA	Tramite il connettore e la CRL della tua CA
Modello di licenza	Intune Suite o add-on Cloud PKI, per utente	Licenze Windows Server più Intune	Licenze Windows Server più Intune
A chi si adatta	Ambienti cloud-first che dismettono la PKI on-premise	Ambienti con un team AD CS consolidato e una roadmap CA a lungo termine	Casi che richiedono la stessa chiave su più piattaforme, come S/MIME

La nostra guida separata al deployment dei certificati Intune con SCEP e PKCS copre in dettaglio i due percorsi on-premise.

Di cosa hai bisogno prima di distribuire Cloud PKI per EAP-TLS?

Verifica questi sei elementi prima di creare qualsiasi cosa. Ciascuno corrisponde a un errore nella sezione di risoluzione dei problemi sottostante.

• Licenze. Un'abbonamento Intune Plan 1 più Microsoft Intune Suite o l'add-on Cloud PKI autonomo.
• Autorizzazioni. Il ruolo di Intune Administrator o un ruolo personalizzato con le autorizzazioni Cloud PKI.
• Dispositivi registrati. Dispositivi Windows, macOS, iOS/iPadOS o Android registrati in Intune, raggruppati in gruppi di sicurezza Microsoft Entra ID.
• Un server RADIUS compatibile con EAP-TLS. Deve consentirti di importare i certificati CA, raggiungere la CRL di Cloud PKI tramite HTTP e mappare le identità dei certificati agli oggetti Microsoft Entra ID. Microsoft NPS (Network Policy Server) cerca gli account in Active Directory on-premise, pertanto i dispositivi solo cloud non funzioneranno lì.
• Un certificato server RADIUS. Hai anche bisogno del certificato radice e di eventuali certificati intermedi che lo hanno rilasciato, poiché i dispositivi devono convalidare il server.
• Access point compatibili con 802.1X. Devono trasmettere un SSID WPA2-Enterprise o WPA3-Enterprise puntato al tuo server RADIUS.

Dal lato degli access point, tutte le principali piattaforme supportano l'802.1X. Questo include Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Per una guida dettagliata specifica per i singoli fornitori, consulta Configurazione di 802.1X su Juniper Mist con cloud RADIUS.

Come si configurano i certificati Cloud PKI per il WiFi?

La sequenza sottostante sintetizza la procedura di configurazione. Utilizza la documentazione Cloud PKI di Microsoft su Microsoft Learn per le schermate aggiornate e i passaggi dettagliati campo per campo, in quanto il layout del centro di amministrazione varia tra le diverse release.

Passaggio 1: crea la CA root o utilizzane una esistente

Nel centro di amministrazione di Intune, crea una CA root sotto l'amministrazione del tenant. Scegli la dimensione della chiave, il periodo di validità e gli EKU, inclusa la Client Authentication.

Per il modello BYOCA, salta la root. Crea la CA di emissione come tipo BYOCA ed esporta la relativa richiesta di firma del certificato (CSR). Firma la richiesta sulla tua CA privata utilizzando un modello che includa la Client Authentication, quindi carica il certificato firmato e la relativa catena.

Passaggio 2: crea la CA di emissione

Crea una CA di emissione ancorata alla root del passaggio 1. I suoi EKU devono includere la Client Authentication. Una volta creata, la sua pagina delle proprietà mostrerà tre elementi che ti serviranno in seguito:

• l'URI SCEP
• il download del certificato CA
• il punto di distribuzione CRL

Passaggio 3: distribuisci i profili di certificato attendibili

Scarica i certificati della CA root e della CA di emissione. Crea un profilo di certificato attendibile per ciascuno di essi, per ogni piattaforma. Assegnali ai medesimi gruppi che riceveranno i profili SCEP e WiFi.

I dispositivi hanno bisogno di questa catena prima che il profilo SCEP possa avere successo. Crea un ulteriore profilo di certificato attendibile per la CA che ha emesso il certificato del tuo server RADIUS, qualora i dispositivi non la ritengano già attendibile.

Passaggio 4: crea il profilo di certificato SCEP

Crea un profilo di certificato SCEP per ogni piattaforma e indirizzalo verso Cloud PKI. Le decisioni chiave sono le seguenti:

• URL del server SCEP. Incolla l'URI SCEP della CA di emissione esattamente come mostrato. Lascia il testo segnaposto inalterato, in quanto Intune lo risolverà al momento dell'emissione.
• Certificato root. Seleziona il profilo di certificato attendibile per la root Cloud PKI, non per la CA di emissione.
• Tipo di certificato. Scegli i certificati dispositivo per i dispositivi condivisi, come i tablet della reception o i palmari di negozio. Scegli i certificati personali dove il personale utilizza il proprio laptop e desideri che le policy siano legate al singolo utente.
• Subject e Subject Alternative Name (SAN). Includi un identificatore che il tuo server RADIUS possa mappare su Microsoft Entra ID. Alcuni esempi sono la variabile ID dispositivo Entra {{AAD_Device_ID}} o la variabile UPN {{UserPrincipalName}}.
• Uso della chiave ed EKU. Imposta Digital Signature e Key Encipherment, assieme a Client Authentication.
• Archiviazione chiavi su Windows. Registra nel provider di archiviazione chiavi TPM (Trusted Platform Module), in modo che la chiave privata sia vincolata all'hardware e non esportabile.
• Soglia di rinnovo. Imposta la percentuale di durata residua in cui Intune effettua il rinnovo, in modo che i certificati non scadano mai inosservati.

Passaggio 5: rendi il server RADIUS affidabile per Cloud PKI

Importa sia il certificato root di Cloud PKI che quello dell'autorità di certificazione (CA) emittente nello store delle CA attendibili del tuo server RADIUS. L'importazione della sola root è la causa più comune di rifiuto per "CA sconosciuta".

Abilita il controllo CRL e consenti al server RADIUS l'accesso HTTP in uscita al punto di distribuzione CRL indicato in ciascun certificato. Con BYOCA, il server RADIUS potrebbe già considerare attendibile la tua root, quindi aggiungerai solo il nuovo certificato della CA emittente.

Se il cloud RADIUS di Purple autentica il WiFi del tuo personale, il team del tuo account Purple confermerà come la catena Cloud PKI viene caricata per il tuo tenant.

Passaggio 6: crea il profilo WiFi

Crea un profilo WiFi in Intune con protezione enterprise ed EAP-TLS come tipo EAP. Imposta tre campi:

• Certificato di autenticazione client. Seleziona il profilo SCEP dal passaggio 4.
• Certificati root per la convalida del server. Seleziona il profilo del certificato attendibile per la root emittente del tuo server RADIUS.
• Nomi dei server dei certificati. Inserisci nomi che corrispondano esattamente al certificato del server RADIUS.

Assegna il profilo agli stessi gruppi dei profili SCEP e dei certificati attendibili.

Come funziona la revoca con Cloud PKI?

Puoi revocare i certificati Cloud PKI dalla CA emittente nell'interfaccia di amministrazione di Intune. Apri l'elenco dei certificati emessi, seleziona il certificato del dispositivo e revocalo. Cloud PKI pubblica quindi la modifica nel suo CRL (elenco di revoca dei certificati), che si trova nel punto di distribuzione HTTP integrato in ogni certificato emesso.

È il tuo server RADIUS ad applicare la revoca, non Intune. Scarica l'elenco CRL e rifiuta qualsiasi certificato il cui numero di serie compaia al suo interno.

La maggior parte dei server RADIUS conserva in cache un elenco CRL fino al successivo aggiornamento. Un dispositivo revocato può quindi continuare a connettersi fino a quando il server RADIUS non recupera un elenco aggiornato. Riduci questa finestra temporale in tre modi:

1. Revoca esplicitamente. Non fare affidamento sulla rimozione dell'assegnazione di un profilo o sull'eliminazione del record di un dispositivo. Revoca il certificato stesso come parte del processo aziendale di gestione degli accessi.
2. Associa la revoca ai controlli di identità. Se il tuo servizio RADIUS controlla lo stato dell'account Microsoft Entra ID o del dispositivo a ogni autenticazione, la disattivazione dell'account blocca l'accesso prima dell'aggiornamento della CRL.
3. Monitora il recupero della CRL. Imposta avvisi per i download di CRL non riusciti. Un server RADIUS che conserva una CRL non aggiornata continua ad ammettere dispositivi revocati o rifiuta qualsiasi dispositivo, a seconda della sua politica di gestione degli errori.

Come verificare che l'autenticazione WiFi con Cloud PKI funzioni?

Esegui un pilota con un gruppo di test da cinque a 10 dispositivi per ciascuna piattaforma supportata. Conferma cinque elementi:

1. Stato del profilo. Il certificato attendibile, il profilo SCEP e i profili WiFi mostrano tutti esito positivo nei report di configurazione dei dispositivi di Intune.
2. Certificato sul dispositivo. Su Windows, il certificato appare nello store personale con il subject, il SAN e l'EKU Client Authentication previsti. La sua catena dovrebbe risalire fino alla root della Cloud PKI.
3. Registro di emissione. Il certificato appare nell'elenco dei certificati emessi della CA emittente nel centro di amministrazione di Intune.
4. Log RADIUS. Il log di autenticazione mostra il successo dell'EAP-TLS, l'identità prevista e una catena valida.
5. Test di revoca. Revocare un certificato di test. Una volta che il server RADIUS acquisisce la nuova CRL, confermare che il dispositivo venga rifiutato.

Eseguire il test di revoca prima dell'entrata in funzione. È l'unico controllo che dimostra che il server RADIUS può raggiungere la CRL.

Cosa non funziona con Cloud PKI EAP-TLS e come risolverlo?

Sintomo	Causa probabile	Soluzione
Profilo SCEP bloccato in errore o in sospeso	Profili di certificato attendibili non assegnati allo stesso gruppo, oppure il profilo SCEP fa riferimento alla CA emittente anziché alla root	Assegnare i profili attendibili root ed emittente agli stessi gruppi e selezionare la root nel profilo SCEP
Certificato emesso, RADIUS rifiuta con "CA sconosciuta"	È stata importata solo la root in RADIUS	Importare anche il certificato della CA emittente
Ogni dispositivo viene rifiutato dopo l'entrata in funzione	RADIUS non riesce a raggiungere il punto di distribuzione della CRL e si blocca per sicurezza	Consentire il traffico HTTP in uscita da RADIUS verso l'host della CRL
I dispositivi Android rifiutano di connettersi	Nessuna convalida del server impostata; Android 11 e versioni successive la richiedono	Distribuire la root del server RADIUS come profilo attendibile e impostare i nomi dei server dei certificati
Windows chiede al personale di fidarsi del server	I nomi del server nel profilo WiFi non corrispondono al certificato RADIUS	Correggere i nomi del server per farli corrispondere esattamente al certificato
NPS rifiuta i dispositivi associati a Microsoft Entra ID	NPS cerca un account Active Directory on-premise che non esiste	Utilizzare un servizio RADIUS che mappa i certificati sugli oggetti Microsoft Entra ID
Il dispositivo revocato si connette ancora	RADIUS mantiene una CRL in cache	Associare la revoca alla disabilitazione dell'account o del dispositivo in Microsoft Entra ID e verificare il caching della CRL
Il certificato è privo di Client Authentication	CA emittente creata senza tale EKU	Creare una nuova CA emittente con Client Authentication e reindirizzare il profilo SCEP

Se i problemi si concentrano in stanze o piani particolari mentre gli stessi dispositivi si autenticano altrove, il guasto riguarda la copertura radio, non la PKI. L'EAP-TLS scambia più pacchetti rispetto a un handshake con chiave precondivisa, quindi un segnale debole si manifesta con timeout. WiFi Site Surveys: A Practical Planning Guide spiega come individuare tali coperture insufficienti.

Cloud PKI o SCEP con NDES: quale scegliere?

Basare la decisione su ciò che si sta già eseguendo e su ciò che si pianifica di dismettere.

La tua situazione	Raccomandazione	Perché
Parco dispositivi associato a Microsoft Entra ID, nessun AD CS	Cloud PKI con una root Cloud PKI	Nessuna PKI on-premise da creare o gestire
AD CS in place, NDES servers due for an OS refresh	Cloud PKI with BYOCA	Keeps your existing root trust and retires NDES and the connector
AD CS team with a long-term CA roadmap and other certificate templates	SCEP with NDES, review at the next server refresh	Existing investment already covers non-WiFi use cases
Need the same key pair on several devices, such as S/MIME	PKCS for that use case, Cloud PKI for WiFi	PKCS delivers exportable keys; WiFi certificates should stay device-bound
Hybrid-joined devices on NPS today, moving to Entra ID join	Cloud PKI plus a cloud RADIUS service	NPS lookups break once devices leave Active Directory

I settori regolamentati nella sanità mantengono spesso AD CS per altri carichi di lavoro. Per loro, BYOCA è di solito la soluzione ideale, perché mantiene un'unica radice di attendibilità in tutta l'organizzazione. Gli operatori ferroviari che emettono certificati per i tablet del personale a bordo dei treni tendono ad adattarsi al percorso Cloud PKI root. Tali dispositivi sono gestiti in cloud fin dal primo giorno.

Quanto costa Cloud PKI e cosa si ottiene in cambio?

Microsoft concede in licenza Cloud PKI per utente, al mese. Viene fornito all'interno della Intune Suite o come add-on autonomo, oltre a Intune Plan 1. È opportuno verificare il listino prezzi attuale di Microsoft, poiché le opzioni di bundle possono variare.

Questo costo va confrontato con i costi della soluzione on-premise:

• Licenze Windows Server e macchine virtuali per la CA di emissione, NDES e gli host del connettore
• Il reverse proxy o l'application proxy che pubblica NDES
• Backup del database della CA
• Patching e amministrazione dei modelli di certificato

Il ritorno sull'investimento consiste in un numero inferiore di server, nessun endpoint NDES pubblicato su Internet e chiavi vincolate al dispositivo su ogni piattaforma gestita.

Scenario pratico: un gruppo alberghiero di 30 strutture

Situazione. Un gruppo di 30 hotel gestiva 900 laptop e tablet per la reception registrati su Entra ID tramite un SSID aziendale protetto da un'unica chiave pre-condivisa. La rotazione trimestrale di tale chiave richiedeva un intervento su ogni dispositivo in ciascuna struttura. Un tablet smarrito lasciava la chiave esposta fino alla rotazione successiva.

Azione intrapresa. L'IT ha creato una root Cloud PKI e una CA di emissione, per poi distribuire certificati di dispositivo protetti da TPM tramite SCEP. Un servizio RADIUS in cloud convalidava la catena e verificava la CRL. Il gruppo ha attivato un SSID EAP-TLS affiancato a quello precedente per il progetto pilota, ha migrato le strutture a scaglioni e infine ha disattivato la rete basata su chiave pre-condivisa.

Risultato. Il calcolo dello scenario è immediato:

• I segreti condivisi sulla rete aziendale scendono da uno a zero.
• La rotazione trimestrale delle chiavi in 30 strutture viene completamente eliminata.
• Un tablet smarrito comporta la semplice revoca di un certificato anziché la riconfigurazione di 900 dispositivi.
• Nessun server CA, NDES o connettore on-premise è necessario.

Scenario pratico: una catena retail di 250 negozi

Situazione. Una catena retail ha rilasciato certificati WiFi a 4.000 dispositivi portatili e laptop dei negozi tramite AD CS e due server NDES. L'Intune Certificate Connector era in esecuzione su un terzo server. Tutti e tre i server dovevano essere sostituiti per aggiornamento del sistema operativo, e NDES era pubblicato tramite un application proxy.

Azione eseguita. Il team ha creato una CA emittente Cloud PKI come BYOCA e l'ha firmata con la root AD CS esistente. Il server RADIUS si fidava già di quella root, quindi è stato importato solo il nuovo certificato della CA emittente. I profili SCEP sono stati migrati a Cloud PKI un gruppo di negozi alla volta. I certificati esistenti sono rimasti validi fino al rinnovo, garantendo la possibilità di rollback.

Risultato. La catena ha dismesso tre server: due NDES e un host connector. Ha inoltre rimosso l'endpoint NDES pubblicato su Internet. Non è stato necessario riconfigurare la fiducia nella root sul server RADIUS o sui dispositivi. La root AD CS è rimasta attiva per altri carichi di lavoro.

Il ruolo di Purple

Purple Staff WiFi utilizza Identity-Based Networks con RADIUS cloud, collegato a Microsoft Entra ID, Okta o Google Workspace. Purple è indipendente dall'hardware ed è compatibile con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. L'articolo Perché il tuo prossimo aggiornamento WiFi non richiede nuovo hardware spiega perché il passaggio all'accesso del personale basato su certificati raramente comporta la sostituzione degli access point.

Purple è attivo in oltre 80.000 sedi operative (dati Purple) con un uptime del 99,999% ed è certificato ISO 27001. Mantieni il personale e i visitatori su reti separate: Staff WiFi basato su certificati per i dispositivi gestiti e Guest WiFi per tutti gli altri utenti.

Domande frequenti

Microsoft Cloud PKI può rilasciare certificati WiFi?

Sì. Cloud PKI rilascia certificati di autenticazione client a dispositivi Windows, macOS, iOS/iPadOS e Android gestiti da Intune tramite un profilo certificato SCEP. Tali certificati autenticano i dispositivi sulle reti WPA2-Enterprise o WPA3-Enterprise utilizzando EAP-TLS. La CA emittente deve includere l'EKU Client Authentication e il server RADIUS deve fidarsi della root Cloud PKI e della CA emittente. Di norma, Cloud PKI non rilascia il certificato proprio del server RADIUS. Quel certificato proviene da una CA pubblica o dalla PKI esistente.

Serve ancora NDES con Cloud PKI?

No. Cloud PKI gestisce direttamente le richieste SCEP, quindi non sono necessari server NDES, Intune Certificate Connector o reverse proxy per pubblicare NDES su Internet. Il profilo SCEP in Intune punta direttamente all'URI SCEP mostrato sulla CA emittente Cloud PKI. Se si utilizza l'opzione bring-your-own-CA, la root privata firma la CA emittente Cloud PKI una sola volta. Successivamente, la registrazione dei dispositivi non coinvolge più i server on-premise.

In che modo il server RADIUS si fida dei certificati Cloud PKI?

Importare i certificati CA radice e CA di emissione di Cloud PKI nell'archivio CA attendibili del server RADIUS. Scaricarli entrambi dall'Intune admin centre. Importare entrambi, poichè l'importazione della sola radice causa il rifiuto per "CA sconosciuta". Il server RADIUS necessita anche di un accesso HTTP in uscita al punto di distribuzione CRL in ciascun certificato, in modo da poter verificare la revoca. Per i dispositivi associati a Entra ID, deve mappare le identità dei certificati su Microsoft Entra ID anziché su Active Directory on-premise.

Come funziona la revoca con Cloud PKI?

È possibile revocare un certificato dalla CA di emissione nell'Intune admin centre, e Cloud PKI pubblicherà la modifica nella propria CRL. Il server RADIUS scarica tale CRL e rifiuta i certificati revocati. Poiché i server RADIUS memorizzano le CRL in cache, un dispositivo revocato potrebbe connettersi fino al successivo aggiornamento. È possibile colmare questo divario disabilitando anche l'account o il dispositivo Microsoft Entra ID, a condizione che il servizio RADIUS verifichi lo stato dell'identità a ogni autenticazione.

È meglio scegliere Cloud PKI o SCEP con NDES?

Scegliere Cloud PKI se si gestisce un parco dispositivi associato a Microsoft Entra ID o se si pianifica di dismettere i server PKI on-premise. Ciò elimina la CA di emissione, NDES e gli host dei connettori. Mantenere SCEP con NDES se si dispone di un team AD CS consolidato, di una pianificazione CA a lungo termine e di altri modelli di certificato. Se i server NDES devono essere aggiornati, Cloud PKI con BYOCA mantiene la fiducia nella radice esistente ed elimina comunque NDES.

Come viene concesso in licenza Microsoft Cloud PKI?

Cloud PKI viene concesso in licenza per utente, al mese, in aggiunta a Intune Plan 1. Viene fornito come parte di Microsoft Intune Suite o come componente aggiuntivo Cloud PKI autonomo. Verificare il listino prezzi aggiornato di Microsoft prima di definire il budget, poiché i pacchetti variano. Confrontare il costo della licenza con le licenze Windows Server, le macchine virtuali, la pubblicazione del proxy e l'impegno di patching richiesti da uno stack AD CS, NDES e connettori.

È possibile mantenere la CA radice on-premise esistente con Cloud PKI?

Sì, tramite l'opzione bring-your-own-CA. Si crea una CA di emissione Cloud PKI, si esporta la relativa richiesta di firma del certificato e la si firma con la CA radice privata esistente, come AD CS. Qualsiasi elemento che già considera attendibile quella radice, inclusi il server RADIUS e i dispositivi, considererà attendibile la nuova catena. È sufficiente aggiungere solo il certificato della CA di emissione. È possibile migrare i profili SCEP gruppo per gruppo, mentre i certificati esistenti rimangono validi fino al rinnovo.

Cloud PKI funziona con gli access point esistenti?

Sì, a condizione che gli access point supportino l'802.1X con WPA2-Enterprise o WPA3-Enterprise. Cloud PKI influisce solo sui certificati presenti sui dispositivi e sulla fiducia nel server RADIUS. Gli access point si limitano a inoltrare l'autenticazione al server RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet supportano tutti questa funzionalità. Staff WiFi di Purple funziona su tutti e otto come overlay cloud indipendente dall'hardware.