Microsoft Cloud PKI pour le WiFi : déploiement de certificats EAP-TLS avec Intune et Entra ID

Oui. Microsoft Cloud PKI, l'autorité de certification hébergée dans la suite Intune, délivre des certificats WiFi EAP-TLS aux appareils gérés par Intune. Un profil de certificat SCEP les demande directement, vous n'avez donc pas besoin de serveur NDES, de connecteur de certificat ni de CA sur site. Votre serveur RADIUS fait confiance à la racine Cloud PKI importée et vérifie chaque certificat par rapport à la CRL publiée par le service.

Que fait Microsoft Cloud PKI pour l'authentification WiFi ?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) est la méthode 802.1X dans laquelle les deux parties prouvent leur identité au moyen de certificats. L'IEEE 802.1X est la norme de contrôle d'accès basée sur les ports sous-jacente à WPA2 et WPA3. Le point d'accès transmet chaque tentative de connexion à un serveur RADIUS, le serveur d'authentification qui accepte ou rejette l'appareil. Avec EAP-TLS, il n'y a aucun mot de passe à hameçonner et aucune clé partagée à divulguer. Chaque appareil détient sa propre clé privée et son propre certificat.

La partie difficile a toujours été la PKI (infrastructure à clés publiques) sous-jacente. Pour obtenir des certificats sur des appareils gérés par Intune, il fallait traditionnellement quatre éléments :

• une CA d'émission Active Directory Certificate Services (AD CS)
• un serveur NDES (Network Device Enrollment Service)
• le connecteur de certificat Intune
• un reverse proxy ou un proxy d'application Microsoft Entra ID pour publier NDES sur Internet

Chacun d'eux nécessite des correctifs, des sauvegardes et un suivi.

Microsoft Cloud PKI remplace cette pile par une autorité de certification hébergée dans votre tenant Intune. Les appareils demandent des certificats via SCEP (Simple Certificate Enrollment Protocol), et Cloud PKI répond lui-même à ces demandes. Il valide chaque demande auprès d'Intune, signe le certificat et le renvoie. L'appareil génère sa clé privée localement, et la clé ne le quitte jamais.

Pour les parcs joints à Entra ID, cela élimine la dernière dépendance sur site de la chaîne de certification. Les appareils qui n'ont jamais vu de contrôleur de domaine peuvent tout de même obtenir un certificat WiFi.

Comment fonctionne la hiérarchie de la CA Cloud PKI

Cloud PKI utilise une hiérarchie à deux niveaux. Une CA racine signe une ou plusieurs CA d'émission, et la CA d'émission signe les certificats des appareils. Microsoft conserve les clés de signature de la CA dans des modules de sécurité matériels (HSM), de sorte que vous ne gérez jamais le matériel de clé.

Vous choisissez l'une des deux ancres :

• Racine Cloud PKI. Microsoft héberge à la fois la racine et la CA d'émission dans votre tenant. C'est l'option la plus simple pour un environnement Entra ID nouveau.
• Apportez votre propre CA (BYOCA). Vous créez une CA d'émission Cloud PKI, téléchargez sa demande de signature de certificat et la signez avec votre CA racine privée existante, telle qu'une racine AD CS. Tout ce qui fait déjà confiance à cette racine fait alors confiance à la chaîne de la nouvelle CA d'émission.

Vous définissez les usages étendus de clé (EKU) lorsque vous créez chaque AC. Les certificats clients WiFi nécessitent l'EKU Authentification client, vous devez donc l'inclure aux deux niveaux. Planifiez cela soigneusement, car les EKU sont fixes lors de la création de l'AC.

Une limite est importante pour la conception. Cloud PKI délivre des certificats aux appareils gérés par Intune via SCEP. Il n'est pas conçu pour délivrer le propre certificat de votre serveur RADIUS, ce certificat provient donc normalement d'une AC publique ou de votre PKI existante.

Comparaison de Cloud PKI avec SCEP avec NDES et PKCS

	Cloud PKI (SCEP)	SCEP avec NDES	PKCS
