Integrating RADIUS as a Service with Cloud Directories (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 natif cloud, 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. Destiné aux responsables informatiques et aux architectes réseau déjà engagés dans l'identité cloud, ce guide comble le fossé entre la gestion des annuaires et la sécurité physique du réseau.

📖 10 min de lecture📝 2,373 mots🔧 2 exemples concrets❓ 4 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du podcast

Welcome to the Purple Technical Briefing. Today, we are covering a topic that sits at the intersection of cloud identity management and physical network security: integrating RADIUS as a Service with cloud directories, specifically Microsoft Entra ID and Google Workspace.

If you are managing enterprise WiFi across a hotel, a retail estate, a stadium, or a public-sector estate, this briefing is directly relevant to your next infrastructure decision.

Let us start with context. For the past two decades, WiFi authentication in enterprise environments relied on a fairly predictable stack. You had on-premise Active Directory, Windows Network Policy Server acting as the RADIUS server, and WPA2-Enterprise on the access points. It worked. But it required on-premise servers, manual certificate management, and a team with specialist knowledge to keep it running.

The problem is that most organisations are no longer on-premise first. They are cloud-first. Microsoft Entra ID and Google Workspace are now the directories of record for millions of organisations. And here is the gap: your wireless access points still speak RADIUS. They do not understand SAML. They do not understand OAuth. They speak RADIUS, and they always will.

So the question is: how do you bridge your cloud identity platform to your physical network infrastructure, without dragging an on-premise server back into the picture?

The answer is RADIUS as a Service. A cloud-hosted RADIUS server that integrates directly with your cloud directory, validates authentication requests in real time, and returns an access decision to your access point. No on-premise servers. No patching. No 2am certificate renewal emergencies.

The foundation is IEEE 802.1X. When a device tries to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point acts as an authenticator. It intercepts the connection attempt and forwards EAP packets to the RADIUS server. The RADIUS server validates the identity and returns either an Access-Accept or an Access-Reject. Only then does the access point grant network access.

Now, the most consequential technical decision in this entire deployment is your choice of EAP method.

PEAP-MSCHAPv2 is the old way. It uses usernames and passwords. It sounds secure. It is not. If a device does not strictly validate the RADIUS server certificate, an attacker can set up a rogue access point with your SSID, intercept the handshake, and capture the credentials. This is called an Evil Twin attack, and it is happening.

EAP-TLS is the right answer. It uses digital certificates on both the server and the client device for mutual authentication. There are no passwords involved. The device presents its certificate. The RADIUS server validates it against your cloud directory in real time. No credential theft possible. No phishing vector. No helpdesk tickets when someone changes their password.

Let us walk through a Microsoft Entra ID deployment.

Step one: licensing and PKI. You need Microsoft 365 E3 or E5 to access Intune and Conditional Access. Establish a cloud PKI using your Cloud RADIUS vendor's managed PKI or Microsoft's own Cloud PKI.

Step two: certificate deployment via Intune. Create a Trusted Certificate profile with your Root CA and deploy it to device groups. Then create a SCEP certificate profile. For user-based authentication, the subject name uses the User Principal Name.

Step three: Cloud RADIUS configuration. Grant the RADIUS service Microsoft Graph API permissions: User.Read.All and GroupMember.Read.All. Define your authentication policies: allow access if the certificate is issued by our trusted CA, the user is a member of the Corporate-WiFi-Users group in Entra ID, and the device is marked compliant in Intune.

Step four: wireless infrastructure. In your controller, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, add the Cloud RADIUS IP addresses and shared secrets. Set the RADIUS timeout to at least five seconds. Create your WPA3-Enterprise SSID.

Step five: WiFi profile deployment. Create a WiFi configuration profile in Intune. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, link the SCEP certificate profile. Devices silently receive the certificate and WiFi profile on their next sync. They connect automatically. No user interaction required.

Now let us look at the Google Workspace path, because it is architecturally different in one important way.

Google does not offer a native RADIUS service. There is no Google equivalent of Windows NPS. So you always need an intermediary: a Cloud RADIUS provider that connects to Google Workspace via Google Secure LDAP or via a SAML and OAuth integration.

Google Secure LDAP is available on Cloud Identity Premium and Google Workspace Enterprise editions. It provides a traditional LDAP interface to your cloud directory. Your Cloud RADIUS server connects to ldap.google.com on port 636 using client certificates that Google generates for you. From that point, the RADIUS server can query Google's directory to validate credentials or group memberships.

For managed Chromebooks, the deployment path uses the Google Admin Console. You configure a cloud PKI to issue certificates, push the Root CA and client certificates to the Chromebooks, and deploy a WiFi profile specifying EAP-TLS. The Chromebooks connect silently. For BYOD devices and guest access, you use a captive portal tied to Google Single Sign-On. That is the right separation: EAP-TLS for managed devices, captive portal for everything else.

Let us talk about pitfalls, because this is where deployments go wrong.

The first and most common is blocked firewall ports. RADIUS authentication uses UDP port 1812. RADIUS accounting uses UDP port 1813. If those ports are not open outbound from your wireless infrastructure to the Cloud RADIUS service, nothing works. Check this first, every time.

The second pitfall is certificate expiry. If your RADIUS server certificate expires, every device on the network loses connectivity simultaneously. Set monitoring alerts at 90 days, 30 days, and 7 days before expiry. Automate renewal where possible.

The third is clock skew. EAP-TLS relies on accurate timekeeping for certificate validation. If a device's system clock is significantly out of sync, certificate validation fails. Ensure NTP is configured correctly across all devices and infrastructure.

The fourth, specific to PEAP deployments, is failing to enforce strict server certificate validation on client devices. Without it, devices will accept any certificate presented by any access point claiming to be yours. This is the single configuration decision that separates a secure deployment from a vulnerable one.

Now for a rapid-fire question and answer.

Can I use Cloud RADIUS for both staff and guest WiFi? Staff WiFi, yes, using EAP-TLS. Guest WiFi should use a separate captive portal. Mixing the two on a single SSID creates unnecessary complexity and security risk.

Does this work with WPA3? Yes. WPA3-Enterprise is fully supported and recommended for all new deployments.

What about compliance? EAP-TLS with Cloud RADIUS supports PCI DSS requirements for strong authentication on cardholder data networks. It also supports GDPR obligations by enabling precise access logging and instant revocation when an employee leaves.

How does this affect our analytics capabilities? Positively. By tying network access to a verified cloud identity, platforms like Purple's WiFi Analytics provide richer data on space utilisation. You move from anonymous MAC addresses to authenticated, named users, which transforms the quality of your insight.

To summarise the key takeaways.

One: Cloud RADIUS eliminates on-premise server dependencies. Your access points authenticate against a cloud-hosted service that integrates directly with Entra ID or Google Workspace.

Two: EAP-TLS is the right authentication method. Certificates replace passwords. No phishing vector, no credential theft, no helpdesk overhead from password resets.

Three: Microsoft Intune and Google Admin Console automate certificate deployment. Devices receive certificates and WiFi profiles silently, with no user interaction.

Four: Dynamic VLAN assignment via RADIUS attributes enables granular network segmentation based on directory group membership. This limits lateral movement and supports compliance.

Five: Always verify ports 1812 and 1813 are open, monitor certificate expiry, and enforce strict server certificate validation.

If you are planning a deployment this quarter, start with a pilot group of 20 to 50 devices. Validate the certificate deployment, the RADIUS authentication, and the VLAN assignment before rolling out globally. The investment in getting this right pays dividends in reduced helpdesk overhead, a stronger security posture, and the ability to use your network data for genuine business intelligence.

Thank you for listening to the Purple Technical Briefing. For detailed deployment steps, configuration examples, and worked scenarios, see the full technical reference guide at purple.ai.

Points clés à retenir

✓Cloud RADIUS eliminates on-premise NPS and FreeRADIUS servers. Your access points authenticate against a cloud-hosted service that integrates directly with Microsoft Entra ID or Google Workspace.
✓EAP-TLS is the correct authentication method for enterprise WiFi. It uses digital certificates instead of passwords, eliminating credential theft, phishing, and password-related helpdesk overhead.
✓Microsoft Intune and Google Admin Console automate certificate deployment to managed devices via SCEP profiles. Devices receive certificates and WiFi profiles silently, with no user interaction.
✓Google Workspace requires an intermediary for RADIUS integration. Google Secure LDAP (available on Cloud Identity Premium and Enterprise editions) provides the LDAP interface that Cloud RADIUS servers use to query the Google directory.
✓Dynamic VLAN assignment via RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) enables granular network segmentation based on directory group membership, supporting PCI DSS requirements.
✓Check UDP ports 1812 and 1813 first. Blocked firewall ports are the leading cause of initial deployment failure. Monitor certificate expiry at 90, 30, and 7 days. Enforce strict server certificate validation on all PEAP deployments.
✓Disabling a user in Entra ID or Google Workspace immediately revokes their WiFi access at all sites. This is the primary offboarding advantage over PSK-based networks and directly supports GDPR obligations.

