Passer au contenu principal
Français

Comment configurer un serveur RADIUS pour l'authentification WiFi : Guide 802.1X étape par étape

Configurez FreeRADIUS, Windows Server NPS et Cloud RADIUS pour l'authentification WiFi 802.1X en entreprise. Guide étape par étape couvrant les secrets partagés, les certificats EAP-TLS, l'attribution dynamique de VLAN et l'intégration de Microsoft Entra ID.

Par Iain JewittPublié le
📖 8 min de lecture1,933 mots2 exemples concrets3 questions d'entraînement5 définitions clés

Video overview

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans le 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 vaste campus universitaire - s'appuyer sur une simple clé pré-partagée représente un risque de sécurité important. 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, fait office de gardien pour votre réseau. Lorsqu'un appareil tente de se connecter à un point d'accès WiFi, le point d'accès agit comme un 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 rejet. 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 d'architecture majeure à laquelle vous ferez face est le choix 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 de Microsoft, ou NPS, ou le logiciel 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 qualifiée, c'est une approche tout à fait valable. D'un autre côté, les solutions RADIUS dans le cloud sont devenues de plus en plus populaires, en particulier pour les environnements distribués tels que les chaînes de magasins ou les établissements hôteliers. Le RADIUS cloud élimine complètement la gestion du matériel, offre une haute disponibilité intégrée et s'intègre parfaitement 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 n'ayant pas à déployer et à maintenir des serveurs sur site pour chaque site l'emporteront presque certainement sur ce coût. Lors du déploiement de RADIUS, le protocole d'authentification extensible - EAP - est la pièce maîtresse. Il définit la manière dont le client et le serveur négocient et effectuent l'authentification. 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 être lourd sur le plan administratif. Vous avez besoin d'une infrastructure à clés publiques et d'une solution MDM pour pousser les certificats vers 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 à l'aide d'un identifiant et d'un mot de passe. Cette solution est nettement plus facile à déployer que EAP-TLS, car vous n'avez à gérer qu'un seul certificat - celui du serveur. Cependant, et c'est un point critique, si les clients ne sont pas configurés de manière stricte pour valider le certificat du serveur, ils sont vulnérables aux points d'accès malveillants. 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 des certificats sur chaque appareil client. Utilisez des Group Policy Objects pour les appareils Windows et des profils MDM - qu'il s'agisse d'Intune, Jamf ou d'une autre solution - pour les appareils macOS et 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 consiste à 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 indique 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 d'entreprise des BYOD ou des appareils invités. Un membre de l'équipe financière doit se trouver sur un segment de 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 à une solution de Captive Portal comme la plateforme de WiFi invité de Purple est une combinaison puissante. Les collaborateurs 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 main et fournit des analyses sur le comportement des visiteurs, transformant ainsi votre réseau d'un centre de coûts en un actif de business intelligence.Place maintenant à une session rapide de questions-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 les conflits de ressources peuvent provoquer des pannes intermittentes très difficiles à diagnostiquer. Deuxième question : RADIUS peut-il gérer l'authentification des appareils sans écran ni interface, comme les imprimantes ou les capteurs IoT ? Oui, grâce au contournement de l'authentification MAC, ou MAB (MAC Authentication Bypass). 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 serveur 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 ce briefing : 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 organisation est distribuée et orientée 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 grâce à des politiques DNS robustes. Merci de votre écoute.

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

Synthèse

Comment configurer un serveur RADIUS pour l'authentification WiFi : Guide 802.1X étape par étape

Les réseaux sans fil d'entreprise requièrent une gestion centralisée des identités, une segmentation basée sur les rôles et une protection cryptographique forte. S'appuyer sur des clés pré-partagées (PSK) expose les organisations à des fuites de mots de passe, à des accès d'appareils non autorisés et à des difficultés d'administration complexes à chaque départ d'employé.

