Un seul schéma pour tout voir : DHCP, 802.1X/EAP via NPS (RADIUS) et 4‑Way Handshake WPA2. Suivez le flux pas à pas, comprenez le rôle du NAS‑ID côté NPS et validez l’ordre exact des messages pour un Wi‑Fi d’entreprise robuste.
Sommaire
Vue d’ensemble de la question
Objectif : représenter, dans un même diagramme, la séquence complète permettant d’attribuer une adresse IP via DHCP, d’authentifier un poste Wi‑Fi via 802.1X/EAP auprès d’un serveur RADIUS Microsoft NPS, puis d’établir la clé WPA2 par le 4‑Way Handshake. L’architecture applique un filtrage de stratégie NPS basé sur le NAS‑ID et l’ordre exact des messages doit être vérifié.
Diagramme de flux d’appel WPA2‑EAP/802.1X avec NPS & DHCP
.lane {stroke:#555; stroke-dasharray:6 6;} .msg {stroke:#000; stroke-width:1.5; fill:none; marker-end:url(#arrow);} .msgdash {stroke:#000; stroke-dasharray:6 4; fill:none; marker-end:url(#arrowThin);} .lbl {font:12px sans-serif; fill:#111;} .box {fill:#f7f7f7; stroke:#999;} .head {font:bold 14px sans-serif;} .note {font:12px sans-serif; fill:#333;}
<!-- Lanes -->
<rect x="60" y="20" width="200" height="34" class="box"/>
<text x="160" y="42" text-anchor="middle" class="head">Client Wi‑Fi (Supplicant)</text>
<line x1="160" y1="60" x2="160" y2="950" class="lane"/>
<rect x="360" y="20" width="200" height="34" class="box"/>
<text x="460" y="42" text-anchor="middle" class="head">AP / Contrôleur (Authenticator)</text>
<line x1="460" y1="60" x2="460" y2="950" class="lane"/>
<rect x="660" y="20" width="200" height="34" class="box"/>
<text x="760" y="42" text-anchor="middle" class="head">Serveur RADIUS NPS</text>
<line x1="760" y1="60" x2="760" y2="950" class="lane"/>
<rect x="960" y="20" width="200" height="34" class="box"/>
<text x="1060" y="42" text-anchor="middle" class="head">Serveur DHCP</text>
<line x1="1060" y1="60" x2="1060" y2="950" class="lane"/>
<!-- Option A DHCP before 802.1X (dashed) -->
<text x="600" y="78" text-anchor="middle" class="lbl">Option (DHCP avant 802.1X si autorisé)</text>
<line x1="160" y1="95" x2="1060" y2="95" class="msgdash"/>
<text x="610" y="90" class="lbl">DHCP Discover (relayé si nécessaire)</text>
<line x1="1060" y1="120" x2="160" y2="120" class="msgdash"/>
<text x="610" y="115" class="lbl">DHCP Offer</text>
<line x1="160" y1="145" x2="1060" y2="145" class="msgdash"/>
<text x="610" y="140" class="lbl">DHCP Request</text>
<line x1="1060" y1="170" x2="160" y2="170" class="msgdash"/>
<text x="600" y="165" class="lbl">DHCP ACK</text>
<!-- 802.1X start -->
<text x="160" y="205" text-anchor="middle" class="lbl">EAPOL‑Start</text>
<line x1="160" y1="210" x2="460" y2="210" class="msg"/>
<text x="310" y="205" class="lbl"></text>
<text x="460" y="245" text-anchor="middle" class="lbl">EAP‑Request/Identity</text>
<line x1="460" y1="250" x2="160" y2="250" class="msg"/>
<text x="160" y="285" text-anchor="middle" class="lbl">EAP‑Response/Identity</text>
<line x1="160" y1="290" x2="460" y2="290" class="msg"/>
<line x1="460" y1="330" x2="760" y2="330" class="msg"/>
<text x="610" y="325" class="lbl">RADIUS Access‑Request (EAP‑Message, NAS‑ID)</text>
<rect x="780" y="300" width="230" height="38" class="box"/>
<text x="895" y="322" text-anchor="middle" class="note">NAS‑ID utilisé par NPS pour choisir la stratégie</text>
<line x1="760" y1="370" x2="460" y2="370" class="msg"/>
<text x="610" y="365" class="lbl">RADIUS Access‑Challenge (EAP‑Request méthode)</text>
<line x1="460" y1="410" x2="160" y2="410" class="msg"/>
<text x="310" y="405" class="lbl">EAP‑Request (ex. EAP‑TLS/PEAP)</text>
<line x1="160" y1="450" x2="460" y2="450" class="msg"/>
<text x="310" y="445" class="lbl">EAP‑Response (client)</text>
<line x1="460" y1="490" x2="760" y2="490" class="msg"/>
<text x="610" y="485" class="lbl">RADIUS Access‑Request (suite échanges EAP)</text>
<!-- EAP negotiation box -->
<rect x="520" y="515" width="480" height="70" class="box"/>
<text x="760" y="538" text-anchor="middle" class="note">Boucle EAP : TLS/PEAP, certificats, ou MS‑CHAPv2 dans tunnel</text>
<text x="760" y="558" text-anchor="middle" class="note">Validation par NPS/AD → génération PMK</text>
<line x1="760" y1="610" x2="460" y2="610" class="msg"/>
<text x="610" y="605" class="lbl">RADIUS Access‑Accept (VLAN/ACL/Filter‑Id)</text>
<line x1="460" y1="650" x2="160" y2="650" class="msg"/>
<text x="310" y="645" class="lbl">EAP‑Success</text>
<!-- 4-way handshake -->
<line x1="460" y1="700" x2="160" y2="700" class="msg"/>
<text x="310" y="695" class="lbl">WPA2 Msg1 : ANonce</text>
<line x1="160" y1="740" x2="460" y2="740" class="msg"/>
<text x="310" y="735" class="lbl">WPA2 Msg2 : SNonce + MIC</text>
<line x1="460" y1="780" x2="160" y2="780" class="msg"/>
<text x="310" y="775" class="lbl">WPA2 Msg3 : GTK + Install + MIC</text>
<line x1="160" y1="820" x2="460" y2="820" class="msg"/>
<text x="310" y="815" class="lbl">WPA2 Msg4 : ACK</text>
<!-- DHCP after auth -->
<text x="600" y="860" text-anchor="middle" class="lbl">Flux principal (recommandé) : DHCP après 802.1X</text>
<line x1="160" y1="885" x2="1060" y2="885" class="msg"/>
<text x="610" y="880" class="lbl">DHCP Discover</text>
<line x1="1060" y1="915" x2="160" y2="915" class="msg"/>
<text x="610" y="910" class="lbl">DHCP Offer</text>
<line x1="160" y1="945" x2="1060" y2="945" class="msg"/>
<text x="610" y="940" class="lbl">DHCP Request</text>Légende : traits pleins = ordre principal (802.1X/EAP puis DHCP) ; traits pointillés = variante (DHCP avant 802.1X si l’AP/la politique le permettent). Le NAS‑ID est injecté par l’AP dans l’Access‑Request et sert au NPS pour sélectionner la stratégie adéquate. Après EAP‑Success, le 4‑Way Handshake installe les clés et le trafic est chiffré (AES‑CCMP recommandé).
Réponse & solution synthétisée
Initialisation du client
- Le supplicant active le Wi‑Fi, balaye, puis s’associe au BSSID portant le SSID cible.
- Avant d’ouvrir le port de données, l’AP maintient un port 802.1X non autorisé tant que l’authentification n’est pas validée.
Découverte DHCP (peut précéder ou suivre 802.1X)
Selon la politique de pré‑authentification de l’AP/du contrôleur :
- Mode strict (recommandé) : DHCP bloqué jusqu’au succès 802.1X → DORA s’exécute après EAP‑Success.
- Mode permissif (invités/MAB) : DHCP autorisé avant 802.1X (flèches en pointillé), avec ACL de pré‑auth limitant le trafic.
Séquence DHCP classique : Discover → Offer → Request → ACK (UDP 67/68). L’AP ou le contrôleur peut agir comme DHCP relay.
Démarrage 802.1X
- Le client envoie EAPOL‑Start (couche 2).
- L’AP répond par EAP‑Request/Identity.
Échange d’identité
- Le client renvoie EAP‑Response/Identity (nom d’utilisateur ou identité anonyme PEAP).
- L’AP encapsule dans RADIUS Access‑Request (UDP 1812) vers NPS en ajoutant ses attributs : NAS‑IP‑Address, NAS‑Port, NAS‑Identifier (NAS‑ID), Called‑Station‑Id, Calling‑Station‑Id, etc.
- Le NAS‑ID est l’attribut sur lequel votre stratégie NPS filtre pour appliquer les bons profils (VLAN/ACL, règles EAP).
Méthode EAP (EAP‑TLS ou PEAP‑MS‑CHAPv2)
- Le NPS renvoie un Access‑Challenge contenant un EAP‑Request propre à la méthode (ex. démarrage TLS), relayé par l’AP au client.
- Le client répond (EAP‑Response) et l’AP relaie en Access‑Request vers NPS. La boucle se répète jusqu’à l’issue (succès/échec).
- Cas EAP‑TLS : échange de certificats, vérification de la chaîne, construction d’un MSK/PMK.
- Cas PEAP‑MS‑CHAPv2 : établissement d’un tunnel TLS, puis challenge/réponse MS‑CHAPv2 à l’intérieur du tunnel. Le NPS valide contre l’AD.
Décision d’accès
- Succès : NPS envoie Access‑Accept avec les attributs d’autorisation (VLAN dynamique, Filter‑Id pour ACL, Session‑Timeout, etc.). L’AP relaie un EAP‑Success au client.
- Échec : Access‑Reject → port 802.1X reste non autorisé, éventuel basculement MAB/Portail invités selon votre politique.
4‑Way Handshake WPA2
- Message 1 (AP → Client) : envoi de l’ANonce.
- Message 2 (Client → AP) : envoi de l’SNonce et d’un MIC, calcul de la PTK de part et d’autre.
- Message 3 (AP → Client) : transport du GTK et indication d’installation des clés.
- Message 4 (Client → AP) : ACK. Les clés unicast et la group‑key sont installées (AES‑CCMP recommandé).
Renouvellement DHCP (facultatif)
Si une ACL de pré‑auth bloquait DHCP, le client peut renégocier son bail (request/renew) après l’autorisation.
Transmission sécurisée
Le trafic de données passe désormais via le port 802.1X authorized, chiffré par TKIP (déconseillé) ou AES‑CCMP (recommandé). Activez les Protected Management Frames (802.11w) si disponible.
Couches, ports et visibilité protocolaire
| Étape | Couche/Protocoles | Ports | Outils de capture |
|---|---|---|---|
| EAPOL | L2 802.1X (EAPOL) | — | Wireshark : filtre eapol |
| RADIUS | L4 UDP vers NPS | 1812 (auth), 1813 (acct) | Wireshark : filtre radius, journaux NPS |
| DHCP | L3 UDP | 67 (srv), 68 (cli) | Wireshark : filtre dhcp || bootp |
| 4‑Way Handshake | 802.11 gestion/chiffrement | — | Capture radio (moniteur), décodage 802.11 |
Ordonnancement DHCP ↔ 802.1X : choix d’architecture
| Mode | Comportement | Avantages | Risques/Quand l’éviter |
|---|---|---|---|
| 802.1X avant DHCP (recommandé) | Bloque IP tant que non authentifié | Surface d’attaque réduite, pas d’IP « fantôme » | Client voit l’IP tardivement, attention au time‑out DHCP |
| DHCP avant 802.1X (option) | Autorise DORA sous ACL pré‑auth | Association plus rapide, utile pour portail/MAB | IP attribuée à un client potentiellement non approuvé |
NAS‑ID dans NPS : sélection de stratégie
Le NAS‑ID (NAS‑Identifier) est défini par l’AP/contrôleur (ex. SSID-Entreprise-Paris ou AP-SITE-A1). Dans NPS, il sert de condition de stratégie :
- Condition : NAS‑Identifier égale
SSID-Entreprise-Paris. - Contraintes : méthode EAP autorisée (EAP‑TLS ou PEAP), demande de validation du certificat serveur côté client.
- Paramètres : VLAN dynamique, Filter‑Id (ACL), Session‑Timeout, Idle‑Timeout, éventuellement Vendor‑Specific.
Veillez à ce que le format du NAS‑ID soit stable et documenté. Un changement de nom côté contrôleur peut invalider l’appartenance à la stratégie NPS.
Détails EAP utiles à la compréhension
- PMK (Pairwise Master Key) : issue de la méthode EAP (MSK). En WPA2‑Enterprise, la PMK ne provient pas d’un PSK.
- PTK (Pairwise Transient Key) : dérivée de la PMK, des adresses MAC (AA, SPA) et des nonces (ANonce, SNonce) via une PRF spécifique.
- GTK : clé de diffusion multicast/broadcast, distribuée au message 3 du 4‑Way Handshake.
- EAP‑TLS : robustesse maximale si votre PKI est opérationnelle (certificats client et serveur).
- PEAP‑MS‑CHAPv2 : plus simple à déployer, mais exige des mots de passe forts et la validation stricte du certificat serveur.
Attribution dynamique de VLAN et ACL via RADIUS
| But | Attributs RADIUS côté NPS | Exemple de valeur | Effet côté AP/Contrôleur |
|---|---|---|---|
| Placer dans un VLAN | Tunnel‑Type=VLAN, Tunnel‑Medium‑Type=802, Tunnel‑Private‑Group‑Id | 10 (VLAN 10) | Le port virtuel du client est basculé dans le VLAN 10 |
| Appliquer une ACL | Filter‑Id ou VSA spécifique constructeur | ACL-ENT-USER | Activation d’une ACL nommée sur le contrôleur |
| Durée de session | Session‑Timeout | 28800 (8 h) | Renouvellement périodique → réauthentification |
DHCP dans un Wi‑Fi 802.1X
- Sur les WLAN d’entreprise, DHCP après 802.1X évite d’attribuer une IP à un client non autorisé.
- En pré‑auth permissive, limitez le trafic avec une ACL de pré‑auth (NTP, DNS, portail captif, CRL/OCSP si EAP‑TLS).
- Sur les contrôleurs, le DHCP proxy/relay et l’Option 82 peuvent renseigner la localisation d’origine.
Dépannage : où regarder et quoi mesurer
- Wireshark : utilisez le filtre
eapol or radius or (bootp or dhcp). Sur PC, capture filaire impossible pour l’onde radio : utilisez une carte en mode moniteur, ou capture côté AP/contrôleur. - NPS (Windows) : journaux texte dans
%SystemRoot%\System32\LogFiles; évènements (par défaut) 6272 succès / 6273 échec dans l’Observateur d’événements. - AP/Contrôleur : trace AAA/radio, tables d’état 802.1X, cause de déconnexion, PMK cache/OKC/11r si roaming.
- Client Windows :
netsh lan show interfaces,netsh wlan show interfaces, statut de la validation du certificat serveur.
Checklist de validation rapide
- Le client voit le SSID et s’associe sans perte de signal.
- EAPOL‑Start puis EAP‑Request/Identity → EAP‑Response/Identity observés.
- Le RADIUS Access‑Request contient bien NAS‑ID au format attendu (cohérent avec la stratégie NPS).
- La méthode EAP négocie correctement (certificats valides si EAP‑TLS).
- Réception d’un Access‑Accept avec les attributs d’autorisation souhaités.
- EAP‑Success, puis 4‑Way Handshake complet (4 messages, pas de retransmissions excessives).
- DHCP DORA complet, IP/gateway/DNS corrects, trafic chiffré OK.
Erreurs courantes et correctifs
- NAS‑ID incohérent : aucune stratégie ne correspond → rejet. Action : normaliser le schéma de nommage (ex.
SSID-<Site>), mettre à jour NPS. - Certificat serveur non approuvé (EAP‑TLS/PEAP) : l’utilisateur refuse le serveur → échec. Action : déployer l’autorité racine intermédiaire dans l’OS, épingler le CN/SAN attendu.
- Fuseaux horaires/DHCP : bail expiré ou serveur injoignable sous pré‑auth stricte. Action : autoriser provisoirement DHCP/DNS en pré‑auth pour tests, puis refermer.
- PMK/clé installée mais pas de trafic : 4‑Way partiel (Msg3/Msg4 en boucle) → désynchro de nonces ou clé. Action : vérifier 802.11w, compatibilité des chipsets, reconfigurer le WLAN.
- VLAN dynamique non appliqué : attributs incomplets. Action : fournir Tunnel‑Type, Tunnel‑Medium‑Type et Tunnel‑Private‑Group‑Id ensemble.
FAQ express
Le DHCP doit‑il toujours venir après 802.1X ?
Non. Beaucoup d’entreprises imposent 802.1X avant toute IP. Cependant, certains environnements (portails invités, MAB, IoT) autorisent DORA en pré‑auth, sous une ACL restrictive.
Le NAS‑ID est‑il obligatoire ?
Pas pour RADIUS en soi, mais il est très utile pour dispatcher vos stratégies NPS par SSID/site/contrôleur sans dupliquer inutilement les règles.
Faut‑il préférer EAP‑TLS à PEAP‑MS‑CHAPv2 ?
Oui, si vous disposez d’une PKI. EAP‑TLS offre une authentification mutuelle et une meilleure résilience aux attaques par dictionnaire ou relais.
Annexe — chronologie détaillée (référence opératoire)
1) Association 802.11 (Open System) → port 802.1X "unauthorized"
2) EAPOL-Start (client)
3) EAP-Request/Identity (AP) → EAP-Response/Identity (client)
4) Access-Request (AP→NPS) [EAP-Message + NAS-ID + Calling/Called-Station-Id]
5) Access-Challenge (NPS→AP) [EAP-Request (méthode)]
6) Boucle EAP (TLS/PEAP) jusqu'à décision :
- Vérif. certificat serveur (côté client)
- Présentation certificat client (EAP-TLS) ou MS-CHAPv2 dans tunnel (PEAP)
- Validation AD/PKI côté NPS, génération MSK/PMK
7) Access-Accept (NPS→AP) [VLAN/ACL/Session-Timeout/PMK-ID...]
8) EAP-Success (AP→client)
9) 4-Way Handshake WPA2 Msg1..Msg4 → PTK/GTK installés
10) Ouverture port 802.1X (Authorized)
11) DHCP DORA (si pas déjà fait)
12) Échanges de données (AES-CCMP), PMF si activé, reco clé périodique (Group Key Update)
Annexe — modèle de stratégie NPS (exemple textuel)
Stratégie réseau NPS : "WLAN-ENT-Paris"
Conditions :
- NAS-Identifier == "SSID-Entreprise-Paris"
- Authentification EAP autorisée : Smart Card ou autre certificat (EAP-TLS)
Contraintes :
- Exiger la validation du certificat serveur
Paramètres :
- Tunnel-Type = VLAN
- Tunnel-Medium-Type = 802
- Tunnel-Private-Group-Id = 20
- Filter-Id = "ACL-ENT-USER"
- Session-Timeout = 28800
Conclusion opérationnelle
En consolidant DHCP, 802.1X/EAP et le 4‑Way Handshake sur un seul diagramme, on obtient une vision exploitable pour l’intégration et le support. La clé de voûte de l’automatisation côté NPS réside dans un NAS‑ID cohérent, un choix EAP adapté (idéalement EAP‑TLS) et des attributs RADIUS bien renseignés (VLAN, ACL, durées). À partir de cette ossature, ajustez simplement le positionnement de DHCP (pré ou post‑auth) selon la politique de sécurité de votre WLAN.
Référence rapide
- Ordre recommandé : 802.1X/EAP → EAP‑Success → 4‑Way → DHCP.
- NAS‑ID : pilote la sélection de stratégie NPS (par SSID/site).
- VLAN/ACL : renvoyés dans l’Access‑Accept (Tunnel‑Private‑Group‑Id, Filter‑Id).
- Dépannage :
eapol || radius || dhcp+ évènements NPS 6272/6273.