Cisco ISE — AAA com Radius

Fernando Mantovani Pierobon
TechRebels
Published in
5 min readDec 29, 2020

Fala pessoal, todos bem? Espero que sim!

Vamos falar sobre um dos meus assuntos preferidos hoje: AAA (Authentication, Authorization e Accounting)!

Nosso objetivo é logar em um router via SSH, com um usuário do AD autenticando no ISE e obter privilégio 15 automaticamente.

Relembrando:

O quarto artigo do blog mostra o processo de configurar o NAD (Router, Switch, etc.) no ISE. Se você não leu, clique aqui.

No último artigo mostrei como fazer a integração entre o AD e o ISE. Veja aqui.

Bom, nesse momento, temos nosso router configurado (servidor Radius) e o AD integrado ao ISE. Repare na topologia acima. Estamos configurando o R1.

Vamos aplicar as configurações de AAA no roteador:

aaa authentication login SEMAUTENTIC none
aaa authentication login ISE group ISE
aaa authorization exec ISE group ISE

O primeiro comando, cria um grupo de autenticação “sem autenticação”. SEMAUTENTIC é o nome que eu dei e associei a um método ‘none’. Vamos configurar esse método na line con do router, para não ficarmos presos “pra fora” do roteador caso algo dê errado.

O segundo comando cria um grupo de autenticação “ISE” e associa ao grupo “ISE”, que é o nome do servidor que eu criei no artigo com o link acima. Os nomes iguais foram preferência minha, ok? Eles não precisam ser iguais.

Agora que já sabemos “quem” é a pessoa que vai logar no router, veremos “o que” ela pode fazer. Essa parte é bem simples e menos granular do que usando o protocolo TACACS.

Nós já definimos os métodos de autenticação e autorização e apontamos eles para o grupo de servidores Radius chamado ISE. Agora, vamos linkar esses métodos no acesso aos eqtos.

line con 0
logging synchronous
login authentication SEMAUTENTIC

line vty 0 4
authorization exec ISE
login authentication ISE
transport input ssh

Repare na line vty que estou usando SSH. Portanto, não esqueça de gerar a chave rsa com o comando:

crypto key generate rsa label MINHA-CHAVE modulus 2048

Finalizamos a parte do router.

Vamos fazer um teste de autenticação agora sem nenhuma configuração adicional no ISE. Veja o resultado:

Olhando os logs do ISE:

Obs: Pessoal, não vou ficar repetindo os menus ou como encontrar a informação na GUI do ISE. Está tudo explicado no segundo artigo (aqui).

O padrão do ISE, é procurar em todas as bases de usuários configuradas. Portanto, ele procurou no AD, mas não encontrou meu usuário ‘fernando’.

Vou então criá-lo agora no AD (feito!) e também dentro do ISE, mas apontando a senha para o ‘AD’. Isso me permitirá adicionar esse user dentro de um grupo do próprio ISE.

Obs: Tem inúmeras formas de fazer essas associações, seja por grupo no AD, no ISE, etc…

Reparem no “Password Type”:

Fazemos outro teste de autenticação agora e vejam o resultado:

O usuário se autenticou com sucesso e bateu nas políticas padrão de autenticação e autorização.

Vamos agora fechar um pouco nossa política: Na autenticação, permitiremos apenas usuários do AD e, caso eles sejam membros do grupo AD-Admins (que criaremos no ISE), irão se logar e obter privilégio 15 automaticamente (sem usar senha de enable).

Especificando o AD como única base de usuários para autenticação:

Criando grupo AD-Admins no ISE e adicionando o usuário fernando.

Vamos configurar um Authorization Profile e, usando o atributo av-pair, setar o privilégio (priv-lvl) 15:

Na política de autorização, criamos uma nova regra e selecionamos esse profile nela:

Ah, reparem na condição “Identity-AD-Admins”. Essa condição fui eu que criei e ela simplesmente checa se o usuário faz parte do grupo AD-Admins que criamos acima.

Selecionando a condição “IdentityGroup Name”, ao clicar no box abaixo, você seleciona o grupo que você quer e pronto.

Veja como fica:

E, finalmente, tudo pronto!

Vamos testar? Reparem no privilégio que o usuário recebe ao se autenticar.

A política de autenticação ainda é a “Default”, mas ela só puxa usuários do AD e não mais de todas as bases configuradas no ISE. A política de autorização é que a nós criamos: Network Admins (AD), e entrega privilégio 15 automaticamente para os membros do grupo AD-Admins.

E assim finalizamos por hoje! No próximo artigo faremos o mesmo com TACACS, mas iremos autorizar apenas alguns comandos específicos!

Esse foi o último artigo do ano de 2020 e quero aproveitar e desejar a todos um excelente Natal e um Ano Novo com muitos desafios, pois são eles que nos empurram pra frente e nos faz termos sucesso na vida profissional!

Um abraço!

Se você gostou, deixa seu “claps” aí do lado esquerdo e compartilhe nos seus grupos. Você também pode me seguir e a TechRebels!

Sobre o autor:

Fernando Mantovani Pierobon trabalha há 18 anos na área de TI sendo 14 com segurança da tecnologia da informação.

É formado em Ciências da Computação e CCIE Security #63268.

https://www.linkedin.com/in/fernandomantova

--

--