La configuration d'un serveur RADIUS (Remote Authentication Dial-In User Service) permet d'activer l'authentification d'entreprise IEEE 802.1X. Chaque appareil et utilisateur qui se connecte s'authentifie individuellement auprès d'un annuaire central - comme Microsoft Entra ID, Google Workspace, Okta ou un Active Directory sur site.

Ce guide technique fournit des instructions de déploiement étape par étape pour configurer un serveur RADIUS pour le WiFi d'entreprise. Nous couvrons la configuration de FreeRADIUS sous Linux, la configuration de Network Policy Server (NPS) sur Windows Server, les architectures modernes Cloud RADIUS, l'attribution dynamique de VLAN et le renforcement de la sécurité contre BlastRADIUS.

Présentation de l'architecture 802.1X & RADIUS

Le framework IEEE 802.1X divise l'accès au réseau en trois entités distinctes :

  1. Le Supplicant (le demandeur) : L'appareil client final (ordinateur portable, smartphone ou tablette) exécutant le logiciel client 802.1X qui présente ses informations d'identification.
  2. L'Authentificateur : Le point d'accès (AP) sans fil ou le contrôleur LAN sans fil (WLC) qui contrôle l'accès physique au réseau et relaye les messages d'authentification.
  3. Le Serveur d'authentification : Le serveur RADIUS qui valide les informations d'identification par rapport à un annuaire d'identités et renvoie les politiques d'autorisation réseau.
+---------------+        EAP over LAN (EAPoL)        +-------------------+
|  Supplicant   | <================================> |  Authentificateur |
| (Appareil Clt)|                                    | (AP / Contrôleur) |
+---------------+                                    +-------------------+
                                                               ||
                                                               || Protocole RADIUS
                                                               || (UDP 1812 / TCP 2083)
                                                               \/
                                                     +-------------------+
                                                     |  Serveur RADIUS   |
                                                     |  (FreeRADIUS/NPS) |
                                                     +-------------------+
                                                               ||
                                                               || Recherche d'identité
                                                               \/
                                                     +-------------------+
                                                     | Fournisseur Ident |
                                                     | (Entra ID / LDAP) |
                                                     +-------------------+

Flux de communication RADIUS

  1. Association : Le client s'associe au SSID d'entreprise (WPA2-Enterprise ou WPA3-Enterprise).
  2. Initiation EAP : L'AP bloque tout le trafic de données et envoie une trame EAP-Request/Identity au client.
  3. Réponse d'identité : Le client répond avec une trame EAP-Response/Identity.
  4. Encapsulation RADIUS : L'AP encapsule la charge utile EAP dans un paquet RADIUS Access-Request et la transmet au serveur RADIUS.
  5. Négociation EAP : Le client et le serveur RADIUS négocient la méthode d'authentification cryptographique (telle que EAP-TLS ou PEAP).
  6. Autorisation & Access-Accept : Une fois la validation réussie, le serveur RADIUS émet un paquet RADIUS Access-Accept contenant la clé PMK (Pairwise Master Key) et des attributs facultatifs d'attribution dynamique de VLAN.
  7. Ouverture du port : L'AP débloque le port virtuel et lance la poignée de main à 4 voies (4-way handshake) pour chiffrer le trafic sans fil sur les ondes.

Pour des concepts d'architecture plus approfondis, découvrez notre Guide de Sécurité WiFi pour Entreprise et notre Guide du Captive Portal.

Configuration étape par étape : FreeRADIUS sur Linux

FreeRADIUS est la suite RADIUS open-source standard mondiale. Vous trouverez ci-dessous la séquence de configuration pour Ubuntu 24.04 LTS / Debian 12.

Étape 1 : Installer les paquets FreeRADIUS

sudo apt update
sudo apt install -y freeradius freeradius-utils freeradius-ldap ssl-cert

Étape 2 : Définir les clients Network Access Server (NAS)