Synthèse

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 sur 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.

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 aucun serveur sur site, sans cycles de mise à jour et sans point de défaillance unique. Associée à l'authentification basée sur des 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 natif cloud, le déploiement d'EAP-TLS via Microsoft Intune et la console d'administration Google, ainsi que les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les hôtels, les commerces de détail, les stades et les espaces publics. Pour une introduction plus large au contrôle d'accès au réseau, consultez Un guide sur votre système de contrôle d'accès au réseau .

Analyse technique approfondie : architecture et normes

Le rôle de RADIUS et de la norme 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 parties (supplicant, authentificateur, serveur d'authentification) est la pierre angulaire de la sécurité sans fil d'entreprise et est défini dans 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 cloud

Une architecture RADIUS native cloud é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 déroule entièrement dans le cloud. Cela s'aligne sur 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)	Natif cloud (RADIUSaaS)
Infrastructure	VM Windows Server ou bare metal 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 + connecteur Intune	PKI cloud du fournisseur ou de Microsoft
Haute disponibilité	HA manuelle et répartition de charge	Mise à l'échelle automatique par le fournisseur
Temps de configuration	De quelques jours à plusieurs semaines	Quelques heures
Idéal pour	AD hybride, appareils existants	Organisations cloud-first gérées par MDM
Complexité opérationnelle	Plus élevée au départ et au quotidien	Coûts opérationnels réduits

EAP-TLS vs PEAP-MSCHAPv2 : le choix critique

Le choix de la méthode EAP est la décision de sécurité la plus déterminante 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 l'homme du milieu (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 pirate avec votre SSID, intercepter la liaison EAP (handshake) et capturer les identifiants.

Il s'agit d'une attaque de type "Evil Twin" (jumeau maléfique), 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 transparente 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 avec 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, il fournit une interface LDAP traditionnelle pour votre annuaire cloud. Votre serveur Cloud RADIUS se connecte à ldap.google.com sur le port 636 à l'aide de certificats clients que Google génèates pour vous. À partir de ce moment, le serveur RADIUS interroge l'annuaire de Google pour valider les identifiants ou les appartenances aux groupes, tout comme il interrogerait un Active Directory sur site.

Une autre méthode 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 (Google Admin Console) 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.

Guide d'implémentation

L'implémentation 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 des identités et des appareils

Pour Microsoft Entra ID : vérifiez que votre tenant dispose de licences Microsoft 365 E3/E5 ou Enterprise Mobility + Security (EMS) E3/E5. Cela inclut Microsoft Intune et l'accès conditionnel (Conditional Access). 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'appareil.

É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 (Microsoft Intune Certificate Connector).

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é (Trusted Certificate). Téléversez 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 liaison TLS (TLS handshake). Ensuite, créez 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 (User Principal Name) ou l'identifiant de l'appareil.

Parcours console d'administration Google : accédez à Appareils, puis Réseaux, puis Certificats. Téléversez votre Root CA. 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 certificat Google Cloud (Google Cloud Certificate Connector) qui sert de proxy pour les requêtes vers une autorité de certification Microsoft sur site. Déployez la Root CA et les profils de certificat client 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 tenant d'annuaire. Pour Entra ID, cela nécessite au minimum User.Read.All and 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 et les secrets partagés du serveur Cloud RADIUS en tant que serveurs d'authentification RADIUS. Configurez des serveurs primaires et secondaires pour la redondance. Définissez le délai d'expiration (timeout) RADIUS sur un minimum de cinq secondes pour tenir compte de la latence des allers-retours avec le cloud.

Créez un nouveau SSID configuré pour WPA2-Enterprise ou WPA3-Enterprise. Pour les déploiements dans le secteur de l' hôtellerie , assurez-vous que le SSID de l'entreprise se trouve sur un VLAN distinct de tout réseau Guest WiFi . Pour les environnements de la vente au détail , envisagez de déployer le SSID de l'entreprise uniquement dans les zones réservées au personnel (back-of-house).

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. Sous les paramètres EAP, sélectionnez EAP-TLS. Liez le profil de certificat SCEP en tant que certificat client et spécifiez le profil Trusted Root CA. 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 poussez le certificat Root CA approuvé vers les appareils. Appliquez ce profil à vos unités organisationnelles. Les Chromebooks se connectent silencieusement et de manière sécurisée.

Bonnes pratiques

Imposez l'EAP-TLS sur tous les nouveaux déploiements. Ne déployez pas de nouveaux réseaux utilisant PEAP-MSCHAPv2. Les risques de sécurité sont bien documentés et le chemin de migration est simple avec les outils MDM modernes.

Exigez une validation stricte du certificat du serveur. Si vous devez utiliser PEAP pour les appareils existants (legacy), 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 existe un champ pour spécifier la CA approuvée 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 au groupe de l'utilisateur dans Entra ID ou Google Workspace et attribuez-les dynamiquement à différents VLAN. Le serveur RADIUS renvoie le 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 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 génère une surcharge de support excessive. La plateforme Guest WiFi de Purple gère l'intégration 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 la surveillance et les alertes à 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 lorsque votre PKI le prend en charge.

Testez les paramètres de délai d'attente (timeout) RADIUS. Cloud RADIUS introduit une latence réseau aller-retour que le NPS sur site n'a pas. Définissez le délai d'attente RADIUS sur vos points d'accès à au moins de cinq secondes. Un délai d'attente de deux secondes - courant dans les configurations par défaut - entraînera des échecs d'authentification intermittents.

Résolution des problèmes et atténuation des risques

Les ports de pare-feu bloqués sont la cause principale de l'échec du déploiement initial. L'authentification RADIUS nécessite le port UDP 1812 sortant de votre infrastructure sans fil vers le service Cloud RADIUS. La comptabilité (accounting) RADIUS nécessite le port UDP 1813. Vérifiez qu'ils sont ouverts avant toute autre résolution de problème.

Les échecs de validation de certificat se présentent sous la forme de rejets d'authentification sans cause évidente. Vérifiez les éléments suivants dans l'ordre : l'expiration du certificat sur le client et sur le serveur RADIUS ; le décalage d'horloge entre l'appareil client et le serveur RADIUS (EAP-TLS repose sur une heure précise) ; et si le certificat de l'autorité de certification racine (Root CA) a été déployé avec succès sur l'appareil via MDM.

La non-application de l'appartenance aux groupes 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 Cloud RADIUS dispose des autorisations API appropriées pour lire les appartenances aux groupes. Dans Entra ID, confirmez que le principal de service dispose de 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 est défini sur 802 (valeur 6) et Tunnel-Private-Group-Id correspond à l'ID de VLAN configuré sur le commutateur ou le contrôleur.

L'échec d'EAP-TLS pour les appareils BYOD indique 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é d'organisation (Organisational Unit) et que l'appareil s'est synchronisé récemment.

ROI et impact commercial

Le passage à Cloud RADIUS permet de réaliser des économies opérationnelles mesurables. Le RADIUS sur site nécessite au minimum deux serveurs pour la haute disponibilité, les correctifs continus du 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 RADIUS sur un an dépasse généralement le coût annuel d'un abonnement Cloud RADIUS.

L'intérêt commercial 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 :

Désactivation instantanée des accès. 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 son accès WiFi. Cela répond directement aux 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.

Preuve 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 répond à l'exigence 10 de la norme PCI DSS (journalisation et surveillance) et aux obligations de responsabilité du GDPR.

Cohérence multi-site. Un seul service Cloud RADIUS authentifie tous vos sites avec des politiques cohérentes, gérées à partir d'un tableau de bord unique. Ajouter un nouvel hôtel, un magasin ou un lieu de réception 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 essentielle au fonctionnement, les fournisseurs de Cloud RADIUS proposent généralement des SLA de disponibilité de 99,999 % avec basculement multi-région intégré. Purple fonctionne avec une 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 de l'ordinateur WAN : un guide pratique pour 2026 et Journée mondiale du WiFi 2026 : comment votre établissement peut aider à combler le fossé numérique .

Définitions clés

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service. The RADIUS server acts as the decision engine between your access points and your identity directory.

Every enterprise WPA2-Enterprise or WPA3-Enterprise WiFi network depends on a RADIUS server. Without it, IEEE 802.1X authentication does not function.

RADIUS as a Service (RADIUSaaS)

A cloud-hosted RADIUS implementation delivered as a managed service. The provider maintains the infrastructure, patching, high availability, and identity provider integrations. You configure authentication policies and point your access points to the cloud RADIUS IPs.

RADIUSaaS eliminates the need for on-premise NPS or FreeRADIUS servers, removing the associated hardware, OS patching, and specialist maintenance overhead.

IEEE 802.1X

An IEEE standard for port-based Network Access Control. It defines the three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS server). The authenticator blocks all traffic until the RADIUS server grants access.

