Para implementar a configuração neste documento, você precisa de qualquer versão do Cisco Secure que suporte o Secure ID da Security Dynamics Incorporated (SDI).
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Observação: o Secure ID geralmente é instalado antes do Cisco Secure UNIX (CSUnix) ser instalado. Essas instruções descrevem como instalar o cliente SDI após a instalação do CSUnix.
No servidor SDI, execute sdadmin. Informe ao servidor SDI que a máquina do CSUnix é um cliente e especifique que os usuários SDI em questão sejam ativados no cliente do CSUnix.
Use o comando nslookup #.#.#.# ou nslookup <nome do host> para certificar-se de que o cliente CSUnix e o servidor SDI possam fazer uma pesquisa direta e reversa um do outro.
Copie o arquivo /etc/sdace.txt do servidor SDI para o arquivo /etc/sdace.txt do cliente CSUnix.
Copie o arquivo sdconf.rec do servidor SDI para o cliente CSUnix; esse arquivo pode residir em qualquer lugar do cliente CSUnix. No entanto, se ele for colocado na mesma estrutura de diretórios no cliente CSUnix que estava no servidor SDI, o arquivo sdace.txt não precisará ser modificado.
/etc/sdace.txt ou VAR_ACE deve apontar para o caminho onde o arquivo sdconf.rec está localizado. Para verificar isso, execute cat /etc/sdace.txt ou verifique a saída de env para ter certeza de que VAR_ACE está definido no perfil da raiz quando a raiz é iniciada.
Faça backup do CSU.cfg do cliente do CSUnix e modifique a seção AUTHEN config_external_authen_symbols com estas linhas:
Reciclar o CSUnix pela execução do K80CiscoSecure e do S80CiscoSecure.
Se $BASE/utils/psg mostrar que o processo do Cisco Secure AAA Server Process estava ativo antes que o arquivo CSU.cfg fosse modificado, mas não depois, então erros foram feitos na revisão do arquivo CSU.cfg. Restaure o arquivo CSU.cfg original e tente fazer novamente as alterações descritas na etapa 6.
Para testar o Secure ID e o CSUnix, execute estas etapas:
Certifique-se de que um usuário que não seja SDI possa executar Telnet para o roteador e ser autenticado com o CSUnix. Se isso não funcionar, o SDI não funcionará.
Teste a autenticação SDI básica no roteador e execute este comando:
aaa new-model aaa authentication login default tacacs+ none
Observação: isso pressupõe que os comandos tacacs-server já estejam ativos no roteador.
Adicione um usuário SDI da linha de comando CSUnix para inserir esse comando
$BASE/CLI/AddProfile -p 9900 -u sdi_user -pw sdi
Tente se autenticar como um usuário. . Se esse usuário trabalhar, o SDI estará operacional e você poderá adicionar mais informações aos perfis de usuário.
Os usuários SDI podem ser testados com o perfil unknown_user no CSUnix. (Os usuários não precisam ser listados explicitamente no CSUnix se todos forem passados para o SDI e tiverem o mesmo perfil.) Se já existir um perfil de usuário desconhecido, exclua-o com a ajuda deste comando:
$BASE/CLI/DeleteProfile -p 9900 -u unknown_user
Use este comando para adicionar outro perfil de usuário desconhecido:
$BASE/CLI/AddProfile -p 9900 -u unknown_user -pw sdi
Esse comando passa todos os usuários desconhecidos para o SDI.
Realizar um teste inicial sem SDI. Se esse perfil de usuário não funcionar sem uma senha SDI para autenticação de login, Challenge Handshake Authentication Protocol (CHAP) e Password Authentication Protocol (PAP), ele não funcionará com uma senha SDI:
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ password = chap "chappwd" password = pap "pappwd" password = clear,"clearpwd" default service=permit service=shell { } service=ppp { protocol=lcp { } protocol=ip { } } }
Quando o perfil funcionar, adicione "sdi" ao perfil em vez de "clear", como mostrado neste exemplo:
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ password = chap "chappwd" password = pap "pappwd" password = sdi default service=permit service=shell { } service=ppp { protocol=lcp { } protocol=ip { } } }
Esse perfil permite que o usuário faça login com estas combinações:
Faça Telnet para o roteador e use SDI. (Isso pressupõe que o comando aaa authentication login default tacacs+ foi executado no roteador.)
Conexão PPP e PAP de rede dial-up. (Isso pressupõe que os comandos aaa authentication ppp default if-needed tacacs e ppp authen pap foram executados no roteador).
Observação: no PC, em Dial-Up Networking, certifique-se de que a opção "Accept any authentication including clear text" (Aceitar qualquer autenticação, incluindo texto não criptografado) esteja marcada. Antes de discar, digite uma destas combinações de nome de usuário/senha na janela do terminal:
username: cse*code+card password: pap (must agree with profile) username: cse password: code+card
Conexão PPP e CHAP de rede dial-up. (Isso pressupõe que os comandos aaa authentication ppp default if-needed tacacs e ppp authen chap foram executados no roteador).
Observação: no PC, em Dial-Up Networking, a opção "Accept any authentication including clear text" ou "Accept only encrypted authentication" deve estar marcada. Antes de discar, digite este nome de usuário e senha na janela do terminal:
username: cse*code+card password: chap (must agree with profile)
Essas combinações produzem os seguintes erros de depuração do CSUnix:
CHAP e nenhuma senha de "texto claro" no campo de senha. O usuário digita code+card em vez da senha "cleartext". O RFC 1994 sobre CHAP requer armazenamento de senha de texto claro.
username: cse password: code+card CiscoSecure INFO - User cse, No tokencard password received CiscoSecure NOTICE - Authentication - Incorrect password;
CHAP e uma senha CHAP inválida.
username: cse*code+card password: wrong chap password
(O usuário passa para o SDI, e o SDI passa para o usuário, mas o CSUnix falha no usuário porque a senha do CHAP é inválida.)
CiscoSecure INFO - The character * was found in username: username=cse,passcode=1234755962 CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE CiscoSecure INFO - sdi_verify: rtn 1 CiscoSecure NOTICE - Authentication - Incorrect password;
PAP e uma senha PAP inválida.
username: cse*code+card password: wrong pap password
(O usuário passa para o SDI, e o SDI passa para o usuário, mas o CSUnix falha no usuário porque a senha do CHAP é inválida.)
CiscoSecure INFO - 52 User Profiles and 8 Group Profiles loaded into Cache. CiscoSecure INFO - The character * was found in username: username=cse,passcode=1234651500 CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE CiscoSecure INFO - sdi_verify: rtn 1 CiscoSecure NOTICE - Authentication - Incorrect password;
O usuário precisa fazer a autenticação CHAP e login; o PAP falha.
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ password = chap "********" password = sdi default service=permit service=shell { } service=ppp { protocol=lcp { } protocol=ip { } }
O usuário precisa fazer a autenticação PAP e de login; o CHAP falha.
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ member = admin password = pap "********" password = sdi default service=permit service=shell { } service=ppp { protocol=lcp { } protocol=ip { } } }
Estas seções contêm os procedimentos RADIUS do CSUnix.
Execute estas etapas para testar a autenticação:
Realizar um teste inicial sem SDI. Se esse perfil de usuário não funcionar sem uma senha SDI para autenticação de login, ele não funcionará com uma senha SDI:
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ radius=Cisco { check_items= { 2="whatever" } reply_attributes= { 6=6 } } }
Quando esse perfil funcionar, substitua "what" por "sdi", como mostrado neste exemplo:
# ./ViewProfile -p 9900 -u cse User Profile Information user = cse{ radius=Cisco { check_items= { 2=sdi } reply_attributes= { 6=6 } } }
Execute estas etapas para testar a autenticação:
Observação: a autenticação PPP CHAP com CSUnix e RADIUS não é suportada.
Realizar um teste inicial sem SDI. Se esse perfil de usuário não funcionar sem uma senha SDI para a autenticação PPP/PAP e o "modo assíncrono dedicado", ele não funcionará com uma senha SDI:
# ./ViewProfile -p 9900 -u cse user = cse { password = pap "pappass" radius=Cisco { check_items = { } reply_attributes= { 6=2 7=1 } } }
Quando o perfil acima funcionar, adicione password = sdi ao perfil e adicione attribute 200=1 como mostrado neste exemplo (isso define Cisco_Token_Immediate como yes.):
# ./ViewProfile -p 9900 -u cse user = cse { password = pap "pappass" password = sdi radius=Cisco { check_items = { 200=1 } reply_attributes= { 6=2 7=1 } } }
Na seção "Advanced GUI, server", certifique-se de que "Enable Token Caching" esteja configurado. Isso pode ser confirmado na interface de linha de comando (CLI) com:
$BASE/CLI/ViewProfile -p 9900 -u SERVER.#.#.#.# !--- Where #.#.#.# is the IP address of the CSUnix server. TokenCachingEnabled="yes"
Assume-se que os comandos aaa authentication ppp default if-needed tacacs e PPP authen PAP foram executados no roteador. Digite esse nome de usuário e senha na janela do terminal antes de discar.:
username: cse password: code+card
Observação: no PC, em Dial-Up Networking, certifique-se de que a opção "Accept any authentication including clear text" (Aceitar qualquer autenticação incluindo texto não criptografado) esteja marcada.
Estas seções contêm dicas para dicas de depuração e verificação.
Este é um exemplo de uma boa depuração:
CiscoSecure DEBUG - RADIUS ; Outgoing Accept Packet id=133 (10.31.1.6) User-Service-Type = Framed-User Framed-Protocol = PPP CiscoSecure DEBUG - RADIUS ; Request from host a1f0106 nas (10.31.1.6) code=1 id=134 length=73 CiscoSecure DEBUG - RADIUS ; Incoming Packet id=134 (10.31.1.6) Client-Id = 10.31.1.6 Client-Port-Id = 1 NAS-Port-Type = Async User-Name = "cse" Password = "?\235\306" User-Service-Type = Framed-User Framed-Protocol = PPP CiscoSecure DEBUG - RADIUS ; Authenticate (10.31.1.6) CiscoSecure DEBUG - RADIUS ; checkList: ASCEND_TOKEN_IMMEDIATE = 1 CiscoSecure DEBUG - RADIUS ; User PASSWORD type is Special CiscoSecure DEBUG - RADIUS ; authPapPwd (10.31.1.6) CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse CiscoSecure DEBUG - profile_valid_tcaching FALSE ending. CiscoSecure DEBUG - Token Caching. IGNORE. CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE CiscoSecure INFO - sdi_verify: rtn 1 CiscoSecure DEBUG - RADIUS ; Sending Ack of id 134 to a1f0106 (10.31.1.6)
A depuração é armazenada no arquivo especificado em /etc/syslog.conf para local0.debug.
Nenhum usuário pode autenticar - SDI ou de outra forma:
Depois de adicionar o ID seguro, certifique-se de que nenhum erro tenha sido feito ao modificar o arquivo CSU.cfg. Corrija o arquivo CSU.cfg ou reverta para o arquivo CSU.cfg de backup.
Este é um exemplo de uma boa depuração:
Dec 13 11:24:22 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse Dec 13 11:24:22 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: cse authenticated by ACE Srvr Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: cse authenticated by ACE Srvr Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=GET_PASSCODE Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=GET_PASSCODE Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: rtn 1 Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: rtn 1
Este é um exemplo de uma depuração inválida:
O CSUnix encontra o perfil de usuário e o envia para o servidor SDI, mas o servidor SDI falha no usuário porque a senha está incorreta.
Dec 13 11:26:22 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse Dec 13 11:26:22 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: WARNING - sdi_verify: cse denied access by ACE Srvr Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: WARNING - sdi_verify: cse denied access by ACE Srvr Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=GET_PASSCODE Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=GET_PASSCODE Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: rtn 0 Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi_verify: rtn 0 Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: NOTICE - Authentication - Incorrect password; Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure: NOTICE - Authentication - Incorrect password;
Este é um exemplo de como o servidor Ace está inoperante:
Digite ./aceserver stop no servidor SDI. O usuário não recebe a mensagem "Enter PASSCODE".
Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure: ERROR - sdi_challenge error: sd_init failed cli/srvr comm init (cse) Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure: ERROR - sdi_challenge error: sd_init failed cli/srvr comm init (cse) Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=RESET Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure: INFO - sdi: cse free external_data memory,state=RESET
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
17-Oct-2001 |
Versão inicial |