Modifiez /etc/freeradius/3.0/clients.conf pour autoriser vos points d'accès sans fil et configurer un secret partagé :

client enterprise_wlan {
  ipaddr: 192.168.10.0/24
  secret: Str0ngSh@redSecr3t2026!
  shortname: branch-aps
  nas_type: other
  require_message_authenticator: yes
}

Note : Imposez toujours les attributs Message-Authenticator de la RFC 2869 pour vous prémunir contre les attaques de falsification BlastRADIUS.

Étape 3 : Configurer les modules d'authentification EAP

Ouvrez /etc/freeradius/3.0/mods-available/eap et configurez la méthode EAP par défaut :

eap {
  default_eap_type: tls
  timer_expire: 60
  ignore_unknown_eap_types: no
  cisco_accounting_username_bug: no
  max_sessions: 4096

  tls-config tls-common {
    certdir: ${confdir}/certs
    cadir: ${confdir}/certs
    private_key_file: ${certdir}/radius-server.key
    certificate_file: ${certdir}/radius-server.crt
    ca_file: ${cadir}/ca.crt
    cipher_list: HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH
    tls_min_version: 1.2
  }
}

Étape 4 : Tester en mode débogage

Avant de l'exécuter en tant que service système, arrêtez le démon et lancez-le en mode débogage au premier plan :

sudo systemctl stop freeradius
sudo freeradius -X

Testez l'authentification locale à l'aide de radtest :

radtest testuser Password123 127.0.0.1 0 testing123

Une réponse réussie renvoie Received Access-Accept Id 1.

Configuration étape par étape : Windows Server NPS

Microsoft Network Policy Server (NPS) est le rôle de serveur RADIUS intégré pour les environnements Windows Server connectés à Active Directory Domain Services (AD DS).

+-------------------------------------------------------------------------+
|                  Windows Server Network Policy Server                   |
|                                                                         |
|  [Clients RADIUS (AP / WLC)] ---> [Stratégies de demande de connexion]  |
|                                                  |                      |
|                                                  v                      |
|  [Active Directory DS / PKI] <--- [Stratégies réseau (VLAN / EAP-TLS)]  |
+-------------------------------------------------------------------------+

Étape 1 : Installer les services d'accès et de stratégie réseau

Ouvrez PowerShell en tant qu'administrateur :

Install-WindowsFeature NPAS -IncludeManagementTools
Register-ActiveDirectoryServer -Server nps01.corp.local

