Passer au contenu principal

Comment configurer un serveur RADIUS pour l'authentification WiFi

Ce guide de référence offre aux responsables informatiques et aux architectes réseau un plan d'action complet pour déployer un serveur RADIUS destiné à l'authentification WiFi d'entreprise. Il aborde les compromis d'architecture entre les déploiements sur site et dans le cloud, la sélection des méthodes EAP, l'intégration à Active Directory et l'attribution dynamique de VLAN. Les exploitants de sites et les équipes informatiques y trouveront des étapes de mise en œuvre concrètes, des études de cas réelles et des stratégies de réduction des risques pour passer d'un environnement PSK non sécurisé à une infrastructure 802.1X robuste dès ce trimestre.

Par Iain JewittPublié le
📖 8 min de lecture2,205 mots2 exemples concrets3 questions d'entraînement9 définitions clés

Video overview

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans ce briefing technique de Purple. Aujourd'hui, nous abordons une décision d'infrastructure essentielle pour tout responsable informatique d'entreprise : comment configurer un serveur RADIUS pour l'authentification WiFi. Si vous gérez un déploiement à grande échelle - qu'il s'agisse d'une chaîne d'hôtels, d'un réseau de vente au détail ou d'un campus universitaire étendu - s'en remettre à une simple clé pré-partagée constitue un risque de sécurité majeur. Nous avons besoin de la norme 802.1X, et cela signifie que nous avons besoin de RADIUS. Commençons par le contexte. RADIUS, ou Remote Authentication Dial-In User Service, agit comme le gardien de votre réseau. Lorsqu'un appareil tente de se connecter à un point d'accès WiFi, le point d'accès joue le rôle d'authentificateur et transmet les identifiants au serveur RADIUS. Le serveur vérifie ces identifiants par rapport à un annuaire - comme Active Directory ou une base de données LDAP - puis renvoie un message d'acceptation ou de refus. C'est le fondement de la sécurité WiFi d'entreprise, et c'est le mécanisme qui vous permet d'appliquer des politiques d'accès granulaires à grande échelle. Passons maintenant à l'analyse technique approfondie. La première décision architecturale majeure à laquelle vous ferez face est de choisir entre un serveur RADIUS sur site et une solution hébergée dans le cloud. Historiquement, les solutions sur site comme le Network Policy Server (NPS) de Microsoft ou la solution open-source FreeRADIUS étaient la norme. Elles offrent un contrôle total sur l'infrastructure et ne dépendent pas d'une connexion internet externe pour l'authentification. Cependant, elles nécessitent du matériel dédié, une maintenance continue et une configuration manuelle de la redondance. Si vous disposez d'un seul centre de données et d'une équipe informatique bien dotée en personnel, c'est une approche tout à fait valable. D'un autre côté, les solutions de RADIUS dans le cloud sont devenues de plus en plus populaires, en particulier pour les environnements distribués comme les chaînes de magasins ou les établissements hôteliers. Le RADIUS dans le cloud élimine complètement la gestion du matériel, offre une haute disponibilité intégrée et s'intègre de manière transparente aux fournisseurs d'identité cloud comme Azure Active Directory ou Okta. Le compromis est que l'authentification nécessite une connexion internet fiable et qu'il y a un coût d'abonnement récurrent. Pour un exploitant de sites gérant cinquante ou cent établissements, les économies opérationnelles réalisées en évitant de déployer et de maintenir des serveurs sur site à chaque endroit compenseront presque certainement ce coût. Lors du déploiement de RADIUS, le protocole d'authentification extensible - EAP - est l'élément critique. Il définit comment le client et le serveur négocient et effectuent l'authentification. Le protocole EAP-TLS est la référence absolue en matière de sécurité car il utilise des certificats numériques tant sur le client que sur le serveur, éliminant ainsi complètement le besoin de mots de passe. Cela signifie que même si un attaquant intercepte l'échange d'authentification, il n'y a aucun identifiant à voler. Cependant, le déploiement de certificats clients peut s'avérer lourd sur le plan administratif. Vous avez besoin d'une infrastructure à clés publiques et d'une solution MDM pour diffuser les certificats sur chaque appareil. PEAP-MSCHAPv2 est l'alternative la plus courante. Elle utilise un certificat côté serveur pour établir un tunnel TLS chiffré, au sein duquel l'utilisateur s'authentifie avec un nom d'utilisateur et un mot de passe. C'est nettement plus simple à déployer que l'EAP-TLS car vous n'avez qu'un seul certificat à gérer - celui du serveur. Cependant, et c'est un point critique - si les clients ne sont pas rigoureusement configurés pour valider le certificat du serveur, ils sont vulnérables aux points d'accès illégitimes. Un attaquant peut installer un faux point d'accès, présenter un certificat frauduleux et capturer les identifiants. Il ne s'agit pas d'une attaque théorique. C'est une menace réelle et bien documentée. Parlons maintenant des recommandations de mise en œuvre et des pièges à éviter. La première recommandation est d'imposer une validation stricte du certificat sur chaque appareil client. Utilisez des objets de stratégie de groupe pour les appareils Windows et des profils MDM - qu'il s'agisse d'Intune, Jamf ou d'une autre solution - pour macOS et les appareils mobiles. Le profil doit spécifier exactement à quelle autorité de certification faire confiance et quel est le nom de serveur attendu. Ne laissez pas l'utilisateur final configurer cela manuellement. La deuxième recommandation est de mettre en œuvre l'attribution dynamique de VLAN. Au lieu de placer tous les utilisateurs authentifiés sur le même réseau plat, configurez le serveur RADIUS pour qu'il demande au point d'accès de placer l'utilisateur sur un VLAN spécifique en fonction de son appartenance à un groupe dans l'annuaire. C'est essentiel pour segmenter les appareils de l'entreprise des appareils BYOD ou invités. Un membre de l'équipe financière doit se trouver sur un segment réseau différent de celui d'un prestataire de passage pour la journée. La troisième recommandation concerne l'accès des invités. Pour les établissements qui doivent fournir du WiFi aux visiteurs - hôtels, magasins de détail, centres de conférence - l'intégration de votre infrastructure RADIUS avec une solution de Captive Portal comme la plateforme Guest WiFi de Purple est une combinaison puissante. Le personnel et les appareils de l'entreprise s'authentifient de manière transparente via 802.1X, tandis que les invités sont redirigés vers un portail personnalisé pour s'authentifier. La plateforme de Purple capture ensuite des données de première partie et fournit des analyses sur le comportement des visiteurs, transformant ainsi votre réseau d'un centre de coûts en un actif d'aide à la décision.Passons maintenant à une session rapide de questions et réponses. Première question : ai-je besoin d'un serveur dédié pour RADIUS ? Pour les déploiements sur site, oui, il est fortement recommandé de l'exécuter sur une machine virtuelle dédiée plutôt que de partager les ressources avec un contrôleur de domaine. L'authentification est une opération sensible à la latence, et la concurrence pour les ressources peut provoquer des pannes intermittentes très difficiles à diagnostiquer. Deuxième question : RADIUS peut-il gérer l'authentification des appareils sans écran comme les imprimantes ou les capteurs IoT ? Oui, grâce au MAC Authentication Bypass, ou MAB. Cela permet aux appareils dépourvus de fonctionnalités 802.1X d'être authentifiés en fonction de leur adresse MAC. Cependant, les adresses MAC étant faciles à usurper, les appareils authentifiés par MAB doivent toujours être placés sur un VLAN hautement restreint. Troisième question : comment gérer la redondance des serveurs RADIUS ? Déployez toujours au moins deux serveurs RADIUS - un principal et un secondaire. Configurez tous les points d'accès pour qu'ils basculent sur le secondaire si le principal devient inaccessible. Pour le RADIUS dans le cloud, cette redondance est généralement intégrée et gérée par le fournisseur. Pour résumer les points clés de notre séance d'aujourd'hui. Les clés prépartagées ne sont pas acceptables pour le WiFi d'entreprise. Implémentez le 802.1X. Choisissez votre modèle de déploiement - sur site ou cloud - en fonction de vos ressources informatiques, du nombre de sites que vous gérez et de votre infrastructure d'identité existante. Si votre infrastructure est distribuée et axée sur le cloud, le RADIUS dans le cloud est presque certainement la bonne solution. Imposez une validation stricte des certificats sur les clients. C'est non négociable. Utilisez l'attribution dynamique de VLAN pour segmenter votre réseau. Et enfin, réfléchissez à la manière dont votre infrastructure d'authentification peut s'intégrer à des plateformes plus larges pour apporter de la valeur commerciale au-delà du simple contrôle d'accès. Pour aller plus loin, nous vous recommandons d'explorer les guides de Purple sur la configuration de l'authentification WiFi 802.1X et la sécurisation de votre réseau avec des politiques DNS robustes. Merci pour votre écoute.