Hébergement de l'AC	Hébergé par Microsoft dans votre tenant Intune	Votre AD CS ou AC tierce	Votre AD CS ou AC tierce
Serveurs sur site	Aucun	AC d'émission, serveur NDES, hôte de connecteur	AC d'émission, hôte de connecteur
Composant publié sur Internet	Aucun	NDES, via un proxy inverse ou un proxy d'application	Aucun
Lieu de génération de la clé privée	Sur l'appareil	Sur l'appareil	Côté AC, délivrée à l'appareil sous forme de fichier PFX
Adapté aux parcs Microsoft Entra ID exclusifs	Natif	Fonctionne, mais conserve les dépendances sur site	Fonctionne, mais conserve les dépendances sur site
Révocation	Révocation dans le centre d'administration Intune, publiée par CRL	Via le connecteur et la CRL de votre AC	Via le connecteur et la CRL de votre AC
Modèle de licence	Intune Suite ou complément Cloud PKI, par utilisateur	Licences Windows Server plus Intune	Licences Windows Server plus Intune
À qui cela convient	Environnements cloud-first abandonnant la PKI sur site	Environnements avec une équipe AD CS expérimentée et une feuille de route AC à long terme	Cas nécessitant la même clé sur plusieurs plateformes, comme S/MIME

Notre guide séparé sur le déploiement de certificats Intune avec SCEP et PKCS couvre en détail les deux voies sur site.

De quoi avez-vous besoin avant de déployer Cloud PKI pour EAP-TLS ?

Vérifiez ces six éléments avant de créer quoi que ce soit. Chacun correspond à une défaillance dans la section de dépannage ci-dessous.

• Licences. Un abonnement Intune Plan 1 plus Microsoft Intune Suite ou le complément autonome Cloud PKI.
• Autorisations. Le rôle d'administrateur Intune, ou un rôle personnalisé avec les autorisations Cloud PKI.
• Appareils inscrits. Appareils Windows, macOS, iOS/iPadOS ou Android inscrits dans Intune, regroupés dans des groupes de sécurité Microsoft Entra ID.
• Un serveur RADIUS compatible EAP-TLS. Il doit vous permettre d'importer des certificats d'AC, d'atteindre la CRL Cloud PKI via HTTP et d'associer les identités de certificat aux objets Microsoft Entra ID. Microsoft NPS (Network Policy Server) recherche les comptes dans Active Directory sur site, de sorte que les appareils cloud uniquement y échouent.
• Un certificat de serveur RADIUS. Vous avez également besoin du certificat racine et de tous les certificats intermédiaires qui l'ont délivré, car les appareils doivent valider le serveur.
• Points d'accès compatibles 802.1X. Ceux-ci doivent diffuser un SSID WPA2-Enterprise ou WPA3-Enterprise pointant vers votre serveur RADIUS.

Du côté des points d'accès, toutes les plates-formes majeures prennent en charge 802.1X. Cela inclut Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Pour un guide étape par étape spécifique à un fournisseur, consultez Configuration de 802.1X sur Juniper Mist avec cloud RADIUS.

Comment configurer des certificats Cloud PKI pour le WiFi ?

La séquence ci-dessous résume les étapes de création. Utilisez la documentation Cloud PKI de Microsoft sur Microsoft Learn pour voir les écrans actuels et les instructions champ par champ, car la disposition du centre d'administration évolue entre les versions.

Étape 1 : créer l'AC racine, ou utiliser la vôtre

Dans le centre d'administration Intune, créez une AC racine sous l'administration du tenant. Choisissez la taille de la clé, la période de validité et les EKU, y compris l'authentification client.

Pour le BYOCA, sautez l'étape de l'AC racine. Créez l'AC d'émission en tant que type BYOCA et exportez sa demande de signature de certificat. Signez la demande sur votre AC privée à l'aide d'un modèle incluant l'authentification client, puis téléchargez le certificat signé et sa chaîne.

Étape 2 : créer l'AC d'émission

