Troubleshooting Wi-Fi EAP-TLS : corréler Windows, certificats et NPS

Résumé opérationnel

Je relève l’heure, le SSID, le contexte avant ou après ouverture de session, le point d’accès et le serveur NPS qui a traité la requête. Sans ces éléments, un Reason Code NPS ne peut pas être relié au bon poste.

Côté Windows, le canal WLAN-AutoConfig/Operational et les événements EapHost montrent la négociation. Je vérifie ensuite le certificat sélectionnable : bon magasin, clé privée, EKU, validité, chaîne et identité.

Côté NPS, les événements d’audit, notamment les refus 6273 lorsqu’ils sont activés, fournissent policy, client RADIUS, méthode et Reason Code. La correction doit viser cette cause, pas désactiver la validation TLS.

Je relève l’heure, le SSID, le contexte avant ou après ouverture de session, le point d’accès et le serveur NPS qui a traité la requête. Sans ces éléments, un Reason Code NPS ne peut pas être relié au bon poste.

Symptôme, contexte et périmètre de l’incident

Je classe le symptôme : SSID absent, profil absent, demande de validation, échec immédiat, boucle d’authentification, accès limité ou déconnexion après renouvellement. Le moment de l’échec détermine les preuves à collecter.

netsh wlan show wlanreport génère un rapport local utile, tandis que Microsoft-Windows-WLAN-AutoConfig/Operational expose association et 802.1X. Je conserve la fenêtre de temps avant de reproduire une seconde fois.

Le besoin opérationnel doit être défini avant de choisir un profil ou un outil. Il faut distinguer le résultat attendu, l’expérience utilisateur, le propriétaire de la configuration et les contrôles qui confirmeront son application. La présence d’un paramètre dans une console ne justifie pas son activation.

L’intention configurée dans le cloud, son applicabilité, l’état reçu par Windows et le résultat observé correspondent à quatre informations différentes. Une affectation réussie, un état vert ou une requête HTTP acceptée ne prouve pas à lui seul que tout le parcours fonctionne.

• Wi-Fi, EAP-TLS, NPS, Troubleshooting
• postes Windows gérés et services Microsoft officiellement documentés
• validation en laboratoire puis pilote représentatif avant généralisation

Questions à résoudre et méthode de diagnostic

Le diagnostic de « Troubleshooting Wi-Fi, certificats et NPS » commence par le symptôme exact et son horodatage. Plusieurs causes restent possibles tant qu’un log, un état local ou une donnée du service ne les a pas confirmées ou écartées. Une affectation visible dans le portail, un code isolé ou un état ancien ne suffit pas.

La première collecte reste en lecture seule : contexte utilisateur ou SYSTEM, version de Windows et des composants, identifiants de corrélation, événements, logs et état du registre. Aucun cache, certificat, objet ou clé ne doit être supprimé avant cette collecte.

La première phase qui diverge détermine la suite. Une seule cause est corrigée à la fois, puis le scénario initial est rejoué. Un contournement temporaire ne doit pas être présenté comme une correction définitive.

Les heures du portail et du poste, le décalage UTC et les identifiants présents dans plusieurs logs forment une chronologie unique. Deux messages identiques peuvent appartenir à des tentatives différentes. La conclusion indique clairement les faits confirmés, les hypothèses probables et les points qui restent impossibles à vérifier.

• comprendre l’architecture, les dépendances et les limites
• mettre en œuvre un pilote mesurable et reproductible
• construire un diagnostic et un rollback utilisables par l’exploitation

Cartographie du flux à diagnostiquer

Je classe le symptôme : SSID absent, profil absent, demande de validation, échec immédiat, boucle d’authentification, accès limité ou déconnexion après renouvellement. Le moment de l’échec détermine les preuves à collecter.

netsh wlan show wlanreport génère un rapport local utile, tandis que Microsoft-Windows-WLAN-AutoConfig/Operational expose association et 802.1X. Je conserve la fenêtre de temps avant de reproduire une seconde fois.

Le certificat serveur est contrôlé avant que le client ne présente son identité. Une racine manquante, un nom RADIUS non autorisé, une date invalide ou une CRL inaccessible peuvent arrêter le tunnel TLS avant toute entrée NPS exploitable.

État initial et prérequis de collecte

Je fige l’état du poste avant toute correction : versions, heure, identité, contexte d’exécution, affectations, autorités de gestion et dernier cycle connu. Cette photographie permet de distinguer la cause initiale des effets produits par les essais suivants.

