MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Restreindre l’accès Wi‑Fi par groupe Active Directory avec NPS sur Windows Server 2022 (WPA2‑Enterprise, 802.1X, VLAN)

Restreindre l’accès Wi‑Fi par groupe Active Directory avec NPS sur Windows Server 2022 (WPA2‑Enterprise, 802.1X, VLAN)

Windows Server

Avec Windows Server 2022 et NPS (RADIUS), vous pouvez autoriser chaque groupe Active Directory à n’accéder qu’à son SSID WPA2‑Enterprise. Ce guide pas à pas couvre la configuration, EAP‑TLS, l’assignation dynamique de VLAN, les bonnes pratiques et le dépannage.

Sommaire

Vue d’ensemble de la question

Un administrateur exploite Windows Server 2022 comme serveur RADIUS (rôle Network Policy Server, NPS) pour deux SSID WPA2‑Enterprise : « Alpha » et « Beeta ». L’objectif : contraindre les comptes membres du groupe AD Alpha à se connecter uniquement au SSID Alpha, et symétriquement les comptes du groupe Beeta au SSID Beeta. La séparation logique peut être renforcée par une affectation VLAN dynamique côté RADIUS.

Réponse & solution

Créer une stratégie d’accès réseau (Network Policy) par groupe

Le cœur de la solution repose sur deux Network Policies distinctes dans NPS, filtrées par groupe AD et, idéalement, par SSID.

  1. Préparer Active Directory
    • Créer deux groupes de sécurité globaux (par ex. WiFi-Alpha et WiFi-Beeta).
    • Ajouter les utilisateurs concernés à leur groupe respectif.
    # PowerShell (exécuté avec les RSAT AD) New-ADGroup -Name "WiFi-Alpha" -GroupScope Global -GroupCategory Security New-ADGroup -Name "WiFi-Beeta" -GroupScope Global -GroupCategory Security # Exemple d’ajout d’un utilisateur Add-ADGroupMember -Identity "WiFi-Alpha" -Members jdupont Add-ADGroupMember -Identity "WiFi-Beeta" -Members mbernard
  2. Déclarer les points d’accès/contrôleurs comme clients RADIUS
    • Ouvrir NPS → Clients et serveurs RADIUS → Clients RADIUS → Nouveau.
    • Renseigner Nom convivial, Adresse IP (ou plage) et Secret partagé identique à celui configuré sur le contrôleur Wi‑Fi.
    • Répéter pour tous les contrôleurs/AP (ou utiliser des plages d’adresses).
  3. Créer la stratégie « Alpha »
    • Aller dans NPS → Stratégies → Stratégies réseau → Nouvelle.
    • Nom : WiFi-Alpha-Users. Type de réseau : Non spécifié.
    • Conditions :
      • Groupes Windows = WiFi-Alpha.
      • (Recommandé) Type de port NAS = Wireless – IEEE 802.11.
      • (Fortement recommandé) Called‑Station‑ID → opérateur se termine par → valeur :Alpha (voir la section SSID ci‑dessous).
    • Contraintes :
      • Authentification : même type EAP que sur le WLAN (PEAP ou, mieux, EAP‑TLS).
      • Si PEAP, activer Valider le certificat du serveur côté clients et choisir l’autorité de certification interne de confiance.
    • Paramètres :
      • Accès accordé.
      • (Option VLAN — voir plus bas) Renseigner Tunnel‑Type, Tunnel‑Medium‑Type, Tunnel‑Private‑Group‑ID.
  4. Dupliquer pour « Beeta »
    • Créer WiFi-Beeta-Users avec Groupes Windows = WiFi-Beeta et Called‑Station‑ID se terminant par :Beeta.
  5. Ordre d’évaluation
    • Mettre les deux stratégies spécifiques (Alpha, Beeta) au‑dessus d’éventuelles stratégies génériques.
    • En cas de chevauchement, la première stratégie dont les conditions correspondent s’applique.

Exemple de matrice de stratégies