Créez une AC d'émission ancrée à l'AC racine de l'étape 1. Ses EKU doivent inclure l'authentification client. Une fois créée, sa page de propriétés affiche trois éléments dont vous aurez besoin plus tard :

• l'URI SCEP
• le téléchargement du certificat d'AC
• le point de distribution CRL

Étape 3 : déployer les profils de certificats approuvés

Téléchargez les certificats de l'AC racine et de l'AC d'émission. Créez un profil de certificat approuvé pour chacun, par plate-forme. Attribuez-les aux mêmes groupes qui recevront les profils SCEP et WiFi.

Les appareils ont besoin de cette chaîne avant que le profil SCEP ne puisse être appliqué avec succès. Créez un autre profil de certificat approuvé pour l'AC qui a émis le certificat de votre serveur RADIUS, si les appareils ne lui font pas déjà confiance.

Étape 4 : créer le profil de certificat SCEP

Créez un profil de certificat SCEP par plate-forme et pointez-le vers Cloud PKI. Voici les décisions clés :

• URL du serveur SCEP. Collez l'URI SCEP de l'AC d'émission exactement comme indiqué. Laissez le texte de remplacement intact, car Intune le résout lors de l'émission.
• Certificat racine. Sélectionnez le profil de certificat approuvé pour la racine Cloud PKI, et non l'AC d'émission.
• Type de certificat. Choisissez des certificats d'appareil pour les appareils partagés tels que les tablettes de réception ou les terminaux portables de magasin. Choisissez des certificats individuels lorsque le personnel utilise son propre ordinateur portable et que vous souhaitez que la politique soit liée à la personne.
• Sujet et nom alternatif du sujet (SAN). Incluez un identifiant que votre serveur RADIUS peut associer à Microsoft Entra ID. Par exemple, la variable d'ID d'appareil Entra {{AAD_Device_ID}} ou la variable UPN {{UserPrincipalName}}.
• Utilisation de la clé et EKU. Définissez la signature numérique et le chiffrement de la clé, avec l'authentification client.
• Stockage de la clé sur Windows. Effectuez l'inscription auprès du fournisseur de stockage de clés TPM (Trusted Platform Module), afin que la clé privée soit liée au matériel et non exportable.
• Seuil de renouvellement. Définissez le pourcentage de durée de vie restante à partir duquel Intune procède au renouvellement, afin qu'aucun certificat n'expire sans que vous ne le remarquiez.

Étape 5 : configurer le serveur RADIUS pour qu'il fasse confiance à Cloud PKI

Importez les certificats de l'autorité de certification (CA) racine et d'émission de Cloud PKI dans le magasin de CA de confiance de votre serveur RADIUS. L'importation de la racine seule est la cause la plus fréquente des rejets pour "CA inconnue".

Activez la vérification CRL et autorisez le serveur RADIUS à accéder en HTTP sortant au point de distribution CRL répertorié dans chaque certificat. Avec l'option BYOCA, il est possible que le serveur RADIUS fasse déjà confiance à votre racine ; vous n'ajoutez alors que le nouveau certificat de la CA d'émission.

Si le cloud RADIUS de Purple authentifie votre WiFi réservé au personnel, votre équipe de compte Purple vous confirmera comment la chaîne Cloud PKI est chargée pour votre environnement.

Étape 6 : créer le profil WiFi

Créez un profil WiFi Intune avec une sécurité entreprise et EAP-TLS comme type d'EAP. Renseignez trois champs :

• Certificat d'authentification client. Sélectionnez le profil SCEP de l'étape 4.
• Certificats racines pour la validation du serveur. Sélectionnez le profil de certificat de confiance pour la racine d'émission de votre serveur RADIUS.
• Noms des serveurs de certificats. Saisissez des noms qui correspondent exactement au certificat du serveur RADIUS.

Attribuez le profil aux mêmes groupes que les profils SCEP et de certificat de confiance.

Comment fonctionne la révocation avec Cloud PKI ?