Fait partie de notre série principale : Guide de sécurité WiFi pour les entreprises

Comment configurer un serveur RADIUS pour l'authentification WiFi

Synthèse

Pour les environnements d'entreprise - qu'il s'agisse d'un campus universitaire étendu, d'un stade à haute densité ou d'une chaîne de vente au détail distribuée - s'appuyer sur une clé pré-partagée (PSK) pour l'accès WiFi représente un risque de sécurité majeur. Un seul identifiant compromis expose l'ensemble du réseau, et la révocation de l'accès nécessite de changer le mot de passe de tous les appareils du parc. La mise en œuvre de l'authentification 802.1X via un serveur RADIUS élimine complètement ce problème : chaque utilisateur s'authentifie individuellement, l'accès peut être révoqué instantanément, et la segmentation du réseau est appliquée de manière dynamique.

Ce guide fournit une feuille de route définitive aux responsables informatiques et aux architectes réseau pour déployer l'authentification RADIUS. Nous couvrons les compromis architecturaux entre les déploiements sur site et hébergés dans le cloud, la configuration des méthodes EAP (Extensible Authentication Protocol) et l'intégration avec les services d'annuaire comme Active Directory. Nous démontrons également comment une couche d'authentification robuste s'intègre aux solutions de Guest WiFi pour offrir un accès transparent aux visiteurs, tout en collectant les WiFi Analytics qui transforment votre réseau en un outil d'intelligence d'affaires.