StratégieConditionsActionAttributs RADIUS
WiFi-Alpha-UsersGroupes Windows = WiFi-Alpha;
NAS‑Port‑Type = Wireless 802.11;
Called‑Station‑ID se termine par :Alpha		Accès accordéOptionnel : Tunnel‑Type=VLAN; Tunnel‑Medium‑Type=802; Tunnel‑Private‑Group‑ID=20
WiFi-Beeta-UsersGroupes Windows = WiFi-Beeta;
NAS‑Port‑Type = Wireless 802.11;
Called‑Station‑ID se termine par :Beeta		Accès accordéOptionnel : Tunnel‑Type=VLAN; Tunnel‑Medium‑Type=802; Tunnel‑Private‑Group‑ID=30
WiFi-Deny‑Others (facultatif)NAS‑Port‑Type = Wireless 802.11Accès refusé(Aucun)

Filtrer directement sur le SSID (option recommandé)

Selon les contrôleurs Wi‑Fi, l’attribut RADIUS Called‑Station‑ID contient la MAC du BSSID suivie de : puis le SSID. Exemples fréquents :

  • aa-bb-cc-dd-ee-ff:Alpha (format MAC avec tirets)
  • aabb.ccdd.eeff:Alpha (format MAC à la Cisco)

Dans NPS, ajoutez une Condition sur Called‑Station‑ID et utilisez l’opérateur se termine par « :Alpha » (respectivement « :Beeta »). Ainsi, même si un utilisateur est déplacé de groupe par erreur, il ne pourra pas s’authentifier sur le SSID non autorisé.

Alternatives (selon matériel) : certains équipements envoient aussi un Service‑Type ou un attribut VSA indiquant le SSID/ESSID. S’il est disponible, vous pouvez l’ajouter comme condition supplémentaire.

Connexions simultanées : séparer les VLAN

Pour cloisonner le trafic, attribuez dynamiquement un VLAN par groupe via RADIUS. NPS expose les attributs standard suivants :

  • Tunnel‑Type = VLAN (valeur RADIUS standard)
  • Tunnel‑Medium‑Type = 802
  • Tunnel‑Private‑Group‑ID = l’ID VLAN (ex. « 20 » ou « 30 »)

Configurez ces attributs dans Stratégies réseau → votre stratégie → Paramètres → Attributs RADIUS → Standard. La plupart des contrôleurs (Cisco, HPE/Aruba, Ruckus, Extreme, Ubiquiti, etc.) acceptent ces valeurs et placeront automatiquement l’utilisateur dans le VLAN indiqué.

Exemple de cartographie VLAN

Groupe ADSSIDVLANUtilisation
WiFi-AlphaAlpha20Postes & utilisateurs Alpha
WiFi-BeetaBeeta30Postes & utilisateurs Beeta

Bonnes pratiques VLAN :

  • Créez des ACL inter‑VLAN strictes (pare‑feu/routeur) : autorisez uniquement les flux nécessaires (DNS/DHCP/NTP, ressources internes, proxy) et interdisez le reste.
  • Activez l’isolation client (AP) pour les SSID où la communication latérale n’est pas requise.
  • Si des appareils Alpha et Beeta doivent accéder à des serveurs communs, préférez un transit contrôlé via un pare‑feu L3 plutôt que des VLAN partagés.

Bonnes pratiques de sécurité

  • Privilégier EAP‑TLS : authentification par certificats, évite les faiblesses de PEAP‑MSCHAPv2. Déployez une AC interne (AD CS) et des modèles de certificats Ordinateur/Utilisateur avec l’auto‑inscription par GPO.
  • Configurer l’auto‑inscription : GPO → Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies de clé publique → Services de certificats – Auto‑inscription : Activer, cocher Inscrire les certificats requis et Mettre à jour si le certificat existe.
  • NPS et certificat serveur : le certificat du NPS doit inclure l’usage Server Authentication et un nom (CN/SAN) conforme. Les clients doivent valider le certificat du serveur RADIUS.
  • Chiffrement : désactiver TLS 1.0/1.1, exiger TLS 1.2 ou supérieur. Nettoyer les suites RSA faibles.
  • Limiter les méthodes EAP : ne conserver que celles requises (EAP‑TLS ou PEAP). Désactiver EAP obsolètes.
  • Rôles/segmentation : chaque SSID ne doit publier que ce qui est nécessaire (bande passante, isolation, QoS). Évitez la diffusion de SSID superflus.
  • Supervision : surveiller les échecs/acceptations, taux de réauthentification, temps de réponse RADIUS. Détecter les anomalies d’attributs (SSID/VLAN).