The foundational standard for enterprise WiFi authentication. WPA2-Enterprise and WPA3-Enterprise both rely on 802.1X.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

An authentication method defined in RFC 5216 that uses digital certificates on both the RADIUS server and the client device for mutual authentication. Neither party sends a password. The client presents its certificate; the server validates it against the directory in real time.

The gold standard for enterprise WiFi security. Eliminates credential theft, phishing, and password-related helpdesk overhead. Required for PCI DSS compliance on cardholder data networks.

PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)

An authentication method that creates an encrypted TLS tunnel and then sends the user's username and password through it. Vulnerable to Evil Twin attacks if the client does not strictly validate the RADIUS server certificate.

The legacy default for enterprise WiFi. Still widely deployed but should be migrated to EAP-TLS in all new and existing deployments where possible.

Microsoft Entra ID

Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory (Azure AD). Manages user identities, group memberships, device compliance, and Conditional Access policies.

The primary identity source for Cloud RADIUS in Microsoft-centric environments. Cloud RADIUS providers connect to Entra ID via Microsoft Graph API.

Google Secure LDAP

A managed service available on Cloud Identity Premium and Google Workspace Enterprise editions that provides a traditional LDAP interface to Google's cloud directory. RADIUS servers connect to ldap.google.com on port 636 using client certificates.

