4 posts tagged with "autorização"

Artigo originalmente publicado no medium em Março de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal, tudo bem?

Continuando nossa série sobre o ISE - começamos pelo básico nos artigos ISE Basics - Parte 1 e ISE Basics - Parte 2 e depois fizemos um lab completo no último artigo: Cisco ISE - Autenticação MAB e 802.1X - vamos agora customizar as políticas de autenticação e autorização.

A intenção é que você perceba a granularidade do ISE.

Nosso objetivo: Vamos negar a regra padrão de autenticação e não vamos mexer na regra de MAB. Mas, para 802.1X, vamos autenticar apenas os switches dentro do grupo "Switches" e os usuários criados localmente no ISE que fazem parte do grupo Lab_Admin. Por fim, para essa mesma regra, vamos aplicar uma VLAN e uma DACL (Downloadable ACL) caso a autenticação seja bem sucedida.

Lembrando que esse artigo é uma continuação dos anteriores, caso você não entenda algo, consulte eles, ok?

Vamos começar clicando em Policy > Conditions > Authentication e Compound Conditions. Aqui, vamos criar uma nova condição para que uma autenticação ocorra. Nela vamos selecionar apenas o grupo "Switches" que criamos nos artigos anteriores, que é onde colocamos o nosso switch de teste "SW1".

Agora aplicamos essa nova condição. Vá para Policy > Authentication, negue a última regra padrão (isso só para essa versão que estamos usando, a 2.1) e edite a regra de Dot1x. Na condição, remova Wireless_802.1x, altere a regra para AND, e selecione a condição que criamos acima. Por fim, na última caixa, altere qual base de dados o ISE irá pesquisar. Altere de All_User_ID_Stores para Internal Users. Ou seja, apenas usuários criados localmente poderão se autenticar. Caso houvesse uma base do AD integrada (futuramente faremos isso), esses usuários externos não poderiam se autenticar. Por fim, salve tudo.

Vamos agora para Policy > Authorization e crie uma nova regra. Nomeie como está abaixo e edite a condição. Selecione dentro de User Identities Store, o grupo Lab_Admin. É nesse grupo que nosso usuário de teste "Fernando" está inserido (também foi criado nos artigos anteriores).

Ligue a VM do Windows e vamos testar a autenticação, que ocorrerá com sucesso. Veja abaixo em Operations > Radius > Live Logs.

Caso tentemos autenticar um usuário "Henrique" que eu criei agora, mas não faz parte do grupo Lab_Admin, veja o resultado:

O processo de autenticação passou, pois a condição para o switch está OK, mas o usuário não obteve autorização para o login. O processo deu match na nossa regra de autenticação mas, na autorização, ele bateu na regra default, que nega o acesso. Analise a figura pra entender bem. A quantidade de informação é grande, e isso facilita muito o troubleshooting.

Cavando um pouquinho mais, vamos agora ao invés de apenas permitir o acesso, vamos criar um profile e aplicar configurações no switch, caso a autenticação seja bem sucedida.

Clique em Policy > Policy Elements > Results > Authorization > Downloadable ACLs. Conforme a figura, vamos criar uma ACL que será enviada pelo ISE para o switch especificamente para esse usuário nessa porta que ele se autenticou.

A granularidade aqui é de uma ACL comum ok? No nosso exemplo, vamos apenas negar o ping para o ISE. De resto, tudo permanece liberado.

Agora, ainda nesse menu, vá no item acima e à esquerda: Authorization Profiles. Acompanhe na figura, você irá escolher a DACL que criamos e também irá setar uma VLAN específica para esse usuário. No nosso caso será a VLAN 1 mesmo, já que não criamos outra.

E aí ficou fácil! Vamos voltar pra Autenticação e Autorização e, ao invés de selecionar "PermitAccess", vamos escolher esse Authorization Profile que acabamos de criar. Veja, como ficou:

Vamos testar novamente a autenticação. Dê um bounce na placa de rede, e um clear authentication sessions no switch. Entre com o usuário "Fernando" na caixa que vai aparecer no Windows e analise os logs:

Repare acima que a ACL foi enviada com sucesso para o switch.

Abrindo o log da ACL (na lupinha em Details), veja a mensagem de sucesso e o nosso network device "SW1".

No switch, entre com o comando show authentication sessions int e0/2 details e você terá o seguinte:

SW1#show authe sessions int e0/2 details
            Interface:  Ethernet0/2
          MAC Address:  5000.0003.0000
         IPv6 Address:  Unknown
         IPv4 Address:  10.1.1.2
            User-Name:  fernando
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
      Restart timeout:  N/A