Validation et dépannage

Procédure de validation rapide :

  1. Tester un compte membre de WiFi-Alpha :
    • Association au SSID Alpha : doit réussir (RADIUS Access‑Accept, code 2).
    • Association au SSID Beeta : doit échouer (RADIUS Access‑Reject, code 3).
  2. Répéter avec un compte membre de WiFi-Beeta (symétrique).

Outils et journaux utiles :

  • Observateur d’événements → Rôles de serveur → Network Policy and Access Services :
    • 6272 : accès accordé (voir la stratégie appliquée).
    • 6273 : accès refusé (raison détaillée : groupe, méthode EAP, SSID, etc.).
  • Comptabilité NPS : activer le Journal de comptes (texte ou SQL) depuis les propriétés NPS → Comptabilité. Les fichiers texte par défaut se trouvent dans %SystemRoot%\System32\LogFiles.
  • Traces RAS/NPS : netsh ras set tracing * enabled # ... reproduire le problème ... netsh ras set tracing * disabled Les traces sont générées dans %windir%\tracing.
  • Export/import de configuration : # Sauvegarde de la configuration NPS netsh nps export filename="C:\Backup\nps-config.xml" exportPSK=YES # Restauration (sur serveur de test) netsh nps import filename="C:\Backup\nps-config.xml"

Check‑list de vérification

PointAttenduComment vérifier
Client RADIUSAdresse IP/secret correctsPing/horodatage cohérent, journal NPS client inconnu absent
Groupes ADUtilisateurs dans le bon groupeADUC/PowerShell Get-ADUser (attribut memberOf)
Conditions NPSGroupes + NAS‑Port‑Type + Called‑Station‑IDÉvénement 6272 : liste des conditions évaluées
Méthode EAPIdentique côté WLAN et NPSCapture côté contrôleur : Access‑Challenge/Accept attendus
VLAN dynamiqueAttributs Tunnel envoyésTrame RADIUS/contrôleur : VLAN=20/30 selon groupe

Informations complémentaires utiles

  • Centraliser les règles : un NPS unique peut servir plusieurs contrôleurs Wi‑Fi/switches. Mettez à jour la liste des clients RADIUS et segmentez par Connection Request Policies si nécessaire.
  • Connection Request Policies (CRP) : utiles pour dispatcher certaines requêtes vers un NPS secondaire (invités/IoT/EDU) ou pour appliquer des règles de charge.
  • Documentation et nommage : adoptez des libellés explicites (ex. WiFi-Alpha-Users, WiFi-Beeta-Users) et mentionnez SSID/VLAN dans la description pour faciliter la maintenance.
  • Disponibilité : déclarez deux serveurs NPS sur le contrôleur, avec time‑out/poids adéquats. Synchronisez leurs secrets et exportez la configuration.
  • Pare‑feu : autorisez UDP 1812/1813 (ou 1645/1646 selon réglage) entre contrôleur(s) et NPS.
  • Péremption d’appartenance groupe : un changement de groupe AD sera pris en compte à la prochaine (ré)authentification 802.1X. Vous pouvez forcer un cycle avec l’attribut Session‑Timeout (par ex. 3600 s).
  • Postes joints au domaine : pour l’expérience la plus fluide, configurez l’authentification machine (certificat ordinateur) et/ou utilisateur selon le scénario, avec profils Wi‑Fi distribués par GPO/MDM.

Mise en œuvre détaillée pas à pas

Paramétrer les clients RADIUS (contrôleurs/AP)

  1. Sur le contrôleur Wi‑Fi, activer WPA2‑Enterprise (802.1X) pour Alpha et Beeta, en pointant vers le NPS.
  2. Définir le secret partagé et, si possible, verrouiller la source (IP du contrôleur) côté NPS.
  3. Activer l’envoi de Called‑Station‑ID et s’assurer que le SSID est inclus (voir documentation du constructeur).

