Comment tester l'authentification RADIUS étape par étape
Published
Vous êtes sur un site avec un ordinateur portable, un point d'accès et un serveur RADIUS qui « devrait déjà être prêt ». Quelqu'un a effectué un ping. Le port UDP 1812 est ouvert. Un test du tableau de bord a même affiché un voyant vert. Rien de tout cela ne vous dit si un équipement du personnel aboutit sur le VLAN du personnel, ou si un certificat révoqué obtient toujours une session.
Savoir comment tester l'authentification RADIUS relève d'une chaîne de preuves, et non d'une seule connexion. Traitez chaque Access-Accept comme une hypothèse. Vous devez toujours vérifier la méthode, les attributs, l'adresse source et le comportement du réseau lorsque le serveur, l'annuaire ou le certificat est erroné.
Commencez par une requête contrôlée. Élargissez ensuite les cas d'usage jusqu'à ce qu'aucun faux succès ne puisse dissimuler d'erreur.
Table des matières
- Envoyez votre premier test avec radtest
- Pourquoi un Access-Accept ne prouve pas l'accès au réseau
- Cas de test dont chaque déploiement RADIUS a besoin
- Mesurez la charge et la latence avec radclient
- Scénarios de défaillance, basculement et contrôles de sécurité
- Lisez les journaux pour confirmer chaque résultat de test
- Déterminez quand le RADIUS est prêt pour le déploiement
Envoyer votre premier test avec radtest
La commande que vous pouvez exécuter dans les cinq prochaines minutes est radtest testing password 127.0.0.1 0 testing123. Le manuel radtest FreeRADIUS définit cette commande comme un Access-Request contrôlé comportant cinq entrées : le nom d'utilisateur, le mot de passe, l'adresse du serveur, le NAS-Port et le secret partagé. Le protocole PAP est configuré par défaut. Ce même utilitaire peut également envoyer des requêtes CHAP, MS-CHAP ou EAP-MD5.
Exécutez la référence de base avant de modifier quoi que ce soit d'autre
- Définissez un compte de test. Placez un nom d'utilisateur et un mot de passe connus à l'emplacement où le serveur les trouvera. Vous avez besoin d'un identifiant que vous pouvez saisir sans avoir à le chercher dans un annuaire.
- Répertoriez le client. L'hôte ou le NAS depuis lequel vous envoyez les requêtes doit être présent dans
clients.confavec le secret que vous allez saisir. Une source inconnue constitue un échec différent d'un mauvais mot de passe. - Démarrez le serveur en mode de débogage. Chaque paquet et motif de rejet doit s'afficher sur le terminal. Un échec silencieux rend le test inutile.
- Envoyez les cinq paramètres. Nom d'utilisateur, mot de passe, serveur, NAS-Port, secret. Un NAS-Port égal à
0suffit pour cette première validation. - Lisez le code, puis le motif. Access-Accept signifie que le serveur a approuvé ces identifiants. Access-Reject signifie qu'il les a refusés. La sortie de débogage permet de faire la distinction entre un secret partagé incorrect, un client inconnu, des identifiants invalides et un échec de politique.
- Répétez l'opération depuis le NAS. Envoyez la même requête depuis l'adresse du point d'accès ou du commutateur, et pas seulement depuis localhost. Les clients sont généralement autorisés à la fois par leur adresse source et leur secret partagé.
L'accessibilité n'est pas le résultat final. Le paquet doit arriver et la décision d'autorisation doit être celle que vous attendiez. En cas d'acceptation, inspectez les attributs retournés tels que le VLAN, le type de service ou l'adresse encadrée (framed address). Une acceptation qui indique le mauvais VLAN n'est pas une réussite, même si le code semble correct.
Après cette acceptation de base, le même manuel répertorie huit méthodes pouvant fonctionner pour le compte d'exemple : PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC et EAP-MD5. Ne tentez pas de les utiliser toutes les huit aujourd'hui.
Règle pratique : Enregistrez un Access-Accept provenant de l'adresse NAS réelle et un Access-Reject issu d'un mot de passe erroné. Ces deux notes constituent la ligne de référence à laquelle chaque cas ultérieur sera comparé.
Pourquoi Access-Accept ne prouve pas l'accès au réseau
Un test d'infrastructure affiché vert est le faux succès que je ne validerais pas. Il montre souvent seulement qu'une requête a reçu une réponse.
Le guide de dépannage Meraki RADIUS indique que son test de tableau de bord utilise PEAP avec MS-CHAPv2. Ce test échoue, ou ne fournit aucune validation significative pour EAP-TLS, car le point d'accès ne possède pas de certificat client. Le WiFi basé sur certificat doit être testé avec un véritable supplicant disposant du bon certificat et de la bonne chaîne de confiance.
Quatre niveaux, quatre questions différentes
Transport cherche à savoir si un élément a répondu. Un dépassement de délai n'est pas un rejet.
L'authentification permet de savoir si le mot de passe ou le certificat était valide pour cette identité.
L'autorisation permet de savoir si la réponse contenait le VLAN, le rôle ou l'ACL que vous souhaitiez envoyer.
La joignabilité permet de vérifier si le point d'accès a obtenu l'adresse attendue, la politique DNS et l'accès aux ressources que ce segment doit autoriser.
La validation d'une couche ne dit rien sur les trois autres. Ces mêmes recommandations Meraki, lues en parallèle du comportement EAP de FreeRADIUS, décrivent un test EAP-TLS réussi comme un échange multipaquet de Access-Request et Access-Challenge, suivi d'un accès réseau client réel. Un simple test de connectivité ne constitue pas ce test.
Vérifiez le nom de serveur approuvé par le demandeur, la chaîne de CA, l'expiration du certificat et l'horloge de l'appareil. Dérive horlogère fait échouer un certificat valide. Supposons qu'un ordinateur portable d'un employé s'authentifie, puis se retrouve sur le réseau VLAN par défaut au lieu du segment réservé au personnel. L'acceptation était authentique. Le placement réseau était incorrect. C'est le raté que la plupart des listes de contrôle ne consignent jamais.
Conservez des lignes distinctes pour les utilisateurs par mot de passe, les appareils EAP-TLS, les identités xPSK et les politiques basées sur l'annuaire. Une acceptation PAP ne doit pas remplacer une jonction par certificat.
Tester EAP-TLS sur un appareil de secours
- Émettre un certificat client de test à partir de la même autorité de certification (CA) que celle approuvée par le serveur.
- Installer le certificat et la chaîne de CA sur un ordinateur portable ou un téléphone de réserve.
- Confirmer que le demandeur valide le nom de serveur que vous avez configuré.
- Se connecter et capturer l'échange de défi (challenge), et non une simple requête d'un seul paquet.
- Confirmer que la session se termine sur le VLAN attendu avec un accès réseau réel.
Une vue synthétique de cet échange facilite l'identification de la capture lorsque votre propre trace contient du bruit.
Cas de test indispensables pour chaque déploiement RADIUS
Des identifiants valides peuvent générer une réponse Access-Accept alors même que l'utilisateur atterrit sur le mauvais réseau. Testez chaque couche séparément : la gestion de la requête, l'authentification, les attributs d'autorisation et l'accès réel du point de terminaison. Le guide de test de performance FreeRADIUS couvre la charge ainsi que l'exactitude. Incluez également des cas négatifs : des identifiants invalides doivent renvoyer Access-Reject, tandis que des requêtes mal formées, un NAS non reconnu et un secret partagé incorrect ne doivent pas permettre de connexion réussie.
Le flux de travail radtest est établi depuis longtemps et utilise toujours les cinq mêmes entrées. Pour les méthodes en tunnel, testez le serveur d'authentification interne séparément sur le port UDP 18120. Effectuez un test interne MS-CHAP lorsque PEAP est la méthode externe. Cela permet d'isoler si une défaillance provient de l'échange EAP externe, de la configuration du certificat ou du TLS, ou de la vérification des identifiants internes.
Un message Access-Accept constitue une hypothèse à vérifier et non la preuve d'un accès réseau correct. Le guide d'implémentation FreeRADIUS décrit comment un NAS peut ignorer un attribut VLAN non pris en charge ou associer un attribut manquant à un VLAN par défaut. Vérifiez les attributs retournés, puis contrôlez l'adresse du point de terminaison, le VLAN, la liste de contrôle d'accès (ACL), la politique DNS et la joignabilité. EAP-MD5 ne fournit pas les éléments de clé nécessaires au sans-fil ; une acceptation EAP-MD5 ne garantit donc pas la compatibilité WiFi. Utilisez-le uniquement pour des tests filaires limités.
Déterminez les segments prévus avant d'effectuer les tests d'autorisation ; le WiFi contrôle d'accès explique comment structurer cette politique.
Neuf lignes constituant le strict minimum
| Cas de test | Procédure d'exécution | Résultat attendu |
|---|---|---|
| Acceptation de référence | Exécutez radtest avec un compte de test valide depuis l'adresse IP du NAS |
Access-Accept avec l'attribut VLAN attendu ; confirmez que le point d'accès aboutit sur cet attribut VLAN |
| Mot de passe incorrect | Exécutez radtest avec un mot de passe incorrect |
Access-Reject avec un motif enregistré dans les journaux |
| Secret partagé incorrect | Envoyez la requête depuis un client configuré avec un secret ne correspondant pas | Aucun Access-Accept ; erreur de secret visible dans la sortie de débogage |
| NAS inconnu | Envoyez la requête depuis une adresse IP non définie comme client | Abandonné ou rejeté et journalisé |
| Appareil EAP-TLS valide | Connectez un vrai demandeur d'accès (supplicant) avec un certificat valide et une chaîne de confiance | Access-Accept et attribut VLAN correct pour son groupe ; confirmez l'accès réseau depuis l'appareil |
| Certificat expiré ou révoqué | Connectez un appareil doté d'un certificat expiré ou révoqué | Access-Reject, sans basculement vers un réseau par défaut |
| Changement de groupe dans l'annuaire | Déplacez l'utilisateur de test dans un autre groupe, puis réauthentifiez-le | Le VLAN ou le rôle change pour correspondre au nouveau groupe, ou l'accès est refusé |
| Serveur principal indisponible | Bloquez le port UDP 1812 vers le serveur principal ou arrêtez-le | Basculement vers le serveur secondaire dans le délai imparti, avec la même politique appliquée |
| Début et fin de comptabilité (Accounting) | Démarrez une session, puis terminez-la | Les enregistrements de début et de fin correspondent à la session |
Pour chaque ligne, enregistrez l'arrivée de la demande, le code de réponse, la latence aller-retour, la politique sélectionnée, les attributs retournés, ainsi que le début et la fin de la comptabilisation. Répétez chaque test afin de détecter les pertes UDP intermittentes. Une seule exécution propre peut rater un mauvais VLAN ou une décision de politique incohérente.
Une acceptation qui place le client sur le mauvais réseau est un test échoué.
Mesurer la charge et la latence avec radclient
Une acceptation sans bruit masque les files d'attente. Les tests de charge nécessitent un outil conçu pour les traitements par lots, et non une simple connexion supplémentaire.
- Créez un fichier d'authentification contenant des noms d'utilisateur et des mots de passe aléatoires. Mélangez des entrées valides et non valides pour que les rejets soient comptabilisés et non traités comme des interférences.
- Envoyez le fichier et chronométrez le lot à l'aide de la commande Unix
timependant queradclientsollicite le serveur. - Enregistrez les chiffres bruts. Total des demandes, acceptations, rejets, dépassements de délai, réponses d'erreur et temps écoulé.
- Calculez les taux. Le taux d'acceptation doit correspondre à la part valide du fichier. Le taux de rejet doit correspondre à la part non valide. Calculez également la latence moyenne et les percentiles de latence.
- Répétez l'opération pendant les heures de pointe. Une heure d'arrivée le matin ou le début des cours révélera des phénomènes de mise en attente qu'un test en laboratoire à l'heure du déjeuner ne montrera jamais.
| Indicateur | Méthode de calcul | Cible |
|---|---|---|
| Demandes totales | Nombre de lignes envoyées depuis le fichier d'authentification | Équivaut à la taille du fichier |
| Taux d'acceptation | Acceptations divisées par le nombre total de demandes | Correspond à la part valide du fichier |
| Taux de rejet | Rejets divisés par le nombre total de demandes | Correspond à la part non valide du fichier |
| Dépassements de délai et erreurs | Nombre de réponses sans réponse et d'erreurs lors de l'exécution | Zéro sur un parcours sans erreur |
| Latence moyenne | Temps de réponse moyen pour l'ensemble des demandes | Conforme à votre cible de latence lors des pics d'activité |
| Temps écoulé | Temps Unix mesuré pour l'ensemble du lot | Stable d'une exécution à l'autre |
Séparer le tunnel du magasin de comptes
Si le taux d'acceptation est inférieur à la proportion valide, n'incriminez pas la "charge" avant de savoir quelle moitié a échoué. Pour PEAP, testez la méthode interne de manière isolée avec une requête MS-CHAP adressée au serveur interne. Une acceptation interne accompagnée d'une jonction externe défaillante pointe vers des certificats ou des paramètres TLS incorrects. Handshake externe qui échoue lors du contrôle interne indique un problème au niveau du répertoire de comptes, du hachage de mot de passe ou du groupe attendu par la politique.
Conservez ces temps de réponse dans le même journal que les résultats fonctionnels. Une modification ultérieure du firmware ou de l'annuaire devra être comparée à cette ligne de référence, et non à une impression selon laquelle « cela semblait plus lent ».
Si les délais d'expiration n'augmentent qu'aux heures de pointe, corrigez la capacité ou le chemin d'accès avant d'ajouter des sites. Un serveur correct mais lent échouera quand même face aux clients qui abandonnent en premier.
Scénarios d'échec, basculement et vérifications de sécurité
Un échange fonctionnel peut tout de même être risqué. Le dépannage qui se limite à vérifier si UDP 1812 a reçu une réponse s'arrête trop tôt.
Le bulletin de sécurité 2025 de Juniper décrit l'exposition à Blast-RADIUS dans l'authentificateur de réponse RFC 2865. Un attaquant local en mesure de modifier le trafic peut potentiellement transformer une réponse valide en une autre réponse grâce à une collision de préfixe choisi MD5. La mention « Authentification réussie » ne constitue pas une preuve que le déploiement est protégé.
Vérifications à inclure dans la même exécution que le basculement
Protégez le chemin d'accès là où la plateforme le permet. Confirmez que la manipulation sur le chemin est bloquée et que la validation de Message-Authenticator est appliquée aux paquets qui la requièrent.
Désactivez les méthodes faibles. Les types EAP obsolètes doivent être désactivés et non laissés « au cas où ». Si vous hésitez encore entre les méthodes externes par certificat et par mot de passe, comparez-les dans EAP-TLS vs PEAP avant de les laisser toutes les deux activées.
Provoquez intentionnellement une défaillance du serveur. Chaque scénario ci-dessous doit présenter le comportement de défaillance sécurisée (fail-closed) ou de repli contrôlé prévu, ainsi qu'une ligne de journal, une alerte et une expérience utilisateur que vous pouvez expliquer à un responsable de site.
| Scénario de défaillance | Comment le déclencher | Condition de réussite |
|---|---|---|
| Délai d'attente dépassé | Bloquer le UDP 1812 vers le serveur | Fail closed ou basculement contrôlé, journalisé et alerté |
| Access-Reject | Utiliser un mauvais mot de passe | Accès refusé sans réseau de secours |
| Certificat expiré | Appareil avec un certificat expiré | Access-Reject sans VLAN par défaut |
| Certificat révoqué | Appareil avec un certificat révoqué | Access-Reject sans VLAN par défaut |
| IP source NAS inconnue | Envoyer depuis une adresse non définie | Ignoré ou rejeté et journalisé |
| Secret partagé incorrect | Secret discordant sur le client | Pas d'Access-Accept et erreur de secret dans la sortie de débogage |
| Annuaire inaccessible | Interrompre la connectivité à l'annuaire | Refus ou basculement contrôlé selon la politique |
| Réponse d'autorisation différée | Ajouter un délai à la réponse d'autorisation | Délai d'attente géré sans accès ouvert |
Ce que le basculement régional doit préserver
La réponse d'un autre serveur ne garantit pas la cohérence des politiques. Lorsque vous arrêtez le serveur principal, comparez le VLAN, les limites de bande passante, le statut de révocation et les attributs d'audit du serveur secondaire avec ceux du serveur principal. Un invité qui bascule dans un segment réservé au personnel constitue un test échoué, même si la connexion a été rapide.
Marquez tout scénario qui bascule sur un accès ouvert comme ayant échoué, que l'utilisateur parvienne ou non à se connecter. Inscrivez chaque résultat dans le même journal de test que la référence fonctionnelle afin qu'une modification ultérieure du basculement soit évidente.
Consulter les journaux pour confirmer chaque résultat de test
Chaque test doit laisser une trace que vous pouvez associer à un identifiant de test ou à un compte connu. Sur un parc très fréquenté, cette étiquette est le moyen de retrouver votre exécution sans avoir à faire défiler la matinée de tous les autres.
Pour chaque authentification, alignez ces champs :
- Identité et appareil : qui ou quoi a rejoint le réseau, et non une simple adresse MAC que vous espérez être la vôtre.
- Méthode : EAP-TLS, PEAP ou un PSK individuel. Une méthode que vous n'avez pas déployée constitue une anomalie.
- Emplacement : point d'accès, SSID et site.
- Décision : VLAN et rôle renvoyé, ou raison du rejet.
- Heure : horodatage situé dans la plage temporelle que vous avez testée.
Notre journal d'authentification est conçu pour cette correspondance. Une seule requête sur l'ensemble du parc affiche chaque acceptation et chaque rejet avec l'identité, l'équipement, l'état d'enrôlement, la méthode, le point d'accès, le SSID, le site, le VLAN, le rôle, le motif et les horodatages. Utilisez-le lorsqu'un site compte de nombreux points d'accès et que vous devez déterminer si le même échec se produit partout ou uniquement sur un seul contrôleur.
Trois schémas indiquant que les notes sont erronées
La raison ne correspond pas au test. Vous avez envoyé un mauvais mot de passe et le journal indique un client inconnu. Vous avez testé la mauvaise chose, ou deux erreurs se sont superposées.
L'acceptation nomme le VLAN par défaut. Les identifiants ont fonctionné. Pas le placement. Ne fermez pas le ticket.
L'accounting a démarré et ne s'est jamais arrêté. L'enregistrement de la session est incomplet, vous ne pouvez donc pas prouver que le client a quitté le réseau au moment où vous le pensez. Comparez le début et la fin avec la session que vous avez exécutée, et non avec celle d'un utilisateur à proximité.
Définissez une alerte pour les pics de rejets pendant la fenêtre de test afin qu'un secret partagé incorrect ne ressemble pas à « des erreurs de saisie des utilisateurs ». Conservez l'extrait de journal avec les notes de test. Cet extrait constitue la preuve d'audit lorsque quelqu'un vous demande, des semaines plus tard, ce que vous avez prouvé.
Déterminer quand le déploiement de RADIUS est prêt
Ne passez en production que lorsque les preuves franchissent cinq étapes. L'assurance d'un ingénieur n'en fait pas partie.
- Chaque ligne de la matrice est validée sur chaque type de NAS déployé, y compris pour chaque SSID ou politique d'accès que vous souhaitez conserver.
- Le basculement conserve le même comportement de VLAN, de politique et de révocation que le serveur primaire. Un second serveur répondant avec un rôle différent échoue à cette étape de validation.
- Aucun scénario de défaillance ne doit laisser l'accès ouvert. Un mot de passe incorrect, un annuaire indisponible, un certificat expiré ou une réponse différée ne doivent en aucun cas placer l'utilisateur sur un réseau non restreint.
- La charge reste conforme à votre cible de latence lors des pics d'activité, avec un taux d'acceptation correspondant à la part valide du fichier de test.
- Les journaux indiquent le motif attendu et le VLAN pour chaque test considéré comme réussi.
Patientez avant de généraliser le déploiement tant que ces cinq conditions ne sont pas remplies sur un site réel, et pas seulement en laboratoire VLAN.
Nous vous permettons de le prouver d'abord sur un seul site. Déployez les nouveaux réseaux ouverts, sécurisés et xPSK sur les points d'accès déjà en service sur ce site, aux côtés du réseau utilisé actuellement, puis évaluez le résultat à partir des tickets et des preuves d'audit avant de modifier d'autres sites. Pendant ce pilote, le journal doit répondre à deux questions sans nécessiter de réunion : quels appareils ont rejoint le réseau sur quelle VLAN, et quelle raison d'acceptation ou de rejet s'est manifestée le plus souvent.
N'étendez le périmètre que si les tickets et l'extrait d'audit ne montrent aucun rejet inattendu et aucun appareil sur le mauvais segment. Conservez la matrice en tant que suite de régression permanente. Exécutez-la à nouveau après chaque renouvellement de certificat, mise à jour de firmware ou modification d'annuaire, par rapport à la même référence, avant que les utilisateurs ne voient le changement. Pour savoir comment concevoir ce site pilote, partez de la WiFiconception réseau et testez la architecture que vous prévoyez de conserver, et non une architecture temporaire SSID que vous supprimerez la semaine suivante.
Purple Access vous offre du RADIUS cloud qui place chaque appareil sur le réseau ouvert, sécurisé ou xPSK selon son identité, avec le VLAN et la raison du rejet visibles dans le journal d'authentification. Si vous souhaitez exécuter ce plan de test sur les points d'accès dont vous disposez déjà, commencez par un premier site et analysez le résultat avant d'étendre le déploiement. Visitez Purple Access et dotez votre premier site d'une base de référence défendable.
