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 un RADIUS cloud-native, le déploiement de l'authentification EAP-TLS basée sur des certificats, ainsi que 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 déjà investis dans l'identité cloud, ce guide comble le fossé entre la gestion des annuaires et la sécurité du réseau physique.
Écouter ce guide
Voir la transcription du podcast
Synthèse
Pour les entreprises modernes ayant investi 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 s'appuyait 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 à faire évoluer 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 requêtes d'authentification en temps réel et renvoie les décisions d'accès à vos points d'accès, sans serveurs sur site, sans cycles de mise à jour et sans point de défaillance unique. Combinée à l'authentification basée sur les certificats EAP-TLS, cette architecture élimine le vol d'identifiants, prend en charge la conformité PCI DSS et GDPR, et offre une expérience fluide aux collaborateurs sur chaque site.
Ce guide couvre le choix d'architecture entre le NPS sur site et le RADIUS cloud-native, le déploiement d'EAP-TLS via Microsoft Intune et Google Admin Console, ainsi que les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les hôtels, les réseaux de points de vente, les stades et les sites du secteur public. Pour une introduction plus large au contrôle d'accès réseau, consultez Un guide de votre système de contrôle d'accès réseau .
Analyse technique approfondie : architecture et normes
Le rôle de RADIUS et de l'IEEE 802.1X
Le fondement de la sécurité du WiFi d'entreprise 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. Ce n'est qu'alors que le point d'accès accorde l'accès au réseau.
Ce modèle à trois tiers (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 sa manière de communiquer avec votre annuaire.
Architecture RADIUS cloud-native
Une architecture RADIUS cloud-native élimine le besoin de serveurs NPS ou FreeRADIUS sur site. Un fournisseur tiers de Cloud RADIUS s'intègre directement avec Microsoft Entra ID via l'API Microsoft Graph, ou avec Google Workspace via Google Secure LDAP ou SAML/OAuth. L'authentification se fait entièrement dans le cloud. Cela s'aligne sur les principes d'accès réseau Zero Trust et réduit considérablement la surcharge opérationnelle.
Le tableau ci-dessous compare les deux principales approches architecturales :
| Dimension | Hybride sur site (NPS) | Cloud-native (RADIUSaaS) |
|---|---|---|
| Infrastructure | VM Windows Server ou matériel physique 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 de Microsoft |
| Haute disponibilité | HA manuelle et répartition de charge | Évolutivité automatique par le fournisseur |
| Temps de configuration | De quelques jours à quelques semaines | Quelques heures |
| Idéal pour | AD hybride, appareils existants | Organisations orientées Cloud, gérées par MDM |
| Complexité opérationnelle | Plus élevée au départ et en continu | Surcharge opérationnelle réduite |
EAP-TLS vs. PEAP-MSCHAPv2 : le choix critique
Le choix de la méthode EAP est la décision de sécurité la plus cruciale de ce déploiement. PEAP-MSCHAPv2 repose sur la saisie des identifiants de domaine par les utilisateurs. Cette méthode est vulnérable au vol d'identifiants et aux attaques de type de l'homme du milieu (man-in-the-middle). Si un appareil client ne valide pas strictement le certificat du serveur RADIUS — ce que beaucoup ne 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. Il s'agit d'une attaque de type 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 aucun mot de passe à saisir ou à voler. Dans un environnement Microsoft, les certificats se déploient de manière invisible via Microsoft Intune en utilisant des 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 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 architecturale
Microsoft Entra ID et Google Workspace diffèrent sur un point important concernant l'intégration RADIUS. Microsoft NPS s'intègre nativement avec Active Directory, et les fournisseurs de Cloud RADIUS se connectent à Entra ID via l'API Microsoft Graph. Google, en revanche, ne propose pas de service RADIUS natif. Vous aurez 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, il fournit une interface LDAP traditionnelle à 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 pour vous. À partir de ce point, le serveur RADIUS interroge l'annuaire de Google pour valider les identifiants ou les appartenances à des groupes, tout comme il interrogerait un Active Directory sur site.
Une autre approche utilise 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 à des groupes en temps réel.
Guide de mise en œuvre
La mise en œuvre de RADIUSaaS 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 de gestion de l'identité et des appareils
Pour Microsoft Entra ID : vérifiez que votre locataire dispose de licences 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 géré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 sur site existant connecté via le connecteur de certificat Microsoft Intune.
Phase 2 : configurer le déploiement des certificats
Parcours Microsoft Intune : dans le centre d'administration Intune, créez un profil de configuration de Certificat approuvé. Téléchargez le certificat de l'autorité de certification racine (Root CA) 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 poignée de main TLS. Ensuite, créez un profil de Certificat SCEP. Pour une authentification basée sur l'utilisateur, définissez le nom de l'objet sur CN={{UserPrincipalName}}. Pour une authentification basée sur l'appareil, utilisez CN={{DeviceName}}. Définissez le nom alternatif de l'objet pour inclure le nom principal de l'utilisateur (UPN) ou l'identifiant de l'appareil.
Parcours console d'administration Google : accédez à Appareils, puis Réseaux, puis Certificats. Téléchargez votre autorité de certification racine (Root CA). Configurez un mécanisme de délivrance de certificats - soit une PKI cloud qui prend en charge l'intégration SCEP avec Google Workspace, soit le connecteur de certificat Google Cloud qui sert de proxy pour les requêtes vers une autorité de certification Microsoft sur site. Déployez l'autorité de certification racine et les profils de certificat client sur les unités d'organisation 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 nécessite au minimum User.Read.All et GroupMember.Read.All via l'API Microsoft Graph. Certains fournisseurs exigent é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 et installez-les sur le service RADIUS.
Définissez vos politiques d'authentification dans le 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 [Trusted CA] 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 la 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 du serveur Cloud RADIUS et les secrets partagés en tant que serveurs d'authentification RADIUS. Configurez des serveurs principal et secondaire pour la redondance. Définissez le délai d'expiration RADIUS sur un minimum de cinq secondes pour tenir compte de la latence des trajets aller-retour vers le cloud.
Créez un nouveau SSID configuré pour WPA2-Enterprise ou WPA3-Enterprise. Pour les déploiements dans l' Hôtellerie , assurez-vous que le SSID d'entreprise se trouve 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. Attribuez ce profil WiFi aux mêmes groupes d'appareils qui ont reçu les profils de certificat. Les appareils reçoivent silencieusement le certificat et la configuration WiFi lors de leur prochaine synchronisation Intune.
Console d'administration Google : accédez à Appareils, puis Réseaux, puis Wi-Fi. 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 sur les appareils. Appliquez ce profil à vos unités organisationnelles. Les Chromebooks se connectent silencieusement et en toute sécurité.
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 chemin de migration est simple avec les outils MDM modernes.
Imposez une validation stricte du certificat de serveur. Si vous devez utiliser PEAP pour des appareils existants, configurez les appareils pour valider le certificat du serveur RADIUS. Dans le profil WiFi d'Intune et dans le profil WiFi de la Console d'administration Google, il y a un champ pour spécifier l'AC 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 avec l'attribution dynamique de VLAN. Utilisez votre serveur RADIUS pour inspecter l'appartenance de l'utilisateur à un groupe dans Entra ID ou Google Workspace et attribuez-lui dynamiquement un VLAN différent. Le serveur RADIUS renvoie l'attribut Tunnel-Private-Group-Id au point d'accès, qui place le client sur le bon VLAN. Cela limite les mouvements latéraux en cas de compromission et soutient les exigences de segmentation réseau de la norme PCI DSS.
Séparez l'authentification d'entreprise de celle des invités. Utilisez EAP-TLS pour les appareils gérés par l'entreprise. Utilisez un Captive Portal avec SSO pour le BYOD et les appareils des invités. Tenter de configurer manuellement EAP-TLS sur des appareils non gérés crée une surcharge de support excessive. La plateforme Guest WiFi de Purple gère l'onboarding 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 de surveillance à 90 jours, 30 jours et sept jours avant l'expiration du certificat. Si le certificat de votre serveur RADIUS expire, tous les appareils perdent la connectivité simultanément. Automatisez le renouvellement là où votre PKI le permet.
Testez les paramètres de délai d'attente RADIUS. Le cloud RADIUS introduit une latence de réseau aller-retour que l'NPS sur site n'a pas. Définissez le délai d'attente RADIUS sur vos points d'accès à au moins cinq secondes. Un délai d'attente de deux secondes - courant dans les configurations par défaut - provoquera des échecs d'authentification intermittents.
Dépannage et atténuation des risques
Les ports de pare-feu bloqués sont la cause principale de l'échec initial du déploiement. L'authentification RADIUS nécessite le port UDP 1812 sortant de votre infrastructure sans fil vers le service Cloud RADIUS. La comptabilité RADIUS nécessite le port UDP 1813. Vérifiez qu'ils sont ouverts avant tout autre dépannage.
Les échecs de validation de certificat se présentent sous forme de rejets d'authentification sans cause évidente. Vérifiez dans l'ordre : l'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'AC racine a été déployé avec succès sur l'appareil via le MDM.
La non-application de l'appartenance au groupe est un problème courant lorsque les politiques RADIUS font référence à des groupes Entra ID ou Google Workspace. Vérifiez que le fournisseur de Cloud RADIUS dispose des autorisations API correctes pour lire les appartenances aux groupes. Dans Entra ID, confirmez que le principal de service possède l'autorisation GroupMember.Read.All. Dans Google Workspace, confirmez que le client Secure LDAP a l'autorisation de lire les informations de groupe.
L'attribution de VLAN ne fonctionne pas indique généralement une incompatibilité entre les valeurs des attributs RADIUS et les ID de VLAN configurés sur l'infrastructure sans fil. Confirmez que Tunnel-Type est défini sur VLAN (valeur 13), Tunnel-Medium-Type 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 qui échouent à l'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 d'OS, la gestion des certificats et du temps d'ingénierie spécialisé. Le temps passé par un seul ingénieur sur la maintenance du RADIUS sur une année dépasse généralement le coût annuel d'un abonnement Cloud RADIUS.
L'analyse de rentabilisation va au-delà de la réduction des coûts. En liant l'accès au réseau à des identités cloud vérifiées, vous obtenez :
Une désinscription instantanée. La désactivation d'un utilisateur dans 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 soutient directement les obligations du GDPR concernant les droits d'accès aux données.
Des analyses plus riches. Les 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é, depuis quel appareil, à quel endroit et à quelle heure. Cette piste d'audit prend en charge l'exigence 10 de la norme PCI DSS (journalisation et surveillance) et les 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 magasin ou un lieu consiste 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 significatif.
Pour les opérateurs de Transport et les établissements de Santé où la disponibilité du réseau est cruciale sur le plan 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 avec 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 Purple, 2024).
Pour en savoir plus sur des sujets connexes, consultez Définition du réseau informatique WAN : un guide pratique pour 2026 et Journée mondiale du WiFi 2026 : comment votre établissement peut aider à réduire la fracture numérique .
Définitions clés
RADIUS (Remote Authentication Dial-In User Service)
Un protocole de 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és.
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 service managé. Le fournisseur assure la maintenance de l'infrastructure, l'application des 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 RADIUS cloud.
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 coûts de maintenance spécialisée.
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 en temps réel par rapport à l'annuaire.
La référence absolue en matière de sécurité WiFi d'entreprise. Élimine le vol d'identifiants, le phishing et les frais de support technique liés 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 envoie le nom d'utilisateur et le mot de passe de l'utilisateur. Vulnérable aux attaques de type "Evil Twin" si le client ne valide pas strictement le certificat du serveur RADIUS.
La valeur par défaut héritée pour le WiFi d'entreprise. Encore largement déployée, elle devrait être migrée vers EAP-TLS dans tous les nouveaux déploiements et ceux existants lorsque cela est possible.
Microsoft Entra ID
Le service de gestion des identités et des accès basé sur le cloud de Microsoft, anciennement connu sous le nom d'Azure Active Directory (Azure AD). Gère les identités des utilisateurs, les appartenances aux groupes, la conformité des appareils et les politiques d'accès conditionnel.
La principale source d'identité pour le Cloud RADIUS dans les environnements centrés sur Microsoft. Les fournisseurs de Cloud RADIUS se connectent à Entra ID via l'API Microsoft Graph.
Google Secure LDAP
Un service managé disponible sur les éditions Cloud Identity Premium et Google Workspace Enterprise qui fournit une interface LDAP traditionnelle pour l'annuaire cloud de Google. Les serveurs RADIUS se connectent à ldap.google.com sur le port 636 à l'aide de certificats clients.
La principale voie d'intégration 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 des rôles, politiques, matériels, logiciels et 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 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 la console d'administration Google pour déployer des certificats clients sur des appareils gérés sans intervention de l'utilisateur.
Les profils SCEP dans Intune sont le mécanisme par lequel les appareils de l'entreprise reçoivent de manière transparente les certificats clients nécessaires à l'authentification EAP-TLS.
Dynamic VLAN assignment
Une fonctionnalité RADIUS qui renvoie des attributs d'attribution de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) au point d'accès en fonction de l'appartenance de l'utilisateur authentifié à un groupe d'annuaire. Le point d'accès place automatiquement le client sur le VLAN spécifié.
Permet une segmentation granulaire du réseau sans configuration manuelle des VLAN par appareil. Les employés ayant des rôles ou départements différents atterrissent sur des segments de réseau distincts, limitant les déplacements latéraux et répondant 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 sur site vieillissant vers une solution cloud-native. L'hôtel a récemment migré vers 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 a besoin que le personnel se connecte automatiquement sans saisie 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 de l'API Microsoft Graph (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é (Trusted Certificate) avec l'autorité de certification racine (Root CA) du 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 de sujet 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 [Trusted CA] 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 du Cloud RADIUS en tant que serveurs RADIUS sur le SSID d'arrière-guichet. Définissez le délai d'expiration RADIUS sur 5 secondes. Étape 6 : dans Intune, créez un profil WiFi WPA3-Enterprise pour le SSID d'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 comptant 50 points de vente utilise Google Workspace et gère une flotte de 500 Chromebooks utilisés par les vendeurs pour l'inventaire et les opérations de point de vente. Ils utilisent actuellement une clé WPA2 PSK partagée pour le réseau opérationnel des magasins, ce qui présente 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 identifiants Google Secure LDAP. Étape 3 : configurez une PKI cloud pour émettre des certificats aux Chromebooks. In la console d'administration Google, accédez à Appareils, puis Réseaux, puis Certificats, et importez la Root CA. Configurez le profil d'émission 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 le SSID opérationnel des magasins. Définissez EAP-TLS, liez la Root CA, 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 le SSID des opérations du 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 vendeurs sur le VLAN 20 (opérations du magasin) en fonction de leur appartenance au groupe Google Workspace. Lorsqu'un Chromebook est perdu ou volé, le retirer 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. Quelle est la voie la plus sécurisée et la plus efficace sur le plan opérationnel pour migrer l'authentification WiFi vers une architecture cloud native ?
Conseil : Considérez les vulnérabilités de l'authentification par identifiants, les capacités de Microsoft Intune pour le déploiement de certificats, et la nécessité d'éviter les dépendances vis-à-vis d'une infrastructure sur site.
Voir la réponse type
Déployez une solution Cloud RADIUS intégrée à 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 de confiance 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 au profil de certificat SCEP. Les appareils reçoivent silencieusement le certificat et la configuration WiFi lors de la prochaine synchronisation Intune. Cela élimine le risque de vol d'identifiants 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 peut pas se connecter au WiFi du personnel de l'arrière-guichet 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 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érive de l'horloge), 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 entraînera des échecs d'authentification. 3. Le compte Entra ID de l'utilisateur a été placé dans un groupe différent pendant son absence (par exemple, déplacé du personnel actif vers une autre OU), 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 de 80 magasins. Vous utilisez Google Workspace et gérez 400 Chromebooks via la console d'administration Google. Vous souhaitez remplacer la clé WPA2 PSK partagée actuelle sur le réseau opérationnel des magasins par une authentification 802.1X. Vous n'avez aucun serveur sur site dans aucun magasin. Quelle architecture déployez-vous, et quel est le principal avantage de sécurité par rapport à l'approche PSK actuelle ?
Conseil : Considérez ce qui se passe lorsqu'un Chromebook est perdu ou volé sous 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 délivrer des certificats aux Chromebooks. Dans la console d'administration Google, déployez l'autorité de certification racine (Root CA) et un profil de certificat client SCEP sur l'unité organisationnelle Store-Associates. Créez un profil WiFi WPA3-Enterprise spécifiant EAP-TLS et déployez-le sur la même OU. Configurez les points d'accès HPE Aruba (ou équivalents) de chaque magasin pour qu'ils pointent vers le service Cloud RADIUS. Le principal avantage en matière de sécurité : avec la clé PSK partagée actuelle, un Chromebook perdu ou volé conserve l'accès au WiFi jusqu'à ce que la clé PSK soit modifiée dans les 80 magasins - un processus perturbateur et fastidieux. Avec EAP-TLS, la suppression de l'appareil de l'OU Store-Associates dans la console d'administration Google 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 des appareils ne peut se connecter. Le statut 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'un échec de déploiement initial n'est pas une erreur de configuration dans la politique RADIUS ou le 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 des échecs de déploiement initial. 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 incompatibilité de clé secrète partagée RADIUS entre Meraki et le service Cloud RADIUS ; un délai d'expiration RADIUS configuré trop bas (augmentez-le à au soit 5 secondes) ; et si les IP du serveur Cloud RADIUS sont correctement saisies dans la configuration du SSID Meraki.
Continuer la lecture de cette série
Les avantages de sécurité de RADIUS as a Service pour les effectifs hybrides
Ce guide de référence technique explique comment RADIUS as a Service sécurise l'accès au réseau pour les effectifs hybrides au sein des sites distribués. Il présente l'architecture, les avantages de sécurité et les étapes de déploiement pour remplacer une infrastructure RADIUS sur site par un service d'authentification géré dans le cloud. Destiné aux responsables informatiques et aux architectes réseau des hôtels, chaînes de magasins, stades et organisations du secteur public, ce guide fournit les éléments requis pour évaluer et mettre en œuvre une migration vers le RADIUS cloud dès ce trimestre.
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 l'ensemble 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 de réduction des risques nécessaires pour sécuriser l'accès au réseau tout en éliminant les coûts opérationnels de l'infrastructure 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), en détaillant son architecture, ses méthodes EAP et ses stratégies de déploiement. Il fournit aux responsables informatiques des conseils pratiques pour migrer de serveurs sur site vers un modèle d'authentification cloud évolutif, sécurisé et conforme.