Créer les Network Policies dans NPS

  1. Stratégie WiFi‑Alpha‑Users :
    • Conditions : Groupes Windows → WiFi-Alpha; NAS‑Port‑Type → Wireless 802.11; Called‑Station‑ID → se termine par :Alpha.
    • Contraintes : EAP‑TLS (ou PEAP si transition). Si PEAP, forcer MSCHAPv2 et décocher PAP/CHAP.
    • Paramètres : Accès accordé; Attributs VLAN (si utilisés).
  2. Stratégie WiFi‑Beeta‑Users : même logique avec WiFi-Beeta et :Beeta.
  3. Stratégie de refus générique (optionnelle) : NAS‑Port‑Type = Wireless 802.11 → Accès refusé (placée sous les deux stratégies spécifiques).

Déployer les certificats pour EAP‑TLS (recommandé)

  1. Installer le rôle Services de certificats Active Directory et créer des modèles « Ordinateur »/« Utilisateur » dédiés au Wi‑Fi (EKU Client Authentication).
  2. Configurer l’auto‑inscription via GPO (cf. plus haut) pour ordinateurs et/ou utilisateurs ciblés.
  3. Attribuer au NPS un certificat serveur avec EKU Server Authentication. Vérifier la confiance chaîne CRL/AIA sur les postes.
  4. Dans le profil WLAN des postes, cocher Vérifier le certificat du serveur et sélectionner votre AC.

Profils Wi‑Fi par GPO/MDM (Windows)

Pour éviter les erreurs de saisie, poussez deux profils WLAN :

  • Profil Alpha : SSID Alpha, méthode EAP alignée (EAP‑TLS ou PEAP), option « Se connecter automatiquement » activée pour les membres du groupe Alpha.
  • Profil Beeta : SSID Beeta, idem pour les membres du groupe Beeta.

Le déploiement par ciblage de sécurité (GPO) ou affectation dynamique (MDM) garantit que chaque poste voit le SSID qui le concerne.

Scénarios et cas particuliers

Invités et terminaux non gérés (IoT, imprimantes)

  • Créer un SSID « Invités » isolé, avec portail captif, sans accès au LAN, ou un SSID « IoT » utilisant MAB (MAC Authentication Bypass) sur un NPS distinct.
  • Utiliser des Connection Request Policies pour aiguiller ces flux vers un NPS secondaire et éviter d’encombrer les stratégies principales.

Compatibilité et variations d’attributs

ÉlémentNom/valeur côté RADIUSRemarque
SSID cibléCalled‑Station‑ID (se termine par :SSID)Selon constructeur, format MAC peut varier (tirets, points, majuscules/minuscules)
Type de portNAS‑Port‑Type = Wireless 802.11Filtre les authentifications filaires/PPP hors scope
VLAN dynamiqueTunnel‑Type=VLAN; Tunnel‑Medium‑Type=802; Tunnel‑Private‑Group‑ID=IDLa plupart des contrôleurs appliquent le VLAN renvoyé par RADIUS
RésultatAccess‑Accept (code 2) / Access‑Reject (code 3)Visible dans les logs RADIUS/contrôleur

Erreurs fréquentes et corrections

  • Le mauvais SSID accepte l’utilisateur : la condition Called‑Station‑ID manque ou ne matche pas (casse/format). Utilisez « se termine par :SSID » plutôt que égale.
  • Refus malgré appartenance groupe : l’utilisateur n’a pas encore réauthentifié (802.1X). Forcer une reconnexion ou définir Session‑Timeout côté NPS.
  • PEAP échoue : le client ne fait pas confiance au certificat du NPS. Installer la chaîne AC, cocher « Valider le certificat du serveur » et vérifier le nom du serveur.
  • VLAN ignoré : vérifier que le WLAN/SSID est configuré pour accepter le VLAN dynamique et que le VLAN existe sur le trunk vers les AP.
  • Latence d’authentification : MTU/fragmentation EAP‑TLS, CRL inaccessibles, surcharge NPS. Surveiller la résolution CRL, les time‑outs RADIUS et la charge CPU.

Exemples concrets de configuration d’attributs