Étape 2 : Enregistrer les clients RADIUS (bornes d'accès)

  1. Ouvrez Network Policy Server (nps.msc).
  2. Développez Clients et serveurs RADIUS > Faites un clic droit sur Clients RADIUS > Nouveau.
  3. Saisissez le nom convivial : Cisco-Catalyst-AP-Cluster.
  4. Saisissez l'adresse IP ou le sous-réseau CIDR (ex. 10.50.0.0/24).
  5. Générez et saisissez un secret partagé fort (minimum 24 caractères alphanumériques).

Étape 3 : Créer une stratégie réseau pour l'authentification WiFi

  1. Sous Stratégies > Stratégies réseau, faites un clic droit et sélectionnez Nouveau.
  2. Nom de la stratégie : Staff-WiFi-802.1X-Policy. Type de serveur d'accès réseau : Non spécifié.
  3. Conditions :
    • Ajoutez Groupes Windows : CORP\WiFi-Authorised-Users
    • Ajoutez Type de port NAS : Sans fil - IEEE 802.11 ou Sans fil - Autre
  4. Autorisation d'accès : Sélectionnez Accès accordé.
  5. Méthodes d'authentification :
    • Désélectionnez les méthodes moins sécurisées.
    • Sous Types EAP, ajoutez Microsoft : Carte à puce ou autre certificat (EAP-TLS).
    • Modifiez la méthode et sélectionnez le certificat de serveur RADIUS émis par votre autorité de certification d'entreprise Active Directory Certificate Services (AD CS).
  6. Contraintes : Définissez le délai d'expiration d'inactivité sur 30 minutes et le délai d'expiration de session sur 8 heures.

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.

Cloud RADIUS : Architecture zero-trust moderne

Les serveurs RADIUS sur site traditionnels présentent des défis opérationnels majeurs :

  • Frais élevés de licence serveur et de correctifs.
  • Absence d'API d'authentification natives pour les annuaires d'identité cloud comme Microsoft Entra ID ou Google Workspace.
  • Vulnérabilité aux pannes WAN dans les succursales.

Les réseaux d'entreprise modernes déploient Cloud RADIUS pour centraliser l'authentification sans aucune empreinte de serveur sur site.

Fonctionnalité NPS Windows hérité / FreeRADIUS Architecture Cloud RADIUS
Intégration d'annuaire LDAP / Kerberos sur site Intégration native Microsoft Entra ID, Google Workspace, Okta
Sécurité du transport UDP 1812/1813 non chiffré RadSec (RFC 6614) TLS via TCP 2083
Automatisation des certificats Configuration SCEP / NDES manuelle Connecteurs PKI automatisés pour Intune et Jamf
Haute disponibilité Basculement actif-passif manuel Redondance Anycast globale multi-région
Maintenance Correctifs du système d'exploitation et licences OS Service cloud géré avec mises à jour continues

Pour modéliser votre architecture, explorez notre Guide WiFi multi-locataire et nos Solutions WiFi pour le personnel.

Configuration de l'attribution dynamique de VLAN

L'attribution dynamique de VLAN (définie par les RFC 2868 et RFC 3580) permet à un SSID d'entreprise unique de segmenter dynamiquement les utilisateurs dans des sous-réseaux distincts en fonction de leur appartenance à un groupe d'annuaire.

                          [SSID personnel d'entreprise]
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
        [VLAN 10 : Cadres]     [VLAN 20 : Ingénierie]  [VLAN 30 : Prestataires]
        (10.10.10.0/24)        (10.10.20.0/24)        (10.10.30.0/24)

Attributs RADIUS standard requis

Lorsque le serveur RADIUS valide les identifiants, il ajoute ces attributs à la réponse Access-Accept :

Tunnel-Type = 13 (VLAN)
Tunnel-Medium-Type = 6 (802 - comprend tous les supports 802 plus le format canonique Ethernet)
Tunnel-Private-Group-ID = 20 (ou nom de VLAN "CORP_ENG")

Exemple de mappage dynamique de VLAN FreeRADIUS

Dans /etc/freeradius/3.0/users :

DEFAULT Group == "Engineering-Team"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "20"

DEFAULT Group == "Contractors"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "30"

Règles de pare-feu réseau et configuration des ports

Assurez-vous que les pare-feux réseau autorisent la communication entre les points d'accès et les serveurs RADIUS :

Protocole Numéro de port Description Source Destination
UDP 1812 Authentification RADIUS (RFC 2865) Points d'accès / WLC Serveur RADIUS
UDP 1813 Comptabilité RADIUS (RFC 2866) Points d'accès / WLC Serveur RADIUS
TCP 2083 RadSec - RADIUS sur TLS (RFC 6614) Points d'accès / WLC Cloud RADIUS
UDP 1645 / 1646 Authentification / Comptabilité RADIUS héritée (Obsolète) Anciens appareils NAS Serveur RADIUS

Renforcement de la sécurité et atténuation de BlastRADIUS

Atténuation de BlastRADIUS (CVE-2024-3596)

En juillet 2024, des chercheurs ont révélé BlastRADIUS, une vulnérabilité de collision MD5 dans le protocole RADIUS qui permet à un attaquant positionné entre le point d'accès et le serveur RADIUS de falsifier des réponses Access-Accept.

Pour sécuriser votre déploiement :

  1. Appliquer Message-Authenticator : Exiger l'attribut Message-Authenticator (RFC 2869) sur tous les paquets Access-Request et Access-Accept.
  2. Transition vers EAP-TLS : L'authentification EAP-TLS basée sur les certificats est cryptographiquement insensible à la falsification de proxy car les clés cryptographiques TLS sont dérivées de bout en bout entre le client et le serveur RADIUS.
  3. Déployer RadSec (RFC 6614) : Encapsuler le trafic RADIUS dans des tunnels TLS pour empêcher l'altération des paquets par attaque de l'homme du milieu.

Dépannage des échecs d'authentification 802.1X

Symptôme d'erreur Cause racine Remédiation technique
Le client reçoit immédiatement un échec de connexion Incohérence du secret partagé entre le point d'accès et le serveur RADIUS Vérifier la chaîne du secret partagé dans le contrôleur de point d'accès et la configuration RADIUS.
Délai d'authentification dépassé après 10 à 15 secondes Pare-feu bloquant le port UDP 1812 ou routage manquant Vérifier les listes de contrôle d'accès (ACL) du pare-feu et confirmer que le point d'accès peut pinguer l'IP du serveur RADIUS via le VLAN d'administration.
Journal RADIUS : "CA inconnu" ou "Certificat non approuvé" Certificat de l'autorité de certification (CA) racine manquant sur le client ou le serveur RADIUS Installer les certificats de l'autorité de certification intermédiaire et racine dans le magasin de confiance du client et dans le répertoire de certificats du serveur RADIUS.
Le client s'authentifie mais reçoit une IP APIPA (169.254.x.x) L'ID de VLAN dynamique n'existe pas sur le port trunk du commutateur du point d'accès Vérifier que la configuration du trunk du commutateur achemine bien l'ID de VLAN cible spécifié dans Tunnel-Private-Group-ID.
Journal RADIUS : "Message-Authenticator manquant" Le client NAS ne prend pas en charge la RFC 2869 ou nécessite une mise à jour du firmware Mettre à jour le firmware du contrôleur de point d'accès ou activer l'obligation du Message-Authenticator sur le profil NAS.

Questions fréquentes

Quel port un serveur RADIUS utilise-t-il pour l'authentification WiFi ?

L'authentification RADIUS standard fonctionne sur le port UDP 1812, et la traçabilité (accounting) sur le port UDP 1813. Les anciennes implémentations utilisaient les ports UDP 1645 et 1646. Les déploiements Cloud RADIUS modernes utilisent RadSec sur le port TCP 2083 avec chiffrement TLS.

Dois-je choisir FreeRADIUS ou Windows Server NPS ?

Choisissez Windows Server NPS si votre organisation repose exclusivement sur des services de domaine Active Directory locaux. Choisissez FreeRADIUS pour une flexibilité open-source de haute performance et des environnements Linux. Si votre entreprise utilise des fournisseurs d'identité cloud comme Microsoft Entra ID ou Google Workspace, optez pour Cloud RADIUS.

Comment connecter Microsoft Entra ID (Azure AD) à un serveur RADIUS ?

Microsoft Entra ID ne prend pas en charge nativement les anciens protocoles d'authentification locaux LDAP ou NTLM. Pour connecter Entra ID au WiFi d'entreprise, déployez Cloud RADIUS associé au déploiement de certificats Microsoft Intune SCEP afin d'authentifier les terminaux en utilisant EAP-TLS.

Pourquoi EAP-TLS est-il préférable à PEAP-MSCHAPv2 ?

EAP-TLS utilise une authentification mutuelle par certificat X.509 où le client et le serveur valident tous deux les identités cryptographiques. PEAP-MSCHAPv2 repose sur des mots de passe utilisateurs à l'intérieur d'un tunnel TLS, ce qui expose les réseaux aux attaques par pulvérisation de mots de passe, au phishing et au vol d'identifiants par points d'accès malveillants.

Pour une architecture de sécurité WiFi d'entreprise sur mesure, consultez notre WiFi Analytics Guide ou contactez un spécialiste des réseaux d'entreprise.

Définitions clés

RADIUS (RFC 2865)

Remote Authentication Dial-In User Service. Un protocole client-serveur réseau qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA).

Fonctionne comme le serveur d'authentification validant les identifiants de l'appareil et de l'utilisateur soumis via les points d'accès sans fil.

IEEE 802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports (PNAC) offrant une authentification sécurisée pour les périphériques tentant de se connecter à un réseau LAN ou WLAN.

Définit l'encapsulation des trames EAP entre le supplicant (périphérique d'extrémité) et l'authentificateur (point d'accès).

