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 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.

• Wi-Fi, EAP-TLS, NPS, Troubleshooting
• Endpoint Lab — Profile, TLS, RADIUS, Network
• accès au poste et aux événements WLAN, audit NPS activé et horloge synchronisée, inventaire des AP/contrôleurs RADIUS

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting Wi-Fi, certificats et NPS, l’enquête suit le parcours Profile → TLS → RADIUS → Network. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Qualifier le point de rupture, Exporter WLAN report et événements et Valider certificat serveur. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Profil absent, Échec TLS avant NPS et 6273 NPS » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Qualifier le point de rupture.
• Exporter WLAN report et événements.
• Valider certificat serveur.

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

L’état initial de Troubleshooting Wi-Fi, certificats et NPS doit couvrir 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. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Profile, TLS, RADIUS, Network sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• 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 de Troubleshooting Wi-Fi, certificats et NPS relie Profile, TLS, RADIUS, Network. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Qualifier le point de rupture. Exporter WLAN report et événements. Valider certificat serveur. Valider certificat client. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Affectation ou sync », « Trust ou nom serveur », « Policy ou mapping » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• 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

L’investigation suit l’ordre Profile → TLS → RADIUS → Network. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting Wi-Fi, certificats et NPS, les contrôles « Reproduire et horodater le symptôme », « Contrôler la première couche », « Corréler les preuves » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé de Troubleshooting Wi-Fi, certificats et NPS

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

Traitement, exploitation et cas limites de Troubleshooting Wi-Fi, certificats et NPS

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 propres à Troubleshooting Wi-Fi, certificats et NPS

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é.

• Profil absent — Intune et profils WLAN
• Échec TLS avant NPS — EapHost et chaîne
• 6273 NPS — Reason Code
• Access-Accept mais pas d’IP — Attributs et capture

Pilote et suivi opérationnel de Troubleshooting Wi-Fi, certificats et NPS

Le pilote couvre le périmètre Wi-Fi, EAP-TLS, NPS, Troubleshooting et contrôle Qualifier le point de rupture. Exporter WLAN report et événements. Valider certificat serveur. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting Wi-Fi, certificats et NPS.

Les cas d’échec « Profil absent », « Échec TLS avant NPS », « 6273 NPS » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve le Reason Code doit être corrélé à l’heure et au NAS, WLAN report contient des données réseau, ne pas exporter de clé privée, désactiver la validation serveur est NO-GO. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Qualifier le point de rupture. Exporter WLAN report et événements. Valider certificat serveur. Valider certificat client. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting Wi-Fi, certificats et NPS, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$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 }

$ErrorActionPreference = 'Stop'
try {
  netsh.exe wlan show interfaces
  netsh.exe wlan show profiles
  certutil.exe -user -store My
  Get-WinEvent -LogName 'Microsoft-Windows-WLAN-AutoConfig/Operational' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[07:40:00.110] WLAN   SSID=<SSID> Profile=<PROFILE> Association=Success
[07:40:01.221] EAP    Method=TLS Certificate=<THUMBPRINT>
[07:40:01.882] NPS    EventId=6273 ReasonCode=<CODE> Policy=<POLICY>
[07:40:02.100] WLAN   Authentication=Failed Reason=<REASON>
[07:41:10.772] Check  EKU=ClientAuthentication Chain=Trusted TimeValid=True

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

La matrice couvre notamment Profil absent, Échec TLS avant NPS, 6273 NPS, Access-Accept mais pas d’IP. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Qualifier le point de rupture, Exporter WLAN report et événements et Valider certificat serveur sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

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

La correction de Troubleshooting Wi-Fi, certificats et NPS est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• 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 retour arrière de Troubleshooting Wi-Fi, certificats et NPS restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Qualifier le point de rupture. Exporter WLAN report et événements. Valider certificat serveur. Valider certificat client. ainsi que les causes déjà écartées.