The primary integration path for connecting a Cloud RADIUS server to Google Workspace. Google does not offer a native RADIUS service, so Secure LDAP acts as the bridge.

PKI (Public Key Infrastructure)

The set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. A PKI is required to issue the client and server certificates used in EAP-TLS authentication.

Cloud-native PKI options from RADIUS vendors or Microsoft (Cloud PKI) eliminate the need for on-premise Active Directory Certificate Services (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

A protocol that enables devices to request and receive digital certificates from a Certificate Authority automatically. Used by Microsoft Intune and Google Admin Console to deploy client certificates to managed devices without user interaction.

SCEP profiles in Intune are the mechanism by which corporate devices silently receive the client certificates needed for EAP-TLS authentication.

Dynamic VLAN assignment

A RADIUS feature that returns VLAN assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) to the access point based on the authenticated user's directory group membership. The AP places the client on the specified VLAN automatically.

Enables granular network segmentation without manual VLAN configuration per device. Staff in different roles or departments land on different network segments, limiting lateral movement and supporting PCI DSS segmentation requirements.

Exemples concrets

A 200-room hotel is migrating its back-of-house staff network from an ageing on-premise NPS server to a cloud-native solution. The hotel has recently moved to Microsoft Entra ID and Microsoft 365 E5. Staff devices are Windows laptops managed by Intune. The wireless infrastructure is Cisco Meraki. The hotel needs staff to connect automatically without password prompts, and needs instant revocation when a member of staff leaves.