Je vérifie également que le compte, l’appareil, la licence, la connectivité et les composants nécessaires rendent le scénario réellement applicable. Un prérequis absent doit être traité comme une cause potentielle, pas comme un détail de préparation.

• accès au poste et aux événements WLAN
• audit NPS activé et horloge synchronisée
• inventaire des AP/contrôleurs RADIUS
• droits lecture certificats
• copie du profil Intune
• chemin de secours
• cas reproductible sur un poste pilote

Collecte des preuves : journaux, registre et états

La chronologie relie l’heure de la demande, le check-in, l’événement local, la décision du composant et la remontée dans le portail. Conservez l’heure UTC et l’heure locale. Avant tout partage, anonymisez les UPN, DeviceId, TenantId, noms internes, certificats, adresses et contenus métiers.

La collecte initiale reste en lecture seule. Ne videz pas un cache, ne supprimez pas une clé, ne réinitialisez pas un agent et ne forcez pas un enrôlement avant d’avoir capturé les informations utiles. Ces actions changent l’état et peuvent faire disparaître la cause initiale.

Les scripts publiés ici illustrent la collecte décrite dans l’article et restent en lecture seule. Une remédiation doit proposer une simulation, limiter sa cible, expliquer son impact et restaurer l’état précédent. Une opération privilégiée ou à grande échelle exige en plus une validation formelle et un pilote représentatif.

• Qualifier le point de rupture.
• Exporter WLAN report et événements.
• Valider certificat serveur.
• Valider certificat client.
• Corréler l’événement NPS.
• Contrôler VLAN, DHCP et DNS
• Rejouer sur deux AP

Investigation pas à pas

Je suis l’ordre réel du traitement et je m’arrête à la première divergence démontrée. Poursuivre malgré une preuve manquante créerait des symptômes secondaires et rendrait la chronologie moins fiable.

Pour chaque étape, je note l’action, l’emplacement, le résultat attendu et la méthode de vérification. Les champs Impact et Retour arrière concernent l’éventuelle correction ; la phase d’observation reste en lecture seule autant que possible.

Fonctionnement détaillé et responsabilités

Je classe le symptôme : SSID absent, profil absent, demande de validation, échec immédiat, boucle d’authentification, accès limité ou déconnexion après renouvellement. Le moment de l’échec détermine les preuves à collecter.

netsh wlan show wlanreport génère un rapport local utile, tandis que Microsoft-Windows-WLAN-AutoConfig/Operational expose association et 802.1X. Je conserve la fenêtre de temps avant de reproduire une seconde fois.

Le certificat serveur est contrôlé avant que le client ne présente son identité. Une racine manquante, un nom RADIUS non autorisé, une date invalide ou une CRL inaccessible peuvent arrêter le tunnel TLS avant toute entrée NPS exploitable.

• accès au poste et aux événements WLAN
• audit NPS activé et horloge synchronisée
• inventaire des AP/contrôleurs RADIUS
• droits lecture certificats

Configuration, exploitation et cas limites

Pour le certificat client, je vérifie CurrentUser\My ou LocalMachine\My selon le profil, HasPrivateKey, Client Authentication, période de validité, chaîne, SAN et ACL de clé. Plusieurs certificats éligibles peuvent rendre la sélection ambiguë.

NPS doit connaître le point d’accès ou le contrôleur comme client RADIUS avec adresse et secret cohérents. Une requête qui n’atteint pas NPS oriente vers le réseau, le NAS ou le secret partagé, pas vers Intune.

Un refus NPS contient policy et Reason Code. Je confirme ordre des Connection Request Policies et Network Policies, groupes autorisés, méthode EAP, contraintes de certificat, strong mapping et état de révocation.

• Corréler l’événement NPS.
• Contrôler VLAN, DHCP et DNS
• Rejouer sur deux AP

Lire les états et les résultats

Une authentification acceptée suivie d’un réseau sans accès déplace l’enquête vers VLAN, attributs RADIUS, DHCP, routes, pare-feu et DNS. Modifier le certificat ne corrige pas une attribution VLAN erronée.

Après renouvellement, je compare l’ancien et le nouveau certificat : émetteur, sujet, SAN, EKU, OID SID, fournisseur et chaîne. Le serveur peut encore faire confiance à l’ancienne CA ou mapper un ancien format.