Analyse Technique Approfondie

L'Architecture 802.1X

La norme IEEE 802.1X définit le contrôle d'accès réseau basé sur les ports (PNAC). Dans un contexte sans fil, elle implique trois rôles principaux travaillant de concert :

Rôle Composant Responsabilité
Supplicant Appareil client (ordinateur portable, smartphone) Présente les identifiants pour demander l'accès au réseau
Authentificateur Point d'accès ou contrôleur WiFi Applique le contrôle d'accès ; relais les messages EAP
Serveur d'Authentification Serveur RADIUS Valide les identifiants ; renvoie les attributs d'acceptation/refus et de politique

Lorsqu'un supplicant s'associe à un point d'accès, l'AP bloque tout le trafic de données à l'exception des messages EAP (Extensible Authentication Protocol). L'AP encapsule ces messages EAP dans des paquets RADIUS et les transmet au serveur RADIUS. Le serveur vérifie les identifiants par rapport à une base de données d'annuaire - généralement LDAP ou Active Directory - et renvoie un message Access-Accept ou Access-Reject. S'il est accepté, l'AP débloque le port et le trafic du client s'écoule librement.

Comment configurer un serveur RADIUS pour l'authentification WiFi - architecture overview

Choisir une Méthode EAP

La sécurité de votre déploiement RADIUS dépend fortement de la méthode EAP sélectionnée. Les deux plus courantes dans les déploiements d'entreprise sont :

EAP-TLS (Transport Layer Security) est la référence absolue. Il nécessite des certificats numériques à la fois sur le serveur RADIUS et sur chaque appareil client, éliminant totalement les mots de passe. Même si un attaquant intercepte l'intégralité de l'échange d'authentification, il n'y a aucun identifiant à extraire. Le compromis réside dans la charge administrative : le déploiement et la gestion des certificats clients nécessitent une infrastructure de clés publiques (PKI) opérationnelle et une solution MDM (par exemple, Microsoft Intune, Jamf) pour distribuer les certificats aux terminaux.

PEAP-MSCHAPv2 (Protected EAP) est la méthode la plus largement déployée en pratique. Elle utilise un certificat côté serveur pour établir un tunnel TLS chiffré, au sein duquel le client s'authentifie à l'aide d'un nom d'utilisateur et d'un mot de passe. C'est nettement plus simple à déployer que EAP-TLS car un seul certificat - celui du serveur - doit être géré. Cependant, elle comporte une réserve essentielle : si les appareils clients ne sont pas explicitement configurés pour valider le certificat du serveur RADIUS, ils sont vulnérables aux attaques de type Man-in-the-Middle (MitM) via des points d'accès malveillants.

Note de sécurité critique : Le fait de ne pas imposer une validation stricte des certificats sur les appareils clients annule de fait les avantages de sécurité de PEAP-MSCHAPv2. Un attaquant peut déployer un point d'accès malveillant, présenter un faux certificat et intercepter les identifiants des utilisateurs en clair. Il ne s'agit pas d'un risque théorique - c'est un vecteur d'attaque bien documenté qui a été exploité dans des environnements réels.


Guide de mise en œuvre

Étape 1 : Décision architecturale - RADIUS sur site vs. Cloud

La première décision consiste à choisir où héberger l'infrastructure RADIUS. Il s'agit principalement d'une question opérationnelle et de coût, et non de sécurité - les deux modèles peuvent être déployés de manière sécurisée.

Comment configurer un serveur RADIUS pour l'authentification WiFi - comparison chart

RADIUS sur site (par exemple, Microsoft NPS, FreeRADIUS, Cisco ISE) convient aux organisations disposant d'un personnel informatique dédié, d'une infrastructure d'annuaire sur site existante et de contraintes strictes en matière de souveraineté des données ou de conformité. Il ne dépend pas de la connectivité internet pour l'authentification, ce qui constitue un avantage certain pour les environnements où la disponibilité d'internet ne peut être garantie.

Cloud RADIUS est de plus en plus le modèle privilégié pour les environnements distribués - chaînes de Retail, groupes de Hospitality et hubs de Transport où le déploiement de serveurs sur chaque site est techniquement et opérationnellement irréalisable. Cloud RADIUS s'intègre nativement avec les fournisseurs d'identité cloud (Azure AD, Google Workspace, Okta) et offre une haute disponibilité intégrée ainsi qu'une évolutivité mondiale.