Deploy a Cloud RADIUS solution with Entra ID integration. Step 1: grant the Cloud RADIUS provider Microsoft Graph API permissions (User.Read.All, GroupMember.Read.All, Device.Read.All) in the Entra ID tenant. Step 2: in Intune, create a Trusted Certificate profile with the Cloud RADIUS Root CA and deploy it to the 'All Corporate Devices' group. Step 3: create a SCEP Certificate profile with Subject Name CN={{UserPrincipalName}} and deploy it to the same group. Step 4: configure the Cloud RADIUS authentication policy: allow access if certificate is issued by [Trusted CA] AND user is member of [Hotel-Staff-WiFi] Entra ID group AND device is Intune-compliant. Step 5: in Cisco Meraki dashboard, add the Cloud RADIUS primary and secondary IPs as RADIUS servers on the back-of-house SSID. Set RADIUS timeout to 5 seconds. Step 6: in Intune, create a WPA3-Enterprise WiFi profile for the back-of-house SSID, specifying EAP-TLS and linking the SCEP certificate profile. Deploy to the 'All Corporate Devices' group. Devices silently receive the certificate and WiFi profile on next Intune sync and connect automatically. When a staff member leaves, disabling their Entra ID account immediately revokes network access at all sites.

Commentaire de l'examinateur : This approach eliminates the on-premise NPS dependency entirely. EAP-TLS removes the phishing vector of credential-based authentication. Intune automates certificate lifecycle management, removing the manual overhead that caused the previous NPS deployment to fall behind on certificate renewals. The Entra ID group policy means that when HR disables an account, network access is revoked in real time - no manual RADIUS policy update required. The Cisco Meraki integration is straightforward: Cloud RADIUS is hardware-agnostic and works with any 802.1X-capable infrastructure.

