TACACS+: un rechazo, una caída y una recuperación no son la misma prueba
Un ingeniero de redes japonés detalla por qué validar TACACS+ con un login correcto deja sin cubrir los tres estados que de verdad rompen el acceso a los dispositivos.
Un despliegue de TACACS+ no queda validado porque un login funcione. El autor de la nota, un ingeniero de redes japonés, sostiene que hay que probar por separado tres estados que suelen meterse en el mismo saco: un rechazo explícito del servidor, un servidor que no responde y la recuperación tras el fallo. En cada uno hay que anotar qué servidor autenticó la sesión, qué permisos quedaron activos y qué evidencia de accounting se generó. Los ejemplos que da son diseños de prueba, no resultados de un cliente.
FAIL no es ERROR
El error de método más común es simular una caída escribiendo mal la contraseña. Un servidor puede estar perfectamente accesible y decidir rechazar la autenticación: eso es un FAIL, una decisión completada. Un timeout es otra cosa, porque no llegó respuesta utilizable, y un error de protocolo es un tercer caso. La RFC 8907, sección 4.4 los separa: el FAIL se aplica como decisión, mientras que el ERROR debe tratarse como si el servidor fuera inalcanzable, lo que habilita métodos alternativos. Antes de escribir el resultado esperado, conviene mirar cómo se comporta la lista de métodos en la plataforma concreta.
Evidencia, no impresiones
"Me salió el prompt" no dice nada: ni qué servidor contestó ni si el equipo tiró de una cuenta local. Para la caída de un solo servidor, la secuencia razonable es registrar la configuración de partida, confirmar el acceso normal, provocar el fallo, abrir una sesión de gestión nueva con la cuenta de prueba e identificar qué fuente autenticó ese intento. Luego se comprueban permisos y registros, y se mide el tiempo transcurrido contra el límite acordado antes de empezar. También importa cómo se provoca el fallo: descartar tráfico, rechazar la conexión y parar el servicio no producen las mismas observaciones.
La cuenta de emergencia merece su propio examen. TACACS+ separa autenticación, autorización y accounting, y superar una etapa no dice nada de las demás. Entrar en local no implica que la sesión de gestión se estableciera, que se aplicara el rol previsto o que las operaciones de recuperación funcionaran. La guía de Cisco para NX-OS 10.4(x) sirve de ejemplo: la autorización de comandos tiene su propia configuración de fallback y la local solo entra si los grupos de servidores no responden y ese fallback está configurado; sin él, la autorización falla. La del console se configura aparte.
Si el diseño no contempla fallback local, no se añade uno para que la prueba salga.
Lo que se juega aquí es si el equipo sabe quién entró cuando la infraestructura de AAA está a medias. Un test limitado al camino feliz deja sin respuesta la pregunta que importa durante un incidente: qué credencial abrió la sesión y qué quedó registrado.