Étape 2 : Installer et configurer le serveur RADIUS

Pour un déploiement sur site utilisant Microsoft NPS (le choix le plus courant dans les environnements centrés sur Windows) :

  1. Installez le rôle Serveur de stratégie réseau (NPS) via le Gestionnaire de serveur.
  2. Enregistrez le serveur NPS dans Active Directory pour lui permettre de lire les propriétés de connexion des utilisateurs.
  3. Créez une entrée RADIUS Client pour chaque point d'accès ou contrôleur sans fil, en spécifiant l'adresse IP du point d'accès et un secret partagé fort et unique.
  4. Configurez une Network Policy définissant les conditions (par exemple, l'appartenance à un groupe d'utilisateurs) et les contraintes (par exemple, la méthode EAP, le délai d'expiration de la session) pour l'accès.
  5. Configurez la Connection Request Policy pour traiter les requêtes localement.

Pour FreeRADIUS sur Linux :

  1. Installez via le gestionnaire de paquets : sudo apt-get install freeradius freeradius-ldap.
  2. Configurez /etc/freeradius/3.0/clients.conf pour définir les clients RADIUS (les points d'accès) et leurs secrets partagés.
  3. Configurez le module LDAP dans /etc/freeradius/3.0/mods-available/ldap pour pointer vers votre Active Directory ou serveur LDAP.
  4. Activez le module LDAP : sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/.
  5. Définissez les méthodes EAP dans /etc/freeradius/3.0/mods-available/eap.

Étape 3 : Configurer les points d'accès

Sur votre contrôleur sans fil ou vos points d'accès individuels :

  1. Définissez l'adresse ou les adresses IP du serveur RADIUS et le port d'authentification (par défaut : UDP 1812).
  2. Configurez le Shared Secret - utilisez un minimum de 22 caractères, en mélangeant des caractères alphanumériques et spéciaux. Utilisez un secret unique par emplacement ou par groupe de points d'accès.
  3. Configurez le SSID pour utiliser le mode de sécurité WPA2-Enterprise ou WPA3-Enterprise avec la gestion des clés 802.1X.
  4. Configurez un serveur RADIUS secondaire pour la redondance.

Étape 4 : Intégration de l'annuaire

Pour l'intégration d'un AD sur site, le serveur RADIUS doit être joint au domaine ou disposer d'un accès en lecture LDAP. Assurez-vous que les comptes de service utilisés pour la liaison LDAP disposent des autorisations minimales requises. Pour le RADIUS cloud, configurez la synchronisation basée sur l'API ou l'intégration SAML/OIDC avec votre fournisseur d'identité.

Définissez des groupes d'utilisateurs clairs dans votre annuaire, car ce sont eux qui dicteront les politiques d'autorisation. Structure de groupe recommandée :

Groupe VLAN Niveau d'accès
Corp_Staff VLAN 10 Réseau interne complet
Corp_Contractors VLAN 20 Internet + ressources internes spécifiques
Corp_IoT VLAN 30 Isolé, ports spécifiques aux appareils uniquement
Corp_Guests VLAN 100 Internet uniquement via captive portal

Étape 5 : Configuration des clients et validation des certificats

Il s'agit de l'étape la plus critique sur le plan opérationnel. Utilisez les stratégies de groupe (GPO) pour Windows et les profils MDM pour macOS/iOS/Android afin de déployer silencieusement les configurations WiFi sur les appareils gérés. Le profil doit spécifier :

  • L'Autorité de certification racine (Root CA) qui a émis le certificat du serveur RADIUS.
  • Le nom de serveur attendu (CN ou SAN du certificat du serveur).
  • La méthode EAP et le protocole d'authentification interne.

Pour les appareils BYOD non gérés, fournissez des instructions d'intégration claires en libre-service, idéalement via un portail de contrôle d'accès au réseau (NAC).

Étape 6 : Implémenter l'attribution dynamique de VLAN

Configurez le serveur RADIUS pour renvoyer les attributs d'attribution de VLAN dans la réponse Access-Accept :

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = IEEE-802 (6)
  • Tunnel-Private-Group-Id = <VLAN ID>

Le point d'accès lit ces attributs et place le client authentifié sur le VLAN spécifié - aucune reconfiguration manuelle n'est requise lorsque les utilisateurs changent de rôle ou d'emplacement.


Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.

Bonnes Pratiques

La redondance est non négociable. Déployez un minimum de deux serveurs RADIUS (primaire et secondaire) et configurez tous les points d'accès pour un basculement automatique. Pour les déploiements sur site, envisagez de placer le serveur secondaire dans un emplacement physique ou une zone de disponibilité différents. Une panne du serveur RADIUS signifie que personne ne peut s'authentifier, ce qui représente une panne réseau complète pour les SSID protégés par 802.1X.

Surveillez l'expiration des certificats de manière proactive. L'expiration d'un certificat de serveur RADIUS est l'une des causes les plus courantes d'échecs d'authentification soudains et généralisés. Mettez en place une surveillance pour alerter les administrateurs au moins 30 jours avant l'expiration. Cela s'applique à la fois au certificat du serveur et à tous les certificats de l'autorité de certification (CA) intermédiaire dans la chaîne.

Traitez le Secret Partagé comme une information d'identification essentielle. Le secret partagé entre le point d'accès et le serveur RADIUS chiffre les paquets RADIUS. Utilisez des secrets uniques par emplacement ou par groupe de points d'accès, stockez-les dans un gestionnaire de secrets et renouvelez-les périodiquement. Consultez notre guide sur la Protection de votre réseau avec un DNS solide et la sécurité pour des recommandations plus larges sur l'hygiène de la sécurité réseau.

S'aligner sur les référentiels de conformité. Pour les environnements soumis à PCI-DSS (par exemple, les réseaux de paiement du commerce de détail), l'authentification 802.1X prend directement en charge les exigences en matière de contrôle d'accès au réseau et de journalisation des audits. Pour la conformité GDPR, les journaux de comptabilité RADIUS (port 1813) fournissent une piste d'audit détaillée de qui a accédé au réseau, d'où et quand - ce qui est précieux pour la réponse aux incidents. Pour les environnements de Santé, la segmentation du réseau via l'attribution dynamique de VLAN prend en charge les exigences HIPAA pour la protection des informations de santé protégées électroniques (ePHI).


Dépannage et atténuation des risques

Mode de défaillance Symptôme Résolution
Expiration du certificat Échecs d'authentification de masse soudains Surveiller l'expiration ; renouveler et redéployer le certificat
Désynchronisation NTP Échecs EAP-TLS intermittents S'assurer que le serveur RADIUS et les contrôleurs de domaine se synchronisent sur la même source NTP
Perte de connectivité LDAP L'authentification échoue lorsque l'AD est inaccessible Déployer des contrôleurs de domaine redondants ; configurer RADIUS pour mettre en cache les authentications récentes
Secret Partagé incorrect Les journaux du point d'accès affichent RADIUS timeout ou Bad authenticator Vérifier que le secret correspond à la fois sur le point d'accès et sur le serveur RADIUS
Incohérence du certificat client Échecs EAP-TLS pour des appareils spécifiques Vérifier que le certificat client est émis par une autorité de certification de confiance ; vérifier la période de validité du certificat
VLAN non attribué Utilisateur authentifié mais sur le mauvais segment de réseau Vérifier que les attributs RADIUS sont correctement renvoyés ; vérifier la configuration VLAN du point d'accès

Pour approfondir le processus de configuration 802.1X lui-même, le guide Comment configurer l'authentification WiFi 802.1X : Un guide étape par étape propose des procédures de configuration détaillées et spécifiques à chaque constructeur.


ROI et impact commercial

Le passage d'un PSK à un système 802.1X basé sur RADIUS nécessite un investissement initial en configuration, et potentiellement en licences pour les solutions cloud ou en matériel pour les déploiements sur site. Le calcul du ROI est simple :

Atténuation des risques : Le coût moyen d'une violation de données au Royaume-Uni dépasse les 3 millions de livres sterling (rapport IBM sur le coût d'une violation de données). Un PSK compromis peut exposer l'ensemble du réseau. Le protocole 802.1X limite la zone d'impact à un seul compte utilisateur compromis, qui peut être désactivé en quelques secondes via l'annuaire.

Efficacité opérationnelle : L'attribution dynamique de VLAN élimine la reconfiguration manuelle du réseau lors des changements de rôle du personnel. L'intégration d'un nouvel employé consiste simplement à l'ajouter au bon groupe Active Directory - son accès au réseau suit automatiquement.

Posture de conformité : Pour les organisations soumises aux normes PCI-DSS, ISO 27001 ou Cyber Essentials Plus, le 802.1X est un contrôle direct que les auditeurs s'attendent à voir. Son déploiement renforce votre conformité et réduit les coûts de correction des audits.

Expérience invité et analyses : Pour les exploitants de sites, l'intégration de RADIUS pour l'authentification du personnel avec la plateforme Guest WiFi de Purple pour l'accès des visiteurs crée un modèle d'accès unifié et hiérarchisé. Le personnel s'authentifie de manière transparente via 802.1X ; les invités se connectent via un portail captif personnalisé. La plateforme WiFi Analytics de Purple offre ensuite une visibilité en temps réel sur les temps de séjour des visiteurs, les taux de visites répétées et les indicateurs d'engagement - des données qui influencent directement les dépenses marketing et les décisions d'exploitation des sites.


Pour aller plus loin, consultez le guide Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo pour obtenir des conseils de mise en œuvre en portugais, et l'article Qu'est-ce qu'une ligne louée ? Internet professionnel dédié pour savoir comment s'assurer que la connectivité sous-jacente répond aux exigences de l'entreprise.

Définitions clés

RADIUS (Remote Authentication Dial-In User Service)

Un protocole réseau fournissant une gestion centralisée de l'Authentification, de l'Autorisation et de la Comptabilité (AAA) pour les utilisateurs se connectant à un service réseau. Défini dans la RFC 2865.

Le composant serveur central qui valide les identifiants des utilisateurs auprès d'un annuaire avant d'accorder l'accès au WiFi. Tout déploiement de WiFi d'entreprise utilisant le protocole 802.1X requiert un serveur RADIUS.

802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports (PNAC). Elle fournit un mécanisme d'authentification aux appareils souhaitant se connecter à un LAN ou WLAN, bloquant tout trafic non-EAP jusqu'à ce que l'authentification réussisse.

Le cadre de référence global qui définit la manière dont le Supplicant, l'Authentificateur et le serveur d'authentification communiquent. Lorsque les équipes informatiques parlent de "sécurité WiFi d'entreprise", elles font généralement référence au WPA2/WPA3-Enterprise avec 802.1X.

Supplicant

L'appareil client - ou plus précisément, la pile logicielle 802.1X sur cet appareil - qui lance le processus d'authentification en présentant des identifiants au réseau.

Sur Windows, le supplicant intégré est le service de configuration automatique sans fil. Sur macOS et iOS, il est natif au système d'exploitation. S'assurer que le supplicant est correctement configuré (particulièrement pour la validation des certificats) est la source la plus fréquente de problèmes de déploiement.

Authentificateur

L'appareil réseau - généralement un point d'accès WiFi ou un contrôleur sans fil - qui agit comme intermédiaire entre le Supplicant et le serveur RADIUS, appliquant le contrôle d'accès en fonction du résultat de l'authentification.

L'AP bloque tout le trafic de données sur le port jusqu'à ce qu'il reçoive un Access-Accept du serveur RADIUS. Il lit également les attributs RADIUS (par exemple, l'attribution de VLAN) de la réponse Access-Accept et les applique à la session.

