802.1X : déboguer « auth failed » côté client

Tu connais le scénario. Tu branches un PC sur un port « propre », le switch est en 802.1X, ça doit juste marcher… et non. Le client tourne, tente, retente, puis tu vois un truc du genre « auth failed », « authentication failed », « échec d’authentification » selon l’OS. Et toi tu te retrouves à fixer l’écran en te demandant si c’est le mot de passe, le certificat, l’heure, le VLAN, ou juste un supplicant qui fait n’importe quoi.

Dans ce billet, je te montre comment je débogue un « auth failed » côté client. L’idée est simple : partir du poste, récupérer des preuves, comprendre à quel moment ça casse (EAP, certif, identité, méthode), et ensuite seulement aller embêter le switch ou le serveur RADIUS.

Si tu es en BTS SIO SISR, c’est typiquement le genre de cas pratique qu’on voit en TP. D’ailleurs, je poste ce genre de labs régulièrement sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) donc garde le site sous la main si tu veux d’autres pas à pas.

Rappel rapide : ce que veut dire « auth failed » côté client

Côté client, « auth failed » est un symptôme, pas une cause. Dans 802.1X, le poste parle EAP via le switch (authenticator), et le switch relaie au serveur RADIUS (auth server). Le poste ne voit pas toujours le vrai motif. Parfois l’OS affiche juste « échec ».

Ce qu’on veut identifier :

• est ce que le lien est bien up, et 802.1X démarre vraiment
• quelle méthode EAP est tentée (PEAP, EAP-TLS, TTLS, etc.)
• à quel moment ça casse : validation serveur, certif client, identifiants, stratégie NPS, chaîne de confiance, etc.

Petit pense-bête : PEAP = souvent identifiant/mot de passe dans un tunnel TLS. EAP-TLS = certif client obligatoire. Et là, un détail bête (heure, EKU, CA, chaîne) suffit à faire tomber l’auth.

Avant de sortir les logs : check de base, vraiment

Oui c’est trivial, mais si tu zappes ça tu vas perdre 30 minutes.

1. Câble, port, link

• Le lien Ethernet est il « connecté » ?
• Si tu as une IP APIPA (169.254.x.x), c’est fréquent quand le port est en « guest vlan » ou bloqué.

2. Heure et date du poste

• Si l’horloge est en vrac, la validation des certificats peut échouer direct.
• Vérifie : heure locale, fuseau, synchro NTP.

3. Certificats installés (si EAP-TLS ou PEAP avec validation stricte)

• CA racine de l’autorité qui a signé le certif serveur RADIUS : présente dans « Autorités de certification racines de confiance »
• Certificat client : présent dans « Personnel », avec clé privée, non expiré.

4. Service supplicant

• Windows : service Wired AutoConfig doit être en cours d’exécution.
• Linux : wpa_supplicant actif, ou NetworkManager correctement configuré.

Côté Windows : les 3 endroits où je regarde en premier

1) État 802.1X sur la carte réseau

Sur Windows, tu peux déjà voir si la tentative se lance.

• ncpa.cpl puis clic droit carte Ethernet → État → parfois tu vois « authentification 802.1X »
• Ou via PowerShell :

powershell Get-NetAdapter | Select Name, Status, LinkSpeed

Si la carte est down, tout le reste est inutile.

2) Observateur d’événements : le vrai point de départ

C’est le plus rentable. Va ici :

• Observateur d’événements → Journaux des applications et des services →
  Microsoft → Windows → Wired-AutoConfig → Operational

Tu cherches des événements autour de l’échec. Souvent tu vois :

• méthode EAP utilisée
• erreurs de certificat
• « reason code »

Exemples typiques (selon version Windows) :

• échec de validation du certificat serveur
• aucun certificat client disponible
• échec d’authentification utilisateur ou ordinateur
• méthode EAP non autorisée

Astuce : exporte les événements et garde une capture. En environnement TP, ça te sert de preuve dans un compte rendu.