EAP-TLS (RFC 5216)

Extensible Authentication Protocol - Transport Layer Security. Protocole d'authentification mutuelle basé sur des certificats où le serveur RADIUS et le client valident tous deux des certificats numériques.

La méthode d'authentification standard de l'industrie pour le WiFi d'entreprise zero-trust, éliminant les mots de passe.

RadSec (RFC 6614)

RADIUS sur TLS. Une norme qui encapsule les paquets UDP RADIUS traditionnels dans des tunnels TLS TCP sécurisés sur le port 2083.

Sécurise le trafic d'authentification RADIUS qui traverse les liaisons WAN publiques non sécurisées entre les points d'accès locaux et les serveurs Cloud RADIUS.

Attribution dynamique de VLAN (RFC 3580)

Un mécanisme RADIUS qui renvoie des identifiants VLAN dans les réponses Access-Accept en fonction du rôle de l'utilisateur ou de la posture de l'appareil.

Permet à un SSID d'entreprise unique de placer dynamiquement les utilisateurs sur des segments réseau isolés.

Exemples concrets

Un ingénieur réseau doit configurer FreeRADIUS pour authentifier les clients sans fil se connectant via 12 points d'accès Cisco Catalyst sur le sous-réseau 10.20.0.0/24 avec le secret partagé SecretAuthKey2026. Quelle configuration doit être placée dans clients.conf ?