EAP (Extensible Authentication Protocol)

Un cadre d'authentification défini dans la RFC 3748 qui fournit un mécanisme de transport standardisé pour diverses méthodes d'authentification (TLS, PEAP, TTLS, etc.) entre le Supplicant et le serveur d'authentification.

L'EAP est la "langue" parlée entre le client et le serveur RADIUS. Le choix de la méthode EAP (EAP-TLS par rapport à PEAP) détermine le niveau de sécurité et la complexité de déploiement du système d'authentification.

PEAP (Protected EAP)

Une méthode EAP qui établit d'abord un tunnel TLS à l'aide du certificat du serveur, puis effectue une authentification secondaire (généralement MSCHAPv2 avec nom d'utilisateur/mot de passe) à l'intérieur de ce tunnel chiffré.

La méthode d'authentification WiFi d'entreprise la plus courante en raison de son équilibre entre sécurité et simplicité de déploiement. Elle ne nécessite qu'un certificat côté serveur, ce qui la rend beaucoup plus facile à déployer que l'EAP-TLS.

Attribution dynamique de VLAN

Une fonctionnalité RADIUS par laquelle le serveur inclut des attributs spécifiques au VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) dans la réponse Access-Accept, ordonnant à l'AP de placer le client authentifié sur un VLAN spécifique.