3) Traces netsh WLAN… oui, même pour filaire, et aussi netsh lan

Sur Windows, tu as des commandes utiles :

cmd netsh lan show interfaces netsh lan show profiles

Et pour la trace 802.1X filaire :

cmd netsh lan set tracing * enabled

Reproduis le problème, puis :

cmd netsh lan set tracing * disabled

Les logs se retrouvent généralement dans C:\ProgramData\Microsoft\WiredAutoConfig\Tracing (selon build). Dedans, tu as des fichiers ETL et/ou textes.

Pour aller plus loin, tu peux aussi capturer avec Wireshark (on en parle plus bas), mais déjà ces traces Windows donnent souvent le pourquoi.

Les causes les plus fréquentes, vues depuis le poste

Cas 1 : validation du certificat serveur refusée (PEAP ou TTLS)

Symptômes :

• message Windows du style « impossible de valider le certificat »
• dans les logs : « server certificate validation failed »

Causes classiques :

• le poste ne fait pas confiance à la CA qui a signé le certificat du serveur RADIUS
• le nom du serveur dans le certificat ne correspond pas (CN / SAN)
• certificat expiré
• heure du poste incorrecte

Ce que je fais :

• installer la CA racine dans le magasin « racines de confiance »
• vérifier le certificat serveur RADIUS : CN/SAN, dates, chaîne
• vérifier dans le profil 802.1X si « valider le certificat serveur » est activé, et sur quel nom on pin

Sur un domaine AD, c’est souvent GPO qui pousse la CA et les paramètres PEAP. Si tu testes hors domaine, tu es vite dans le flou.

Cas 2 : aucun certificat client disponible (EAP-TLS)

Symptômes :

• Windows boucle puis échec rapide
• log : « no valid client certificate found »

Checklist certif client :

• présent dans « Personnel »
• possède une clé privée
• EKU : « Client Authentication »
• chaîne valide jusqu’à une CA de confiance
• non révoqué (si CRL/OCSP check activé)
• nom sujet ou UPN conforme à la stratégie NPS (selon mapping)

Commande utile pour lister rapidement :

cmd certutil -store my

Et si tu veux vérifier la chaîne :

cmd certutil -verify -urlfetch toncert.cer

Le -urlfetch te dira si la CRL est joignable. Et oui, en lab, la CRL inaccessible fait parfois échouer selon la config.

Cas 3 : mauvais type d’identité : utilisateur vs ordinateur

Gros classique en entreprise. On croit que c’est l’utilisateur, mais la politique attend le compte machine, ou l’inverse.

• Authentification ordinateur : avant ouverture de session, utile pour mettre le poste sur le bon VLAN
• Authentification utilisateur : après login

Dans les GPO, on peut forcer :

• « authentifier en tant qu’ordinateur lorsque des infos ordinateur sont disponibles »
• « authentifier en tant qu’utilisateur »

Si la stratégie RADIUS (NPS) n’autorise que les machines (groupe AD « Domain Computers »), un test en user only va échouer.

À regarder dans les logs Wired AutoConfig : on voit souvent quel mode a été utilisé.

Cas 4 : méthode EAP non alignée

Exemple : le serveur attend PEAP MSCHAPv2, mais le client tente EAP-TLS. Ou inversement.

Sur Windows, dans le profil 802.1X, vérifie :

• type EAP configuré
• propriétés PEAP (EAP interne MSCHAPv2)
• options du type « utiliser automatiquement mon nom d’ouverture de session Windows »

En lab, je vois souvent un profil « bricolé » qui traîne et qui force une méthode différente de celle du NPS.

Cas 5 : mot de passe incorrect… oui, ça arrive

PEAP MSCHAPv2 : si l’utilisateur tape mal son mot de passe, le poste dit « auth failed ». Mais là le serveur NPS loguera un « bad credentials ». Côté client, ce n’est pas toujours clair.