Vous révoquez les certificats Cloud PKI depuis la CA d'émission dans le centre d'administration Intune. Ouvrez la liste des certificats émis, sélectionnez le certificat de l'appareil et révoquez-le. Cloud PKI publie ensuite la modification dans sa CRL (liste de révocation de certificats), qui se trouve au niveau du point de distribution HTTP intégré à chaque certificat émis.

C'est votre serveur RADIUS qui applique la révocation, et non Intune. Il télécharge la CRL et rejette tout certificat dont le numéro de série y figure.

La plupart des serveurs RADIUS mettent en cache une CRL jusqu'à sa prochaine heure de mise à jour. Un appareil révoqué peut donc continuer à se connecter jusqu'à ce que le serveur RADIUS récupère une nouvelle liste. Réduisez ce délai de trois manières :

1. Révoquez explicitement. Ne vous fiez pas à la suppression d'une attribution de profil ou à la suppression d'un enregistrement d'appareil. Révoquez le certificat lui-même dans le cadre de vos processus de gestion des arrivées, départs et changements de poste (JML).
2. Associez la révocation à des contrôles d'identité. Si votre service RADIUS vérifie le statut du compte Microsoft Entra ID ou de l'appareil lors de chaque authentification, la désactivation du compte bloque l'accès avant même le rafraîchissement de la CRL.
3. Surveillez la récupération des CRL. Créez des alertes en cas d'échec de téléchargement des CRL. Un serveur RADIUS conservant une CRL obsolète continue d'autoriser des appareils révoqués ou rejette tous les appareils, selon sa politique de gestion des défaillances.

Comment vérifier que l'authentification WiFi Cloud PKI fonctionne ?

Effectuez un test pilote avec un groupe d'essai de cinq à 10 appareils sur chaque plateforme que vous prenez en charge. Confirmez cinq points :

1. Statut du profil. Les profils de certificat de confiance, SCEP et WiFi indiquent tous un succès dans les rapports de configuration des appareils Intune.
2. Certificat sur l'appareil. Sur Windows, le certificat apparaît dans le magasin personnel avec le sujet, le SAN et l'EKU d'authentification client attendus. Sa chaîne doit remonter jusqu'à la racine Cloud PKI.
3. Registre d'émission. Le certificat apparaît dans la liste des certificats émis par l'AC émettrice dans le centre d'administration Intune.
4. Jounaux RADIUS. Le journal d'authentification affiche la réussite de l'EAP-TLS, l'identité attendue et une chaîne valide.
5. Test de révocation. Révoquez un certificat de test. Une fois que le serveur RADIUS a récupéré la nouvelle CRL, confirmez que l'appareil est rejeté.

Exécutez le test de révocation avant de passer en production. C'est le seul contrôle qui prouve que votre serveur RADIUS peut atteindre la CRL.

Quels sont les problèmes fréquents avec Cloud PKI EAP-TLS et comment les résoudre ?

Symptôme	Cause probable	Solution
Profil SCEP bloqué en erreur ou en attente	Les profils de certificats de confiance ne sont pas attribués au même groupe, ou le profil SCEP fait référence à l'AC émettrice au lieu de la racine	Attribuez les profils de confiance racine et émetteurs aux mêmes groupes, et sélectionnez la racine dans le profil SCEP
Certificat émis, RADIUS rejette avec « AC inconnue »	Seule la racine a été importée dans RADIUS	Importez également le certificat de l'AC émettrice
Tous les appareils rejetés après le passage en production	RADIUS ne peut pas atteindre le point de distribution de la CRL et se bloque par sécurité	Autorisez le flux HTTP sortant depuis RADIUS vers l'hôte de la CRL
Les appareils Android refusent de se connecter	Aucune validation du serveur définie ; Android 11 et versions ultérieures l'exigent	Déployez la racine du serveur RADIUS en tant que profil de confiance et définissez les noms de serveur de certificat
Windows demande au personnel de faire confiance au serveur	Les noms de serveur dans le profil WiFi ne correspondent pas au certificat RADIUS	Corrigez les noms de serveur pour qu'ils correspondent exactement au certificat
NPS rejette les appareils joints à Microsoft Entra ID	NPS recherche un compte Active Directory sur site qui n'existe pas	Utilisez un service RADIUS qui associe les certificats aux objets Microsoft Entra ID
L'appareil révoqué se connecte toujours	RADIUS conserve une CRL en cache	Associez la révocation à un compte Microsoft Entra ID ou à la désactivation de l'appareil, et vérifiez la mise en cache de la CRL
Le certificat n'a pas d'authentification client	AC émettrice créée sans cet EKU	Créez une nouvelle AC émettrice avec l'authentification client et pointez à nouveau le profil SCEP

