Faites cohabiter, sur un même NPS Windows Server 2016, l’authentification Wi‑Fi des comptes AD locaux et celle d’un second serveur RADIUS : compréhension du flux, règles NPS, astuces UniFi, journalisation et tests pour une configuration robuste et facilement maintenable.
Problématique
Votre contrôleur de domaine Windows Server 2016 héberge également Network Policy Server (NPS) et sert d’autorité RADIUS pour un réseau Wi‑Fi UniFi (WPA2/3‑Enterprise). Les comptes Active Directory s’authentifient correctement tant que NPS décide localement. Mais dès que vous créez un Remote RADIUS Server Group et modifiez votre Connection Request Policy (CRP) pour Forwarding to remote server, seuls les comptes distants fonctionnent ; les comptes AD locaux sont refusés.
La cause est structurelle : une CRP décide soit d’authentifier localement, soit de transférer. Pour « faire les deux », il faut segmenter les demandes via deux CRP distinctes, ordonnées et filtrées par des conditions précises (attributs RADIUS, format d’identité, SSID, etc.).
Architecture et prérequis
- Un serveur Windows Server 2016 membre du domaine, rôle NPS installé et inscrit dans Active Directory pour autoriser l’authentification des utilisateurs du domaine.
- Un réseau Wi‑Fi UniFi configuré en WPA2/3‑Enterprise (802.1X) pointant vers le NPS.
- Un second serveur RADIUS (NPS, FreeRADIUS, appliance, etc.) hébergeant un autre référentiel d’identités.
- Secrets partagés cohérents, ports UDP 1812 (auth) et 1813 (accounting) ouverts, horloge synchronisée (NTP).
- Certificat serveur valide pour PEAP/EAP‑TLS : les clients doivent faire confiance à l’AC qui a émis ce certificat.
Solution récapitulative
| Étape | Action | Détails clés |
|---|---|---|
| 1 | Configurer le groupe de serveurs RADIUS distants | Déclarez l’adresse IP/nom, ports UDP 1812/1813, secret partagé identique des deux côtés. Activez Accounting si vous tenez des journaux centralisés. |
| 2 | Créer deux Connection Request Policies et les ordonner | CRP‑Local (priorité haute) : conditions qui caractérisent vos comptes AD (ex. identifiants sans suffixe, DOMAIN\user, SSID interne). Action : Authenticate requests on this server.CRP‑Remote (priorité suivante) : conditions inverses (ex. user@exemple.com, SSID invité). Action : Forward to <Remote RADIUS Server Group>. |
| 3 | Vérifier/Créer les Network Policies | Pour la partie locale : groupes AD autorisés, méthodes PEAP/EAP‑TLS, contraintes cryptographiques. Pour la partie distante : aucune Network Policy locale requise (c’est le serveur distant qui tranche). |
| 4 | Contrôler l’ordre d’évaluation | NPS lit les CRP de haut en bas et s’arrête à la première correspondance. Si CRP‑Remote est au‑dessus, toutes les demandes seront proxyfiées. |
| 5 | Activer et lire la journalisation NPS | Activez le journal texte et le canal d’événements Microsoft‑Windows‑NPS/Operational. Les événements indiquent la CRP et la Network Policy appliquées. |
| 6 | Ouvrir les ports et synchroniser l’heure | UDP 1812/1813 entre AP/contrôleur ↔ NPS ↔ serveur distant. NTP impératif (sinon échec EAP‑TLS). |
| 7 | Tester et ajuster | Envoyez des identités représentatives : alice (local) et bob@example.com (distant). Analysez les journaux et l’appariement des CRP. |
| 8 | Activer les options avancées | Réécriture d’attributs, délais/relances côté groupe distant, scénarios de délestage/fallback, classification par SSID/VLAN/NAS‑ID. |
Étapes détaillées
Déclarer le groupe de serveurs RADIUS distants
- Ouvrez Network Policy Server → RADIUS Clients and Servers → Remote RADIUS Server Groups → New.
- Ajoutez le serveur distant : IP ou FQDN, port 1812 (authentification) et 1813 (accounting), secret partagé.
- Dans l’onglet Load Balancing : configurez Timeout (ex. 5 s) et Number of seconds between requests, ainsi que le nombre d’Attempts. Si vous avez plusieurs serveurs distants, ajustez l’ordre et la pondération.
- Si vous collectez l’accounting sur le serveur distant, activez l’onglet Accounting.
Définir une logique de répartition claire
Le cœur de la solution est de différencier les demandes. Choisissez des critères observables et stables :
| Signal | Comment l’obtenir | Exemple de condition | Usage typique |
|---|---|---|---|
| Format de l’identité (User‑Name) | Les clients envoient user, DOMAIN\user ou user@realm | Regex .+@exemple\.com$ → distant | Séparer UPN externe vs comptes AD internes |
| SSID / Called‑Station‑ID | UniFi inclut MAC:SSID dans Called‑Station‑ID | *:INVITES → distant | Réseau invité géré par un RADIUS externe |
| NAS‑Identifier (NAS‑ID) | Profil RADIUS UniFi ou AP affecte un NAS‑ID | NAS‑ID guest‑gw → distant | Identifier une passerelle/contrôleur spécifique |
| VLAN attribué par le WLAN | Condition Tunnel‑Private‑Group‑ID après authentification | SSID interne → local, guest → distant | Séparation de trafic |
| Origine des AP (RADIUS Client) | Adresse IP des AP déclarés dans NPS | AP bâtiment A → local | Multi‑sites |
Créer les Connection Request Policies
Dans Policies → Connection Request Policies :
CRP‑Local (priorité la plus haute)
- New → Nom :
CRP‑Local, Type : Unspecified. - Conditions : ajoutez un ou plusieurs critères qui captent vos identités locales, par exemple :
- User‑Name does not match
.+@exemple\.com$(pas de suffixe externe) - OU User‑Name matches
^[^@\\]+$(chaîne sans@ni\) - OU Called‑Station‑ID contient votre SSID interne (ex.
MAC:ENTREPRISE)
- User‑Name does not match
- Settings : Authenticate requests on this server.
- Authentication : laissez Authenticate on this server et passez à la configuration des Network Policies.
CRP‑Remote (priorité juste en dessous)
- New → Nom :
CRP‑Remote. - Conditions : définissez l’inverse des précédentes, par exemple :
- User‑Name matches
.+@exemple\.com$, ou Realm =exemple.com - OU Called‑Station‑ID contient le SSID invité (ex.
MAC:INVITES) - OU NAS‑Identifier =
guest‑gw
- User‑Name matches
- Settings : Forward requests to the following remote RADIUS server group → choisissez votre groupe créé plus haut.
- Attribute manipulation (optionnel) : si nécessaire, ajoutez une règle pour User‑Name (ex. retirer un suffixe
@extou en ajouter un) afin que le serveur distant reçoive le format d’identité attendu.
Créer/Vérifier les Network Policies locales
Les Network Policies ne s’appliquent que si la CRP décide « Authenticate on this server ». Créez au moins une policy « Accès Wi‑Fi interne » :
- Conditions : groupes AD autorisés (Windows Groups), NAS‑Port‑Type = Wireless – IEEE 802.11, SSID interne via Called‑Station‑ID si vous voulez affiner.
- Constraints : PEAP (EAP‑MSCHAPv2) et/ou EAP‑TLS selon votre stratégie. Assurez‑vous que le certificat serveur NPS est émis par une AC approuvée par les postes.
- Settings : chiffrement requis, éventuels attributs RADIUS (VLAN, session‑timeout) si vous affectez de la QoS ou des VLAN dynamiques depuis NPS.
Pour le trafic proxyfié (CRP‑Remote), aucune Network Policy locale n’est nécessaire ; c’est le serveur distant qui décide.
Contrôle de l’ordre et logique d’évaluation
NPS évalue d’abord les Connection Request Policies de haut en bas. À la première correspondance, il arrête l’évaluation et applique l’action (local vs proxy). Ce n’est qu’ensuite, si et seulement si l’action est « Authenticate on this server », que NPS évalue les Network Policies. Placez donc CRP‑Local au‑dessus de CRP‑Remote si vous souhaitez privilégier les identités AD quand l’intention n’est pas explicite.
if (CRP‑Local.conditions match) {
authenticate_on_this_server();
} else if (CRP‑Remote.conditions match) {
proxy_to_remote_group();
} else {
reject("No matching Connection Request Policy");
}
Journalisation et diagnostic
Activez une visibilité maximale dès le début :
- Fichier de log NPS : Accounting → Log to a text file. Par défaut :
%SystemRoot%\System32\LogFiles(format IAS). Vous pouvez convertir ces logs en CSV pour analyser les attributs. - Journal d’événements : Applications and Services Logs → Microsoft → Windows → NPS → Operational.
| ID d’événement | Signification | Ce que vous devez vérifier |
|---|---|---|
| 6272 | Accès accordé | Confirme la CRP et la Network Policy utilisées, le type d’EAP et l’identité. |
| 6273 | Accès refusé | Raison du refus (groupes, contraintes EAP, certificat, mot de passe), CRP appliquée. |
| 6278 | Requête ignorée | Problèmes de formulation (attributs manquants, stratégie non applicable) ou proxy non joignable. |
Exemples PowerShell utiles :
# Derniers événements NPS pertinents
Get-WinEvent -LogName 'Microsoft-Windows-NPS/Operational' |
Where-Object {$_.Id -in 6272,6273,6278} |
Select-Object TimeCreated, Id, Message -First 30
# Export de la configuration NPS (sauvegarde)
netsh nps export filename="C:\Backup\nps-config.xml" exportPSK=YES Cas d’école UniFi
Dans l’interface UniFi (Network/Application), vérifiez :
- RADIUS profile : adresse IP du NPS, secret, ports. Décidez si les AP envoient directement au NPS, ou si la passerelle/contrôleur proxy. Déclarez chaque émetteur dans RADIUS Clients du NPS (IP, secret, vendor = RADIUS Standard ou Ubiquiti si vous utilisez des attributs vendor‑specific).
- SSID : activez WPA‑Enterprise et associez le profil RADIUS correct. Optionnel : définissez un NAS‑Identifier par SSID pour différencier la CRP (ex.
NAS‑ID = ENTREPRISEvsNAS‑ID = INVITES). - Accounting : si vous centralisez l’accounting ailleurs, cochez‑le et envoyez vers le serveur concerné (local ou distant) selon votre architecture.
Attributs courants qu’UniFi inclut :
| Attribut | Exemple | Intérêt pour la CRP |
|---|---|---|
| NAS‑Port‑Type | Wireless‑IEEE 802.11 | Limiter aux requêtes Wi‑Fi (exclure VPN/dial‑in) |
| Called‑Station‑ID | AA‑BB‑CC‑DD‑EE‑FF:ENTREPRISE | Identifier l’SSID (chaîne après :) |
| Calling‑Station‑ID | 11‑22‑33‑44‑55‑66 (MAC client) | Audit, corrélation |
| NAS‑Identifier | guest‑gw | Décision CRP par profil/site |
Tests et validations
Pour valider la mécanique CRP (sans nécessairement réaliser un EAP complet), vous pouvez utiliser des outils RADIUS « simples » qui envoient PAP/CHAP ; ils ne simulent pas PEAP/EAP‑TLS mais suffisent pour vérifier quelle CRP s’applique et quel serveur reçoit la demande.
- NTRadPing sous Windows : envoyez
User-Name/User-Passwordet observez la réponse. - radtest/radclient (FreeRADIUS) :
# Test basique (PAP) - utile pour vérifier le routage CRP radtest alice "MotDePasse!" 192.0.2.10:1812 0 MonSecretPartage # Test MSCHAPv2 (toujours sans PEAP) - selon compilation radtest -t mschap [bob@exemple.com](mailto:bob@exemple.com) "MotDePasse!" 192.0.2.10 0 MonSecretPartage
Ensuite, testez depuis un client réel (Windows/macOS/iOS/Android) pour valider la couche EAP et la chaîne de certificats.
Options avancées
Réécriture d’attributs (User‑Name)
Dans la CRP‑Remote (onglet Settings → Attribute → Manipulation Rules), vous pouvez :
- Retirer un suffixe : Find =
@ext$, Replace = . - Ajouter un realm attendu par le serveur distant : si le client envoie
bob, remplacez parbob@exemple.com.
Exemple de règle de remplacement :
# Pseudo-règle (documentation)
IF User-Name matches ^([^@]+)$ THEN
SET User-Name = ${1}@exemple.com
Délais, relances et disponibilité du serveur distant
Dans le Remote RADIUS Server Group :
- Timeout : gardez‑le court (3–5 s) pour éviter des latences perçues par l’utilisateur.
- Attempts : 2–3 tentatives maximum, surtout via WAN.
- Plusieurs serveurs distants : ajoutez un second nœud pour la haute disponibilité et activez l’ordonnancement adéquat.
Stratégie de fallback
Rappel important : NPS n’évalue pas les CRP suivantes si une CRP a déjà fait correspondance, même si le proxy en aval ne répond pas. Le « fallback local » n’est donc pas automatique en cas de panne du serveur distant. Les approches réalistes sont :
- Prévoir un second serveur distant dans le groupe (HA en amont).
- Conserver la possibilité d’inverser l’ordre des CRP (ou de désactiver temporairement la CRP‑Remote) lors d’un incident.
- Réduire Timeout/Attempts pour que l’échec soit rapide et contrôlé côté utilisateur.
Erreurs fréquentes et corrections
- La CRP‑Remote est au‑dessus de la CRP‑Local : toutes les demandes partent en proxy, les comptes AD échouent → remontez la CRP‑Local.
- Le NPS n’est pas « Register in Active Directory » : les comptes AD ne s’authentifient pas → enregistrez le serveur dans AD.
- Certificat serveur non approuvé : les clients refusent PEAP/EAP‑TLS → déployez la chaîne via GPO, utilisez un modèle serveur NPS et un CN/SAN adapté.
- RADIUS Client non déclaré : AP/contrôleur inconnu du NPS → ajoutez chaque IP d’AP/passerelle avec le bon secret.
- Format d’identité inattendu : la regex ne matche pas → ajustez les conditions (journalisez User‑Name pour voir le flux réel).
Matrice de décision et d’essais
| Identité test | Attributs pertinents | CRP attendue | Résultat escompté |
|---|---|---|---|
alice | User‑Name sans @ ni \, SSID = ENTREPRISE | CRP‑Local | Authentifié par NPS local, Network Policy AD appliquée |
DOMAIN\alice | User‑Name avec \ | CRP‑Local | Authentifié localement (PEAP/EAP‑TLS) |
bob@example.com | Suffixe @exemple.com, SSID = ENTREPRISE | CRP‑Remote | Proxy au serveur RADIUS distant, décision déléguée |
carol@ext | Suff. @ext, SSID = INVITES | CRP‑Remote + réécriture | Le proxy reçoit carol@exemple.com après rewriting |
Annexe : modèles de conditions CRP prêts à l’emploi
Dans la fenêtre des conditions d’une CRP, ajoutez User‑Name avec l’opérateur Matches the regular expression :
# Local (accepte user ou DOMAIN\user)
^[^@\\]+$|^[^@]+\\[^@]+$
# Distant (UPN vers domaine externe)
[.+@exemple.com](mailto:.+@exemple.com)$ Conditions SSID (via Called‑Station‑ID) :
# Interne
^([0-9A-F]{2}-){5}[0-9A-F]{2}:ENTREPRISE$
# Invités
^([0-9A-F]{2}-){5}[0-9A-F]{2}:INVITES$ Annexe : checklist opérationnelle
- Le groupe Remote RADIUS Server Group contient l’IP/port corrects et le secret partagé est identique.
- Deux CRP existent, CRP‑Local au‑dessus de CRP‑Remote, avec conditions stables.
- Les Network Policies locales autorisent les groupes AD, PEAP/EAP‑TLS sont configurés et le certificat serveur est valide.
- Tous les AP/contrôleurs sont ajoutés dans RADIUS Clients sur le NPS, ainsi que sur le serveur RADIUS distant si l’accounting est envoyé là‑bas.
- Les journaux NPS (texte + événements) sont activés et contrôlés après chaque changement.
- Les ports UDP 1812/1813 sont ouverts et NTP est opérationnel sur l’ensemble des nœuds (clients compris).
- Des tests représentatifs (
alice,bob@example.com) réussissent et la CRP appariée est celle attendue.
Questions fréquentes
Peut‑on utiliser une seule CRP pour authentifier localement et faire du proxy ?
Non. Une CRP impose un comportement exclusif : local ou proxy. Il faut donc plusieurs CRP avec des conditions distinctives, et un ordre cohérent.
Mes Network Policies locales ne s’appliquent pas aux comptes distants, est‑ce normal ?
Oui. Dès que la CRP choisit « Forward to remote server », la décision d’accès appartient au serveur distant ; vos Network Policies locales ne sont pas évaluées.
Comment séparer proprement « interne » et « invité » ?
Le plus simple est d’utiliser des SSID dédiés (ENTREPRISE vs INVITES) et d’exploiter Called‑Station‑ID ou NAS‑Identifier dans vos CRP.
J’obtiens des erreurs PEAP côté clients après l’ajout du proxy ; pourquoi ?
Vérifiez la chaîne de certificats du NPS et/ou du serveur distant. Les clients doivent a priori faire confiance à l’AC qui signe le certificat serveur présenté durant EAP.
Comment diagnostiquer un mauvais aiguillage CRP ?
Regardez les événements 6272/6273 dans Microsoft‑Windows‑NPS/Operational et les logs IAS ; vous y verrez l’identité reçue, la CRP appliquée et, le cas échéant, le serveur distant contacté.
Conclusion
La clé pour faire cohabiter comptes Active Directory locaux et identités d’un RADIUS distant sur un même NPS est d’orchestrer l’aiguillage en amont : deux Connection Request Policies bien pensées, des conditions simples et fiables (format d’identité, SSID, NAS‑ID), un ordre d’évaluation maîtrisé et une journalisation bavarde. En procédant ainsi, vous offrez aux utilisateurs une expérience unifiée (un seul SSID si vous le souhaitez) tout en gardant le contrôle côté sécurité et supervision. Cette méthode s’applique particulièrement bien aux déploiements UniFi mais reste valable avec d’autres infrastructures 802.1X. Une fois stabilisée, votre Wi‑Fi Enterprise acceptera indifféremment les comptes du domaine et ceux du serveur RADIUS externe, sans conflit ni surprise.
En appliquant cette méthode (deux CRP ordonnées + groupe RADIUS distant correctement déclaré), vos utilisateurs pourront s’authentifier indifféremment via le domaine local ou via le serveur RADIUS externe, sans conflit.