Uso del servidor Token RSA y del protocolo SDI para ASA y ACS
Contenido
Introducción
Este documento describe los procedimientos de troubleshooting para el RSA Authentication Manager, que se puede integrar con el Cisco Adaptive Security Appliance (ASA) y el Cisco Secure Access Control Server (ACS).
El Administrador de autenticación RSA es una solución que proporciona la contraseña de un solo uso (OTP) para la autenticación. Esta contraseña se cambia cada 60 segundos y sólo se puede utilizar una vez. Es compatible con tokens de hardware y software.
Prerequisites
Requirements
Cisco recomienda tener conocimientos básicos sobre estos temas:
- Configuración CLI de Cisco ASA
- configuración ACS de Cisco
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software:
- Software Cisco ASA, versión 8.4 y posteriores
- Cisco Secure ACS, versión 5.3 y posteriores
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Teoría
Se puede acceder al servidor RSA con RADIUS o el protocolo RSA propietario: SDI. Tanto el ASA como el ACS pueden utilizar ambos protocolos (RADIUS, SDI) para acceder al RSA.
Recuerde que RSA se puede integrar con Cisco AnyConnect Secure Mobility Client cuando se utiliza un token de software. Este documento se centra exclusivamente en la integración de ASA y ACS. Para obtener más información sobre AnyConnect, consulte la sección Uso de la autenticación SDI de la Guía del administrador de Cisco AnyConnect Secure Mobility Client, versión 3.1.
RSA a través de RADIUS
RADIUS tiene una gran ventaja sobre SDI. En RSA, es posible asignar perfiles específicos (llamados grupos en ACS) a los usuarios. Estos perfiles tienen atributos RADIUS específicos definidos. Después de una autenticación exitosa, el mensaje RADIUS-Accept devuelto desde RSA contiene esos atributos. Basándose en esos atributos, la AEC toma decisiones adicionales. El escenario más común es la decisión de utilizar el mapeo de grupos de ACS para mapear atributos RADIUS específicos, relacionados con el perfil en el RSA, a un grupo específico en el ACS. Con esta lógica, es posible mover todo el proceso de autorización del RSA al ACS y aún mantener la lógica granular, como en el RSA.
RSA mediante SDI
SDI tiene dos ventajas principales sobre RADIUS. La primera es que toda la sesión está cifrada. La segunda son las opciones interesantes que el agente SDI proporciona: puede determinar si la falla se ha creado debido a un error de autenticación o autorización o porque no se ha encontrado el usuario.
Esta información es utilizada por el ACS en acción para la identidad. Por ejemplo, podría continuar para "usuario no encontrado" pero rechazar para "error de autenticación".
Hay una diferencia más entre RADIUS y SDI. Cuando un Dispositivo de Acceso a la Red como ASA utiliza SDI, el ACS realiza solamente la autenticación. Cuando utiliza RADIUS, el ACS realiza la autenticación, autorización y contabilización (AAA). Sin embargo, esto no es una gran diferencia. Es posible configurar SDI para la autenticación y RADIUS para la contabilización de las mismas sesiones.
Protocolo SDI
De forma predeterminada, SDI utiliza el protocolo de datagramas de usuario (UDP) 5500. SDI utiliza una clave de cifrado simétrico, similar a la clave RADIUS, para cifrar las sesiones. Esa clave se guarda en un archivo node secret y es diferente para cada cliente SDI. Ese archivo se implementa manual o automáticamente.
Para el nodo de implementación automática, el archivo secreto se descarga automáticamente después de la primera autenticación correcta. El secreto de nodo se cifra con una clave derivada del código de acceso del usuario y otra información. Esto crea algunos posibles problemas de seguridad, por lo que la primera autenticación debe realizarse localmente y utilizar el protocolo cifrado (Secure Shell [SSH], no telnet) para garantizar que el atacante no pueda interceptar y descifrar ese archivo.
Configuración
SDI en ACS
Se configura en Usuarios y almacenes de identidad > Almacén de identidad externo > Servidores Token de ID seguro RSA.
El RSA tiene varios servidores de réplica, como los servidores secundarios para el ACS. No hay necesidad de poner todas las direcciones allí, solo el archivo sdconf.rec proporcionado por el administrador RSA. Este archivo incluye la dirección IP del servidor RSA principal. Después del primer nodo de autenticación exitoso, el archivo secreto se descarga junto con las direcciones IP de todas las réplicas RSA.
Para diferenciar "usuario no encontrado" de "fallo de autenticación", elija la configuración en la pestaña Advanced:
También es posible cambiar los mecanismos predeterminados de ruteo (balanceo de carga) entre varios servidores RSA (primarios y réplicas). Cámbielo con el archivo sdopts.rec proporcionado por el administrador RSA. En ACS, se carga en Users and Identity Stores > External Identity Store > RSA Secure ID Token Servers > ACS Instance Settings.
Para la implementación de clústeres, la configuración se debe replicar. Después de la primera autenticación exitosa, cada nodo ACS utiliza su propio secreto de nodo descargado del servidor RSA primario. Es importante recordar configurar el RSA para todos los nodos ACS en el clúster.
SDI en ASA
ASA no permite la carga del archivo sdconf.rec. Y, al igual que ACS, solo permite la implementación automática. El ASA debe configurarse manualmente para señalar al servidor RSA primario. No se necesita una contraseña. Después del primer nodo de autenticación correcto, se instala el archivo secreto (archivo .sdi en flash) y se protegen las sesiones de autenticación adicionales. También se descarga la dirección IP de otros servidores RSA.
Aquí tiene un ejemplo:
aaa-server SDI protocol sdi
aaa-server SDI (backbone) host 1.1.1.1
debug sdi 255
test aaa auth SDI host 1.1.1.1 user test pass 321321321
Después de una autenticación exitosa, el comando show aaa-server protocol sdi o el comando show aaa-server <aaa-server-group> muestra todos los servidores RSA (si hay más de uno), mientras que el comando show run muestra solamente la dirección IP primaria:
bsns-asa5510-17# show aaa-server RSA
Server Group: RSA
Server Protocol: sdi
Server Address: 10.0.0.101
Server port: 5500
Server status: ACTIVE (admin initiated), Last transaction at
10:13:55 UTC Sat Jul 27 2013
Number of pending requests 0
Average round trip time 706ms
Number of authentication requests 4
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 1
Number of rejects 3
Number of challenges 0
Number of malformed responses 0
Number of bad authenticators 0
Number of timeouts 0
Number of unrecognized responses 0
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: OK
Number of accepts 0
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
Active Address: 10.0.0.102
Server Address: 10.0.0.102
Server port: 5500
Priority: 8
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
Troubleshoot
En esta sección se brinda información que puede utilizar para resolver problemas en su configuración.
No hay configuración de agente en RSA
En muchos casos, después de instalar un nuevo ASA o cambiar la dirección IP de ASA, es fácil olvidar hacer los mismos cambios en el RSA. La dirección IP del agente en el RSA debe actualizarse para todos los clientes que acceden al RSA. A continuación, se genera el nuevo secreto de nodo. Lo mismo se aplica al ACS, especialmente a los nodos secundarios porque tienen diferentes direcciones IP y el RSA necesita confiar en ellos.
Nodo secreto dañado
A veces, el archivo de nodo secreto en el ASA o el RSA se daña. Entonces, es mejor quitar la configuración del agente en el RSA y agregarla nuevamente. También debe realizar el mismo proceso en ASA/ACS: quitar y agregar la configuración de nuevo. Además, elimine el archivo .sdi en la memoria flash, de modo que en la siguiente autenticación se instale un nuevo archivo .sdi. La implementación automática de secreto de nodo debe producirse una vez que se haya completado.
Nodo en modo suspendido
A veces uno de los nodos está en modo suspendido, lo que se debe a que no hay respuesta de ese servidor:
asa# show aaa-server RSA
<.....output ommited"
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: SUSPENDED
En el modo suspendido, el ASA no intenta enviar ningún paquete a ese nodo; necesita tener un estado OK para eso. El servidor fallado se pone en modo activo otra vez después del temporizador muerto. Para obtener más información, refiérase a la sección comando reactivation-mode en la Referencia de Comandos de la Serie Cisco ASA, 9.1 guide.
En tales escenarios, es mejor quitar y agregar la configuración de servidor AAA para ese grupo para activar ese servidor en modo activo nuevamente.
Cuenta bloqueada
Después de varios reintentos, el RSA puede bloquear la cuenta. Se comprueba fácilmente en el RSA con informes. En ASA/ACS, los informes solo muestran "autenticación fallida".
Problemas y fragmentación de la unidad de transición máxima (MTU)
SDI utiliza UDP como transporte, no como detección de trayecto de MTU. Además, el tráfico UDP no tiene el bit Don't Fragment (DF) configurado de forma predeterminada. A veces, para paquetes más grandes, puede haber problemas de fragmentación. Es fácil detectar el tráfico en RSA (tanto el dispositivo como la máquina virtual [VM] utilizan Windows y Wireshark). Complete el mismo proceso en el ASA/ACS y compare. Además, pruebe RADIUS o WebAuthentication en el RSA para compararlo con SDI (para reducir el problema).
Paquetes y depuraciones para ACS
Debido a que la carga útil SDI está cifrada, la única manera de resolver problemas de las capturas es comparar el tamaño de la respuesta. Si es menor que 200 bytes, puede haber un problema. Un intercambio SDI típico implica cuatro paquetes, cada uno de los cuales es de 550 bytes, pero eso puede cambiar con la versión del servidor RSA:
En caso de problemas, generalmente se intercambian más de cuatro paquetes y tamaños más pequeños:
Además, los registros de ACS son bastante claros. Estos son los registros SDI típicos en el ACS:
EventHandler,11/03/2013,13:47:58:416,DEBUG,3050957712,Stack: 0xa3de560
Calling backRSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in
thread:3050957712,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:47:58:416,DEBUG,3050957712,cntx=0000146144,
sesn=acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState
::onEnterState],RSACheckPasscodeState.cpp:23
EventHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,Stack: 0xa3de560
Calling RSAAgent:Method MethodCaller<RSAAgent, RSAAgentEvent> in thread:
3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:47:58:416,DEBUG,3002137488,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSAAgent::handleCheckPasscode],
RSAAgent.cpp:319
RSASessionHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,[RSASessionHandler::
checkPasscode] call AceCheck,RSASessionHandler.cpp:251
EventHandler,11/03/2013,13:48:00:417,DEBUG,2965347216,Stack: 0xc14bba0
Create newstack, EventStack.cpp:27
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0 Calling
RSAAgent: Method MethodCaller<RSAAgent, RSAServerResponseEvent> in
thread:3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:48:00:417,DEBUG,3002137488,cntx=0000146144,sesn=acs-01
/150591921/1587,user=mickey.mouse,[RSAAgent::handleResponse] operation completed
with ACM_OKstatus,RSAAgent.cpp:237
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0
EventStack.cpp:37
EventHandler,11/03/2013,13:48:00:417,DEBUG,3049905040,Stack: 0xa3de560 Calling
back RSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in thread:
3049905040,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:48:00:417,DEBUG,3049905040,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState::onRSAAgentResponse]
Checkpasscode succeeded, Authentication passed,RSACheckPasscodeState.cpp:55
Información Relacionada
- Recursos del Administrador de autenticación RSA
- Sección Soporte del Servidor RSA/SDI de la Guía de Configuración de Cisco ASA 5500 Series mediante CLI, 8.4 y 8.6
- Sección RSA SecurID Server de la Guía del usuario de Cisco Secure Access Control System 5.4
- Soporte Técnico y Documentación - Cisco Systems
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
13-Jun-2013 |
Versión inicial |
Comentarios