Si les échecs se concentrent dans des pièces ou des étages particuliers alors que les mêmes appareils s'authentifient ailleurs, le problème vient de la couverture radio, pas de la PKI. L'EAP-TLS échange plus de paquets qu'une poignée de main à clé prépartagée, de sorte qu'un signal faible se traduit par des dépassements de délai. WiFi Site Surveys: A Practical Planning Guide explique comment détecter ces lacunes.

Cloud PKI ou SCEP avec NDES : lequel choisir ?

Basez votre décision sur ce que vous utilisez déjà et ce que vous prévoyez de retirer.

Votre situation	Recommandation	Pourquoi
Parc joint à Microsoft Entra ID, pas de AD CS	Cloud PKI avec une racine Cloud PKI	Pas de PKI sur site à concevoir ou à gérer
AD CS en place, serveurs NDES devant subir un renouvellement d'OS	PKI Cloud avec BYOCA	Conserve votre ancrage de confiance existant et met au rebut NDES et le connecteur
Équipe AD CS avec une feuille de route CA à long terme et d'autres modèles de certificats	SCEP avec NDES, examen lors de la prochaine mise à niveau des serveurs	L'investissement existant couvre déjà les cas d'usage hors WiFi
Besoin de la même paire de clés sur plusieurs appareils, comme S/MIME	PKCS pour ce cas d'usage, PKI Cloud pour le WiFi	PKCS fournit des clés exportables ; les certificats WiFi doivent rester liés à l'appareil
Appareils joints hybrides sur NPS aujourd'hui, migrant vers une jonction Microsoft Entra ID	PKI Cloud plus un service RADIUS cloud	Les recherches NPS échouent dès que les appareils quittent Active Directory

Les environnements réglementés dans le secteur de la santé conservent souvent AD CS pour d'autres charges de travail. Pour eux, l'option BYOCA est généralement la plus adaptée, car elle conserve une seule racine de confiance au sein de l'organisation. Les opérateurs ferroviaires délivrant des certificats aux tablettes du personnel à bord des trains optent plutôt pour la racine PKI Cloud. Ces appareils sont gérés via le cloud dès le premier jour.

Combien coûte la PKI Cloud et quels sont les bénéfices ?

Microsoft facture la PKI Cloud par utilisateur et par mois. Elle est disponible soit au sein d'Intune Suite, soit sous forme de module complémentaire indépendant, en plus d'Intune Plan 1. Consultez la liste des tarifs actuels de Microsoft, car les offres regroupées évoluent.

Comparez cela à ce que vous coûte l'option sur site :

• Licences Windows Server et machines virtuelles pour la CA d'émission, NDES et les hôtes connecteurs
• Le reverse proxy ou proxy d'application publiant NDES
• Sauvegardes de la base de données CA
• Application des correctifs et administration des modèles de certificats

Le bénéfice réside dans la réduction du nombre de serveurs, l'absence de point de terminaison NDES publié sur Internet et des clés liées aux appareils sur chaque plateforme que vous gérez.

Scénario concret : un groupe hôtelier de 30 établissements

Situation. Un groupe de 30 hôtels exploitait 900 ordinateurs portables et tablettes de réception joints à Microsoft Entra ID sur un SSID réservé au personnel, sécurisé par une seule clé partagée. Renouveler cette clé chaque trimestre nécessitait une intervention sur chaque appareil de chaque établissement. Une tablette perdue exposait la clé jusqu'au renouvellement suivant.