Permet à un seul SSID de desservir plusieurs populations d'utilisateurs ayant des exigences de sécurité différentes. Élimine le besoin de diffuser plusieurs SSID pour différents groupes d'utilisateurs, réduisant ainsi la surcharge RF et simplifiant l'expérience utilisateur.

Secret partagé

Une chaîne de caractères préconfigurée connue uniquement de l'Authentificateur (AP) et du serveur RADIUS, utilisée pour signer et chiffrer les paquets RADIUS, garantissant l'intégrité et l'authenticité de la communication.

Un élément critique de la configuration de sécurité. Si le secret partagé est faible ou compromis, un attaquant pourrait falsifier des réponses RADIUS Access-Accept, accordant ainsi un accès réseau non autorisé. Utilisez des secrets uniques par emplacement et stockez-les dans un gestionnaire de secrets.

Contournement de l'authentification MAC (MAB)

Un mécanisme d'authentification de secours dans lequel l'adresse MAC d'un appareil est utilisée comme identifiant, permettant l'accès au réseau pour les appareils qui ne prennent pas en charge les supplicants 802.1X.

Utilisé pour les appareils sans interface utilisateur (imprimantes, capteurs IoT, caméras IP). Les adresses MAC étant visibles publiquement et faciles à usurper, le MAB fournit une identification de l'appareil plutôt qu'une authentification forte. Associez-le toujours à une attribution de VLAN restrictive.

Exemples concrets

Une chaîne nationale de vente au détail comptant 500 points de vente doit mettre en œuvre un WiFi sécurisé pour les tablettes des directeurs de magasin et les terminaux de point de vente. Elle utilise actuellement une clé PSK unique pour l'ensemble des magasins, qui est fréquemment partagée avec du personnel et des sous-traitants non autorisés. Elle s'appuie sur Azure AD pour la gestion des identités et ne dispose d'aucun personnel informatique dédié dans les succursales.

