Comment utiliser Microsoft Intune pour déployer des certificats WiFi sur les appareils

COMMENT UTILISER MICROSOFT INTUNE POUR DÉPLOYER DES CERTIFICATS WIFI SUR LES APPAREILS Une note d'information Purple sur l'intelligence WiFi d'entreprise [INTRODUCTION & CONTEXTE — environ 1 minute] Ravi de vous retrouver. Je m'exprime aujourd'hui au nom de Purple, la plateforme d'intelligence WiFi d'entreprise, et cet épisode est un point d'information ciblé sur l'une des fonctionnalités les plus pratiques — et honnêtement, les plus sous-estimées — de la boîte à outils Microsoft Intune : le déploiement automatisé de certificats pour l'authentification WiFi 802.1X. Si vous gérez le WiFi sur un parc hôtelier, une chaîne de magasins, un stade ou un domaine du secteur public, vous connaissez le problème que je m'apprête à décrire. Vous avez des centaines ou des milliers d'appareils gérés. Vous voulez qu'ils se connectent à votre WiFi d'entreprise automatiquement, de manière sécurisée, sans que les utilisateurs n'aient à saisir de mots de passe, et sans que le service informatique n'ait à manipuler chaque appareil. Et vous voulez que cette connexion soit cryptographiquement forte — pas seulement un mot de passe partagé que quelqu'un a déjà envoyé par e-mail à la moitié de l'organisation. C'est exactement ce que résout le déploiement de certificats Intune. Et dans les neuf prochaines minutes, je vais vous expliquer comment cela fonctionne, comment le déployer et les pièges qui piègent la plupart des équipes lors de leur première tentative. [ANALYSE TECHNIQUE APPROFONDIE — environ 5 minutes] Commençons par l'architecture. La base ici est la norme IEEE 802.1X — la norme de contrôle d'accès réseau basée sur les ports qui constitue l'épine dorsale de la sécurité WiFi d'entreprise depuis plus de deux décennies. Lorsqu'un appareil se connecte à votre WiFi, la norme 802.1X exige qu'il s'authentifie avant d'obtenir un accès au réseau. La conversation d'authentification a lieu entre trois parties : l'appareil — appelé le suppliant —, votre point d'accès WiFi, qui fait office d'authentificateur, et votre serveur RADIUS, qui est le serveur d'authentification prenant la décision finale. Désormais, le 802.1X prend en charge plusieurs méthodes d'authentification. La plus sécurisée est EAP-TLS — Extensible Authentication Protocol avec Transport Layer Security. EAP-TLS utilise une authentification mutuelle par certificat : l'appareil présente un certificat pour prouver son identité, et le serveur RADIUS présente un certificat pour prouver la sienne. Aucun mot de passe n'est requis. Aucun identifiant ne peut être hameçonné. C'est notre objectif. Le défi a toujours été d'installer ces certificats sur les appareils à grande échelle. C'est là qu'intervient Microsoft Intune. Intune prend en charge deux mécanismes de déploiement de certificats : SCEP — Simple Certificate Enrollment Protocol — et PKCS, qui signifie Public Key Cryptography Standards. Il est important de comprendre la différence. Avec SCEP, la clé privée est générée sur l'appareil lui-même. L'appareil crée une demande de signature de certificat (CSR), l'envoie à votre autorité de certification (CA) via un serveur intermédiaire appelé NDES — Network Device Enrollment Service — et la CA renvoie le certificat. La clé privée ne quitte jamais l'appareil. C'est l'approche la plus sécurisée, recommandée pour les environnements BYOD et les déploiements à haute sécurité. Avec PKCS, l'Autorité de Certification génère la paire de clés, et l'Intune Certificate Connector fournit la clé privée et le certificat à l'appareil. C'est plus simple à configurer — aucun serveur NDES n'est requis — mais la clé privée transite par le connecteur, ce qui est un élément à prendre en compte pour votre posture de sécurité. Pour la plupart des déploiements d'entreprise, je recommanderais SCEP pour les environnements BYOD et d'appareils mixtes, et PKCS lorsque vous disposez d'un parc homogène d'appareils Windows appartenant à l'entreprise et que vous souhaitez minimiser la complexité de l'infrastructure. Parlons maintenant de la séquence de déploiement — car l'ordre est important et une mauvaise configuration est la cause la plus fréquente d'échecs de déploiement. Étape une : configurez votre Autorité de Certification. Vous avez besoin d'un modèle de certificat sur votre instance Active Directory Certificate Services — ou si vous êtes entièrement cloud-native, l'Intune Cloud PKI de Microsoft est désormais disponible et supprime complètement l'exigence d'une CA sur site. Le modèle doit comporter les extensions d'utilisation de clé correctes : l'Authentification Client est obligatoire. Définissez la taille minimale de la clé sur 2048 bits, ou 4096 si la politique de sécurité de votre organisation l'exige. Étape deux : déployez le certificat racine de confiance. Avant qu'un appareil ne puisse valider le certificat du serveur RADIUS, il doit faire confiance à la CA qui l'a émis. Vous créez un profil de configuration de Certificat de Confiance dans Intune, téléchargez le certificat de la CA racine et l'attribuez à vos groupes d'appareils. Cela doit être installé sur les appareils avant tout profil WiFi ou profil de certificat client. Si vous vous trompez dans la séquence, les appareils rejetteront le serveur RADIUS et vous passerez l'après-midi à analyser l'Event ID 20271 dans le journal d'événements Windows. Étape trois : déployez le profil de certificat client. Il s'agit soit de votre profil SCEP — pointant vers l'URL de votre serveur NDES — soit de votre profil PKCS, pointant vers votre Autorité de Certification. Le Subject Alternative Name doit inclure le User Principal Name pour les certificats d'utilisateur, ou l'AAD Device ID pour les certificats d'appareil. Cette distinction est importante : les certificats d'utilisateur authentifient l'utilisateur connecté, les certificats d'appareil authentifient la machine elle-même, ce qui signifie que l'appareil peut se connecter au WiFi avant qu'un utilisateur ne se connecte — ce qui est utile pour les scénarios de jonction de domaine et les déploiements de bornes. Étape quatre : créez le profil de configuration WiFi. Dans Intune, cela se trouve sous Appareils, Profils de configuration, Modèles, Wi-Fi. Définissez le type de WiFi sur Entreprise, saisissez votre SSID, définissez le type EAP sur EAP-TLS, configurez les paramètres de confiance du serveur — c'est ici que vous référencez le nom du certificat du serveur RADIUS — et pour l'authentification client, référencez le profil de certificat que vous avez créé à l'étape trois. Étape cinq : attribuez le tout aux bons groupes et validez. Attribuez votre certificat racine, votre certificat client et vos profils WiFi aux mêmes groupes d'appareils ou d'utilisateurs. Utilisez les rapports intégrés d'Intune pour surveiller l'état du déploiement des profils. Un déploiement réussi affiche les trois profils avec le statut Réussi dans la liste des profils de configuration de l'appareil. Un point critique concernant la configuration NPS pour les environnements Windows Server : depuis début 2024, Microsoft a renforcé les exigences de mappage des certificats. Si vous utilisez des certificats d'appareil avec des appareils joints à Azure AD s'authentifiant auprès d'un NPS sur site, vous devez vous assurer que l'attribut altSecurityIdentities sur l'objet ordinateur dans Active Directory est renseigné avec l'empreinte du certificat. Cela ne se fait pas automatiquement — vous avez besoin d'un script ou d'un flux de travail pour le gérer, généralement déclenché lorsque l'autorité de certification émet un nouveau certificat. [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES — environ 2 minutes] Laissez-moi vous présenter les trois pièges que je vois le plus fréquemment dans les déploiements d'entreprise. Premier piège : les ruptures de la chaîne de certification. L'appareil doit faire confiance à chaque certificat de la chaîne, depuis l'autorité de certification racine jusqu'au certificat du serveur RADIUS. Si le certificat de votre serveur RADIUS a été émis par une autorité de certification intermédiaire, vous devez déployer à la fois la racine et l'intermédiaire sur les appareils. J'ai vu des déploiements échouer pendant des semaines parce que quelqu'un avait déployé la racine mais pas l'intermédiaire. Deuxième piège : le timing d'attribution des profils. Les profils Intune n'arrivent pas instantanément sur les appareils. Dans un grand parc informatique, la propagation des profils après leur attribution peut prendre de 15 à 30 minutes. Ne faites pas de tests immédiatement après avoir créé les profils. Utilisez le bouton Synchroniser dans le portail Intune pour forcer une vérification, puis patientez. De plus, les profils de certificat client doivent être déployés et confirmés avant que le profil WiFi ne soit appliqué — si le profil WiFi fait référence à un certificat qui n'existe pas encore, le profil échouera silencieusement sur certaines plateformes. Troisième piège : la révocation des certificats BYOD. Lorsqu'un appareil est désinscrit d'Intune — parce qu'un employé s'en va ou qu'un appareil est perdu — vous devez disposer d'un processus pour révoquer le certificat. Si vous utilisez SCEP avec ADCS, configurez correctement le point de distribution de la liste de révocation de certificats (CRL) et assurez-vous que votre serveur RADIUS vérifie la CRL ou l'OCSP lors de chaque authentification. Il s'agit d'une exigence de conformité dans le cadre de référentiels tels que PCI DSS, qui impose que les mécanismes de contrôle d'accès soient révoqués rapidement lorsqu'ils ne sont plus nécessaires. Sur le thème de la conformité : si vous opérez dans le cadre de la norme PCI DSS — les environnements de paiement de détail, par exemple — l'authentification 802.1X basée sur les certificats est votre contrôle le plus solide pour l'accès au réseau sans fil. Elle répond à l'exigence 1.3 de PCI DSS concernant les contrôles d'accès au réseau et à l'exigence 8.6 concernant les facteurs d'authentification. Documentez votre processus de gestion du cycle de vie des certificats dans le cadre de vos preuves de conformité. Pour les environnements réglementés par le GDPR, en particulier dans l'hôtellerie et le secteur public, la séparation entre votre réseau d'entreprise 802.1X et votre réseau WiFi invité est essentielle. Votre réseau d'entreprise géré par Intune doit se trouver sur un VLAN et un SSID complètement distincts de tout réseau d'invités ou de visiteurs. La plateforme de WiFi invité de Purple gère la partie visible par les visiteurs — Captive Portal, capture de consentement, analyses — tandis que votre réseau d'entreprise géré par Intune prend en charge le personnel et les appareils opérationnels. Ces deux réseaux ne doivent jamais partager la même infrastructure d'authentification. [Q&R RAPIDE — environ 1 minute] Passons en revue quelques questions qui reviennent régulièrement. Puis-je utiliser Intune Cloud PKI au lieu d'un ADCS sur site ? Oui. Intune Cloud PKI de Microsoft, lancé en 2024, fournit une autorité de certification (CA) entièrement gérée dans Azure. Il élimine le besoin de serveur NDES pour SCEP et simplifie considérablement la configuration du connecteur. Pour les nouveaux déploiements ou les organisations sans infrastructure ADCS existante, c'est la voie recommandée. Cela fonctionne-t-il pour les appareils macOS et iOS ? Oui. Intune prend en charge les profils de certificat pour Windows, iOS, iPadOS, Android et macOS. Les types de profils et les options de configuration varient légèrement selon la plateforme, mais l'architecture de base — racine de confiance, certificat client, profil WiFi — reste cohérente. Qu'en est-il des appareils personnels dans le cadre d'un programme BYOD ? SCEP est votre meilleur allié ici. Grâce aux politiques de conformité des appareils d'Intune, vous pouvez exiger qu'un appareil réponde à des normes de sécurité minimales avant qu'un certificat ne lui soit délivré. Si l'appareil n'est plus conforme — pas de verrouillage d'écran, système d'exploitation obsolète — le certificat peut être révoqué et l'accès au réseau supprimé automatiquement. Purple peut-il s'intégrer à cette architecture ? Absolument. La plateforme de Purple se positionne du côté du réseau invité, gérant l'authentification par Captive Portal, la gestion du consentement et les analyses. Le réseau d'entreprise 802.1X et le WiFi invité de Purple fonctionnent en parallèle — même infrastructure physique, mais SSIDs et VLANs différents — vous offrant une séparation complète entre la connectivité du personnel et l'engagement des visiteurs. [RÉSUMÉ & PROCHAINES ÉTAPES — environ 1 minute] Pour résumer : le déploiement de certificats WiFi via Intune est un processus en cinq étapes — configuration de la CA, déploiement de la racine de confiance, profil de certificat client, profil WiFi et attribution de groupe. Choisissez SCEP pour le BYOD et les environnements hautement sécurisés ; PKCS pour les flottes d'entreprise plus simples. Respectez le bon ordre des étapes, gérez l'exigence de mappage de certificat NPS et mettez en place un flux de travail de révocation de certificat dès le premier jour. L'intérêt commercial est évident : vous éliminez les mots de passe WiFi partagés, vous obtenez des journaux d'authentification par appareil et par utilisateur, vous répondez aux exigences de sécurité sans fil PCI DSS et ISO 27001, et vous réduisez la charge de travail informatique liée à la gestion des identifiants WiFi sur un vaste parc d'appareils. Si vous planifiez un déploiement et souhaitez comprendre comment la plateforme de guest WiFi et d'analytics de Purple s'intègre à l'architecture de votre réseau d'entreprise, visitez purple.ai. Nous proposons des guides détaillés sur l'intégration d'Azure Entra ID, l'architecture 802.1X et la conception de réseaux invités pour les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Merci pour votre écoute. À la prochaine.