Comment configurer SCEP pour l'enrôlement automatique de certificats WiFi d'entreprise
Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatique de certificats WiFi d'entreprise, couvrant l'architecture complète depuis la PKI et NDES jusqu'au déploiement de profils MDM et la validation RADIUS. Il s'adresse aux directeurs informatiques, architectes réseau et CTO d'hôtels, de chaînes de vente au détail, de stades, de centres de conférence et d'organisations du secteur public qui doivent abandonner les clés pré-partagées pour mettre en œuvre une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud superposée et agnostique de Purple s'intègre directement à cette architecture, fournissant la couche WiFi invités et BYOD qui coexiste avec le réseau de votre personnel authentifié par certificat.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
Résumé
Pour les espaces professionnels - qu'il s'agisse d'un hôtel de 200 chambres, d'une chaîne de vente au détail de 50 points de vente ou d'un grand centre de conférence - dépendre de clés pré-partagées pour le WiFi des employés représente un risque de sécurité et un goulot d'étranglement opérationnel. Une seule clé compromise expose l'ensemble du réseau. L'authentification par certificat via le protocole IEEE 802.1X et EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) élimine totalement ce risque. Chaque appareil prouve son identité de manière cryptographique avant que le point d'accès ne lui accorde l'accès au réseau.
Le défi réside dans la distribution. Déployer manuellement des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android n'est pas viable. Le SCEP (Simple Certificate Enrollment Protocol), formalisé en tant que RFC 8894 par l'IETF en 2020, résout ce problème. Il automatise le processus de demande, d'émission et d'installation de certificats numériques sur les appareils gérés via votre plateforme MDM - sans aucune intervention de l'utilisateur.
Ce guide couvre l'ensemble de l'architecture : le rôle du SCEP, son intégration avec Microsoft Intune, Jamf et d'autres plateformes MDM, la séquence exacte de déploiement que la plupart des équipes ratent, et les pièges opérationnels qui causent des interruptions de service. Nous abordons également deux scénarios réels de déploiement dans l'hôtellerie et la vente au détail, et expliquons où la plateforme de Guest WiFi de Purple s'intègre aux côtés de votre réseau d'employés authentifié par certificat.
Écoutez le podcast informatif complémentaire :
Analyse technique détaillée : SCEP, PKI et 802.1X
Ce que fait réellement le SCEP
Le SCEP ne remplace pas votre Public Key Infrastructure (PKI). C'est la couche d'enregistrement automatisée qui se superpose à celle-ci. Votre PKI - généralement une hiérarchie à deux niveaux avec une autorité de certification (CA) racine hors ligne et une CA émettrice en ligne - reste l'ancre de confiance. Le SCEP automatise l'étape où un appareil demande un certificat à cette CA, éliminant ainsi le besoin de génération manuelle de CSR et d'installation de certificats.
Dans le contexte de l'authentification WiFi, le protocole cible est l'EAP-TLS. Il s'agit de la méthode d'authentification 802.1X qui exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. Aucune des parties ne fait confiance à l'autre sans preuve cryptographique. Ce modèle d'authentification mutuelle élimine le vol de clés d'identification et protège contre les attaques de type "evil twin", dans lesquelles un attaquant configure un faux point d'accès pour collecter des noms d'utilisateur et des mots de passe.
Pour une analyse détaillée du handshake EAP-TLS, consultez notre guide sur la WiFi Certificate Authentication: Secure Network Access.
Le flux d'enregistrement SCEP, étape par étape
La chaîne d'enregistrement complète fonctionne de la manière suivante. Votre plateforme MDM - Microsoft Intune, Jamf ou un autre MDM - envoie une charge utile SCEP à un appareil géré. Cette charge utile contient deux éléments : l'URL SCEP qui pointe vers votre serveur NDES (Network Device Enrollment Service) ou votre passerelle SCEP cloud, et un mot de passe de défi ou secret partagé.
L'appareil génère sa propre paire de clés publique et privée localement. Il s'agit de la propriété de sécurité essentielle du SCEP : la clé privée est générée sur l'appareil, stockée dans l'enclave sécurisée ou la puce TPM, et n'est jamais transmise sur le réseau. L'appareil crée ensuite une demande de signature de certificat (CSR) et l'envoie à la passerelle SCEP. La passerelle valide le mot de passe de défi, transmet la CSR à votre Autorité de Certification (CA), et la CA la signe puis renvoie le certificat public à l'appareil.
À partir de ce moment, lorsque l'appareil se connecte à votre SSID de WiFi, il présente ce certificat au serveur RADIUS. Le serveur RADIUS valide le certificat par rapport à sa chaîne de confiance de CA, vérifie la liste de révocation de certificats (CRL) pour confirmer que le certificat n'a pas été révoqué et, si tout est correct, envoie un message Access-Accept au point d'accès. L'appareil est sur le réseau. Tout le processus est invisible pour l'utilisateur.
SCEP vs PKCS : lequel utiliser pour le WiFi
As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.
Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.
O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.
| Propriedade | SCEP | PKCS |
|---|---|---|
| Geração de chave privada | No dispositivo (TPM/Secure Enclave) | Centralizada (CA) |
| Transmissão de chave privada | Nunca | Através da rede |
| Servidor NDES necessário | Sim (ou gateway na nuvem) | Não |
| Recomendado para WiFi | Sim | Não |
| Recomendado para S/MIME | Não | Sim |
Compatibilidade de hardware
O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.
A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.
Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.
Guia de implementação: a sequência de implementação
A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.
A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.
Étape 1 : déployer le profil de certificat de racine de confiance (Trusted Root)
Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification (CA) émettrice. Exportez votre certificat de CA racine - ainsi que tout certificat de CA intermédiaire - sous forme de fichiers .cer. Dans votre centre d'administration MDM, créez un profil de certificat de confiance, téléchargez le fichier .cer et déployez-le sur votre groupe d'appareils cible.
Si vous disposez d'une hiérarchie PKI à deux niveaux (recommandé), vous devez déployer à la fois le certificat de la CA racine et celui de la CA émettrice en tant que profils de certificat de confiance distincts, ou sous forme de chaîne dans un seul profil, selon votre plateforme MDM.
Étape 2 : configurer le profil de certificat SCEP
Une fois la confiance établie, configurez le profil SCEP pour indiquer aux appareils comment obtenir leur certificat client.
Créez un nouveau profil de configuration et sélectionnez le type de profil de certificat SCEP. Configurez le format du nom de l'objet (Subject name). Pour l'authentification basée sur l'utilisateur, CN={{UserPrincipalName}} est la norme. Pour l'authentification des appareils (appareils partagés, IoT, terminaux POS), utilisez CN={{AAD_Device_ID}}. Définissez l'utilisation de la clé (Key usage) sur Signature numérique et Chiffrement de clé. Définissez l'utilisation étendue de la clé (Extended Key Usage) sur Authentification client (OID : 1.3.6.1.5.5.7.3.2). Associez ce profil au profil de certificat de racine de confiance créé à l'Étape 1. Fournissez l'URL externe de votre serveur NDES. Pour Microsoft Intune spécifiquement, le serveur NDES doit être publié via le Proxy d'application Azure AD pour permettre aux appareils distants de s'enregistrer avant de se connecter au réseau local. N'exposez pas le NDES directement sur Internet.
Étape 3 : déployer le profil WiFi 802.1X
La dernière étape consiste à pousser la configuration WiFi qui associe les certificats au SSID du réseau. Créez un profil de configuration de WiFi. Saisissez le nom du réseau (SSID) exactement tel qu'il est diffusé par vos points d'accès. Sélectionnez WPA2 ou WPA3 comme type de sécurité. Définissez le type d'EAP sur EAP-TLS. Dans les paramètres d'authentification, sélectionnez le profil de certificat SCEP créé à l'Étape 2 comme certificat d'authentification client. Spécifiez le certificat Trusted Root pour la validation du serveur - cela garantit que l'appareil se connecte uniquement à votre serveur RADIUS légitime et non à un point d'accès non autorisé.
Intégration du fournisseur d'identité
Les attributs du certificat SCEP - spécifiquement le Subject Alternative Name (SAN) - peuvent contenir le nom principal de l'utilisateur de Microsoft Entra ID, Okta ou Google Workspace. Cela associe le certificat à une identité spécifique. Lorsque vous désactivez un compte dans Entra ID et que le MDM supprime l'enregistrement de l'appareil, le certificat est révoqué et l'accès au WiFi est coupé automatiquement. Cette révocation automatisée est le scénario de sécurité que les clés pré-partagées ne peuvent pas égaler.
Pour en savoir plus sur EAP Method WiFi: A Guide to Secure Network Access, y compris les chemins de migration PEAP-MSCHAPv2, consultez notre guide dédié.
-
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
Bonnes pratiques et normes du secteur
Positionnement du serveur NDES
Le serveur NDES doit être accessible depuis Internet afin que les appareils puissent s'enregistrer avant d'arriver sur site. Publiez l'URL du NDES via l'Azure AD Application Proxy. Cela fournit un accès distant sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'Accès Conditionnel au flux d'enregistrement. N'exposez jamais le NDES directement à Internet.
Pour les réseaux de plus de 500 appareils gérés, envisagez une passerelle SCEP dans le cloud plutôt qu'un NDES local. Les passerelles dans le cloud éliminent le point de défaillance unique du NDES, s'adaptent horizontalement et s'intègrent généralement directement avec les services RADIUS dans le cloud.
Disponibilité de la CRL
Votre serveur RADIUS vérifie la Liste de Révocation de Certificats (CRL) chaque fois qu'un appareil s'authentifie. Si votre Point de Distribution de CRL (CDP) est indisponible - parce qu'un serveur est en panne ou que l'URL a changé - l'authentification échoue pour tous les appareils du réseau en même temps. Configurez votre serveur NPS ou RADIUS pour imposer une vérification stricte de la CRL et rendez vos points de terminaison de CRL hautement disponibles. Testez la révocation avant de passer en production.
L'exigence 8.6 de la norme PCI-DSS 4.0 exige une authentification multifacteur au niveau de la couche réseau pour les environnements de données de titulaires de cartes. L'EAP-TLS avec des certificats provisionnés par SCEP répond à cette exigence pour les réseaux sans fil dans les environnements de Retail et Hospitality.
Compatibilité avec WPA3
L'EAP-TLS est entièrement compatible avec le WPA3-Enterprise. Le WPA3-Enterprise avec la suite de sécurité 192 bits (Suite B) exige l'EAP-TLS et constitue la combinaison recommandée par la Wi-Fi Alliance pour les réseaux gouvernementaux, financiers et de santé. Si vous déployez dans des environnements de Saúde ou Transportes avec des exigences de conformité strictes, le WPA3-Enterprise avec EAP-TLS est l'architecture cible correcte.
BYOD et WiFi de convidados
Le SCEP nécessite l'inscription au MDM pour envoyer le payload du certificat. Il ne couvre pas les appareils BYOD non gérés ou les invités. Pour ces cas d'utilisation, vous avez besoin d'un SSID distinct avec un Captive Portal et une vérification d'identité. La plateforme de Purple gère cette couche de manière propre, en coexistant avec votre réseau d'employés authentifié par certificat. Notre plateforme de Guest WiFi prend en charge les opt-ins de choix conscient, la capture de données de première partie et l'intégration avec Microsoft Entra ID, Okta et Google Workspace pour la vérification d'identité.
-
Résolution des problèmes et atténuation des risques
Échec de l'application du profil de WiFi
Symptôme : L'appareil reçoit les certificats Trusted Root et SCEP, mais le profil de WiFi est affiché comme Erreur ou Non Applicable dans le MDM.
Cause première : Incompatibilité de ciblage de groupe. Si le profil SCEP cible un groupe d'Utilisateurs et que le profil de WiFi cible un groupe d'Appareils, le MDM ne peut pas résoudre la dépendance.
Solution : Auditez vos attributions. Assurez-vous que les profils Trusted Root, SCEP et WiFi ciblent tous exactement le même groupe d'annuaire.
Erreurs NDES 403 Forbidden
Symptôme : Les appareils ne parviennent pas à obtenir le certificat SCEP. Les journaux IIS du NDES affichent des erreurs HTTP 403.
Cause première : Le compte de service du MDM Certificate Connector ne dispose pas des autorisations de Lecture et d'Inscription (Read and Enroll) sur le modèle de certificat, ou le filtrage d'URL du pare-feu bloque les paramètres de query string du SCEP.
Solution : Vérifiez que le compte du connecteur dispose des autorisations de Lecture et d'Inscription sur le modèle de la CA. Vérifiez les journaux du pare-feu pour vous assurer que les URL contenant ?operation=GetCACaps ne sont pas bloquées.
Échec d'authentification en masse après l'expiration de la CRL
Symptôme : Tous les appareils du réseau échouent à l'authentification simultanément.
Cause première : La CRL a expiré ou l'URL du CDP est inaccessible. Le serveur RADIUS ne peut pas confirmer si les certificats sont valides et échoue par défaut (fails closed).
Solution : Configurez la surveillance et les alertes de CRL. Publiez les CRL avec une période de validité de loin supérieure à l'intervalle de publication. Testez l'accessibilité du CDP depuis le serveur RADIUS avant le déploiement.
Expiration de certificat causant des échecs silencieux
Symptôme : Des appareils individuels perdent la connexion par intermittence, sans motif clair.
Cause première : Les certificats clients ont expiré et le MDM ne les a pas renouvelés avec succès.
Solution : Configurez le renouvellement du certificat pour qu'il se déclenche à 80 % de la durée de vie du certificat. Surveillez les rapports d'état d'inscription du MDM pour les appareils présentant des erreurs de certificat. Définissez des périodes de validité de certificat adaptées au cycle de renouvellement de vos appareils - généralement un à deux ans pour les endpoints gérés.
-
ROI et impact entrepreneurial
La transition vers l'authentification par certificat 802.1X basée sur SCEP offre des rendements mesurables en termes de sécurité, d'opérations et de conformité.
Réduction des tickets de support : Le WiFi basé sur mot de passe génère un volume important de tickets de support - expiration de mots de passe, blocages et fautes de frappe. L'authentification par certificat est invisible pour l'utilisateur. Les organisations constatent généralement une réduction de 70-80 % du volume de support lié au WiFi après la migration.
Posture de sécurité : EAP-TLS élimine la collecte d'identifiants et les attaques Man-in-the-Middle. Cela soutient directement la conformité avec la norme PCI-DSS 4.0 pour les réseaux de vente au détail et d'hôtellerie, ainsi que les exigences de l'Article 32 du GDPR concernant les mesures de sécurité techniques appropriées.
Révocation automatisée : Lorsqu'un collaborateur quitte l'entreprise, la désactivation de son compte dans Microsoft Entra ID déclenche la révocation automatique du certificat et la désassociation du MDM. L'accès au WiFi est coupé sans aucune intervention manuelle de la part de l'équipe réseau.
Segmentation réseau : L'attribution dynamique de VLAN via les attributs de certificat RADIUS vous offre une segmentation réseau appliquée de manière cryptographique. Les appareils entrent dans le bon segment de réseau en fonction des propriétés du certificat, et non de la sélection du SSID ou du filtrage d'adresses MAC - deux méthodes facilement contournables.
Purple opère dans plus de 80 000 sites actifs avec un taux de disponibilité de 99,999 %, et notre plateforme possède les certifications ISO 27001, GDPR, CCPA et Cyber Essentials. Notre infrastructure cloud agnostique en termes de matériel s'intègre avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet - pour que votre réseau de collaborateurs authentifié par certificat et notre couche de WiFi pour invités fonctionnent sur la même infrastructure.
Pour en savoir plus sur la manière dont l'analyse comportementale (Behavioral Analytics: Insights for WiFi Networks) peut compléter votre déploiement de réseau sécurisé, consultez notre guide d'analyse.
-
Références
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
Définitions clés
SCEP (Simple Certificate Enrollment Protocol)
Un protocole formalisé dans l'RFC 8894 qui permet aux appareils gérés de demander et de recevoir automatiquement des certificats numériques X.509 auprès d'une autorité de certification via HTTP, en utilisant un mot de passe de défi partagé pour l'authentification initiale. La clé privée est générée sur l'appareil et n'est jamais transmise.
Le mécanisme standard utilisé par les plateformes MDM comme Microsoft Intune et Jamf pour déployer des certificats d'authentification WiFi sur des terminaux gérés à grande échelle.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
La méthode d'authentification 802.1X la plus sécurisée, exigeant que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. L'authentification mutuelle signifie qu'aucune des parties ne fait confiance à l'autre sans preuve cryptographique.
Le protocole d'authentification cible pour le WiFi d'entreprise. Obligatoire ou fortement recommandé par PCI-DSS 4.0, WPA3-Enterprise 192 bits (Suite B) et HIPAA pour les réseaux sans fil traitant des données sensibles.
NDES (Network Device Enrollment Service)
Un rôle Windows Server de Microsoft qui agit en tant qu'autorité d'enregistrement (RA) entre les appareils compatibles SCEP et une autorité de certification. Il valide les mots de passe de défi et transmet les CSR à la CA pour le compte des appareils qui ne disposent pas d'identifiants de domaine.
Infrastructure requise pour le déploiement SCEP avec Microsoft Intune. Doit être publiée via Azure AD Application Proxy plutôt que d'être exposée directement sur Internet.
PKI (Public Key Infrastructure)
La hiérarchie des autorités de certification, des politiques et des procédures utilisées pour émettre, gérer et révoquer des certificats numériques. Une PKI à deux niveaux se compose d'une CA racine hors ligne (l'ancre de confiance principale) et d'une CA émettrice en ligne (qui gère l'émission quotidienne des certificats).
Le prérequis non négociable pour le déploiement d'EAP-TLS et de SCEP. La CA racine doit être maintenue hors ligne (air-gapped) ; sa clé privée est le fondement de toute votre chaîne de confiance de certificats.
CSR (Certificate Signing Request)
Un message généré par un appareil contenant sa clé publique et ses informations d'identité, envoyé à une autorité de certification pour demander un certificat numérique signé. Dans SCEP, la CSR est générée sur l'appareil et encapsulée dans une enveloppe PKCS avant la transmission.
Généré automatiquement par l'appareil lors du flux d'enregistrement SCEP. La clé privée utilisée pour signer la CSR ne quitte jamais l'appareil.
CRL (Certificate Revocation List)
Une liste publiée par l'autorité de certification contenant les numéros de série des certificats révoqués avant leur date d'expiration. Les serveurs RADIUS vérifient la CRL à chaque tentative d'authentification pour s'assurer que les certificats révoqués ne peuvent pas accéder au réseau.
La disponibilité du point de distribution CRL (CDP) est essentielle. Si le serveur RADIUS ne peut pas atteindre la CRL, il se bloque par sécurité et refuse toute authentification - provoquant une panne générale du réseau.
RADIUS (Remote Authentication Dial-In User Service)
Un protocole réseau qui fournit une centralisation de l'authentification, de l'autorisation et de la traçabilité (AAA) pour l'accès au réseau. Dans le cadre du WiFi 802.1X, le serveur RADIUS valide les certificats des clients, vérifie la CRL et renvoie un message Access-Accept ou Access-Reject au point d'accès.
Le serveur d'authentification dans le modèle suppliant-authentificateur-serveur de la norme 802.1X. Les implémentations courantes incluent Windows NPS, FreeRADIUS et les services RADIUS-as-a-Service dans le cloud.
Assignation dynamique de VLAN
Une fonctionnalité RADIUS qui place un appareil authentifié sur un VLAN spécifique en fonction des attributs du certificat ou de l'appartenance à un groupe d'annuaire, plutôt que de s'appuyer sur la sélection du SSID ou le filtrage d'adresses MAC. Renforce la segmentation du réseau par l'identité de l'appareil.
Permet à un seul SSID de desservir plusieurs types d'appareils avec des niveaux d'accès réseau différents. Un appareil du personnel obtient le VLAN 10 (accès interne) ; un appareil de prestataire obtient le VLAN 20 (Internet uniquement) ; un terminal de point de vente obtient le VLAN 30 (systèmes de paiement uniquement).
MDM (Mobile Device Management)
Logiciel utilisé par les équipes informatiques pour enregistrer, configurer, sécuriser et gérer les smartphones, tablettes et ordinateurs portables. Les plateformes MDM comme Microsoft Intune et Jamf utilisent des profils SCEP pour envoyer des instructions d'enregistrement de certificats aux appareils gérés sans intervention de l'utilisateur.
Le prérequis pour le déploiement de certificats basé sur SCEP. Les appareils doivent être enregistrés dans le MDM avant de pouvoir recevoir les profils SCEP et WiFi. Les appareils personnels non gérés (BYOD) nécessitent une approche d'intégration distincte.
Exemples concrets
Un établissement Premier Inn de 200 chambres doit sécuriser le WiFi de son personnel pour les tablettes de point de vente et les smartphones du service d'étage. Il utilise actuellement une clé pré-partagée qui a été divulguée à des sous-traitants. Il gère ses appareils via Microsoft Intune et possède un parc mixte d'appareils iOS et Android. L'établissement utilise des points d'accès HPE Aruba.
- Déployer une PKI interne Microsoft AD CS à deux niveaux. Configurer NDES sur un Windows Server dédié et le publier via Azure AD Application Proxy.
- Dans Intune, créer un profil de certificat racine de confiance contenant les certificats de l'AC racine et de l'AC émettrice. Déployer sur un groupe Azure AD "Appareils du personnel de l'établissement".
- Créer un profil de certificat SCEP dans Intune pointant vers l'URL externe de NDES. Définir le format du nom de l'objet sur CN={{AAD_Device_ID}} car il s'agit d'appareils partagés. Définir l'utilisation de la clé sur Signature numérique et Chiffrement de clé, et l'utilisation étendue de la clé sur Authentification client. Déployer sur "Appareils du personnel de l'établissement".
- Créer un profil Wi-Fi pour l'SSID du personnel, en configurant le WPA2-Enterprise et l'EAP-TLS. Sélectionner le profil SCEP pour l'authentification client et l'AC racine pour la validation du serveur. Déployer sur "Appareils du personnel de l'établissement".
- Configurer les paramètres RADIUS de HPE Aruba pour pointer vers Windows NPS. Sur NPS, configurer une stratégie réseau exigeant EAP-TLS et attribuant le VLAN 10 pour les appareils du personnel.
- Une fois que les appareils reçoivent les profils et se connectent avec succès, changer la clé PSK sur l'ancien SSID et planifier sa mise hors service.
Une chaîne de vente au détail de 50 magasins souhaite déployer le 802.1X pour les ordinateurs portables professionnels sur l'ensemble de ses sites. Elle utilise des points d'accès Cisco Meraki et Microsoft Intune. Elle ne souhaite pas déployer et maintenir de serveurs NDES locaux ni d'infrastructure AD CS sur chaque site ou dans son centre de données.
- Mettre en œuvre un service de PKI et de passerelle SCEP basé sur le cloud qui s'intègre à Intune via le protocole SCEP. L'autorité de certification (CA) cloud délivre les certificats ; la passerelle SCEP cloud gère la validation des CSR.
- Configurer le service RADIUS cloud (fourni par le fournisseur de PKI) au sein du tableau de bord Cisco Meraki sous Sans-fil > Contrôle d'accès pour l'SSID d'entreprise. Définir la sécurité sur WPA2-Enterprise et pointer le RADIUS vers le service cloud.
- Dans Intune, créer un profil de certificat racine approuvé contenant le certificat racine de la CA cloud. Déployer sur le groupe d'appareils « Corporate Laptops ».
- Créer un profil de certificat SCEP pointant vers l'URL de la passerelle SCEP cloud. Définir le nom de l'objet sur CN={{UserPrincipalName}} pour l'authentification basée sur l'utilisateur. Déployer sur « Corporate Laptops ».
- Créer un profil WiFi pour l'SSID d'entreprise avec EAP-TLS, en référençant le profil SCEP et la racine de la CA cloud. Déployer sur « Corporate Laptops ».
- Lorsque les ordinateurs portables s'enregistrent dans Intune, ils demandent automatiquement des certificats à la CA cloud via la passerelle SCEP cloud. Aucune infrastructure sur site n'est requise sur l'un des 50 sites.
Questions d'entraînement
Q1. Votre organisation migre de PEAP-MSCHAPv2 vers EAP-TLS. Vous avez déployé avec succès les profils de racine de confiance et SCEP sur votre groupe Azure AD "Corporate Users" dans Intune. Vous déployez le profil WiFi sur "All Corporate Devices". Les utilisateurs signalent qu'ils ne peuvent pas se connecter et le profil WiFi apparaît comme Non applicable.
Conseil : Vérifiez les dépendances de profil et les règles de ciblage de groupe. Intune résout les dépendances de profil en fonction du groupe attribué.
Voir la réponse type
Le problème est lié à une incohérence de ciblage de groupe. Le profil WiFi dépend du profil SCEP, qui ciblait un groupe d'utilisateurs ("Corporate Users"). Le profil WiFi ciblait un groupe d'appareils ("All Corporate Devices"). Intune ne peut pas résoudre la dépendance entre différents types de groupes. La solution consiste à modifier les trois attributions de profil - racine de confiance, SCEP et WiFi - pour cibler le même groupe. Choisissez d'utiliser un groupe d'utilisateurs ou un groupe d'appareils en fonction de votre modèle d'authentification (basé sur l'utilisateur ou sur l'appareil) et appliquez-le de manière cohérente sur les trois profils.
Q2. Un audit de sécurité révèle que lorsqu'un employé est licencié et que son compte Microsoft Entra ID est désactivé, son smartphone d'entreprise peut toujours se connecter au réseau WiFi du personnel pendant une période allant jusqu'à une semaine après son départ.
Conseil : Considérez comment le serveur RADIUS détermine si un certificat est toujours valide après la désactivation du compte. Quel est le mécanisme de communication du statut de révocation ?
Voir la réponse type
Le serveur RADIUS n'effectue pas de vérification stricte de la liste de révocation de certificats (CRL), ou la CRL est publiée trop rarement. Lorsqu'un employé est licencié, le MDM doit désinscrire l'appareil et l'AC doit révoquer le certificat. Cependant, si le serveur RADIUS ne vérifie pas la CRL à chaque tentative d'authentification - ou si la CRL n'est publiée que de manière hebdomadaire - le certificat révoqué continue d'être accepté. La correction implique trois étapes : configurer le serveur RADIUS pour imposer une vérification stricte de la CRL à chaque authentification ; configurer l'AC pour publier la CRL à un intervalle plus court (quotidien ou plus fréquent) ; et s'assurer que le MDM est configuré pour déclencher la révocation du certificat lorsqu'un appareil est désinscrit.
Q3. Vous devez fournir un accès WiFi sécurisé pour des appareils IoT sans écran ni interface (thermostats intelligents, écrans d'affichage dynamique) qui ne peuvent pas exécuter d'agent MDM et ne peuvent pas afficher de Captive Portal. Pouvez-vous utiliser SCEP pour ces appareils et, si ce n'est pas le cas, quelle est l'alternative recommandée ?
Conseil : Pensez aux prérequis pour l'inscription SCEP et aux alternatives qui existent pour les appareils qui ne peuvent pas être inscrits dans un MDM ou interagir avec un navigateur.
Voir la réponse type
SCEP ne peut pas être utilisé pour ces appareils. SCEP nécessite un agent MDM pour recevoir l'URL d'inscription et le mot de passe de défi, générer la paire de clés et installer le certificat résultant. Les appareils IoT sans écran qui ne peuvent pas exécuter d'agent MDM ne peuvent pas participer au flux d'inscription SCEP. Les alternatives recommandées sont : (1) le MAC Authentication Bypass (MAB) combiné à une segmentation VLAN stricte - le serveur RADIUS autorise l'appareil en fonction de son adresse MAC et le place sur un VLAN IoT isolé sans accès aux systèmes de l'entreprise ; (2) si l'appareil le prend en charge, EST (Enrollment over Secure Transport, RFC 7030) peut fournir des certificats aux appareils qui prennent en charge HTTPS mais pas le MDM ; (3) pour les appareils disposant d'une interface de gestion, certains fournisseurs prennent en charge l'inscription SCEP directement via le firmware de l'appareil sans nécessiter d'agent MDM. Dans tous les cas, les appareils IoT doivent être isolés sur un VLAN dédié, quelle que soit la méthode d'authentification utilisée.
Continuer la lecture de cette série
Comment segmenter de manière sécurisée les réseaux WiFi du personnel et des invités : meilleures pratiques pour les LAN d'entreprise
Ce guide fournit aux responsables informatiques et aux architectes réseau un modèle technique et indépendant des fournisseurs pour sécuriser les réseaux LAN d'entreprise en segmentant correctement le trafic WiFi du personnel et des invités. Il couvre l'authentification 802.1X, le RADIUS dans le cloud, l'isolation VLAN et la gestion du cycle de vie des identifiants nécessaires pour éliminer les phrases de passe partagées et protéger les actifs de l'entreprise.
Le meilleur filtrage DNS : un guide complet pour les entreprises
Ce guide de référence technique explique comment le filtrage DNS d'entreprise sécurise les réseaux publics en bloquant les domaines malveillants au niveau de la couche de résolution - avant même qu'une connexion ne soit établie. Il fournit aux directeurs informatiques, architectes réseau et équipes d'exploitation des sites l'architecture de déploiement, la configuration du pare-feu et le contexte de conformité nécessaires pour protéger le WiFi invité dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Purple Shield bloque les logiciels malveillants, les botnets et les contenus inappropriés au niveau DNS sur plus de 80 000 sites actifs.
Comprendre Cisco SUDI : L'identité ancrée dans le matériel pour le contrôle d'accès réseau sécurisé
Ce guide explique comment Cisco SUDI fournit une identité sécurisée par cryptographie et ancrée dans le matériel pour l'infrastructure réseau d'entreprise. Découvrez comment remplacer les adresses MAC falsifiables par des certificats 802.1AR immuables afin de sécuriser le contrôle d'accès réseau de votre site.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.