Déployez une solution Cloud RADIUS intégrée directement avec Azure AD. Cela élimine la nécessité de déployer et de gérer des serveurs RADIUS sur site dans 500 points de vente. L'équipe informatique utilise Microsoft Intune pour pousser un profil WiFi configuré pour PEAP-MSCHAPv2 vers toutes les tablettes des directeurs de magasin et les terminaux de point de vente, en imposant strictement la validation du certificat du serveur Cloud RADIUS. La politique de Cloud RADIUS vérifie l'appartenance de l'utilisateur aux groupes Azure AD avant d'accorder l'accès : le groupe "Store_Managers" reçoit le VLAN 10 (accès complet aux terminaux de point de vente et au back-office), tandis que le groupe "Contractors" reçoit le VLAN 20 (accès internet uniquement). À la fin de la mission d'un sous-traitant, le fait de le retirer du groupe Azure AD révoque immédiatement son accès WiFi sur l'ensemble des 500 points de vente simultanément - aucun changement de clé PSK n'est nécessaire.

Commentaire de l'examinateur : Cette approche résout la vulnérabilité principale (le partage de la clé PSK) tout en tenant compte des contraintes opérationnelles (absence de personnel informatique local, environnement Azure AD). Cloud RADIUS offre l'évolutivité nécessaire et s'intègre nativement avec le fournisseur d'identités existant. L'utilisation de l'attribution dynamique de VLAN garantit que même si l'appareil d'un sous-traitant est présent sur site après la fin de sa mission, son retrait du groupe d'annuaire constitue l'unique action requise pour révoquer l'accès.

Un hôtel de centre-ville de 400 chambres doit fournir un WiFi sécurisé à la fois pour son personnel (réception, entretien, direction) et pour ses clients. Le personnel doit accéder au système de gestion hôtelière (PMS) et aux serveurs internes. Les clients ont uniquement besoin d'un accès à internet. L'hôtel dispose d'un unique environnement Windows Server sur site.

Déployez Microsoft NPS sur une machine virtuelle Windows Server dédiée. Configurez deux SSID sur l'infrastructure sans fil : "Hotel_Staff" (WPA2-Enterprise, 802.1X) et "Hotel_Guest" (ouvert ou WPA2-Personal, avec redirection vers un Captive Portal). Pour le SSID du personnel, NPS valide les identifiants auprès d'Active Directory et renvoie des attributions dynamiques de VLAN : groupe AD "Management" → VLAN 10 (accès complet), "FrontDesk" → VLAN 20 (accès au PMS), "Housekeeping" → VLAN 30 (accès internet et application de planification uniquement). Pour les clients, intégrez le Captive Portal avec la plateforme de WiFi invité de Purple afin d'offrir une expérience de connexion personnalisée aux couleurs de la marque, de collecter des données de premier niveau (e-mail, consentement marketing) et d'obtenir des analyses sur le temps de séjour et les visites récurrentes. Le modèle à double SSID sépare complètement le trafic du personnel et des clients au niveau de la couche réseau.

Commentaire de l'examinateur : Le modèle à double SSID est ici la bonne approche, plutôt qu'un SSID unique avec un routage de politiques complexe. Il offre une séparation opérationnelle claire et simplifie le dépannage. L'intégration de Purple pour le SSID invité est une décision commerciale judicieuse : elle transforme le réseau invité, de centre de coûts en un canal de capture de données et de marketing, avec un retour sur investissement mesurable grâce aux taux de visites répétées et à l'engagement des campagnes d'e-mailing.

Questions d'entraînement

Q1. Votre organisation migre 2 000 ordinateurs portables Windows d'une clé PSK partagée vers le 802.1X avec PEAP-MSCHAPv2. Votre équipe de sécurité signale que PEAP est vulnérable à la collecte d'identifiants via des points d'accès malveillants. Quelle est l'étape de configuration la plus importante pour atténuer ce risque, et comment la déployez-vous à grande échelle ?

Conseil : Réfléchissez à ce qui empêche un client de faire confiance à un serveur RADIUS frauduleux présentant un certificat auto-signé.

Voir la réponse type

L'étape critique consiste à imposer une validation stricte du certificat de serveur sur chaque appareil client. À l'aide d'objets de stratégie de groupe (GPO), déployez un profil WiFi sur les 2 000 ordinateurs portables spécifiant : (1) le certificat de l'autorité de certification (CA) racine exact qui a émis le certificat du serveur RADIUS, (2) le nom de serveur attendu (CN/SAN), et (3) que le client ne doit pas inviter l'utilisateur à faire confiance à de nouveaux certificats. Cela garantit que même si un attaquant déploie un point d'accès malveillant avec un faux certificat, le client rejettera la liaison TLS et refusera d'envoyer les identifiants. Sans cette configuration, PEAP n'offre aucune protection significative contre les attaques de points d'accès malveillants.