client branch_aps { ipaddr = 10.20.0.0/24 secret = SecretAuthKey2026 nas_type = cisco require_message_authenticator = yes }

Commentaire de l'examinateur : Définir la portée de tout un sous-réseau dans clients.conf simplifie l'ajout de points d'accès. Définir require_message_authenticator = yes atténue les attaques de falsification BlastRADIUS (CVE-2024-3596).

Un service informatique migre 2 000 ordinateurs portables d'entreprise Windows 11 d'Active Directory vers Microsoft Entra ID et Intune. Comment l'infrastructure RADIUS doit-elle être mise à jour pour prendre en charge l'authentification WiFi sans mot de passe sans conserver de contrôleurs de domaine sur site ?

  1. Déployez Cloud RADIUS avec l'intégration native de Microsoft Entra ID. 2. Configurez les profils de certificats SCEP ou PKCS de Microsoft Intune pour délivrer automatiquement des certificats clients aux ordinateurs portables gérés. 3. Configurez le contrôleur sans fil pour diriger l'authentification 802.1X vers le serveur Cloud RADIUS via RadSec (port TLS 2083). 4. Imposez EAP-TLS comme méthode d'authentification principale dans le profil de configuration WiFi Intune.
Commentaire de l'examinateur : Comme Microsoft Entra ID n'expose pas de points de terminaison natifs NTLM ou Kerberos pour l'ancienne méthode PEAP-MSCHAPv2, l'EAP-TLS basé sur les certificats combiné à Cloud RADIUS est la voie de migration d'entreprise recommandée.

Questions d'entraînement

Q1. Lors d'un déploiement sans fil 802.1X, les appareils clients se connectent et s'authentifient avec succès, mais ils reçoivent une adresse IP sur le VLAN natif par défaut au lieu du VLAN d'entreprise attribué. Quels attributs RADIUS le serveur doit-il renvoyer ?