A retail chain with 50 stores uses Google Workspace and manages a fleet of 500 Chromebooks used by store associates for inventory and point-of-sale operations. They currently use a shared WPA2 PSK for the store operations network, which creates a security risk when devices are lost or stolen. They want to move to 802.1X authentication without deploying local servers at each store. Their wireless infrastructure is HPE Aruba.

Deploy a Cloud RADIUS solution with Google Workspace integration via Google Secure LDAP. Step 1: in Google Admin Console, navigate to Apps, then LDAP, and add a new LDAP client for the Cloud RADIUS service. Configure read permissions for user information and group membership. Download the generated client certificate and key. Step 2: configure the Cloud RADIUS service with the Google Secure LDAP credentials. Step 3: configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, navigate to Devices, then Networks, then Certificates, and upload the Root CA. Configure the certificate issuance profile and apply it to the Store-Associates Organisational Unit. Step 4: in Google Admin Console, create a WPA3-Enterprise WiFi profile for the store operations SSID. Set EAP-TLS, link the Root CA, and apply to the Store-Associates OU. Chromebooks receive the certificate and WiFi profile on next Admin Console sync. Step 5: in HPE Aruba Central, configure the store operations SSID with WPA3-Enterprise and add the Cloud RADIUS primary and secondary IPs. Set RADIUS timeout to 5 seconds. Configure dynamic VLAN assignment to place store associates on VLAN 20 (store operations) based on their Google Workspace group membership. When a Chromebook is lost or stolen, removing it from the Store-Associates OU immediately revokes its network access.

Commentaire de l'examinateur : This deployment eliminates the shared PSK risk. A lost or stolen Chromebook with a shared PSK gives an attacker persistent network access until the PSK is rotated across all 50 stores. With EAP-TLS, the certificate on the lost device can be revoked immediately. The Google Secure LDAP integration is the correct path for Google Workspace environments - it provides a stable, standards-based interface that the Cloud RADIUS service can query without requiring a custom API integration. Dynamic VLAN assignment ensures store associates land on the correct network segment, supporting PCI DSS network segmentation requirements for retail environments.

Questions d'entraînement

Q1. Your organisation is migrating from on-premise Active Directory to Microsoft Entra ID. You currently use PEAP-MSCHAPv2 for WiFi authentication on 300 corporate laptops managed by Intune. You have Microsoft 365 E5 licensing. What is the most secure and operationally efficient path to migrate WiFi authentication to a cloud-native architecture?

Conseil : Consider the vulnerabilities of credential-based authentication, the capabilities of Microsoft Intune for certificate deployment, and the need to avoid on-premise infrastructure dependencies.

Voir la réponse type

Deploy a Cloud RADIUS solution with Entra ID integration. Use Microsoft Intune to deploy a Trusted Certificate profile (Root CA) and a SCEP Certificate profile to the 300 laptops. Configure the Cloud RADIUS authentication policy to require a valid certificate from the trusted CA and membership of the Corporate-WiFi-Users Entra ID group. Create a WPA3-Enterprise WiFi profile in Intune specifying EAP-TLS and link the SCEP certificate profile. Devices silently receive the certificate and WiFi configuration on next Intune sync. This eliminates PEAP-MSCHAPv2 credential theft risk, removes the on-premise NPS dependency, and provides instant revocation when an Entra ID account is disabled.