Q2. Un directeur informatique d'hôpital doit fournir un accès réseau à 300 appareils IoT médicaux (pompes à perfusion, équipements de surveillance) qui ne prennent pas en charge le 802.1X. Ces appareils côtoient les postes de travail du personnel sur la même infrastructure sans fil. Comment l'infrastructure RADIUS doit-elle gérer ces appareils, et quels contrôles réseau doivent être mis en place ?

Conseil : Pensez à la méthode d'authentification disponible pour les appareils sans écran et à la manière de compenser sa faiblesse intrinsèque.

Voir la réponse type

Configurez le MAC Authentication Bypass (MAB) sur le serveur RADIUS pour ces appareils spécifiques. Enregistrez l'adresse MAC de chaque appareil dans un groupe Active Directory dédié ou dans une base de données RADIUS. Les adresses MAC étant faciles à usurper, le serveur RADIUS doit utiliser l'attribution dynamique de VLAN pour placer tous les appareils authentifiés par MAB sur un VLAN dédié et hautement restreint (par exemple, le VLAN 30 - IoT). Ce VLAN doit être protégé par un pare-feu pour autoriser uniquement la communication avec des adresses IP de serveurs médicaux spécifiques et bloquer tout autre trafic, y compris l'accès à internet et les mouvements latéraux vers les VLAN du personnel. Les postes de travail du personnel s'authentifient via 802.1X et sont placés sur un VLAN distinct. Cette architecture répond aux exigences de segmentation réseau de la norme HIPAA pour les appareils adjacents aux ePHI.

Q3. Vous êtes l'architecte réseau d'une chaîne de 50 restaurants. L'authentification fonctionne correctement dans 49 établissements à l'aide de Cloud RADIUS, mais un établissement spécifique signale que tous les appareils échouent à s'authentifier. Le portail de gestion Cloud RADIUS indique qu'aucune demande d'authentification n'arrive de cet établissement. Quelle est votre approche de diagnostic ?

Conseil : Si le serveur RADIUS ne reçoit aucune demande, le problème se situe sur le chemin de communication entre l'authentificateur et le serveur, et non dans la logique d'authentification elle-même.

Voir la réponse type

Puisque le serveur RADIUS ne reçoit aucune demande de cet établissement, le problème se situe entre les points d'accès et le serveur cloud RADIUS. Étapes de diagnostic dans l'ordre : (1) Vérifiez l'adresse IP et le port du serveur RADIUS (UDP 1812) configurés sur les points d'accès ou le contrôleur sans fil de l'établissement - une faute de frappe à ce niveau est la cause la plus fréquente. (2) Vérifiez les règles du pare-feu local ou du routeur de cet établissement pour confirmer que le trafic sortant UDP 1812 est autorisé vers la plage IP du cloud RADIUS. (3) Vérifiez que le secret partagé configuré sur les points d'accès correspond au secret configuré pour cet établissement dans le portail Cloud RADIUS - une non-correspondance amène le serveur RADIUS à rejeter silencieusement les paquets. (4) Vérifiez si la connexion internet de l'établissement fonctionne - le cloud RADIUS nécessite une connectivité internet fiable. L'exécution d'une capture de paquets sur le point d'accès ou le routeur en amont confirmera si les paquets RADIUS sont envoyés et si les réponses sont reçues.

Continuer la lecture de cette série

Guide de l'administrateur réseau pour la configuration de l'authentification RADIUS pour le WiFi invité

Une référence technique complète pour les administrateurs réseau sur le déploiement de l'authentification RADIUS pour le WiFi invité. Couvre l'architecture, les étapes de configuration indépendantes du constructeur, les meilleures pratiques de sécurité et le dépannage des échecs de déploiement courants.

Lire le guide →

Mise en œuvre de SCEP pour un accès WiFi 802.1X et BYOD sécurisé dans l'enseignement supérieur

Ce guide technique explique en détail comment les équipes informatiques de l'enseignement supérieur peuvent automatiser l'inscription aux certificats 802.1X pour des milliers d'appareils BYOD à l'aide de SCEP. Il présente l'architecture, les avantages en matière de sécurité et les étapes de déploiement concrètes pour remplacer l'intégration manuelle par un modèle d'accès réseau sécurisé et sans contact.

Lire le guide →

Configuration de l'authentification RADIUS pour les réseaux WiFi invités et collaborateurs

Ce guide de référence technique présente l'architecture, la configuration et le déploiement de l'authentification RADIUS pour les réseaux WiFi d'entreprise destinés aux invités et aux collaborateurs. Il fournit aux architectes réseau et aux responsables informatiques les protocoles exacts, les normes de sécurité et les méthodologies de dépannage requis pour concevoir des systèmes de contrôle d'accès sans fil sécurisés et évolutifs.

Lire le guide →

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.