Donc côté client : vérifie si une fenêtre d’identifiants apparaît, ou si un cache d’identifiants obsolète est utilisé.

Wireshark : voir l’EAP, et arrêter de deviner

Quand tu captures sur le poste, tu peux voir les trames EAPOL et parfois des indications de cause (pas toujours, car une partie est dans TLS). Mais déjà tu sais si le dialogue démarre.

Filtre Wireshark utile :

• eapol
• eap
• radius (si tu captures côté serveur ou sur un SPAN)

Ce que tu veux voir :

• EAPOL-Start
• EAP-Request Identity
• EAP-Response Identity
• puis EAP-TLS ou PEAP

Si tu vois un EAP-Failure juste après l’identité, ça sent souvent :

• identité rejetée par la policy
• méthode non autorisée

Si ça part en TLS puis ça coupe, ça sent plus :

• problème de certificat
• mismatch de paramètres cryptos
• validation serveur refusée

Note pratique : si tu ne peux pas capturer facilement, demande un port mirror sur le switch. En TP, c’est souvent la solution la plus propre.

Linux : wpa_supplicant en mode verbeux, et tu as la réponse

Sur Linux, quand tu fais du 802.1X filaire, wpa_supplicant est ton ami. L’avantage : il parle. Beaucoup.

Exemple de commande (à adapter à ton interface) :

bash sudo wpa_supplicant -i eth0 -D wired -c /etc/wpa_supplicant/wired.conf -dd

Le -dd est très verbeux. Tu verras :

• negotiation EAP
• erreurs TLS
• certificat introuvable
• CA non reconnue

Exemple de conf EAP-TLS minimaliste :

conf network={ key_mgmt=IEEE8021X eap=TLS identity="poste01" ca_cert="/etc/ssl/certs/ca.pem" client_cert="/etc/ssl/certs/client.pem" private_key="/etc/ssl/private/client.key" }

Pour PEAP :

conf network={ key_mgmt=IEEE8021X eap=PEAP identity="user1" password="motdepasse" ca_cert="/etc/ssl/certs/ca.pem" phase2="auth=MSCHAPV2" }

Si tu n’as pas le CA, tu vas le voir direct. Et si tu as un souci de droits sur la clé privée, pareil.

En parlant de problèmes liés aux réseaux sans fil et à leur sécurité, il peut être intéressant d'explorer des méthodes telles que celles décrites dans ce guide sur le pentesting wifi. De plus, pour ceux qui cherchent à partager ou discuter des expériences liées à ce sujet, rejoindre des groupes sur les réseaux sociaux comme celui-ci groupe Facebook pourrait s'avérer bénéfique.

macOS : profil et logs, sinon ça devient vite opaque

Sur macOS, si c’est géré par profil (MDM), l’interface est simple mais le diagnostic peut être pénible.

Deux pistes :

• vérifier le profil 802.1X dans Réglages réseau
• consulter les logs via la Console (Console.app) en filtrant sur EAPOL, 802.1X, wpa

Et en cas de doute, exporter les profils, vérifier :

• méthode EAP
• CA de confiance
• identité

Petite méthode de tri : 6 questions pour isoler le souci vite

Quand j’ai « auth failed », je me pose ça, dans cet ordre :

1. Est ce que 802.1X démarre (EAPOL visible) ?
2. Quelle méthode EAP est tentée ?
3. Est ce que le poste fait confiance au certificat serveur (si PEAP/TTLS) ?
4. Est ce qu’un certificat client valide existe (si EAP-TLS) ?
5. Est ce que l’identité envoyée est celle attendue (user vs machine, format) ?
6. Est ce que l’échec arrive avant TLS, pendant TLS, ou après ?

En 10 minutes tu sais généralement dans quelle famille de panne tu es.

Exemples concrets : ce que j’ai vu en TP, et pourquoi ça échoue

Exemple A : EAP-TLS, mais le certificat client n’a pas « Client Authentication »

