Uso do servidor de token RSA e do protocolo SDI para ASA e ACS
Contents
Introdução
Este documento descreve os procedimentos de solução de problemas do RSA Authentication Manager, que podem ser integrados ao Cisco Adaptive Security Appliance (ASA) e ao Cisco Secure Access Control Server (ACS).
O RSA Authentication Manager é uma solução que fornece OTP (One Time Password, senha única) para autenticação. Essa senha é alterada a cada 60 segundos e só pode ser usada uma vez. Ele suporta tokens de hardware e software.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento básico destes tópicos:
- Configuração CLI do Cisco ASA
- configuração do Cisco ACS
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software:
- Software Cisco ASA, versão 8.4 e posterior
- Cisco Secure ACS, versão 5.3 e posterior
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Teoria
O servidor RSA pode ser acessado com o RADIUS ou com o protocolo RSA proprietário: SDI. Tanto o ASA quanto o ACS podem usar ambos os protocolos (RADIUS, SDI) para acessar o RSA.
Lembre-se de que o RSA pode ser integrado ao Cisco AnyConnect Secure Mobility Client quando um token de software é usado. Este documento concentra-se exclusivamente na integração do ASA e do ACS. Para obter mais informações sobre o AnyConnect, consulte a seção Uso da autenticação SDI do Guia do Administrador do Cisco AnyConnect Secure Mobility Client, Release 3.1.
RSA via RADIUS
O RADIUS tem uma grande vantagem sobre o SDI. No RSA, é possível atribuir perfis específicos (chamados de grupos no ACS) aos usuários. Esses perfis têm atributos RADIUS específicos definidos. Após a autenticação bem-sucedida, a mensagem RADIUS-Accept retornada pelo RSA contém esses atributos. Com base nesses atributos, o ACS toma decisões adicionais. O cenário mais comum é a decisão de usar o Mapeamento de grupo ACS para mapear atributos RADIUS específicos, relacionados ao perfil no RSA, para um grupo específico no ACS. Com essa lógica, é possível mover todo o processo de autorização do RSA para o ACS e ainda manter a lógica granular, como no RSA.
RSA via SDI
A SDI tem duas vantagens principais sobre o RADIUS. A primeira é que toda a sessão é criptografada. A segunda são as opções interessantes que o agente SDI fornece: ele pode determinar se a falha foi criada devido a uma falha de autenticação ou autorização ou porque o usuário não foi encontrado.
Essas informações são usadas pelo ACS em ação para identidade. Por exemplo, ele pode continuar para "usuário não encontrado", mas rejeitar para "falha de autenticação".
Há mais uma diferença entre RADIUS e SDI. Quando um dispositivo de acesso à rede como o ASA usa SDI, o ACS executa apenas a autenticação. Quando ele usa o RADIUS, o ACS executa autenticação, autorização, contabilização (AAA). No entanto, esta não é uma grande diferença. É possível configurar o SDI para autenticação e o RADIUS para contabilização das mesmas sessões.
Protocolo SDI
Por padrão, o SDI usa o User Datagram Protocol (UDP) 5500. O SDI usa uma chave de criptografia simétrica, similar à chave RADIUS, para criptografar sessões. Essa chave é salva em um arquivo de segredo de nó e é diferente para cada cliente SDI. Esse arquivo é implantado manual ou automaticamente.
Para o nó de implantação automática, o arquivo secreto é baixado automaticamente após a primeira autenticação bem-sucedida. O segredo do nó é criptografado com uma chave derivada da senha do usuário e outras informações. Isso cria alguns problemas de segurança possíveis, portanto, a primeira autenticação deve ser executada localmente e usar o protocolo criptografado (Secure Shell [SSH], não o telnet) para garantir que o invasor não possa interceptar e descriptografar esse arquivo.
Configuração
SDI no ACS
Ele é configurado em Users and Identity Stores > External Identity Store > RSA Secure ID Token Servers.
O RSA tem vários servidores de réplica, como os servidores secundários para o ACS. Não há necessidade de colocar todos os endereços lá, apenas o arquivo sdconf.rec fornecido pelo administrador do RSA. Esse arquivo inclui o endereço IP do servidor RSA primário. Após o primeiro nó de autenticação bem-sucedido, o arquivo secreto é baixado junto com os endereços IP de todas as réplicas RSA.
Para diferenciar "usuário não encontrado" de "falha de autenticação", escolha as configurações na guia Avançado:
Também é possível alterar os mecanismos de roteamento padrão (balanceamento de carga) entre vários servidores RSA (primários e réplicas). Altere-o com o arquivo sdopts.rec fornecido pelo administrador RSA. No ACS, ele é carregado em Users and Identity Stores > External Identity Store > RSA Secure ID Token Servers > ACS Instance Settings.
Para implantação de cluster, a configuração deve ser replicada. Após a primeira autenticação bem-sucedida, cada nó ACS usa seu próprio segredo de nó baixado do servidor RSA primário. É importante lembrar de configurar o RSA para todos os nós ACS no cluster.
SDI no ASA
O ASA não permite o carregamento do arquivo sdconf.rec. E, como o ACS, ele permite apenas a implantação automática. O ASA precisa ser configurado manualmente para apontar para o servidor RSA principal. Não é necessária uma senha. Após o primeiro nó de autenticação bem-sucedido, o arquivo secreto é instalado (arquivo .sdi na flash) e outras sessões de autenticação são protegidas. Também é feito o download do endereço IP de outros servidores RSA.
Aqui está um exemplo:
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
Após a autenticação bem-sucedida, o comando show aaa-server protocol sdi ou show aaa-server <aaa-server-group> mostra todos os servidores RSA (se houver mais de um), enquanto o comando show run mostra apenas o endereço IP primário:
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
Troubleshooting
Esta seção disponibiliza informações para a solução de problemas de configuração.
Nenhuma configuração de agente em RSA
Em muitos casos, após instalar um novo ASA ou alterar o endereço IP do ASA, é fácil esquecer de fazer as mesmas alterações no RSA. O endereço IP do agente no RSA precisa ser atualizado para todos os clientes que acessam o RSA. Em seguida, o novo segredo de nó é gerado. O mesmo se aplica ao ACS, especialmente aos nós secundários, pois eles têm endereços IP diferentes e o RSA precisa confiar neles.
Nó Secreto Corrompido
Às vezes, o arquivo de nó secreto no ASA ou no RSA é corrompido. Em seguida, é melhor remover a configuração do agente no RSA e adicioná-la novamente. Você também precisa fazer o mesmo processo no ASA/ACS - remova e adicione a configuração novamente. Além disso, exclua o arquivo .sdi na memória flash para que, na próxima autenticação, um novo arquivo .sdi seja instalado. A implantação automática de segredo de nó deve ocorrer quando isso for concluído.
Nó no modo suspenso
Às vezes, um dos nós está no modo suspenso, o que é causado por nenhuma resposta desse 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
No modo suspenso, o ASA não tenta enviar nenhum pacote para esse nó; ele precisa ter um status OK para isso. O servidor com falha é colocado no modo ativo novamente após o temporizador de Dead. Para obter mais informações, consulte a seção comando do modo de reativação no guia Referência de Comandos do Cisco ASA Series, 9.1.
Nesses cenários, é melhor remover e adicionar a configuração do servidor AAA para esse grupo a fim de disparar esse servidor no modo ativo novamente.
Conta bloqueada
Após várias tentativas, o RSA pode bloquear a conta. Ele é facilmente verificado no RSA com relatórios. No ASA/ACS, os relatórios mostram apenas "falha na autenticação".
Problemas e fragmentação da Unidade Máxima de Transição (MTU)
O SDI usa UDP como transporte, não descoberta de caminho de MTU. Além disso, o tráfego UDP não tem o bit Don't Fragment (DF) definido por padrão. Às vezes, para pacotes maiores, pode haver problemas de fragmentação. É fácil farejar o tráfego no RSA (o dispositivo e a máquina virtual [VM] usam o Windows e o Wireshark). Conclua o mesmo processo no ASA/ACS e compare. Além disso, teste o RADIUS ou a autenticação da Web no RSA para compará-lo ao SDI (para restringir o problema).
Pacotes e depurações para ACS
Como o payload SDI é criptografado, a única maneira de solucionar problemas nas capturas é comparar o tamanho da resposta. Se for menor que 200 bytes, pode haver um problema. Uma troca SDI típica envolve quatro pacotes, cada um com 550 bytes, mas que podem ser alterados com a versão do servidor RSA:
Em caso de problemas, geralmente são mais de quatro pacotes trocados e tamanhos menores:
Além disso, os registros ACS são bem claros. Aqui estão os logs SDI típicos no 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
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
13-Jun-2013 |
Versão inicial |
Feedback