Un échec de connexion 802.1X ou NAC filaire peut venir du client, de l'équipement d'accès qui applique le port, ou du serveur RADIUS derrière — et le code de raison pointe à chaque fois vers un endroit différent. Voici la chaîne à vérifier dans l'ordre, à quoi ressemble l'échange EAP à chaque saut, les vrais codes d'erreur et la CLI à consulter, et en quoi cela diffère d'une connexion Portal ou d'un échec d'authentification sans fil.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
802.1X authentifie le port lui-même, avant même que le client n'obtienne une adresse IP — c'est exactement pourquoi cela casse différemment de Portal ou du sans-fil.
Sur un port de commutateur ou de pare-feu filaire exécutant 802.1X, rien au-dessus de la couche 2 ne s'est encore produit lorsque l'échange démarre — pas de DHCP, pas d'adresse IP, pas de redirection HTTP. C'est la différence fondamentale avec une connexion Portal, qui authentifie un appareil qui a déjà une adresse et essaie d'atteindre une page web captée. Cela signifie aussi que la chaîne qui doit fonctionner est courte et stricte : le supplicant 802.1X du client, l'équipement d'accès qui applique le port et relaie vers le serveur RADIUS, et le serveur RADIUS/AAA lui-même qui décide accept ou reject.
Voici cette chaîne, à quoi ressemble l'échange EAP à chaque saut, les codes d'erreur d'authentification d'accès et la CLI qui expliquent réellement la plupart des tickets, où se situe la question de secours/repli, et en quoi cela diffère d'un échec de connexion Portal ou d'un problème spécifique au sans-fil.
Client, équipement d'accès, serveur RADIUS — trois maillons, et la séquence des messages EAP entre eux indique lequel a réellement cassé.
Lire cette séquence de haut en bas avant de toucher à toute configuration indique si le client n'a même jamais envoyé EAPOL-Start, si l'équipement d'accès n'a jamais relayé vers RADIUS, ou si RADIUS a répondu mais avec un rejet.
Les légendes du schéma restent en anglais pour la clarté technique.
Les étapes 1 à 3 se produisent avant même que l'équipement d'accès n'ait parlé à RADIUS — si le client ne dépasse jamais l'étape 2 ou 3, regardez le client et le port, pas le serveur RADIUS. Les étapes 4 à 9 sont là où une politique de domaine d'authentification, un compte verrouillé, ou un identifiant erroné se manifeste par un Access-Reject. L'étape 11 est celle que l'on oublie : un Access-Accept à l'étape 9 ne garantit pas que l'utilisateur reste en ligne — un échec de comptabilité ensuite peut encore le déconnecter.
Trois vérifications, dans l'ordre — qui est réellement en ligne, pourquoi ceux qui ne le sont pas ont été déconnectés, et si le compte lui-même est le problème.
[HUAWEI] display access-user interface 10ge 1/0/1
Total: 1
UserID Username IP address MAC Status
32984 lulu 192.85.11.2 00e0-fc55-0102 Success
<HUAWEI> display authentication-profile configuration name p1
...
Authentication mode : multi-authen
<HUAWEI> display domain name test
Domain-name : test
Domain-state : Block
// Block forces every user in this domain offline — not a credential problem
<HUAWEI> display remote-user authen-fail blocked
// lists remote accounts currently locked out after repeated authentication failuresDe vrais codes d'erreur d'authentification d'accès, ce qu'ils signifient réellement, et la commande qui le confirme.
SYMPTÔMEEAPOL client timeout (code d'erreur 206) : le client ne répond tout simplement pas à la requête EAP.
CAUSESur un échec d'authentification sans fil, le même code est très souvent un problème de signal faible. Sur un port filaire, il n'y a pas de liaison radio à incriminer — c'est presque toujours le supplicant 802.1X lui-même : non exécuté, mal configuré, ou un défaut de pilote côté client.
SOLUTIONConfirmez que le supplicant fonctionne réellement et est correctement configuré sur le client avant de toucher au port ou au serveur RADIUS ; ne retentez l'authentification qu'une fois le côté client confirmé sain.
SYMPTÔMERemote user is blocked (code d'erreur 519) et Authenticate fail (code d'erreur 147) : un compte distant se retrouve verrouillé après trop de tentatives échouées dans la fenêtre de nouvelle tentative, et tout appareil qui l'utilise encore échoue à partir de là.
CAUSESi plusieurs clients 802.1X sont configurés pour s'authentifier avec le même compte, un appareil avec un mot de passe périmé ou erroné peut verrouiller ce compte pour tous les autres appareils qui l'utilisent — un simple champ de mot de passe erroné se transforme en panne à l'échelle du bureau.
SOLUTIONVérifiez display remote-user authen-fail blocked, débloquez le compte avec remote-user authen-fail unblock une fois l'identifiant correct confirmé, et — si les comptes partagés sont inévitables — désactivez le verrouillage par compte pour ce scénario avec undo access-user remote authen-fail.
<HUAWEI> display remote-user authen-fail blocked
[HUAWEI-aaa] remote-user authen-fail unblock
[HUAWEI-aaa] undo access-user remote authen-failSYMPTÔMEDomain policy failed force user to offline (code d'erreur 371) : des utilisateurs avec des identifiants entièrement corrects ne peuvent toujours pas se connecter.
CAUSELe domaine d'authentification lui-même est en état Block — un interrupteur au niveau du domaine qui court-circuite entièrement les vérifications d'identifiants individuelles, et facile à manquer car le symptôme ressemble exactement à un mot de passe erroné.
SOLUTIONVérifiez display domain name <domain> pour le champ Domain-state avant de dépanner des comptes individuels ; réactivez-le en vue de domaine AAA avec state active.
SYMPTÔMEBeyond access limit (code d'erreur 57) : un nouvel appareil ne peut pas se connecter sur un port qui en a déjà un authentifié.
CAUSELes modes single-terminal et multi-share n'autorisent qu'un seul appareil en ligne à la fois sur ce port ; single-voice-with-data autorise exactement un appareil vocal et un appareil de données. Un port avec un téléphone IP en chaîne avec un PC, ou plusieurs terminaux derrière un petit commutateur non géré, a besoin de multi-authen — tout autre mode rejettera le second appareil par conception, pas par défaut.
SOLUTIONVérifiez ensemble display authentication-profile configuration et display access-user interface avant de supposer un problème RADIUS ou de licence ; passez le profil en multi-authen avec un max-user-number approprié si le port doit réellement porter plus d'un ou deux appareils authentifiés.
SYMPTÔMEEAPOL client user name is different (code d'erreur 420) : le client relance l'authentification en cours de session avec un nom d'utilisateur différent de celui du départ.
CAUSECertains logiciels clients ou tentatives manuelles changent de compte entre les essais sans se déconnecter complètement au préalable — l'équipement d'accès traite la discordance comme une condition de panne plutôt qu'une nouvelle connexion propre.
SOLUTIONAssurez-vous que le client se déconnecte proprement (EAPOL-Logoff) avant de retenter avec un compte différent, plutôt que de changer d'identifiants en cours de session.
SYMPTÔMEAccounting server no response (code d'erreur 410) : l'utilisateur s'authentifie avec succès puis est déconnecté peu après.
CAUSEL'authentification et la comptabilité sont des échanges RADIUS distincts. Un chemin d'authentification qui fonctionne avec une liaison de comptabilité en panne ou inaccessible — un serveur différent, une liaison différente, un mode de défaillance entièrement différent — force quand même l'utilisateur hors ligne même si ses identifiants étaient corrects.
SOLUTIONFaites un Ping spécifiquement vers le serveur de comptabilité et vérifiez ses propres journaux et son statut — ne supposez pas qu'une panne au stade de la comptabilité est le même problème que le stade d'authentification qui a déjà réussi.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Portal authentifie un appareil qui a déjà une adresse IP et essaie d'atteindre une page web captée via HTTP — les modes d'échec sont une page qui ne s'affiche pas, ou RADIUS approuvant une connexion que le client voit pourtant encore comme rejetée. 802.1X/NAC authentifie le port lui-même à la couche 2, avant même que le DHCP ne s'exécute, en utilisant EAPOL et EAP plutôt qu'une page web. Si le client n'obtient jamais du tout d'adresse IP et qu'il n'y a pas de page de connexion en jeu, vous dépannez du 802.1X, pas du Portal — voir L'authentification Portal échoue sur les routeurs d'entreprise pour la chaîne spécifique à Portal.
Les codes d'erreur d'authentification d'accès sont en grande partie partagés entre filaire et sans fil — le même code EAPOL client timeout, par exemple, peut se déclencher dans les deux cas. La différence est la cause : sur le sans-fil, ce code est très souvent un problème de signal faible ou d'itinérance spécifique à la liaison radio ; sur un port filaire, il n'y a pas de radio à incriminer, donc le même symptôme pointe presque toujours vers le supplicant du client ou le câble/port lui-même. Diagnostiquez les deux différemment même lorsque le code d'erreur correspond.
Cela se produit lorsque plusieurs clients 802.1X sont configurés pour s'authentifier avec le même compte partagé. Suffisamment de tentatives échouées dans la fenêtre de nouvelle tentative verrouille ce compte selon display remote-user authen-fail blocked, et tout autre appareil qui l'utilise encore échoue à partir de là — pas à cause d'un problème de leur côté. Débloquez le compte avec remote-user authen-fail unblock, et envisagez undo access-user remote authen-fail si les comptes partagés sont inévitables dans votre environnement.
Le modèle de domaine d'authentification sépare le schéma d'authentification du schéma de comptabilité, ce qui rend possible un schéma d'authentification local, indépendant de RADIUS, comme repli pour un domaine donné. Le mécanisme exact d'échappement/contournement pour un équipement d'accès spécifique est une fonctionnalité de plateforme commutateur ou AC en dehors de ce que ce matériel source axé sur le pare-feu couvre en profondeur — voir la note sur les limites honnêtes ci-dessous avant de supposer qu'une commande spécifique existe sur votre équipement.
L'authentification et la comptabilité sont deux échanges RADIUS distincts. Un Access-Accept confirme que les identifiants étaient corrects ; il ne garantit pas que la liaison de comptabilité est saine. Accounting server no response (code d'erreur 410) déconnecte l'utilisateur par la suite même si l'authentification elle-même a réussi — vérifiez spécifiquement le serveur de comptabilité et la liaison vers lui, pas à nouveau le chemin d'authentification.
Cette note s'appuie sur la référence des codes d'erreur d'authentification d'accès partagée de Huawei et la CLI AAA/domaine, recoupée entre le matériel de maintenance HiSecEngine USG6000F/USG6000G/USG12000 et USG6000E/USG9500. Elle couvre la chaîne client-équipement d'accès-RADIUS, l'échange EAP, et les codes d'erreur et commandes que la référence montre en pratique. Elle ne couvre pas en profondeur le mécanisme de VLAN d'échappement/contournement spécifique à un fournisseur pour un serveur RADIUS inaccessible, ni le comportement d'itinérance sans fil spécifique à un AC — ceux-ci figurent dans la propre documentation d'une plateforme commutateur ou AC.
Indiquez-nous le code d'erreur ou le symptôme de display aaa online-fail-record, et s'il s'agit de filaire ou de sans-fil — nous vous aiderons à l'interpréter.