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

COMMENT UTILISER MICROSOFT INTUNE POUR DEPLOYER DES CERTIFICATS WIFI SUR LES APPAREILS Une note d'information Purple Enterprise WiFi Intelligence [INTRODUCTION & CONTEXTE — environ 1 minute] Bienvenue. Je m'exprime aujourd'hui au nom de Purple, la plateforme d'intelligence WiFi pour entreprises, et cet épisode est un briefing ciblé sur l'une des fonctionnalités les plus pratiques - et franchement, 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 dans 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 disposez de centaines ou de 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 individuellement. Et vous voulez que cette connexion soit forte sur le plan cryptographique - 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 minutes qui suivent, 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 repose ici sur l'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 des entreprises 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 tout accès au réseau. La communication d'authentification se déroule 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 l'EAP-TLS - Extensible Authentication Protocol avec Transport Layer Security. L'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 l'objectif que nous visons. Le défi a toujours été de déployer ces certificats sur les appareils à grande échelle. C'est là que Microsoft Intune intervient. Intune prend en charge deux mécanismes de déploiement de certificats : SCEP - Simple Certificate Enrolment 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, l'envoie à votre autorité de certification via un serveur intermédiaire appelé NDES - Network Device Enrolment Service - et l'autorité de certification 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 le connecteur de certificat Intune 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 se tromper est la cause la plus fréquente d'échecs de déploiement. Étape un : 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, Microsoft Intune Cloud PKI est désormais disponible pour tous et supprime complètement l'exigence d'une autorité de certification locale. Le modèle doit comporter les extensions d'utilisation de clé appropriées : l'authentification du 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 puisse valider le certificat du serveur RADIUS, il doit faire confiance à l'autorité de certification qui l'a émis. Vous créez un profil de configuration de certificat de confiance dans Intune, téléchargez le certificat de l'autorité de certification racine et l'attribuez à vos groupes d'appareils. Celui-ci doit arriver sur les appareils avant tout profil WiFi ou profil de certificat client. Si vous vous trompez dans l'ordre, les appareils rejetteront le serveur RADIUS et vous passerez l'après-midi à analyser l'ID d'événement 20271 dans le journal des é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 nom alternatif du sujet (Subject Alternative Name) doit inclure le nom principal de l'utilisateur (User Principal Name) pour les certificats d'utilisateur, ou l'ID d'appareil AAD 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 - 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 d'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 du 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 vos profils de certificat racine, de certificat client et de WiFi aux mêmes groupes d'appareils ou d'utilisateurs. Utilisez les rapports intégrés d'Intune pour surveiller l'état de 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 de 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 produit 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 À ÉVITER — environ 2 minutes] Permettez-moi de vous présenter les trois pièges que je rencontre le plus fréquemment dans les déploiements d'entreprise. Premier piège : les ruptures de 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 de l'attribution des profils. Les profils Intune ne s'appliquent pas instantanément sur les appareils. Dans un parc de grande taille, la propagation des profils après attribution peut prendre 15 à 30 minutes. Ne faites pas de tests immédiatement après la création des 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 l'application du profil WiFi - 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 retiré 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 et assurez-vous que votre serveur RADIUS vérifie la CRL ou l'OCSP à chaque authentification. Il s'agit d'une exigence de conformité dans le cadre de référentiels comme PCI-DSS, qui impose de révoquer rapidement les mécanismes de contrôle d'accès lorsqu'ils ne sont plus nécessaires. Sur le thème de la conformité : si vous opérez dans un périmètre 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 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. Le service Intune Cloud PKI de Microsoft, lancé en 2024, fournit une autorité de certification 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 ne disposant pas d'une 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 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 situe 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, SSIDs et VLANs différents - ce qui vous offre 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 l'autorité de certification, 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. Veillez à respecter l'ordre des étapes, gérez l'exigence de mappage des certificats NPS et créez un flux de travail de révocation des certificats 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 les coûts informatiques liés à la gestion des identifiants WiFi sur un grand parc d'équipements.Si vous planifiez un déploiement et souhaitez comprendre comment la plateforme d'analyse et de WiFi invité de Purple s'intègre à l'architecture de votre réseau d'entreprise, visitez purple.ai. Nous disposons de guides détaillés sur l'intégration de Microsoft 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 public. Merci pour votre écoute. À la prochaine.