Rejet RADIUS contre absence de réponse : quand la connexion locale s’exécute

Conserver un compte local d’urgence n’en fait pas une seconde chance pour chaque connexion rejetée. Dans le modèle AAA de Cisco IOS et IOS XE, cette base n’est consultée que lorsque la méthode précédente échoue d’une manière précise, et un serveur RADIUS qui répond par un rejet n’a pas échoué de cette manière. Le compte local couvre une méthode injoignable, pas une méthode refusée. Croire le contraire transforme une décision de politique en une chasse à une panne de serveur qui n’existe pas.

Pourquoi la liste des méthodes ressemble à une échelle

Une ligne comme aaa authentication login default group radius local se lit de gauche à droite, et la plupart des gens la lisent comme essayez RADIUS, puis essayez la base locale. La syntaxe invite à cette lecture parce qu’une liste est une séquence. La sémantique est plus étroite : la liste nomme des méthodes d’authentification, et la règle de passage d’une méthode à la suivante dépend du résultat de la méthode précédente, non du fait de donner à l’utilisateur une nouvelle tentative.

Une méthode qui renvoie une erreur et une méthode qui renvoie un échec mènent ici à des résultats différents. Le rejet est une réponse, car le serveur a traité les identifiants et a dit non, et la liste s’arrête là. Un serveur injoignable, une requête expirée ou une réponse qui ne peut pas être validée est le cas qui laisse la méthode suivante s’exécuter, et seulement là où la gestion des échecs de la plateforme est configurée ainsi. C’est pourquoi le conseil classique d’ajouter local fonctionne lors des pannes et ne fait rien pour les mots de passe erronés. Lisez plutôt la liste comme deux questions : quelle méthode répond, et ce que la plateforme considère comme une réponse.

Séparez la liste des méthodes du groupe de serveurs

La liste des méthodes est une couche et le groupe de serveurs en est une autre. Le mot-clé group radius nomme un groupe dont l’ordre interne, les nouvelles tentatives, les délais et la détection de serveur mort appartiennent au groupe, tandis qu’une méthode locale est une couche au-dessus. Régler quoi que ce soit à l’intérieur du groupe ne peut donc pas transformer un rejet en repli. Confirmez la liste à laquelle le service fait réellement référence avant de modifier l’une ou l’autre couche.

Affichez la configuration AAA et lisez la liste vers laquelle le service pointe, pas la valeur par défaut que vous croyez avoir écrite. Faites-le depuis l’équipement sur lequel le service se termine réellement.

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

La table des serveurs indique l’état et les compteurs de chaque entrée, ce qui vous dit si la passerelle a atteint le serveur pendant la tentative. Un serveur marqué actif avec un compteur de requêtes croissant a répondu, donc la connexion échouée est une décision et non un problème de connectivité.

Lisez la réponse avant le journal

Le code de réponse nomme le résultat et implique sa propre étape suivante. Access-Reject signifie que le backend a pris une décision, donc la preuve utile est la politique qui a correspondu et l’état du compte derrière elle. Access-Challenge signifie que l’échange veut une autre étape prise en charge, comme un second facteur, et un repli local sauterait silencieusement quelque chose que la politique exige.

Reproduisez une tentative avec un compte de test désigné afin que la réponse et l’enregistrement du backend puissent être comparés au même horodatage. Utilisez un identifiant que vous êtes autorisé à faire échouer.

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

Une entrée de client RADIUS absente ou non reconnue est une cause fréquente de délai silencieux, car le serveur reçoit la requête, ne trouve aucune définition de client correspondante et la rejette sans répondre. Un désaccord de secret partagé ressemble aussi généralement à un délai d’attente, car la réponse échoue à la validation et est écartée. Rien de tout cela ne ressemble à Access-Reject, et rien de tout cela n’est réparé en ajoutant un compte local. Vérifiez la définition du client et le secret des deux côtés avant de toucher à la liste des méthodes.

Pourquoi le compte local n’a jamais rien prouvé

Un compte placé après un groupe dans la liste prouve seulement que quelqu’un a prévu une panne. Il ne dit rien sur le fait que le plan fonctionne, car le cas qui l’exerce est le cas que personne ne répète : le serveur a cessé de répondre. Une connexion locale jamais atteinte en fonctionnement normal peut porter un mot de passe expiré ou un état verrouillé pendant des mois sans que personne ne le remarque.

L’accès d’urgence est une décision de conception, pas un effet secondaire de la configuration. Donnez-lui son propre compte restreint, son propre responsable et une procédure de récupération écrite, et intégrez la rotation du secret partagé dans cette procédure. Conserver un mot de passe local du même nom pour chaque utilisateur central est le schéma qui réintroduit silencieusement l’accès que vous pensiez avoir supprimé.

Le test qui compte est délibéré, et il interrompra les connexions pendant son exécution. C’est exactement pourquoi il appartient à une fenêtre planifiée avec l’étape de retour écrite en premier.

Vérifiez le chemin de repli pendant une fenêtre de maintenance

Ordonnez le test de façon à ne jamais retirer le dernier chemin d’entrée. Confirmez d’abord un chemin de gestion indépendant, puis l’accès normal autorisé, puis un rejet délibéré, puis le comportement de panne approuvé. Ces quatre cas ont des résultats attendus différents, et les fusionner en un seul test est la façon dont les gens se verrouillent hors d’un équipement dont ils ont encore besoin.

Exécutez chaque vérification depuis une session console ou un chemin hors bande, afin qu’une erreur ne puisse pas fermer la session dans laquelle vous travaillez. La console est le seul chemin qui ne dépend pas du composant testé.

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

Ensuite, restaurez la configuration précédente et confirmez que les compteurs bougent à nouveau lors de la prochaine connexion réelle. Si le rejet délibéré produit une connexion locale au lieu d’un rejet, alors la liste ou la gestion des échecs n’est pas ce que vous croyiez, et cette découverte prime sur la panne avec laquelle vous avez commencé. Écrivez le résultat dans l’enregistrement de changement à côté des noms de comptes et de la date du test.