Rechazo de RADIUS frente a sin respuesta: cuándo se ejecuta el inicio de sesión local

Mantener una cuenta local de emergencia no la convierte en una segunda oportunidad para cada inicio de sesión rechazado. En el modelo AAA de Cisco IOS e IOS XE, esa base de datos solo se consulta cuando el método anterior falla de una forma concreta, y un servidor RADIUS que responde con un rechazo no ha fallado de esa forma. La cuenta local cubre un método inaccesible, no uno rechazado. Creer lo contrario convierte una decisión de política en la búsqueda de un fallo de servidor que no existe.

Por qué la lista de métodos parece una escalera

Una línea como aaa authentication login default group radius local se lee de izquierda a derecha, y la mayoría la lee como pruebe RADIUS y luego pruebe la base de datos local. La sintaxis invita a esa lectura porque una lista es una secuencia. La semántica es más estrecha: la lista nombra métodos de autenticación, y la regla para pasar de uno al siguiente depende del resultado del método anterior y no de dar al usuario otro intento.

Un método que devuelve un error y un método que devuelve un fallo llevan aquí a resultados distintos. El rechazo es una respuesta, porque el servidor procesó las credenciales y dijo que no, y la lista se detiene ahí. Un servidor inaccesible, una solicitud caducada o una respuesta que no se puede validar es el caso que deja ejecutar el método siguiente, y solo donde el manejo de fallos de la plataforma está configurado así. Por eso el consejo clásico de añadir local funciona en caídas y no hace nada con contraseñas incorrectas. Lea la lista en cambio como dos preguntas: qué método responde y qué cuenta la plataforma como respuesta.

Separe la lista de métodos del grupo de servidores

La lista de métodos es una capa y el grupo de servidores es otra. La palabra clave group radius nombra un grupo cuyo orden interno, reintentos, tiempos de espera y detección de servidor muerto pertenecen al grupo, mientras que un método local es una capa por encima. Por tanto, ajustar cualquier cosa dentro del grupo no puede convertir un rechazo en un respaldo. Confirme a qué lista hace referencia realmente el servicio antes de cambiar cualquiera de las dos capas.

Imprima la configuración AAA y lea la lista a la que apunta el servicio, no el valor por defecto que recuerda haber escrito. Hágalo desde el dispositivo en el que el servicio termina realmente.

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

La tabla de servidores informa del estado y los contadores de cada entrada, lo que le dice si la puerta de enlace alcanzó el servidor durante el intento. Un servidor marcado como activo con un contador de solicitudes creciente ha estado respondiendo, así que el inicio de sesión fallido es una decisión y no un problema de conectividad.

Lea la respuesta antes que el registro

El código de respuesta nombra el resultado e implica su propio paso siguiente. Access-Reject significa que el backend tomó una decisión, así que la evidencia útil es la política que coincidió y el estado de la cuenta detrás de ella. Access-Challenge significa que el intercambio quiere otro paso admitido, como un segundo factor, y el respaldo local se saltaría en silencio algo que la política exige.

Reproduzca un intento con una cuenta de prueba designada para que la respuesta y el registro del backend puedan compararse en la misma marca de tiempo. Use una credencial que se le permita hacer fallar.

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

Una entrada de cliente RADIUS ausente o no reconocida es una causa habitual de un tiempo de espera silencioso, porque el servidor recibe la solicitud, no encuentra ninguna definición de cliente que coincida y la descarta sin responder. Un desajuste del secreto compartido también suele parecer un tiempo de espera, porque la respuesta falla la validación y se descarta. Nada de eso se parece a Access-Reject, y nada de eso se repara añadiendo una cuenta local. Compruebe la definición del cliente y el secreto en ambos lados antes de tocar la lista de métodos.

Por qué la cuenta local nunca demostró nada

Una cuenta que está después de un grupo en la lista solo demuestra que alguien planificó una caída. No dice nada sobre si el plan funciona, porque el caso que lo pone a prueba es el caso que nadie ensaya: el servidor dejó de responder. Un inicio de sesión local al que nunca se llega en funcionamiento normal puede arrastrar una contraseña caducada o un estado bloqueado durante meses sin que nadie lo note.

El acceso de emergencia es una decisión de diseño, no un efecto secundario de la configuración. Déle su propia cuenta restringida, su propio responsable y un procedimiento de recuperación escrito, e incluya la rotación del secreto compartido en ese procedimiento. Mantener una contraseña local con el mismo nombre para cada usuario central es el patrón que reintroduce en silencio el acceso que creía haber eliminado.

La prueba que importa es deliberada, e interrumpirá inicios de sesión mientras se ejecuta. Es exactamente por eso que pertenece a una ventana programada con el paso de reversión escrito primero.

Compruebe la ruta de respaldo durante una ventana de mantenimiento

Ordene la prueba de modo que nunca elimine la última vía de entrada. Confirme primero una ruta de gestión independiente, después el acceso normal permitido, después un rechazo deliberado, después el comportamiento de caída aprobado. Esos cuatro casos tienen resultados esperados distintos, y juntarlos en una sola prueba es como la gente se deja fuera de un dispositivo que todavía necesita.

Ejecute cada comprobación desde una sesión de consola o desde una ruta fuera de banda, para que un error no pueda cerrar la sesión en la que trabaja. La consola es la única ruta que no depende del componente que se prueba.

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

Después, restaure la configuración anterior y confirme que los contadores vuelven a moverse en el siguiente inicio de sesión real. Si el rechazo deliberado produce un inicio de sesión local en lugar de un rechazo, entonces la lista o el manejo de fallos no es lo que creía, y ese hallazgo supera a la caída con la que empezó. Escriba el resultado en el registro de cambios junto a los nombres de las cuentas y la fecha de la prueba.