Je valide la correction avec un nouvel événement de succès côté poste et un Access-Accept correspondant côté NPS, puis avec DHCP, DNS et ressource métier. Le retour arrière conserve l’ancien profil jusqu’à stabilité.

Une configuration décrit ce qui devrait arriver. L’inventaire montre un état observé à un instant donné, tandis qu’un log d’exécution indique ce que le composant a réellement tenté. Les horodatages et les contextes doivent correspondre avant de relier ces informations.

Les états non applicable, pending, conflict, error et success doivent rester séparés. L’absence d’un poste dans un rapport ne permet pas de conclure : il peut être hors ligne, non éligible, non ciblé, en retard de télémétrie ou exclu de la collecte.

Pilote, généralisation et maintien en conditions opérationnelles

Le pilote couvre plusieurs modèles matériels, versions de Windows, profils réseau, populations utilisateur et exceptions métier. Une cohorte témoin aide à distinguer l’effet du changement d’une évolution globale du service, d’une mise à jour applicative ou d’un incident réseau.

Les critères GO sont définis avant le début : couverture, taux de succès, délai de convergence, incidents, tickets support, régressions et temps de rollback. Une moyenne satisfaisante ne masque pas un sous-groupe en échec ; les résultats sont donc segmentés par version, modèle, site et mode de gestion.

Les cas négatifs sont testés volontairement : appareil hors ligne, licence absente, identité non éligible, règle non applicable, réseau filtré et retour arrière. Un design exploitable doit échouer de manière visible, sûre et compréhensible pour le support.

Après généralisation, les exceptions, permissions, versions de profil et dépendances doivent être revues régulièrement. Le service cloud et Windows évoluent ; une décision correcte aujourd’hui doit rester traçable et être revalidée lorsqu’un prérequis ou une interface change.

Commandes et scripts de diagnostic en lecture seule

Les commandes de cette section servent à inventorier, corréler ou illustrer. Les scripts de diagnostic restent en lecture seule : ils arrêtent leur exécution en cas d’erreur et ne modifient volontairement aucun paramètre du poste.

Je vérifie toujours le contexte d’exécution. Une commande lancée dans la session utilisateur n’observe pas forcément les mêmes certificats, variables, chemins ou ruches de registre qu’un processus exécuté sous SYSTEM.

# Exemple de collecte en lecture seule — à adapter avant utilisation
$ErrorActionPreference = 'Stop'
try {
  netsh.exe wlan show interfaces
  netsh.exe wlan show profiles
  netsh.exe wlan show wlanreport
  Get-WinEvent -LogName 'Microsoft-Windows-WLAN-AutoConfig/Operational' -MaxEvents 180 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte 802.1X impossible : $($_.Exception.Message)"; exit 1 }

Arbre de décision : symptômes, causes et corrections

Le symptôme oriente l’enquête, mais ne sélectionne jamais seul une correction. Je n’applique la réponse proposée que lorsque la preuve recherchée confirme la cause et que les autres hypothèses importantes sont écartées.

Après correction, je rejoue exactement le scénario initial avec les mêmes points de mesure. Si le symptôme se déplace vers une autre phase, je poursuis l’analyse au lieu de déclarer l’incident résolu.

Validation de la correction et critères de clôture

Je valide le comportement local, puis la remontée dans le service. Les délais du portail sont pris en compte, mais l’état attendu sur le poste doit être vérifiable immédiatement ou selon le cycle officiellement documenté.

La clôture exige un résultat reproductible, l’absence de régression, une cause documentée et une correction minimale. La généralisation reste NO-GO si le résultat varie entre deux postes comparables ou si le retour arrière n’est pas maîtrisé.

• Qualifier le point de rupture.
• Exporter WLAN report et événements.
• Valider certificat serveur.
• Valider certificat client.
• Corréler l’événement NPS.
• Contrôler VLAN, DHCP et DNS
• Rejouer sur deux AP

Retour arrière, escalade et points de vigilance

Le rollback restaure l’état ou l’autorité précédente et doit lui aussi être vérifié sur le poste. Retirer une affectation sans confirmer la convergence locale ne constitue pas un retour arrière terminé.

Si la cause reste indéterminée, je conserve la chronologie, les journaux anonymisés, les identifiants de corrélation et la liste des hypothèses déjà écartées avant l’escalade. Je n’efface jamais les preuves pour tenter une réparation générique.