Ce qui a été fait. L'équipe informatique a créé une racine PKI Cloud et une CA d'émission, puis a délivré des certificats d'appareil protégés par TPM via SCEP. Un service RADIUS cloud a validé la chaîne et vérifié la CRL. Le groupe a déployé un SSID EAP-TLS en parallèle de l'ancien pour le projet pilote, a migré les établissements par vagues, puis a désactivé le réseau à clé partagée.

Résultat. La logique du scénario est simple :

• Les secrets partagés sur le réseau du personnel passent de un à zéro.
• La rotation trimestrielle des clés sur 30 établissements s'arrête totalement.
• Une tablette perdue entraîne une simple révocation de certificat au lieu d'une reconfiguraton des clés sur 900 appareils.
• Aucun serveur CA sur site, serveur NDES ou connecteur n'est requis.

Scénario concret : une chaîne de retail de 250 magasins

Situation. Une chaîne de vente au détail a émis des certificats WiFi à 4 000 terminaux portables et ordinateurs portables de magasin via AD CS et deux serveurs NDES. Le Intune Certificate Connector s'exécutait sur un troisième serveur. Les trois serveurs devaient subir un remplacement de système d'exploitation, et NDES était publié via un proxy d'application.

Ce qui a été fait. L'équipe a créé une AC d'émission Cloud PKI en tant que BYOCA et l'a signée avec l'AC racine AD CS existante. Le serveur RADIUS faisant déjà confiance à cette racine, seul le certificat de la nouvelle AC d'émission a été importé. Les profils SCEP ont été migrés vers Cloud PKI un groupe de magasins à la fois. Les certificats existants sont restés valides jusqu'à leur renouvellement, ce qui a préservé la possibilité de retour en arrière.

Résultat. La chaîne a retiré trois serveurs : deux NDES et un hôte de connecteur. Elle a également supprimé le point de terminaison NDES publié sur Internet. Aucune nouvelle approbation de la racine n'a été nécessaire sur le serveur RADIUS ou sur un quelconque appareil. La racine AD CS a été maintenue en place pour d'autres charges de travail.

Où se situe Purple

Purple Staff WiFi utilise des réseaux basés sur l'identité avec un serveur RADIUS cloud, connecté à Microsoft Entra ID, Okta ou Google Workspace. Purple est indépendant du matériel sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. L'article Pourquoi votre prochaine mise à niveau WiFi n'a pas besoin de nouveau matériel explique pourquoi le passage à un accès du personnel basé sur des certificats nécessite rarement le remplacement des points d'accès.

Purple fonctionne sur plus de 80 000 sites actifs (données Purple) avec une disponibilité de 99,999 %, et est certifié ISO 27001. Maintenez le personnel et les visiteurs sur des réseaux séparés : un WiFi réservé au personnel basé sur des certificats pour les appareils que vous gérez, et un WiFi invité pour tous les autres.

Foire aux questions

Microsoft Cloud PKI peut-il émettre des certificats WiFi ?

Oui. Cloud PKI émet des certificats d'authentification client vers les appareils Windows, macOS, iOS/iPadOS et Android gérés par Intune via un profil de certificat SCEP. Ces certificats authentifient les appareils auprès des réseaux WPA2-Enterprise ou WPA3-Enterprise à l'aide d'EAP-TLS. Votre AC d'émission doit inclure l'EKU d'authentification client, et votre serveur RADIUS doit faire confiance à l'AC racine et à l'AC d'émission Cloud PKI. Cloud PKI n'émet normalement pas le propre certificat du serveur RADIUS. Ce certificat provient d'une AC publique ou de votre PKI existante.

Ai-je encore besoin de NDES avec Cloud PKI ?