Conseil : Consultez les attributs de tunnel RFC 2868 et RFC 3580.

Voir la réponse type

Le serveur RADIUS doit renvoyer trois attributs spécifiques dans la réponse Access-Accept : 1. Tunnel-Type = 13 (VLAN), 2. Tunnel-Medium-Type = 6 (802), 3. Tunnel-Private-Group-ID = [ID_ou_nom_du_VLAN]. Le port du commutateur du point d'accès doit également être configuré en tant que port trunk acheminant ce VLAN.

Q2. Quel est le risque de sécurité lié au déploiement de PEAP-MSCHAPv2 sur des réseaux BYOD sans imposer le certificat CA racine du serveur RADIUS sur les appareils clients ?

Conseil : Pensez aux attaques de type point d'accès malveillant (rogue access point) et jumeau maléfique (evil twin).

Voir la réponse type

Si les appareils clients ne valident pas le certificat du serveur RADIUS, un attaquant peut déployer un point d'accès malveillant diffusant le même SSID. Lorsque le client s'y connecte, le serveur malveillant capture la négociation de défi-réponse MS-CHAPv2, permettant ainsi à l'attaquant de casser le mot de passe hors ligne avec des outils comme asleap.

Q3. Quels ports de pare-feu doivent être ouverts entre un point d'accès sans fil local et un serveur Cloud RADIUS lors de l'utilisation de RadSec par rapport au standard RADIUS ?

Conseil : Comparez les ports UDP historiques avec le protocole RADIUS moderne encapsulé dans TLS.

Voir la réponse type

Le standard RADIUS nécessite l'ouverture du port UDP sortant 1812 (Authentification) et du port UDP sortant 1813 (Comptabilité). RadSec nécessite le port TCP sortant 2083 avec chiffrement TLS, offrant une validation mutuelle des certificats et éliminant la transmission UDP en texte clair sur le réseau internet public.

Continuer la lecture de cette série

Dépannage 802.1X sur iOS et macOS : une checklist de déploiement pour Intune, Jamf et Microsoft Entra ID

Utilisez cette checklist pour diagnostiquer pourquoi les iPhones, iPads et Macs échouent à se connecter en 802.1X sur Intune ou Jamf Pro. Chaque échec correspond à l'une des quatre causes suivantes : confiance du serveur, certificat d'identité, mode macOS ou ciblage de groupe Microsoft Entra ID. Vous confirmerez la cause à partir des journaux eapolclient et RADIUS, appliquerez le correctif et planifierez les futures rotations de certificats.

Lire le guide →

Validation du serveur de profil WiFi Intune : noms de serveurs de certificats et liste de contrôle de l'autorité de certification racine pour Microsoft Entra ID

Vous serez en mesure de configurer la partie validation de serveur d'un profil WiFi Intune afin que les protocoles EAP-TLS et PEAP se connectent sur Windows, Apple et Android. Vous ferez correspondre les noms de serveurs de certificats au certificat RADIUS, déployerez la bonne autorité de certification racine, alignerez les attributions de groupes Microsoft Entra ID et planifierez les renouvellements de certificats avant qu'ils n'interrompent silencieusement les connexions.

Lire le guide →

Dépannage Android 802.1X et EAP-TLS : une liste de contrôle de déploiement pour Intune et Microsoft Entra ID

Vous serez en mesure de déterminer précisément pourquoi les téléphones Android gérés échouent à l'authentification EAP-TLS sur votre SSID personnel et de corriger ce problème dans Intune. Associez chaque symptôme aux quatre causes habituelles - autorité de certification (CA) ou domaine manquant, certificat client dans le mauvais profil, valeur de nom de serveur RADIUS incorrecte, ou racine de confiance non distribuée. Appliquez ensuite une liste de contrôle de déploiement qui évite les pannes répétées.

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.