Periodic Acct timeout:  N/A
       Session Uptime:  49s
    Common Session ID:  0A01010A0000000E000E343B
      Acct Session ID:  0x00000004
               Handle:  0xA9000002
       Current Policy:  POLICY_Et0/2
Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecure
Server Policies:
           Vlan Group:  Vlan: 1
              ACS ACL:  xACSACLx-IP-Switches_DACL-5e5a93c0
Method status list:
      Method            State
mab                Stopped
      dot1x              Authc Success

Repare na sessão "Server Policies" destacada. Você verá que foi aplicada a vlan 1 e a ACL que criamos nessa interface eth0/2 apenas.

Para complementar, veja também o show ip access-list.

SW1#show ip access-list
Extended IP access list xACSACLx-IP-Switches_DACL-5e5a93c0 (per-user)
    1 deny icmp any host 10.1.1.100
    2 permit ip any any

Finalizando, vá para a máquina Windows e tente pingar o IP 10.1.1.100 e também o 10.1.1.10 (que é o SW1) ;D

Muito obrigado por lerem e espero que tenham curtido o artigo! Tem muito mais coisa interessante pela frente.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Dezembro de 2020 pelo mesmo autor. As configurações e exemplos continuam válidos.

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!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Janeiro de 2021 pelo mesmo autor. As configurações e exemplos continuam válidos.

Fala pessoal!! Seguindo nossa série, recentemente integramos o ISE com AD, fizemos AAA com Radius e agora vamos fazer o mesmo com TACACS, mas adicionando command authorization.

Nosso objetivo é permitir que um usuário se logue automaticamente com privilégio 15 mas, de forma granular, permitir apenas alguns comandos específicos.

O primeiro passo é ativar o serviço no ISE. Fazemos isso nessa tela:

Em seguida, nesse menu, temos uma visão geral dos passos necessários:

Primeiramente, vamos então adicionar o nosso network device (já fizemos isso nos outros artigos):

Pronto! Vamos criar agora o command set - grupo de comandos que iremos permitir o usuário dar no router. Atente-se à sintaxe, não pode haver erros! Não há checagem por parte do ISE.

Agora vamos criar o Profile. Repare nos menus. A única informação que vamos colocar é o privilégio 15 automático para o usuário.

Feito isso, vamos editar a política de autenticação padrão para buscar o usuário apenas no AD que configuramos no artigo passado.

Repare na estrutura de menu que se trata de outra Policy Set. É uma base de políticas diferente da utilizada pelo Radius. No entanto, elas possuem o mesmo formato.

Na política de autorização, nós definimos o Command Set que criamos, o Profile e, na condição, selecionei apenas o Network Device com o nome "R2". Ou seja, essa condição não se aplica a nenhum outro eqto da rede, apenas a esse router em específico.

Ao logar, o usuário fernando do AD, recebe direto o prompt privilegiado, mas não é possível entrar com o comando show privilege, já que não o permitimos no command set que criamos acima.

Veja abaixo os comandos que permitimos e os que foram negados. Por ex: não permitimos o router rospf, mas permitimos o router eigrp.

Qto aos logs do TACACS, eles são consultados nesse menu:

Um exemplo de log de comando autorizado:

Um exemplo de log de comando não autorizado:

Por fim, mas igualmente importante a config toda do router (também já detalhada nos artigos anteriores):

aaa new-model
!
!
aaa group server tacacs+ ISE_TACACS
 server name ISE_TACACS
!
aaa authentication login NOAUTH none
aaa authentication login ISE_TACACS group ISE_TACACS
aaa authorization config-commands
aaa authorization exec ISE_TACACS group ISE_TACACS
aaa authorization commands 1 ISE_TACACS group ISE_TACACS
aaa authorization commands 15 ISE_TACACS group ISE_TACACS
aaa accounting exec ISE_TACACS start-stop group ISE_TACACS
aaa accounting commands 15 ISE_TACACS start-stop group ISE_TACACS
!
interface Ethernet0/1
 ip address 10.0.0.11 255.255.255.0
!
tacacs server ISE_TACACS
 address ipv4 10.0.0.100
 key cisco123
!
line con 0
 logging synchronous
 login authentication NOAUTH
line aux 0
line vty 0 4
 authorization commands 1 ISE_TACACS
 authorization commands 15 ISE_TACACS
 authorization exec ISE_TACACS
 login authentication ISE_TACACS
 transport input ssh

Importante destacar 3 comandos nessa config:

aaa authorization config-commands

"Config-Commands" significa que o network device precisa obter autorização para comandos dados dentro do prompt de configuração (configure terminal)

aaa authorization commands 15 ISE_TACACS group ISE_TACACS