Non. Cloud PKI répond lui-même aux requêtes SCEP, vous n'avez donc besoin d'aucun serveur NDES, d'aucun Intune Certificate Connector et d'aucun reverse proxy publiant NDES sur Internet. Le profil SCEP dans Intune pointe directement vers l'URI SCEP affiché sur votre AC d'émission Cloud PKI. Si vous utilisez l'option Bring Your Own CA, votre racine privée signe l'AC d'émission Cloud PKI une seule fois. Après cela, l'enrôlement des appareils ne touche plus jamais vos serveurs sur site.

Comment le serveur RADIUS fait-il confiance aux certificats Cloud PKI ?

Vous importez les certificats d'autorité de certification (CA) racine et d'émission de la PKI Cloud dans le magasin d'AC de confiance du serveur RADIUS. Téléchargez les deux depuis le centre d'administration Intune. Importez les deux, car l'importation de la racine seule entraîne des rejets pour "CA inconnue". Le serveur RADIUS a également besoin d'un accès HTTP sortant vers le point de distribution CRL indiqué dans chaque certificat, afin de pouvoir vérifier la révocation. Pour les appareils joints à Microsoft Entra ID, il doit mapper les identités des certificats vers Microsoft Entra ID plutôt que vers Active Directory sur site.

Comment fonctionne la révocation avec la PKI Cloud ?

Vous révoquez un certificat depuis l'AC d'émission dans le centre d'administration Intune, et la PKI Cloud publie la modification sur sa CRL. Votre serveur RADIUS télécharge cette CRL et rejette les certificats révoqués. Comme les serveurs RADIUS mettent les CRL en cache, un appareil révoqué peut continuer à se connecter jusqu'au prochain rafraîchissement. Comblez cet écart en désactivant également le compte ou l'appareil Microsoft Entra ID, à condition que votre service RADIUS vérifie le statut de l'identité lors de chaque authentification.

Dois-je choisir la PKI Cloud ou SCEP avec NDES ?

Choisissez la PKI Cloud si vous gérez un parc d'appareils joints à Microsoft Entra ID ou si vous prévoyez de retirer vos serveurs PKI sur site. Elle élimine l'AC d'émission, NDES et les hôtes connecteurs. Conservez SCEP avec NDES si vous disposez d'une équipe AD CS expérimentée, d'une feuille de route CA à long terme et d'autres modèles de certificats. Si vos serveurs NDES doivent être renouvelés, la PKI Cloud avec BYOCA conserve votre confiance racine existante tout en retirant NDES.

Comment Microsoft Cloud PKI est-il sous licence ?

La PKI Cloud est sous licence par utilisateur et par mois, en supplément d'Intune Plan 1. Elle est disponible soit dans le cadre de la suite Microsoft Intune, soit en tant que module complémentaire Cloud PKI autonome. Consultez la liste des prix actuelle de Microsoft avant d'établir votre budget, car les offres évoluent. Comparez le coût de la licence aux coûts des licences Windows Server, des machines virtuelles, de la publication de proxy et de la maintenance qu'exige une pile AD CS, NDES et connecteurs.

Puis-je conserver mon AC racine sur site existante avec la PKI Cloud ?

Oui, grâce à l'option Bring-Your-Own-CA. Vous créez une AC d'émission PKI Cloud, exportez sa demande de signature de certificat et la signez avec votre AC racine privée existante, telle qu'AD CS. Tout ce qui fait déjà confiance à cette racine, y compris votre serveur RADIUS et vos appareils, fait alors confiance à la nouvelle chaîne. Vous ajoutez uniquement le certificat de l'AC d'émission. Vous pouvez migrer les profils SCEP groupe par groupe tandis que les certificats existants restent valides jusqu'à leur renouvellement.

La PKI Cloud fonctionne-t-elle avec mes points d'accès existants ?

Oui, tant que vos points d'accès prennent en charge le 802.1X avec WPA2-Enterprise ou WPA3-Enterprise. La PKI Cloud n'affecte que les certificats sur les appareils et la confiance sur votre serveur RADIUS. Les points d'accès se contentent de transmettre l'authentification à RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet prennent tous cela en charge. Le Staff WiFi de Purple fonctionne sur ces huit matériels sous la forme d'un overlay cloud agnostique.