# Attributs "Standard" à ajouter dans la stratégie Alpha (onglet Paramètres)
Tunnel-Type                  = VLAN
Tunnel-Medium-Type           = 802
Tunnel-Private-Group-ID      = 20
Session-Timeout              = 3600  # force la réauthentification toutes les 60 min (optionnel)

# Stratégie Beeta

Tunnel-Type                  = VLAN
Tunnel-Medium-Type           = 802
Tunnel-Private-Group-ID      = 30

Script d’aide (exemple) : création des groupes, ajout utilisateur et vérification

# Exécuter dans une console PowerShell avec les RSAT et droits AD
# 1) Création des groupes si non existants
if (-not (Get-ADGroup -Filter "Name -eq 'WiFi-Alpha'" -ErrorAction SilentlyContinue)) {
  New-ADGroup -Name "WiFi-Alpha" -GroupScope Global -GroupCategory Security | Out-Null
}
if (-not (Get-ADGroup -Filter "Name -eq 'WiFi-Beeta'" -ErrorAction SilentlyContinue)) {
  New-ADGroup -Name "WiFi-Beeta" -GroupScope Global -GroupCategory Security | Out-Null
}

# 2) Ajout d’un utilisateur d’exemple

$user = "DOMAINE\jdupont"
Add-ADGroupMember -Identity "WiFi-Alpha" -Members $user

# 3) Vérification de l’appartenance

Get-ADUser jdupont -Properties memberOf | Select-Object -ExpandProperty memberOf

Procédure de test bout‑en‑bout

  1. Sur un poste membre du domaine, connecter au SSID Alpha avec un compte du groupe WiFi-Alpha : valider l’obtention d’une adresse IP dans le VLAN « Alpha » (ex. 20).
  2. Sur le même poste, tenter le SSID Beeta : l’authentification doit être rejetée (Access‑Reject). Vérifier l’événement 6273 côté NPS.
  3. Inverser avec un compte WiFi-Beeta et répéter.
  4. Contrôler la compilation des journaux (NPS et contrôleur) : présence de Called‑Station‑ID, groupe AD détecté, attributs VLAN renvoyés.

FAQ rapide

Q : Puis‑je mélanger authentification machine et utilisateur ?
R : Oui. Créez des stratégies séparées (condition Type d’identité ou Type de certificat) et, si besoin, attribuez des VLAN différents pour les ordinateurs et pour les utilisateurs.

Q : Et si un utilisateur doit accéder temporairement à l’autre SSID ?
R : Créez un groupe AD « WiFi-Exception », une stratégie dédiée (conditions claires et temporisées) et donnez‑lui un ordre supérieur. Retirez l’utilisateur une fois l’intervention terminée.

Q : Comment m’assurer que les changements de groupe sont pris en compte vite ?
R : Réduisez la durée des sessions avec Session‑Timeout (ex. 30–60 min) et/ou forcez la réauthentification côté contrôleur (paramètre reauthentication du WLAN).

Récapitulatif

En définissant une Network Policy NPS par groupe AD et en ajoutant une condition sur le SSID via Called‑Station‑ID, vous limitez efficacement chaque utilisateur à son ESSID. L’application d’un VLAN dynamique renforce l’étanchéité entre environnements. En optant pour EAP‑TLS et en instrumentant correctement la journalisation, vous obtenez une architecture Wi‑Fi 802.1X robuste, auditée et maintenable.

Points clés à emporter

  • Deux stratégies NPS, chacune filtrée par Groupe Windows et Called‑Station‑ID.
  • Même méthode EAP de bout en bout (préférence EAP‑TLS) et validation stricte des certificats.
  • VLAN dynamiques (Tunnel‑Type/Medium/Private‑Group‑ID) pour séparer Alpha et Beeta.
  • Logs NPS (événements 6272/6273) et traces RAS pour diagnostiquer rapidement.
  • Nommage clair, documentation, et CRP si scénarios avancés (invités, IoT, redirection).

En appliquant ces étapes, chaque utilisateur Active Directory est restreint à son SSID et, si souhaité, à son VLAN, garantissant une séparation stricte entre les réseaux Alpha et Beeta et une posture de sécurité renforcée.

Windows Server
Active Directory 802.1X Windows Server NPS EAP‑TLS VLAN
Sommaire