O "15" significa autorização para comandos de usuários que possuem privilege level 15

aaa accounting commands 15 ISE_TACACS start-stop group ISE_TACACS

E, finalmente, o accounting commands 15, que irá logar cada comando no nível de privilégio 15.

Espero que tenham curtido.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo:

Artigo originalmente publicado no medium em Dezembro de 2019 pelo mesmo autor. As configurações e exemplos continuam válidos.

Vamos continuar agora com o nosso tour pelo ISE. Caso você não tenha lido o primeiro artigo, o link é esse aqui: ISE Basics - Parte 1.

Começando pela tela Administration > System > Admin Access e aba Password Policy: Aqui fazemos a configuração da política de senha e autenticação de usuários da GUI e da CLI - usuários de acesso administrativo ao software ISE.

Repare nas possibilidades: tamanho mínimo de senha, histórico, requisito mínimo de complexidade, bloqueio após tentativas incorretas, e etc.

Nessa mesma tela, em Authorization, temos uma ótima granularidade para definir o que cada usuário administrativo pode ou não fazer. Acesso a menus específicos, permissão para criar outros usuários e etc.

Essa possibilidade é bem útil caso tenhamos vários admins olhando pro ISE. Teríamos então um grupo Help Desk com possibilidade de read-only, um grupo Operadores, com permissão de troubleshooting ou review básico de autenticação, e um grupo Admin, que poderia criar e adicionar devices e novas regras - esses são apenas exemplos de possibilidades 😉

Administration > Identity Management. Aqui já começaremos a falar dos usuários de rede, ou seja, usuários que serão utilizados para acesso a recursos da rede (seja Internet, servidores específicos, etc.), via protocolo RADIUS ou TACACS+.

Abaixo, faremos a criação de um usuário como exemplo. Dois pontos de destaque nesse processo:

• Em Password Type, podemos utilizar uma senha que será armazenada na base de dados do ISE ou em uma base externa, como um Microsoft Active Directory (é necessário integração antes, mostraremos em artigos futuros ok?).
• E mais pra baixo, podemos adicionar esse usuário em grupos, que são criados na aba seguinte.

Aqui vemos dois tipos de grupos: usuários e endpoints. Isso porque o ISE autentica não só usuários como também dispositivos.

Esses dispositivos podem ser criados manualmente ou automaticamente, através da funcionalidade de Profiling que comentamos no artigo anterior. Dessa forma, como o ISE pode identificar iPhones, máquinas Windows 7, Linux, Smartphone Samsung, impressoras HP entre outros, podemos criar regras permitindo que apenas um tipo de equipamento acesse determinado recurso na rede. Granularidade total! 😊

A próxima tela External identity Sources, é onde configuramos a integração de uma base de usuários externa com o ISE. Em destaque o Active Directory que é o mais usual.

A próxima tela é a Identity Sources Sequences que trataremos mais pra frente, e a última é a Settings, bem parecida com a tela que falamos no início do artigo. Aqui, nós definiremos a política de usuários para acesso aos recursos da rede, diferente do acesso administrativo ao ISE que falamos acima.

Bom, agora que já temos um usuário e um grupo no ISE, vamos configurar o NAD (Network Access Device). O dispositivo que irá consultar o ISE para confirmar a autenticação e aplicar a política de autorização.

Aqui estamos só tratando da criação do NAD, o processo todo de autenticação será no próximo artigo blz?

Vamos adicionar então nome, IP, e senha do RADIUS.

Na lista, ele irá aparecer dessa forma:

Os NADs também podem ser alocados em grupos, seja por tipo ou localização. Planejar é fundamental para a organização da rede 😉

E, finalmente, vamos pra tela Policy aba Authentication.

Esse é o padrão do ISE nessa versão.

A primeira regra é de MAB - Mac Authentication Bypass, que autentica o MAC Address, ou seja, estamos falando de camada 2.

Traduzindo a regra, significa: SE a autenticação for para MAC Address cabeada (wired) ou wireless, em protocolos permitidos na regra padrão de nome Default Network Access - falaremos mais para frente dela - e, caso esse dispositivo (notebook, celular, etc.) estiver criado na base do ISE, aí ele passará para a próxima etapa: Autorização.

Agora que já sabemos que o usuário foi autenticado com sucesso, vamos definir O QUE ELE PODE FAZER. Essa configuração é feita na tela Authorization.

Abaixo, as regras padrão do ISE nessa versão 2.1.

No próximo artigo, faremos a configuração do switch e uma autenticação básica inicial.

Um abraço!!

Você pode baixar esse artigo em formato PDF no botão abaixo: