A senha AAA / TACACS + no switch Cisco sempre falha no segundo prompt de senha


9

Sempre que efetuar login em um dispositivo de rede usando AAA / TACACS +, se eu digitar o prompt de senha após o nome de usuário, o segundo prompt de senha sempre falha mesmo quando a senha está correta. Preciso aguardar o prompt do nome de usuário novamente e preciso obter a senha correta no primeiro prompt de senha imediatamente após isso. Em outras palavras, sempre que vir o segundo prompt de senha, ele não funcionará.

Veja a interação e a configuração higienizadas abaixo.

Verificação de acesso do usuário
Nome de usuário: nome de usuário
Senha:

Senha: (sempre falha aqui)
% Acesso negado

Verificação de acesso do usuário
Nome de usuário: nome de usuário
Senha:

Conectado a s-site-rack-agg2.example.net na linha 1 (nome do site).
s-site-rack-agg2 #

O que poderia ser diferente com o segundo prompt de senha para explicar esse comportamento?

O AAA típico e a configuração relacionada que tenho é:

aaa novo modelo
grupo padrão tacacs de login de autenticação aaa + linha local
autenticação aaa login CONSOLE none
autenticação aaa ativar grupo padrão tacacs + enable
grupo tacacs padrão de exec de autorização aaa + local se autenticado
comandos de autorização aaa 1 grupo padrão tacacs + local se autenticado
comandos de autorização aaa 7 grupo tacacs padrão + local se autenticado
comandos de aaa 15 grupos tacacs padrão + local se autenticado
aaa padrão contábil exec executivo start-stop group tacacs
comandos de contabilidade do aaa 0 grupo inicial start-stop padrão tacacs +
comandos aaa accounting 1 grupo inicial start-stop padrão tacacs +
comandos de contabilidade do aaa 7 tacacs padrão do grupo start-stop +
comandos de contabilidade aaa 15 grupo inicial start / stop tacacs +
tacacs de grupo start-stop padrão do sistema de contabilidade aaa +
!
interface de origem ip tacacs Loopback0
host tacacs-server -premiaryipremoved- conexão única
host tacacs-server -secondaryipremoved- single-connection
tempo limite do tacacs-server 10
solicitação direcionada do servidor tacacs
chave tacacs-server 7 -removed-
!
linha con 0
 autenticação de login CONSOLE
linha vty 0 4
 local -removido-
 exec-timeout 60 0
 senha 7 - removida -
 telnet de entrada de transporte ssh

Nunca cheguei ao fundo disso, pois as senhas com falha demoravam> o tempo limite para o TACACS retornar uma resposta; portanto, o segundo prompt era da linesenha. As senhas corretas obtiveram uma resposta do TACACS imediatamente. Movido para servidores ACS mais novos, o problema foi resolvido com a mesma configuração, portanto parece que foi um problema do ACS.
generalnetworkerror

Respostas:


4

Eu faria uma depuração no seu servidor TACACS + enquanto você está tentando isso.

Suponho que você deseja usar apenas a autenticação TACACS e somente retorne para logons locais se ele não puder acessar o servidor?

Tente usar isto:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Veja também este site: Tem alguns bons exemplos e explicações

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ heada _4_2 # X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjNfX2hlYWRhX180XzEmcXVlcnk9

Meu palpite é que, desde que você tenha a palavra-chave "local" em:
aaa authentication login default group tacacs+ local line

A autenticação TACACS + retorna uma falha, portanto o roteador tenta fazer a autenticação local. Eu acho que você deve nos fornecer a line vtyconfiguração higienizada. Se você tem
line vty 0 15
login local

Em seguida, ele faria uma autenticação de nome de usuário / senha, caso contrário, está fazendo a senha


lineConfigurações sanitizadas adicionadas ao Q.
generalnetworkerror

Com apenas uma breve olhada no debug, parece que o ACS não volta rápido o suficiente com uma senha incorreta, pois essa condição é a única vez que vejo tempos limite com o servidor TACACS relatados. Todas as outras vezes existem zero tempos limite.
generalnetworkerror

4

Acho que sua configuração é bastante perigosa e você parece indeciso se estiver usando 'enable / line' ou 'local' como fallback, a resposta correta é local, nunca use 'enable' e, especialmente, nunca 'line' para nada (a linha é 'criptografado', não com hash unidirecional).

Eu recomendaria esta configuração:

aaa new-model
! uses tacacs, fallsback to local user if tacacs not working
aaa authentication login default group tacacs+ local
! user gets enabled by tacacs or by enable password
aaa authentication enable default group tacacs+ enable
! console user is authorized as well (gets enabled, if such permission)
aaa authorization console
! configuration commands are authorized as well as exec commands (Good to prevent dangerous commands)
aaa authorization config-commands
! user privilege level is recovered from tacacs or from local account
aaa authorization exec default group tacacs+ local
! level 15 commands are authorized (you really only need this) 
aaa authorization commands 15 default group tacacs+ if-authenticated 
! level 1, 15 commands are logged (you really only need these two)
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
! fallback user consulted only when tacacs is broken
username sikrit privilege 15 secret <password>

O usuário 'sikrit' deve ser usado quando o tacacs não está funcionando (não pode ser usado se o TACACS responder), não há necessidade de senha 'line' no VTY, pois nunca é consultado. Não há necessidade de habilitar a senha, pois ela nunca é consultada. Se você deseja um usuário de backup não ativado, crie outro com 'privilégio 1'.
No entanto, eu adicionei suporte para 'enable' se você quiser usá-lo por algum motivo, afinal.

Se você estiver usando OOB, e o acesso OOB já estiver protegido / autenticado, convém permitir que o usuário OOB sempre use autenticação local, apenas no caso de o TACACS estar quebrado, mas o IOS erroneamente achar que não é, então você adicionaria algo assim :

aaa authentication login CONSOLE local
!
line con 0
 login authentication CONSOLE

A idéia de ter aaa authentication login default group tacacs+ local lineera usar a senha da linha como uma chave de acesso se o modelo AAA fosse implantado em um dispositivo em que o TACACS estava quebrado e nenhum usuário local foi definido. Na verdade, eu tinha aaa authentication login CONSOLE nonena minha configuração que não mostrava originalmente. (Sim, eu tendem a confiar acesso ao console físico para os dispositivos mais do que eu provavelmente deveria.)
generalnetworkerror

Na verdade, não consegui replicar em laboratório o problema que você está vendo. Se você não tiver uma senha 'local' configurada e o IOS considerar que o TACACS não é acessível, faria sentido pedir a senha da 'linha', mas para mim, para o TACACS acessível, não retornaria à 'linha'. Talvez bug no IOS ou TACACS o que torna a falha de autenticação olhar como falha de conexão TACACS (pode valer a pena tentar, sem 'conexão single')
ytti

O segundo prompt de senha sem um segundo prompt de nome de usuário correspondente nos diz definitivamente que falhou na linesenha em um sistema sem nenhum usuário local criado para a localautenticação? [ aaa authentication login default group tacacs+ local line.] tacacs + falha, local ignorado como nenhum usuário local, então senha da linha?
generalnetworkerror

Eu não acho que ele deva fazer fallback no tacacs + auth_failure, deve fazê-lo apenas por falta do tacacs + reply. Então, eu pesquisava opções por que o IOS acha que o tacacs + não está respondendo (presumo que esteja respondendo). Talvez uma coisa a tentar seja a configuração diferente do tacacs (como remover a conexão única); se for um bug do IOS, pode remover o gatilho do bug.
ytti

Você provavelmente não viu meu comentário em outra resposta sobre depuração, mostrando que o tacacs + está demorando> 30 anos para responder somente quando a senha está incorreta; nesse momento, os sistemas consideram a resposta do servidor tacacs ausente e passam para a próxima autenticação. Quando a senha está correta, a resposta tacacs é imediata.
generalnetworkerror

4

Não tenho certeza se a configuração do seu dispositivo local seria responsável por isso, mas sim pelo próprio servidor TACACS. O TACACS envia um proxy do prompt de nome de usuário / senha do servidor TACACS (e possivelmente um armazenamento de identidade externo) ao dispositivo. Portanto, se você estiver usando o ACS (por exemplo) e configurá-lo para conversar com o AD para fazer autenticação do usuário, será necessário pensar no prompt de nome de usuário / senha como proveniente de um controlador de domínio e não do próprio dispositivo.

Recentemente, deparei-me com um problema exatamente como este que foi corrigido por um patch no ACS - novamente, estou assumindo que você está usando o ACS e que ele é extraído do AD para verificação de autenticação / grupo de usuários etc. O ID de bug da Cisco era CSCtz03211 e basicamente o ACS 5.3 estava enviando várias tentativas de autenticação ao AD por uma única tentativa de autenticação de "nome de usuário / senha" ao dispositivo. Isso resultaria no comportamento em que, se um usuário digitasse a senha na primeira tentativa, várias instâncias do nome de usuário / senha incorretos combinados fossem enviadas ao AD e a conta do usuário fosse realmente bloqueada, resultando em tentativas subsequentes de logon com falha. o dispositivo, mesmo se um usuário digitar seu nome de usuário / senha corretamente na segunda tentativa (esse comportamento obviamente varia com os limites de bloqueio que você definiu nas contas de usuário no AD).

Apenas algo a considerar (sem conhecimento da implementação do servidor TACACS).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.