Tu peux avoir un certificat, avec une clé privée, qui a l’air correct. Mais s’il manque l’EKU « Client Authentication », le supplicant le rejettera.

Résultat : « aucun certificat disponible », ou « auth failed » sans détails. Dans certmgr.msc, tu vérifies l’usage amélioré de la clé.

Exemple B : PEAP, validation du serveur activée, mais tu as mis le mauvais nom

Dans les propriétés PEAP, tu peux restreindre aux serveurs RADIUS par nom. Si tu mets nps.lab.local mais que le certificat a radius.lab.local, Windows refuse.

Résultat : échec de validation serveur, même si la CA est bonne.

Exemple C : CRL injoignable

Tu es en lab, ton AD CS publie une CRL sur une URL HTTP interne, mais ton poste sur VLAN invité ne peut pas y accéder.

Selon config, la vérification de révocation échoue et donc TLS échoue.

Résultat : « auth failed », parfois après quelques secondes de tentative.

Conclusion : côté client, tu peux déjà résoudre 80 % des « auth failed »

Si je devais résumer : ne pars pas directement sur le switch. Récupère d’abord les preuves côté client.

• Windows : Wired-AutoConfig Operational + netsh lan tracing
• Linux : wpa_supplicant -dd
• Wireshark : EAPOL pour savoir où ça casse

Et ensuite seulement tu corrèles avec le RADIUS.

Si tu veux, je peux faire un deuxième billet « côté serveur NPS : lire les logs et matcher avec le client », dans le même esprit, avec un mini lab. Sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), je poste souvent des fiches TP prêtes à dérouler, donc tu peux t’abonner ou garder le lien pour la prochaine fois.

Questions fréquemment posées

Qu'est-ce que signifie le message « auth failed » lors d'une connexion 802.1X ?

Le message « auth failed » est un symptôme indiquant un échec d'authentification côté client dans un environnement 802.1X. Il ne précise pas la cause réelle, qui peut être liée au certificat, à l'identité, à la méthode EAP utilisée ou à une erreur dans la chaîne de confiance.

Comment vérifier rapidement si le problème d'authentification vient du poste client ?

Commencez par vérifier que le câble et le port sont bien connectés, que l'heure et la date du poste sont correctes (synchronisation NTP), que les certificats nécessaires sont installés et valides, et que le service supplicant (comme Wired AutoConfig sous Windows) est actif.

Quelle est la différence entre PEAP et EAP-TLS dans l'authentification 802.1X ?

PEAP utilise généralement un identifiant et un mot de passe dans un tunnel TLS sécurisé, tandis qu'EAP-TLS nécessite obligatoirement un certificat client valide pour l'authentification. Une erreur dans les certificats ou leur validation peut provoquer des échecs d'authentification.

Quels outils Windows utiliser pour diagnostiquer un échec d'authentification 802.1X ?

Sous Windows, on peut vérifier l'état 802.1X via ncpa.cpl sur la carte réseau, consulter l'Observateur d'événements dans Journaux des applications et des services > Microsoft > Windows > Wired-AutoConfig > Operational pour voir les erreurs précises, et utiliser les commandes netsh lan show interfaces et netsh lan show profiles pour obtenir des informations détaillées.

Pourquoi est-il important de vérifier l'heure et la date du poste lors d'un échec d'authentification ?

Une mauvaise configuration de l'heure ou du fuseau horaire peut entraîner l'échec de la validation des certificats SSL/TLS utilisés dans l'authentification 802.1X, car les certificats ont une période de validité strictement définie.

Que faire si l'échec d'authentification persiste après avoir vérifié le client ?

Après avoir collecté des preuves côté client (logs, état du service supplicant, certificats), il faut analyser précisément à quel moment ça casse (validation serveur, certificat client, identité ou méthode EAP) avant de contacter ou déboguer le switch authenticator ou le serveur RADIUS.