Intégration de RADIUS-as-a-Service avec les annuaires cloud (Azure AD & Google Workspace)
Ce guide de référence technique détaille comment intégrer RADIUS-as-a-Service avec les annuaires cloud - Microsoft Entra ID et Google Workspace - pour l'authentification WiFi d'entreprise. Il couvre la transition architecturale du NPS sur site vers le RADIUS cloud-native, le déploiement de l'authentification EAP-TLS basée sur les certificats et les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Pour les responsables informatiques et les architectes réseau ayant déjà investi dans l'identité cloud, ce guide comble le fossé entre la gestion des annuaires et la sécurité physique du réseau.
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
Résumé exécutif
Pour les entreprises modernes investies dans les écosystèmes d'identité cloud, relier les annuaires cloud aux réseaux sans fil physiques est un impératif de sécurité critique. Historiquement, l'authentification WiFi reposait sur Active Directory Domain Services sur site et Windows Network Policy Server (NPS). À mesure que les organisations migrent vers Microsoft Entra ID et Google Workspace, cette pile d'authentification sur site devient un handicap - coûteuse à maintenir, difficile à mettre à l'échelle et incompatible avec les modèles de sécurité zero-trust.
Le RADIUS-as-a-Service (RADIUSaaS) change la donne. Un serveur RADIUS hébergé dans le cloud s'intègre directement à votre annuaire cloud, valide les demandes d'authentification en temps réel et renvoie les décisions d'accès à vos points d'accès - sans serveur sur site, sans cycle de correctifs et sans point de défaillance unique. Combinée à l'authentification par certificat EAP-TLS, cette architecture élimine le vol d'identifiants, soutient la conformité PCI-DSS et GDPR, et offre une expérience fluide pour le personnel sur chaque site.
Ce guide couvre le choix d'architecture entre le NPS sur site et le RADIUS natif dans le cloud, le déploiement d'EAP-TLS via Microsoft Intune et Google Admin Console, et les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les hôtels, les parcs de points de vente, les stades et les sites du secteur public. Pour une introduction plus large au contrôle d'accès au réseau, consultez A Guide to Your Network Access Control System.
Analyse technique approfondie : architecture et normes
Le rôle de RADIUS et de l'IEEE 802.1X
La base du WiFi d'entreprise sécurisé est la norme IEEE 802.1X, qui fournit un contrôle d'accès réseau basé sur les ports. Lorsqu'un appareil client (le supplicant) tente de se connecter à un réseau WPA2-Enterprise ou WPA3-Enterprise, le point d'accès sans fil (l'authentificateur) bloque tout le trafic à l'exception des paquets EAP (Extensible Authentication Protocol). Le point d'accès transmet ces paquets à un serveur RADIUS. Le serveur RADIUS valide l'identité par rapport à un service d'annuaire et renvoie un message Access-Accept ou Access-Reject. C'est seulement à ce moment-là que le point d'accès accorde l'accès au réseau.
Ce modèle à trois parties - supplicant, authentificateur, serveur d'authentification - est la pierre angulaire de la sécurité sans fil d'entreprise et est défini par la norme IEEE 802.1X. Il n'a pas fondamentalement changé depuis son introduction. Ce qui a changé, c'est l'emplacement du serveur RADIUS et la manière dont il communique avec votre annuaire.
Architecture RADIUS native dans le cloud
Une architecture RADIUS cloud-native élimine le besoin de serveurs NPS ou FreeRADIUS sur site. Un fournisseur Cloud RADIUS tiers s'intègre directement à Microsoft Entra ID via l'API Microsoft Graph, ou à Google Workspace via Google Secure LDAP ou SAML/OAuth. L'authentification se fait entièrement dans le cloud. Cela s'aligne avec les principes d'accès réseau zero-trust et réduit considérablement les coûts opérationnels.
Le tableau ci-dessous compare les deux principales approches architecturales :
| Dimension | Hybride sur site (NPS) | Cloud-native (RADIUS-as-a-Service) |
|---|---|---|
| Infrastructure | VM Windows Server ou matériel dédié requis | Aucun serveur sur site |
| Source d'identité | AD DS via LDAP/Kerberos | Entra ID ou Google Workspace via API |
| Autorité de certification | ADCS sur site + Intune Connector | PKI Cloud du fournisseur ou Microsoft |
| Haute disponibilité | HA manuelle et répartition de charge | Mise à l'échelle automatique par le fournisseur |
| Temps d'installation | Jours à semaines | Heures |
| Idéal pour | AD hybride, anciens appareils | Entreprises cloud-first, gérées par MDM |
| Complexité opérationnelle | Plus élevée au départ et en continu | Coût opérationnel plus faible |
EAP-TLS vs. PEAP-MSCHAPv2 : le choix critique
Le choix de la méthode EAP est la décision de sécurité la plus importante de ce déploiement. PEAP-MSCHAPv2 repose sur la saisie par les utilisateurs de leurs identifiants de domaine. Cela est vulnérable au vol d'identifiants et aux attaques de type man-in-the-middle. Si un appareil client ne valide pas strictement le certificat du serveur RADIUS - et beaucoup ne le font pas par défaut - un attaquant peut déployer un point d'accès malveillant avec votre SSID, intercepter la liaison EAP et capturer les identifiants. C'est une attaque Evil Twin, et elle est largement documentée.
EAP-TLS (Transport Layer Security) utilise des certificats numériques installés sur l'appareil client pour une authentification mutuelle. Le client et le serveur prouvent tous deux leur identité de manière cryptographique. Il n'y a pas de mot de passe à saisir ou à voler. Dans un environnement Microsoft, les certificats se déploient de manière invisible via Microsoft Intune à l'aide de profils SCEP (Simple Certificate Enrollment Protocol) ou PKCS. C'est la voie recommandée pour tous les nouveaux déploiements et elle est essentielle pour la conformité avec la norme PCI-DSS v4.0 (Exigence 8.3 sur l'authentification forte) et les obligations de protection des données du GDPR.
Google Workspace : la différence d'architecture
Microsoft Entra ID et Google Workspace diffèrent sur un point important concernant l'intégration RADIUS. Microsoft NPS s'intègre nativement à Active Directory, et les fournisseurs Cloud RADIUS se connectent à Entra ID via l'API Microsoft Graph. Google, en revanche, ne propose pas de service RADIUS natif. Vous avez toujours besoin d'un intermédiaire.
Google Secure LDAP est la principale voie d'intégration. Disponible sur les éditions Cloud Identity Premium et Google Workspace Enterprise, elle fournit une interface LDAP traditionnelle pour votre annuaire cloud. Votre serveur Cloud RADIUS se connecte à ldap.google.com sur le port 636 en utilisant des certificats clients générés par Google. À partir de là, le serveur RADIUS interroge l'annuaire de Google pour valider les identifiants ou les appartenances aux groupes, exactement comme il le ferait avec un Active Directory sur site.
Une autre approche consiste à utiliser une intégration basée sur SAML, où le fournisseur Cloud RADIUS s'enregistre en tant qu'application SAML dans la console d'administration Google et effectue une recherche OAuth au moment de l'authentification pour vérifier l'identité de l'utilisateur et ses appartenances aux groupes en temps réel.
-
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.
Guide de mise en œuvre
La mise en œuvre de RADIUS-as-a-Service avec EAP-TLS nécessite de coordonner l'identité, la gestion des appareils et l'infrastructure réseau. L'approche en cinq phases suivante s'applique aux environnements Microsoft Entra ID et Google Workspace.
Phase 1 : préparer l'infrastructure d'identité et de gestion des appareils
Pour Microsoft Entra ID : vérifiez que votre tenant dispose d'une licence Microsoft 365 E3/E5 ou Enterprise Mobility + Security (EMS) E3/E5. Cela inclut Microsoft Intune et l'Accès Conditionnel. Sans Intune, le déploiement automatisé de certificats n'est pas possible.
Pour Google Workspace : confirmez que vous disposez de Cloud Identity Premium ou de Google Workspace Enterprise pour accéder à Google Secure LDAP. Si vous prévoyez d'utiliser EAP-TLS sur des Chromebooks managés, assurez-vous que la console d'administration Google est configurée pour gérer les certificats d'appareils.
Établissez votre infrastructure à clés publiques (PKI). Pour les nouveaux déploiements, une PKI cloud-native fournie par votre fournisseur Cloud RADIUS est fortement recommandée. Les alternatives incluent Microsoft Cloud PKI (disponible avec la licence Intune Suite) ou un déploiement ADCS existant sur site connecté via le connecteur de certificats Microsoft Intune.
Phase 2 : configurer le déploiement de certificats
Parcours Microsoft Intune : dans le centre d'administration Intune, créez un profil de configuration de Certificat de confiance. Téléversez le certificat de l'autorité de certification (CA) racine et déployez-le sur vos groupes d'appareils cibles. Cela garantit que les appareils clients font confiance au certificat présenté par le serveur RADIUS lors de la liaison TLS. Créez ensuite un profil de Certificat SCEP. Pour l'authentification basée sur l'utilisateur, définissez le nom de l'objet (Subject Name) sur CN={{UserPrincipalName}}. Pour l'authentification basée sur l'appareil, utilisez CN={{DeviceName}}. Configurez le nom alternatif de l'objet (Subject Alternative Name) pour inclure le nom principal de l'utilisateur ou l'identifiant de l'appareil.
Parcours console d'administration Google : accédez à Appareils, puis Réseaux, puis Certificats. Téléversez votre CA racine. Configurez un mécanisme de délivrance de certificats - soit une PKI cloud prenant en charge l'intégration SCEP avec Google Workspace, soit le connecteur de certificats Google Cloud qui sert de proxy pour les requêtes vers une autorité de certification Microsoft sur site. Déployez la CA racine et les profils de certificats clients sur les unités organisationnelles appropriées.
Phase 3 : configurer l'intégration Cloud RADIUS
Accordez à votre fournisseur Cloud RADIUS les autorisations API nécessaires dans votre locataire d'annuaire. Pour Entra ID, cela requiert au minimum User.Read.All et GroupMember.Read.All via Microsoft Graph API. Certains fournisseurs requièrent également Device.Read.All pour les vérifications de conformité des appareils. Pour Google Workspace via Secure LDAP, téléchargez le certificat client et la clé depuis la console d'administration Google, puis installez-les sur le service RADIUS.
Définissez vos politiques d'authentification au sein du portail de gestion Cloud RADIUS. Une politique bien structurée pour un environnement d'entreprise : « Autoriser l'accès si le certificat est émis par [CA de confiance] ET que l'utilisateur est membre du groupe [Corporate-WiFi-Users] ET que l'appareil est marqué comme Conforme dans Intune. » Cela applique simultanément l'identité, l'appartenance au groupe et l'état de santé de l'appareil.
Phase 4 : configurer l'infrastructure sans fil
Dans votre contrôleur LAN sans fil ou votre tableau de bord de gestion cloud - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet - ajoutez les adresses IP et les secrets partagés du serveur Cloud RADIUS en tant que serveurs d'authentification RADIUS. Configurez des serveurs principal et secondaire pour la redondance. Définissez le délai d'expiration RADIUS à un minimum de cinq secondes pour s'adapter à la latence du trajet aller-retour vers le cloud.
Créez un nouvel SSID configuré pour WPA2-Enterprise ou WPA3-Enterprise. Pour les déploiements dans l'écriture Hôtellerie, assurez-vous que le SSID d'entreprise est sur un VLAN distinct de tout réseau Guest WiFi. Pour les environnements de Vente au détail, envisagez de déployer le SSID d'entreprise uniquement dans les zones réservées au personnel.
Phase 5 : déployer le profil WiFi via MDM
Microsoft Intune : créez un profil de configuration WiFi. Définissez le SSID pour qu'il corresponde exactement à la configuration de votre infrastructure. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise. Dans les paramètres EAP, sélectionnez EAP-TLS. Associez le profil de certificat SCEP en tant que certificat client et spécifiez le profil de l'autorité de certification racine de confiance (Trusted Root CA). Attribuez ce profil WiFi aux mêmes groupes d'appareils ayant reçu les profils de certificat. Les appareils reçoivent silencieusement le certificat et la configuration WiFi lors de leur prochaine synchronisation Intune.
Google Admin Console : accédez à Appareils, puis Réseaux, puis WiFi. Créez un nouveau profil de réseau WiFi. Définissez le SSID, sélectionnez WPA3-Enterprise, choisissez EAP-TLS et déployez le certificat de l'autorité de certification racine de confiance (Root CA) sur les appareils. Appliquez ce profil à vos unités organisationnelles. Les Chromebooks se connectent de manière transparente et sécurisée.
Bonnes pratiques
Exigez EAP-TLS pour tous les nouveaux déploiements. Ne déployez pas de nouveaux réseaux utilisant PEAP-MSCHAPv2. Les risques de sécurité sont largement documentés et le parcours de migration est simple grâce aux outils MDM modernes.
Impérativement valider les certificats de serveur. Si vous devez utiliser PEAP pour des appareils existants, configurez-les pour valider le certificat du serveur RADIUS. Dans le profil WiFi Intune et le profil WiFi de la Console d'administration Google, il existe un champ pour spécifier l'autorité de certification (CA) de confiance pour la validation du serveur. Ne laissez pas ce champ vide. Cette simple décision de configuration fait toute la différence entre un déploiement sécurisé et un déploiement vulnérable.
Segmentez votre réseau grâce à l'attribution dynamique de VLAN. Utilisez votre serveur RADIUS pour inspecter l'appartenance de l'utilisateur à un groupe dans Microsoft Entra ID ou Google Workspace et attribuez-lui dynamiquement un VLAN spécifique. Le serveur RADIUS renvoie l'attribut Tunnel-Private-Group-Id au point d'accès, ce qui place le client sur le bon VLAN. Cela limite les mouvements latéraux en cas de compromission et répond aux exigences de segmentation réseau de la norme PCI-DSS.
Séparez l'authentification de l'entreprise et des invités. Utilisez EAP-TLS pour les appareils gérés par l'entreprise. Utilisez un Captive Portal avec SSO pour les appareils personnels (BYOD) et les invités. Tenter de configurer manuellement EAP-TLS sur des appareils non gérés génère une surcharge de support excessive. La plateforme Guest WiFi de Purple gère l'accueil des invités séparément, maintenant une séparation claire entre le trafic du personnel et celui des visiteurs.
Surveillez l'expiration des certificats de manière proactive. Configurez des alertes à 90 jours, 30 jours et 7 jours avant l'expiration des certificats. Si le certificat de votre serveur RADIUS expire, tous les appareils perdront leur connexion simultanément. Automatisez le renouvellement dès que votre PKI le permet.
Testez les paramètres de délai d'expiration (timeout) RADIUS. Le Cloud RADIUS introduit une latence réseau liée aux temps de trajet que le serveur NPS local ne présente pas. Réglez le délai d'expiration RADIUS sur vos points d'accès à au moins cinq secondes. Un délai de deux secondes - courant dans les configurations par défaut - entraînera des échecs d'authentification intermittents.
-
Dépannage et atténuation des risques
Les ports de pare-feu bloqués sont la cause principale des échecs lors du déploiement initial. L'authentification RADIUS requiert l'ouverture du port UDP 1812 en sortie depuis votre infrastructure sans fil vers le service Cloud RADIUS. La comptabilité (accounting) RADIUS requiert le port UDP 1813. Vérifiez que ces ports sont ouverts avant toute autre démarche de dépannage.
Les échecs de validation de certificat se manifestent par des rejets d'authentification sans cause apparente. Vérifiez les points suivants dans l'ordre : la date d'expiration du certificat sur le client et sur le serveur RADIUS ; l'écart d'horloge entre l'appareil client et le serveur RADIUS (EAP-TLS repose sur une synchronisation temporelle précise) ; et si le certificat de l'autorité de certification racine (Root CA) a bien été déployé sur l'appareil via MDM.
L'absence d'application de l'appartenance aux groupes est un problème fréquent lorsque les politiques RADIUS font référence à des groupes Microsoft Entra ID ou Google Workspace. Vérifiez que le fournisseur Cloud RADIUS dispose des autorisations API appropriées pour lire les appartenances aux groupes. Dans Microsoft Entra ID, confirmez que le principal de service possède l'autorisation GroupMember.Read.All. Dans Google Workspace, confirmez que le client Secure LDAP est autorisé à lire les informations de groupe.
La défaillance de l'attribution du VLAN indique généralement un décalage entre les valeurs d'attribut RADIUS et les ID de VLAN configurés sur l'infrastructure sans fil. Confirmez que Tunnel-Type est défini sur VLAN (valeur 13), que Tunnel-Medium-Type est défini sur 802 (valeur 6), et que Tunnel-Private-Group-Id correspond à l'ID de VLAN configuré sur le commutateur ou le contrôleur.
Les appareils BYOD échouant à l'authentification EAP-TLS indiquent généralement que le certificat client n'a pas été déployé avec succès. Pour les appareils gérés par Intune, vérifiez le magasin de certificats de l'appareil dans le centre d'administration Intune. Pour les Chromebooks gérés par Google, vérifiez que le profil de certificat est attribué à la bonne unité organisationnelle et que l'appareil s'est synchronisé récemment.
-
ROI et impact commercial
Le passage au Cloud RADIUS offre des économies opérationnelles mesurables. Un RADIUS sur site nécessite au minimum deux serveurs pour la haute disponibilité, l'application continue de correctifs de système d'exploitation, la gestion des certificats et du temps d'ingénierie spécialisé. Le temps passé par un seul ingénieur sur la maintenance de RADIUS sur une année dépasse généralement le coût annuel d'un abonnement Cloud RADIUS.
L'intérêt commercial va bien au-delà de la réduction des coûts. En liant l'accès réseau à des identités cloud vérifiées, vous obtenez :
Une désactivation instantanée. La désactivation d'un utilisateur dans Microsoft Entra ID ou Google Workspace révoque immédiatement son accès au réseau sur tous les sites. Il n'y a pas de délai, pas de processus manuel et aucun risque qu'un ancien employé conserve un accès WiFi. Cela répond directement aux obligations du GDPR concernant les droits d'accès aux données.
Des analyses plus riches. Des plateformes comme WiFi Analytics de Purple fournissent des données plus riches sur l'utilisation de l'espace et les parcours des visiteurs lorsque l'accès au réseau est lié à des identités authentifiées. Vous passez d'adresses MAC anonymes à des utilisateurs nommés et authentifiés, ce qui transforme la qualité des informations disponibles pour les équipes opérationnelles et marketing.
Des preuves de conformité. L'authentification EAP-TLS génère des journaux d'accès détaillés - qui s'est connecté, à partir de quel appareil, à quel endroit et à quelle heure. Cette piste d'audit répond à l'exigence 10 de PCI-DSS (journalisation et surveillance) et aux obligations de responsabilité du GDPR.
Une cohérence multi-sites. Un seul service Cloud RADIUS authentifie tous vos sites avec des politiques cohérentes, gérées depuis un tableau de bord unique. Ajouter un nouvel hôtel, un nouveau magasin ou un nouveau site revient simplement à ajouter ses points d'accès à la configuration RADIUS - et non à expédier et configurer un autre serveur. Pour les organisations gérant de grands parcs, il s'agit d'un avantage opérationnel de taille.
Pour les opérateurs de Transport et les établissements de Santé où la disponibilité du réseau est essentielle d'un point de vue opérationnel, les fournisseurs de Cloud RADIUS proposent généralement des SLA de disponibilité de 99,999 % avec basculement multi-régions intégré. Purple fonctionne à un taux de disponibilité de 99,999 % sur plus de 80 000 sites actifs, avec 440 millions de connexions traitées en 2024 (données internes de Purple, 2024).
Pour approfondir des sujets connexes, consultez WAN Computer Definition: A Practical Guide for 2026 et World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide.
Définitions clés
RADIUS (Remote Authentication Dial-In User Service)
Un protocole réseau défini dans la RFC 2865 qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA) pour les utilisateurs se connectant à un service réseau. Le serveur RADIUS agit comme le moteur de décision entre vos points d'accès et votre annuaire d'identité.
Chaque réseau WiFi d'entreprise WPA2-Enterprise ou WPA3-Enterprise dépend d'un serveur RADIUS. Sans lui, l'authentification IEEE 802.1X ne fonctionne pas.
RADIUS-as-a-Service (RADIUSaaS)
Une implémentation RADIUS hébergée dans le cloud et fournie en tant que SaaS. Le fournisseur gère l'infrastructure, les correctifs, la haute disponibilité et les intégrations avec les fournisseurs d'identité. Vous configurez les politiques d'authentification et pointez vos points d'accès vers les IP du Cloud RADIUS.
RADIUSaaS élimine le besoin de serveurs NPS ou FreeRADIUS sur site, supprimant ainsi le matériel associé, les correctifs du système d'exploitation et les frais de maintenance spécialisés.
IEEE 802.1X
Une norme IEEE pour le contrôle d'accès réseau basé sur les ports. Elle définit le modèle d'authentification à trois parties : le suppliant (appareil client), l'authentificateur (point d'accès ou commutateur) et le serveur d'authentification (serveur RADIUS). L'authentificateur bloque tout le trafic jusqu'à ce que le serveur RADIUS accorde l'accès.
La norme fondamentale pour l'authentification WiFi d'entreprise. WPA2-Enterprise et WPA3-Enterprise reposent tous deux sur la norme 802.1X.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Une méthode d'authentification définie dans la RFC 5216 qui utilise des certificats numériques à la fois sur le serveur RADIUS et sur l'appareil client pour une authentification mutuelle. Aucune des deux parties n'envoie de mot de passe. Le client présente son certificat ; le serveur le valide par rapport à l'annuaire en temps réel.
La référence absolue en matière de sécurité WiFi d'entreprise. Élimine le vol d'identifiants, le phishing et la charge de support technique liée aux mots de passe. Requis pour la conformité PCI-DSS sur les réseaux de données de titulaires de cartes.
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
Une méthode d'authentification qui crée un tunnel TLS chiffré, puis y transmet le nom d'utilisateur et le mot de passe de l'utilisateur. Vulnérable aux attaques Evil Twin si le client ne valide pas strictement le certificat du serveur RADIUS.
Le choix par défaut hérité pour le WiFi d'entreprise. Toujours largement déployé, il doit toutefois être migré vers EAP-TLS dans tous les nouveaux déploiements et ceux existants lorsque cela est possible.
Microsoft Entra ID
Le service cloud de gestion des identités et des accès de Microsoft, anciennement appelé Azure Active Directory (Azure AD). Il gère les identités des utilisateurs, les adhésions aux groupes, la conformité des appareils et les politiques d'accès conditionnel.
La source d'identité principale pour Cloud RADIUS dans les environnements centrés sur Microsoft. Les fournisseurs Cloud RADIUS se connectent à Entra ID via l'API Microsoft Graph.
Google Secure LDAP
Un service géré disponible sur les éditions Cloud Identity Premium et Google Workspace Enterprise qui fournit une interface LDAP traditionnelle vers l'annuaire cloud de Google. Les serveurs RADIUS se connectent à ldap.google.com sur le port 636 en utilisant des certificats clients.
Le chemin d'intégration principal pour connecter un serveur Cloud RADIUS à Google Workspace. Google ne proposant pas de service RADIUS natif, Secure LDAP sert de passerelle.
PKI (Public Key Infrastructure)
L'ensemble de rôles, de politiques, de matériel, de logiciels et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques. Une PKI est requise pour émettre les certificats clients et serveurs utilisés dans l'authentification EAP-TLS.
Les options de PKI cloud natives des fournisseurs RADIUS ou de Microsoft (Cloud PKI) éliminent le besoin de services de certificats Active Directory (ADCS) sur site.
SCEP (Simple Certificate Enrollment Protocol)
Un protocole qui permet aux appareils de demander et de recevoir automatiquement des certificats numériques de la part d'une autorité de certification. Utilisé par Microsoft Intune et Google Admin Console pour déployer des certificats clients sur des appareils gérés sans intervention de l'utilisateur.
Les profils SCEP dans Intune constituent le mécanisme par lequel les appareils d'entreprise reçoivent de manière transparente les certificats clients requis pour l'authentification EAP-TLS.
Dynamic VLAN assignment
Une fonctionnalité RADIUS qui renvoie les attributs d'attribution de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) au point d'accès en fonction de l'appartenance au groupe d'annuaire de l'utilisateur authentifié. L'AP place automatiquement le client sur le VLAN spécifié.
Permet une segmentation réseau granulaire sans configuration manuelle de VLAN par appareil. Les collaborateurs ayant des rôles ou des départements différents atterrissent sur des segments de réseau distincts, ce qui limite les déplacements latéraux et répond aux exigences de segmentation PCI-DSS.
Exemples concrets
Un hôtel de 200 chambres migre le réseau de son personnel d'arrière-guichet d'un serveur NPS vieillissant sur site vers une solution cloud-native. L'hôtel est récemment passé à Microsoft Entra ID et Microsoft 365 E5. Les appareils du personnel sont des ordinateurs portables Windows gérés par Intune. L'infrastructure sans fil est Cisco Meraki. L'hôtel souhaite que le personnel se connecte automatiquement sans invite de mot de passe, et exige une révocation instantanée lorsqu'un membre du personnel quitte l'entreprise.
Déployez une solution Cloud RADIUS avec intégration Entra ID. Étape 1 : accordez au fournisseur Cloud RADIUS les autorisations Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) dans le locataire Entra ID. Étape 2 : dans Intune, créez un profil de certificat approuvé avec la CA racine Cloud RADIUS et déployez-le sur le groupe "Tous les appareils d'entreprise". Étape 3 : créez un profil de certificat SCEP avec le nom d'objet CN={{UserPrincipalName}} et déployez-le sur le même groupe. Étape 4 : configurez la politique d'authentification Cloud RADIUS : autorisez l'accès si le certificat est émis par [CA approuvée] ET que l'utilisateur est membre du groupe Entra ID [Hotel-Staff-WiFi] ET que l'appareil est conforme à Intune. Étape 5 : dans le tableau de bord Cisco Meraki, ajoutez les adresses IP principale et secondaire de Cloud RADIUS en tant que serveurs RADIUS sur le SSID de l'arrière-guichet. Définissez le délai d'expiration RADIUS à 5 secondes. Étape 6 : dans Intune, créez un profil WiFi WPA3-Enterprise pour le SSID de l'arrière-guichet, en spécifiant EAP-TLS et en liant le profil de certificat SCEP. Déployez sur le groupe "Tous les appareils d'entreprise". Les appareils reçoivent silencieusement le certificat et le profil WiFi lors de la prochaine synchronisation Intune et se connectent automatiquement. Lorsqu'un membre du personnel s'en va, la désactivation de son compte Entra ID révoque immédiatement l'accès au réseau sur tous les sites.
Une chaîne de magasins de détail comprenant 50 points de vente utilise Google Workspace et gère un parc de 500 Chromebooks utilisés par les employés pour l'inventaire et les opérations de point de vente. Ils utilisent actuellement un WPA2 PSK partagé pour le réseau opérationnel des magasins, ce qui crée un risque de sécurité en cas de perte ou de vol d'appareils. Ils souhaitent passer à l'authentification 802.1X sans déployer de serveurs locaux dans chaque magasin. Leur infrastructure sans fil est HPE Aruba.
Déployez une solution Cloud RADIUS avec intégration Google Workspace via Google Secure LDAP. Étape 1 : dans la console d'administration Google, accédez à Applications, puis LDAP, et ajoutez un nouveau client LDAP pour le service Cloud RADIUS. Configurez les autorisations de lecture pour les informations utilisateur et l'appartenance aux groupes. Téléchargez le certificat client et la clé générés. Étape 2 : configurez le service Cloud RADIUS avec les informations d'identification Google Secure LDAP. Étape 3 : configurez une infrastructure PKI cloud pour délivrer des certificats aux Chromebooks. Dans la console d'administration Google, accédez à Appareils, puis Réseaux, puis Certificats, et importez la CA racine. Configurez le profil d'attribution de certificat et appliquez-le à l'unité organisationnelle Store-Associates. Étape 4 : dans la console d'administration Google, créez un profil WiFi WPA3-Enterprise pour l'SSID des opérations en magasin. Définissez EAP-TLS, associez la CA racine et appliquez à l'unité organisationnelle Store-Associates. Les Chromebooks reçoivent le certificat et le profil WiFi lors de la prochaine synchronisation de la console d'administration. Étape 5 : dans HPE Aruba Central, configurez l'SSID des opérations en magasin avec WPA3-Enterprise et ajoutez les IP principale et secondaire du Cloud RADIUS. Définissez le délai d'expiration RADIUS sur 5 secondes. Configurez l'attribution dynamique de VLAN pour placer les associés du magasin sur le VLAN 20 (opérations magasin) en fonction de leur appartenance au groupe Google Workspace. Lorsqu'un Chromebook est perdu ou volé, son retrait de l'unité organisationnelle Store-Associates révoque immédiatement son accès au réseau.
Questions d'entraînement
Q1. Votre organisation migre d'Active Directory sur site vers Microsoft Entra ID. Vous utilisez actuellement PEAP-MSCHAPv2 pour l'authentification WiFi sur 300 ordinateurs portables d'entreprise gérés par Intune. Vous disposez de licences Microsoft 365 E5. Quel est le moyen le plus sécurisé et le plus efficace sur le plan opérationnel pour migrer l'authentification WiFi vers une architecture cloud native ?
Conseil : Prenez en compte les vulnérabilités de l'authentification basée sur les identifiants, les capacités de Microsoft Intune pour le déploiement de certificats, et la nécessité d'éviter les dépendances vis-à-vis des infrastructures sur site.
Voir la réponse type
Déployez une solution Cloud RADIUS avec intégration Entra ID. Utilisez Microsoft Intune pour déployer un profil de certificat de confiance (Root CA) et un profil de certificat SCEP sur les 300 ordinateurs portables. Configurez la politique d'authentification Cloud RADIUS pour exiger un certificat valide de l'autorité de certification approuvée et l'appartenance au groupe Entra ID Corporate-WiFi-Users. Créez un profil WiFi WPA3-Enterprise dans Intune en spécifiant EAP-TLS et associez le profil de certificat SCEP. Les appareils reçoivent de manière transparente le certificat et la configuration WiFi lors de la synchronisation Intune suivante. Cela élimine le risque de vol d'identifiants lié à PEAP-MSCHAPv2, supprime la dépendance NPS sur site et permet une révocation instantanée lorsqu'un compte Entra ID est désactivé.
Q2. Un utilisateur de votre hôtel signale qu'il ne parvient pas à se connecter au WiFi du personnel administratif après son retour de deux semaines de vacances. Les autres membres du personnel se connectent sans problème. Le réseau utilise EAP-TLS avec des certificats déployés via Intune. Quelles sont les trois causes les plus probables, par ordre de probabilité ?
Conseil : EAP-TLS repose sur des ressources cryptographiques sensibles au facteur temps et sur des recherches d'annuaire en temps réel.
Voir la réponse type
- Le certificat client de l'utilisateur a expiré. Les certificats ont une période de validité définie, et si l'appareil était hors ligne pendant la fenêtre de renouvellement, le profil SCEP peut ne pas l'avoir renouvelé. Vérifiez la date d'expiration du certificat dans le magasin de certificats d'appareil d'Intune. 2. L'horloge système de l'appareil est considérablement désynchronisée (décalage horaire), ce qui entraîne l'échec de la validation du certificat. EAP-TLS valide les horodatages des certificats ; une horloge désynchronisée de plus de cinq minutes provoquera des échecs d'authentification. 3. Le compte Entra ID de l'utilisateur a été placé dans un autre groupe pendant son absence (par exemple, déplacé du personnel actif vers une autre unité d'organisation), et la politique d'authentification RADIUS ne correspond plus à son appartenance de groupe. Vérifiez les appartenances de groupe de l'utilisateur dans Entra ID par rapport à la politique RADIUS.
Q3. Vous êtes le responsable informatique d'une chaîne de vente au détail comptant 80 magasins. Vous utilisez Google Workspace et gérez 400 Chromebooks via la Google Admin Console. Vous souhaitez remplacer le WPA2 PSK partagé actuel sur le réseau opérationnel des magasins par une authentification 802.1X. Vous n'avez aucun serveur sur site dans aucun de vos magasins. Quelle architecture déployez-vous, et quel est le principal avantage en matière de sécurité par rapport à l'approche PSK actuelle ?
Conseil : Réfléchissez à ce qui se produit lorsqu'un Chromebook est perdu ou volé selon chaque modèle d'authentification.
Voir la réponse type
Déployez un service Cloud RADIUS avec intégration Google Secure LDAP. Configurez une PKI cloud pour émettre des certificats vers les Chromebooks. Dans la Google Admin Console, déployez la CA racine et un profil de certificat client SCEP sur l'unité d'organisation Store-Associates. Créez un profil WiFi WPA3-Enterprise spécifiant EAP-TLS et déployez-le sur cette même unité d'organisation. Configurez les points d'accès HPE Aruba (ou équivalent) de chaque magasin pour pointer vers le service Cloud RADIUS. Le principal avantage en matière de sécurité : avec le PSK partagé actuel, un Chromebook perdu ou volé conserve l'accès WiFi jusqu'à ce que la clé PSK soit modifiée dans les 80 magasins - un processus perturbateur et chronophage. Avec EAP-TLS, la suppression de l'appareil de l'unité d'organisation Store-Associates dans la Google Admin Console révoque immédiatement son certificat et son accès au réseau, sans aucun impact sur les autres appareils.
Q4. Lors d'un déploiement Cloud RADIUS, vous configurez l'SSID sur des points d'accès Cisco Meraki et déployez le profil WiFi Intune sur un groupe pilote de 20 appareils. Aucun de ces appareils ne parvient à se connecter. L'état de l'appareil dans Intune indique que le certificat et le profil WiFi ont été déployés avec succès. Quelle est la première chose à vérifier ?
Conseil : La cause la plus fréquente d'échec d'un premier déploiement n'est pas une erreur de configuration de la politique RADIUS ou du certificat.
Voir la réponse type
Vérifiez que les ports UDP 1812 et 1813 sont ouverts en sortie depuis les points d'accès Cisco Meraki (ou l'infrastructure cloud Meraki) vers les adresses IP du serveur Cloud RADIUS. Les ports de pare-feu bloqués sont la cause principale d'échec lors d'un premier déploiement. Le fait que les certificats et les profils WiFi soient déployés avec succès exclut les problèmes de configuration d'Intune. Les vérifications suivantes sont : une non-correspondance de la clé secrète partagée RADIUS entre Meraki et le service Cloud RADIUS ; un délai d'attente RADIUS configuré trop bas (augmentez-le à au moins 5 secondes) ; et si les IP du serveur Cloud RADIUS sont correctement saisies dans la configuration de l'SSID Meraki.
Continuer la lecture de cette série
Comment implémenter l'authentification 802.1X avec Cloud RADIUS
Ce guide de référence technique fournit un cadre complet pour implémenter l'authentification 802.1X avec Cloud RADIUS sur des parcs d'entreprises distribués. Il détaille l'architecture, la sélection de la méthode EAP, le séquençage du déploiement et les stratégies d'atténuation des risques nécessaires pour sécuriser l'accès au réseau tout en éliminant les coûts opérationnels liés aux infrastructures sur site.
Qu'est-ce que Cloud RADIUS ? Le guide complet du RADIUS-as-a-Service
Ce guide complet explore Cloud RADIUS (RADIUS-as-a-Service), détaillant son architecture, ses méthodes EAP et ses stratégies d'implémentation. Il fournit aux responsables IT des conseils pratiques pour migrer de serveurs sur site vers un modèle d'authentification basé sur le cloud, évolutif, sécurisé et conforme.
Migration de RADIUS sur site (NPS) vers RADIUS-as-a-Service
Ce guide de référence détaille l'architecture technique, la méthodologie de mise en œuvre et l'impact commercial de la migration d'un serveur Microsoft Network Policy Server (NPS) sur site vers un modèle RADIUS-as-a-Service cloud-native. Il fournit aux responsables informatiques et aux architectes réseau des cadres pratiques pour réduire les coûts opérationnels, éliminer les points de défaillance uniques et sécuriser l'authentification d'entreprise sur des sites distribués.
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.