On va être honnête deux secondes. Le Wi‑Fi « partagé » avec une clé WPA2 qui traîne depuis 2019, c’est encore ultra courant. Et ça marche, oui. Jusqu’au jour où un stagiaire la colle sur un post it, où un prestataire repart avec, où un ancien salarié la connaît toujours, où quelqu’un capture un handshake, bref. Tout le monde finit par avoir la clé, et tu ne sais plus vraiment qui est « autorisé ».
802.1X, c’est justement l’idée inverse. On n’autorise pas un appareil parce qu’il connaît un secret commun. On l’autorise parce qu’il s’authentifie, lui, avec une identité. Et derrière on peut mettre des règles. Des VLAN, des ACL, une posture, un accès invité, une expiration… et surtout la révocation propre.
Dans ce lab, on va dérouler 802.1X pour le Wi‑Fi en mode entreprise, étape par étape. Version BTS SIO SISR, donc concret, et avec des choix réalistes.
Objectif : passer d’un Wi‑Fi « PSK » à un Wi‑Fi « WPA2/WPA3‑Enterprise » avec authentification 802.1X via RADIUS (NPS ou FreeRADIUS), certificats si besoin, et segmentation.
1. ce que fait vraiment 802.1X (sans roman)
Dans 802.1X, il y a trois rôles :
- supplicant : le client, ton PC, ton smartphone, etc.
- authenticator : l’équipement qui contrôle l’accès, ici le point d’accès ou le contrôleur Wi‑Fi.
- authentication server : le serveur d’authentification, typiquement un serveur RADIUS.
Et le protocole qui circule entre client et point d’accès, c’est EAP (Extensible Authentication Protocol). Entre point d’accès et serveur, c’est RADIUS.
Le point d’accès ne décide pas « au feeling ». Il relaie, et applique la décision du RADIUS : autorisé, refusé, ou autorisé avec attributs (VLAN, QoS, etc.).
2. les prérequis avant de toucher à la prod
Avant de cliquer partout, tu poses le cadre. Sinon tu vas faire un 802.1X qui marche « sur ton PC » et qui casse sur tout le reste. Classique.
prérequis réseau et infra
- Un RADIUS disponible et joignable depuis les AP : UDP 1812 (auth), 1813 (accounting).
- Une horloge à l’heure partout : NTP sur le serveur, les AP, les postes. Les certificats aiment la ponctualité.
- Une PKI si tu pars sur EAP‑TLS (recommandé pour le top niveau) ou au moins un certificat serveur propre pour PEAP.
- Des VLAN prêts : au minimum « corporate » et « invités ». Idéalement « IoT » aussi.
- Une stratégie de nommage et de groupes AD (si tu es sur Windows) ou des utilisateurs/clients (si tu es sur FreeRADIUS).
prérequis côté Wi‑Fi
- AP et contrôleur compatibles WPA2‑Enterprise et idéalement WPA3‑Enterprise.
- Possibilité d’assigner un VLAN via RADIUS (attributs). Pas obligatoire, mais franchement utile.
3. choisir la méthode EAP (et ne pas regretter après)
Tu vas tomber sur plusieurs méthodes. Les trois qu’on voit le plus :
option A : PEAP (EAP‑MSCHAPv2)
- Très courant en entreprise.
- Authentification par identifiants AD.
- Requiert un certificat côté serveur RADIUS.
- Moins solide qu’EAP‑TLS, mais largement utilisé.
option B : EAP‑TLS
- Authentification par certificats client.
- C’est le Graal en termes de sécurité.
- Plus long à déployer parce qu’il faut gérer les certificats sur les postes.
option C : TEAP / EAP‑TTLS (selon environnements)
- Intéressant, mais pas toujours supporté partout.
Dans un lab BTS SIO SISR, je conseille :
- PEAP pour comprendre et déployer rapidement.
- Puis EAP‑TLS en montée de niveau, pour la vraie approche « zéro mot de passe sur le Wi‑Fi ».
4. architecture de lab (simple et réaliste)
Exemple d’architecture :
- 1 domaine AD :
LAB.LOCAL - 1 serveur Windows Server avec rôle NPS (RADIUS)
- 1 autorité de certification AD CS (si PEAP avec cert serveur, ou EAP‑TLS)
- 1 contrôleur Wi‑Fi ou AP autonome compatible WPA2‑Enterprise
- VLAN 10 : corporate
- VLAN 20 : invités
- VLAN 30 : IoT
5. étape 1 : préparer le serveur RADIUS (NPS sous Windows)
installer NPS
Sur Windows Server :
- Ajouter le rôle Network Policy and Access Services
- Installer Network Policy Server
- Ouvrir la console NPS
enregistrer NPS dans Active Directory
Dans NPS :
- Clic droit sur NPS (Local) → « Enregistrer le serveur dans Active Directory »
Sans ça, NPS ne pourra pas lire correctement les infos des utilisateurs/groupes.
ajouter les AP comme clients RADIUS
Dans RADIUS Clients and Servers → RADIUS Clients → Nouveau :
- Nom :
AP-ETAGE1(par exemple) - IP : IP de l’AP ou du contrôleur
- Secret partagé : long, aléatoire, stocké proprement
Petit rappel qui évite des heures : le secret RADIUS, ce n’est pas le mot de passe Wi‑Fi. C’est juste la clé de confiance entre AP et NPS.
6. étape 2 : certificats (la partie que tout le monde bâcle)
si tu utilises PEAP
Il te faut un certificat serveur sur NPS, avec :
- EKU « Server Authentication »
- Nom cohérent : idéalement le FQDN du serveur RADIUS, ex :
nps01.lab.local - Chaîne de confiance installée sur les clients (autorité racine)
En environnement AD, le plus simple :
- Installer AD CS
- Déployer le certificat serveur via auto enrollment
- Vérifier dans
mmc→ certificats (ordinateur local) → personnel
si tu utilises EAP‑TLS
En plus, il te faut des certificats client sur les postes, avec :
- EKU « Client Authentication »
- Déploiement via GPO (auto enrollment) ou MDM selon ton contexte
Oui, ça demande une PKI propre. Mais après, c’est du beurre.
7. étape 3 : créer les stratégies NPS (Network policies)
Là on va dire à NPS « qui a le droit » et « comment ».
créer un groupe AD pour le Wi‑Fi
Dans AD, créer un groupe WiFi-Corporate-Users et y ajouter les utilisateurs autorisés. Tu peux également créer des groupes supplémentaires comme WiFi-Admins ou WiFi-Students pour gérer les VLAN dynamiques par profil.
configurer une policy 802.1X (PEAP)
Dans NPS → Policies → Network Policies → New, créer une policy nommée WiFi corporate - PEAP.
Conditions
- NAS Port Type : Wireless - IEEE 802.11
- Windows Groups :
WiFi-Corporate-Users
Constraints
- Auth methods : cocher Microsoft: Protected EAP (PEAP)
- Dans PEAP : choisir le certificat serveur
- Autoriser EAP‑MSCHAPv2 si tu restes sur identifiants
Settings
- RADIUS Attributes → éventuellement VLAN dynamique
VLAN dynamique via RADIUS (optionnel mais puissant)
Sur NPS, tu peux pousser les attributs suivants pour assigner un VLAN dynamiquement. L'interface varie selon les constructeurs Wi‑Fi, mais le principe reste le même.
- Tunnel-Type : VLAN
- Tunnel-Medium-Type : 802
- Tunnel-Pvt-Group-ID :
10(ou20, etc.)
8. étape 4 : configurer le SSID en WPA2-Enterprise / WPA3-Enterprise
Sur ton contrôleur/AP, configurer les paramètres suivants :
- Sécurité : WPA2‑Enterprise (AES) ou WPA3‑Enterprise si dispo
- Serveur RADIUS : IP de NPS
- Secret partagé : identique à celui déclaré dans NPS
- Port : 1812
- Accounting (optionnel) : 1813
Astuce terrain : active les logs RADIUS côté contrôleur, au moins au début. Parce que « Access-Reject » sans détail, c'est la misère.
9. étape 5 : configurer les clients (Windows surtout, et éviter les popups)
configuration manuelle (pour test)
Sur Windows :
- Se connecter au SSID
- Méthode : PEAP
- Valider le certificat serveur (ne pas cliquer « se connecter quand même » en production…)
Si le poste ne fait pas confiance à l’autorité, tu vas avoir des alertes. C’est normal. Et c’est précisément ce qu’on veut éviter via déploiement.
configuration via GPO (le vrai mode entreprise)
Dans une GPO :
- Computer Configuration → Policies → Windows Settings → Security Settings → Wireless Network (IEEE 802.11) Policies
- Créer une policy Wi‑Fi
- SSID, WPA2‑Enterprise
- PEAP, valider le serveur, sélectionner l’autorité racine
- Option « se connecter automatiquement »
- Option « utiliser les identifiants Windows » si tu veux du SSO
Avec ça, tu élimines 80 % des erreurs utilisateur.
10. tests et dépannage (les erreurs que tu vas voir, c’est sûr)
vérifier les logs NPS
Sur le serveur :
- Observateur d’événements → Custom Views → Server Roles → Network Policy and Access Services
Tu verras des événements du style :
- Reason Code 16 : identifiants incorrects
- Reason Code 66/67 : méthode EAP non autorisée
- Certificat non valide, chaîne non approuvée, etc.
erreurs fréquentes
- Secret RADIUS différent entre AP et NPS.
- Horloge décalée, certificats vus comme expirés ou pas encore valides.
- Certificat serveur sans bon EKU.
- Clients qui ne valident pas le certificat, et donc vulnérables au rogue AP.
- Groupe AD pas pris en compte (réplication, ou condition mal configurée).
- Mauvais NAS Port Type.
Oui, c’est souvent un détail. Un truc bête. Et tu le trouves dans les logs.
11. aller plus loin : invités, IoT, et « tout ne parle pas 802.1X »
Le monde réel n’est pas composé que de PC gérés par GPO.
réseau invités
Tu as plusieurs options :
- SSID invité séparé en WPA2‑PSK avec rotation fréquente.
- Portail captif.
- 802.1X avec comptes temporaires (si tu as une solution NAC ou un portail RADIUS).
En BTS SIO, déjà : séparer en VLAN, filtrer, et sortir vers Internet uniquement. C’est une base saine.
IoT (imprimantes, badges, capteurs)
Beaucoup d’objets ne supportent pas 802.1X ou le supportent mal.
Solutions :
- SSID IoT dédié, isolé, filtré.
- MAB (MAC authentication bypass) côté filaire, ou équivalent NAC côté Wi‑Fi selon constructeur.
- Certificats si possible, mais souvent c’est du bricolage.
Le point important : ne mélange pas IoT et corporate « juste parce que c’est pratique ».
12. recommandations de sécurité (celles qui comptent)
- Toujours valider le certificat serveur côté client. Sinon tu t’exposes à des attaques de type evil twin.
- Si possible, viser EAP‑TLS pour les postes gérés.
- Segmenter via VLAN dynamiques ou SSID séparés.
- Activer l’accounting RADIUS si tu veux de la traçabilité.
- Mettre en place une politique de révocation : un utilisateur sort du groupe AD, terminé.
- Surveille : logs NPS, logs contrôleur, et idéalement un SIEM ou au moins une collecte centralisée.
13. mini check-list « ça marche » pour ton lab
- NPS enregistré dans l’AD
- AP ajouté comme client RADIUS avec le bon secret
- Certificat serveur valide sur NPS
- Policy NPS avec NAS Port Type = Wireless
- Groupe AD correct
- SSID en WPA2/WPA3‑Enterprise, RADIUS bien renseigné
- Poste client fait confiance à l’autorité
- Logs NPS confirment Access-Accept
14. un mot pour le blog (et pour tes prochains labs)
Si tu veux, on peut pousser ce lab plus loin sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) avec une version « full pratique » : captures Wireshark EAPOL, configuration FreeRADIUS sous Linux, VLAN dynamiques selon groupes AD, et même un mini scénario d’audit (evil twin, erreurs de validation de certificat, etc.). C’est typiquement le genre de sujet qui fait la différence en oral et en dossier.
conclusion
802.1X, ce n’est pas juste « un paramètre Wi‑Fi en plus ». C’est un vrai changement de modèle. On arrête de partager un secret, on met de l’identité, des règles, et de la révocation propre. Et oui, les certificats font un peu peur au début. Mais une fois que tu as compris le flux supplicant, authenticator, RADIUS, tu as une base solide que tu peux réutiliser partout, Wi‑Fi, filaire, VPN, NAC.
Et si tu ne dois retenir qu’une chose : un 802.1X sans validation de certificat côté client, c’est un château avec une porte en carton.
Questions fréquemment posées
Qu'est-ce que le protocole 802.1X et comment fonctionne-t-il pour sécuriser le Wi-Fi en entreprise ?
Le protocole 802.1X est un standard d'authentification réseau qui sécurise l'accès Wi-Fi en entreprise. Il implique trois rôles : le supplicant (client), l'authenticator (point d'accès Wi-Fi) et le serveur d'authentification (typiquement un serveur RADIUS). Le client s'authentifie via EAP, le point d'accès relaie la demande au serveur RADIUS qui décide d'autoriser ou non l'accès, souvent avec des attributs comme VLAN ou QoS.
Quels sont les prérequis indispensables avant de déployer une authentification 802.1X en environnement professionnel ?
Avant de déployer 802.1X, il faut un serveur RADIUS accessible depuis les points d'accès (ports UDP 1812 et 1813), une synchronisation horaire via NTP sur tous les équipements, une infrastructure PKI avec certificats pour EAP-TLS ou PEAP, des VLAN configurés (corporate, invités, IoT), ainsi qu'une stratégie claire de gestion des utilisateurs et groupes (via AD ou FreeRADIUS). Les points d'accès doivent aussi supporter WPA2-Enterprise voire WPA3-Enterprise.
Quelles sont les différentes méthodes EAP disponibles pour l'authentification 802.1X et laquelle choisir ?
Les méthodes EAP principales sont : PEAP (EAP-MSCHAPv2), très répandue et basée sur identifiants AD avec certificat serveur ; EAP-TLS, la plus sécurisée grâce à l'utilisation de certificats client mais plus complexe à déployer ; TEAP/EAP-TTLS, moins supportée mais intéressante dans certains environnements. Pour un lab BTS SIO SISR, on recommande PEAP pour débuter puis évoluer vers EAP-TLS pour une sécurité maximale.
Comment le serveur RADIUS interagit-il avec le point d'accès dans une infrastructure 802.1X ?
Le point d'accès agit comme un relais entre le client et le serveur RADIUS. Il transmet les messages d'authentification EAP du client au serveur RADIUS via le protocole RADIUS. Le serveur prend la décision finale d'autoriser ou refuser l'accès, pouvant aussi définir des attributs comme VLAN attribué ou qualité de service. Le point d'accès applique ensuite cette décision sans prise d'initiative propre.
Quels avantages présente l'utilisation de VLAN dans une architecture Wi-Fi sécurisée avec 802.1X ?
L'utilisation de VLAN permet de segmenter le réseau selon les profils utilisateurs : par exemple, un VLAN 'corporate' pour les salariés, un VLAN 'invités' pour les visiteurs, et un VLAN 'IoT' pour les objets connectés. Cela améliore la sécurité en limitant l'accès aux ressources sensibles selon l'identité authentifiée via 802.1X et facilite la gestion des politiques réseau adaptées à chaque groupe.
Pourquoi est-il déconseillé de continuer à utiliser un Wi-Fi partagé avec une clé WPA2 commune en entreprise ?
Un Wi-Fi partagé avec une clé WPA2 commune est vulnérable car cette clé finit toujours par être connue de trop de personnes : stagiaires la collant sur post-it, prestataires repartant avec, anciens employés la conservant... Cela empêche de contrôler précisément qui est autorisé sur le réseau et expose l'entreprise à des risques de sécurité importants. L'authentification individuelle via 802.1X apporte une gestion fine et révoque facilement les accès non autorisés.
0 Commentaires