Q2. A user at your hotel reports they cannot connect to the back-of-house staff WiFi after returning from a two-week holiday. Other staff are connecting without issue. The network uses EAP-TLS with certificates deployed via Intune. What are the three most likely causes, in order of likelihood?

Conseil : EAP-TLS relies on time-sensitive cryptographic assets and real-time directory lookups.

Voir la réponse type

The user's client certificate has expired. Certificates have a defined validity period, and if the device was offline during the renewal window, the SCEP profile may not have renewed it. Check the certificate expiry date in the Intune device certificate store. 2. The device's system clock is significantly out of sync (clock skew), causing certificate validation to fail. EAP-TLS validates certificate timestamps; a clock more than five minutes out of sync will cause authentication failures. 3. The user's Entra ID account was placed in a different group during their absence (for example, moved from active staff to a different OU), and the RADIUS authentication policy no longer matches their group membership. Check the user's group memberships in Entra ID against the RADIUS policy.

Q3. You are the IT manager for a retail chain with 80 stores. You use Google Workspace and manage 400 Chromebooks via Google Admin Console. You want to replace the current shared WPA2 PSK on the store operations network with 802.1X authentication. You have no on-premise servers at any store location. What architecture do you deploy, and what is the primary security benefit over the current PSK approach?

Conseil : Consider what happens when a Chromebook is lost or stolen under each authentication model.

Voir la réponse type

Deploy a Cloud RADIUS service with Google Secure LDAP integration. Configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, deploy the Root CA and a SCEP client certificate profile to the Store-Associates Organisational Unit. Create a WPA3-Enterprise WiFi profile specifying EAP-TLS and deploy it to the same OU. Configure HPE Aruba (or equivalent) access points at each store to point to the Cloud RADIUS service. The primary security benefit: under the current shared PSK, a lost or stolen Chromebook retains WiFi access until the PSK is rotated across all 80 stores - a disruptive, time-consuming process. With EAP-TLS, removing the device from the Store-Associates OU in Google Admin Console immediately revokes its certificate and network access, with no impact on any other device.

Q4. During a Cloud RADIUS deployment, you configure the SSID on Cisco Meraki access points and deploy the Intune WiFi profile to a pilot group of 20 devices. None of the devices can connect. The Intune device status shows the certificate and WiFi profile as successfully deployed. What is the first thing you check?

Conseil : The most common cause of initial deployment failure is not a configuration error in the RADIUS policy or the certificate.

Voir la réponse type

Check that UDP ports 1812 and 1813 are open outbound from the Cisco Meraki access points (or the Meraki cloud infrastructure) to the Cloud RADIUS server IP addresses. Blocked firewall ports are the leading cause of initial deployment failure. The fact that certificates and WiFi profiles are successfully deployed rules out Intune configuration issues. The next checks are: RADIUS shared secret mismatch between Meraki and the Cloud RADIUS service; RADIUS timeout set too low (increase to at least 5 seconds); and whether the Cloud RADIUS server IPs are correctly entered in the Meraki SSID configuration.

Continuer la lecture de cette série

The Security Benefits of RADIUS as a Service for Hybrid Workforces

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 dans les sites distribués. Il couvre l'architecture, les avantages en matière de sécurité et les étapes de déploiement pour remplacer l'infrastructure RADIUS sur site par un service d'authentification géré dans le cloud. Pour les responsables informatiques et les architectes réseau des hôtels, des chaînes de vente au détail, des stades et des organisations du secteur public, ce guide fournit les preuves nécessaires pour évaluer et mettre en œuvre une migration vers le cloud RADIUS ce trimestre.

How to Implement 802.1X Authentication with Cloud RADIUS

Ce guide de référence technique fournit un cadre complet pour l'implémentation de l'authentification 802.1X avec Cloud RADIUS à travers les infrastructures d'entreprise distribuées. 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 la charge opérationnelle de l'infrastructure sur site.

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Ce guide complet explore Cloud RADIUS (RADIUS en tant que service), détaillant son architecture, ses méthodes EAP et ses stratégies de mise en œuvre. Il fournit aux leaders informatiques des informations exploitables sur la migration des serveurs sur site vers un modèle d'authentification basé sur le cloud, évolutif, sécurisé et conforme.