Implante a postura do ISE

Introdução

Este documento descreve algumas configurações de linha de base que tratam de vários casos de uso com postura baseada em redirecionamento.

Restrições

As configurações neste documento funcionam para NADs da Cisco, mas não necessariamente para NADs de terceiros.

Comportamento do cliente de postura

O cliente de postura pode acionar testes nestes momentos:

• Login inicial
• Alteração de Camada 3 (L3)/Alteração de Placa de Interface de Rede (NIC) (novo endereço IP, alteração de estado da NIC)

Casos de uso 

Caso de uso 1 - A reautenticação do cliente força o NAD a gerar uma nova ID de sessão.

Neste caso de uso, o cliente ainda é compatível, mas devido à reautenticação, o NAD está no estado de redirecionamento (URL de redirecionamento e lista de acesso).

Por padrão, o Identity Services Engine (ISE) é configurado para executar uma avaliação de postura toda vez que se conecta à rede, mais especificamente para cada nova sessão.

Essa configuração é definida em Centros de trabalho > Postura > Configurações > Configurações gerais de postura.

Para evitar que o NAD gere uma nova ID de sessão na reautenticação, configure esses valores de reautenticação no perfil de autorização. O temporizador de reautenticação exibido não é uma recomendação padrão e considera temporizadores de reautenticação por implantação com base no tipo de conexão (sem fio/com fio), design (quais são as regras de persistência no balanceador de carga) e assim por diante.

Política > Elementos de Política > Resultados > Autorização > Perfis de Autorização

Nos switches, você precisa configurar cada interface, ou modelo, para obter seu temporizador de reautenticação do ISE. 

authentication timer reauthenticate server

Observação: se houver um balanceador de carga, você precisará verificar se a persistência está configurada de forma que as reautenticações possam ser retornadas ao PSN (Serviço de Política) original.

Caso de uso 2 - O switch é configurado com MAB DOT1X de ordem e DOT1X MAB de prioridade (com fio).

Nesse caso, as reautenticações podem ser terminadas, pois uma interrupção de contabilização para a sessão 802.1x pode ser enviada quando o MAC Authentication Bypass (MAB) é tentado durante a reautenticação.

• A interrupção de contabilidade enviada para o processo MAB quando ele falha na autenticação está correta, pois o nome de usuário do cliente muda do nome de usuário 802.1X para o nome de usuário MAB.
• Dot1x como o method-id na parada contábil também está correto, pois o método de autorização foi dot1x.
• Quando o método Dot1x é bem-sucedido, ele envia um início de contabilização com method-id como dot1x. Aqui também, esse comportamento é o esperado.

Para resolver esse problema, configure o cisco-av-pair:termination-action-modifier=1 no perfil authZ usado quando um ponto final é compatível. Esse par atributo-valor (AV) especifica que o NAD reutiliza o método escolhido na autenticação original, independentemente da ordem configurada.

Caso de uso 3 - Os clientes sem fio fazem roaming e as autenticações para APs diferentes estão indo para controladores diferentes.

Para essa situação, a rede sem fio precisa ser projetada de modo que os pontos de acesso (APs) ao alcance de outros APs para roaming usem o mesmo controlador ativo. Um exemplo é o failover de comutação dinâmica (SSO - Stateful Switchover) da controladora Wireless LAN (WLC). Para obter mais informações sobre o High Availability (HA) SSO for WLC, consulte o Guia de implantação de alta disponibilidade (SSO).

Caso de uso 4 - Implantações com balanceadores de carga (Pré 2.6 Patch 6, 2.7 Patch P2 e 3.0).

Em implantações com balanceadores de carga envolvidos, é importante certificar-se de que depois de fazer as alterações nos casos de uso anteriores, as sessões continuem indo para a mesma PSN. Antes da versão/patches listados para esta etapa, o status da postura não é replicado entre os nós através da Distribuição de Dados Light (anteriormente Light Session Diretory). Por causa disso, é possível que diferentes PSNs retornem diferentes resultados de status de postura.

Se a persistência não for configurada corretamente, as sessões que reautenticam podem ir para uma PSN diferente daquela que foi usada originalmente. Se isso acontecer, o novo PSN poderá marcar o status de conformidade das sessões como desconhecido e passar o resultado de authZ com a lista de controle de acesso (ACL)/URL de redirecionamento e limitar o acesso dos pontos finais. Novamente, essa alteração no NAD não seria reconhecida pelo módulo de postura e os testes não seriam acionados.

Para obter mais informações sobre como configurar balanceadores de carga, consulte Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP. Ele fornece uma visão geral de alto nível e a configuração específica da F5 de um projeto de práticas recomendadas para implantações do ISE em um ambiente com balanceamento de carga.

Caso de uso 5 - As sondas de descoberta do estágio 2 são respondidas por um servidor diferente do qual o cliente está autenticado (Pré 2.6 Patch 6, 2.7 Patch 2 e 3.0).

Examine os probes dentro da caixa vermelha neste diagrama.

As PSNs armazenam dados de sessão por cinco dias, portanto, às vezes, os dados de sessão de uma sessão "compatível" ainda residem na PSN original, mesmo que o cliente não se autentique com esse nó. Se os testes incluídos na caixa vermelha forem respondidos por uma PSN diferente daquela que autentica atualmente a sessão E que a PSN já possuiu e marcou este endpoint como compatível, é possível que haja uma incompatibilidade entre o status de postura do módulo de postura no endpoint e a PSN de autenticação atual.

Aqui estão alguns cenários comuns em que essa incompatibilidade pode ocorrer:

• Não é recebida uma interrupção de contabilização para um ponto final quando ele se desconecta da rede.
• O NAD fez failover de uma PSN para outra.
• Um balanceador de carga encaminha autenticações para PSNs diferentes para o mesmo ponto final.

Para se proteger desse comportamento, o ISE pode ser configurado para permitir apenas que as sondas de descoberta de um ponto de extremidade específico acessem a PSN na qual está autenticado no momento. Para conseguir isso, configure uma política de autorização diferente para cada PSN em sua implantação. Nessas políticas, faça referência a um perfil authZ diferente que contenha uma lista de controle de acesso para download (DACL) que permita testes SOMENTE para o PSN especificado na condição authZ. Veja este exemplo:

Cada PSN tem uma regra para status de postura desconhecida:

Cada perfil individual faz referência a uma DACL diferente.

Observação: para redes sem fio, use as ACLs do Airespace.

Cada DACL só permite acesso de teste ao PSN que manipula a autenticação.

No exemplo anterior, 10.10.10.1 é o endereço IP de PSN 1. A DACL referenciada pode ser alterada para qualquer serviço/IP adicional conforme necessário, mas limita o acesso somente à PSN que lida com a autenticação.

Alteração de Comportamento Pós 2.6 Patch 6, 2.7 Patch 2 e 3.0

O status da postura foi adicionado ao Diretório de Sessão RADIUS através da estrutura de Distribuição de Dados Light. Cada vez que uma atualização de status de postura é recebida em qualquer PSN, replicada para TODAS as PSNs na implantação. Quando essa alteração estiver em vigor, as implicações de autenticações e/ou testes que alcançam diferentes PSNs em diferentes autenticações serão removidas e qualquer PSN poderá responder a todos os endpoints, independentemente de onde estejam autenticados no momento.

Nos cinco casos de uso neste documento, considere estes comportamentos:

Caso de uso 1 - A reautenticação do cliente força o NAD a gerar uma nova ID de sessão. O cliente ainda é compatível, mas devido à reautenticação, o NAD está no estado de redirecionamento (URL de redirecionamento e lista de acesso).

- Esse comportamento não muda e essa configuração ainda pode ser implementada no ISE e nos NADs.

Caso de uso 2 - O switch é configurado com MAB DOT1X de ordem e DOT1X MAB de prioridade (com fio).

- Esse comportamento não muda e essa configuração ainda pode ser implementada no ISE e nos NADs.

Caso de uso 3 - Os clientes sem fio fazem roaming e as autenticações para APs diferentes estão indo para controladores diferentes.

- Esse comportamento não muda e essa configuração ainda pode ser implementada no ISE e nos NADs.

Caso de uso 4 - Implantações com balanceadores de carga.

- As melhores práticas definidas no guia de balanceamento de carga ainda podem ser seguidas, mas caso as autenticações sejam encaminhadas a diferentes PSNs pelo balanceador de carga, o status correto da postura poderá ser retornado ao cliente.

Caso de uso 5 - As sondas de descoberta do estágio 2 são respondidas por um servidor diferente do qual o cliente é autenticado

- Isso não pode ser um problema com o novo comportamento e o perfil de autorização por PSN é desnecessário.

Considerações ao manter a mesma SessionID

Quando você usa os métodos listados neste documento, um usuário que permanece conectado à rede pode permanecer compatível por longos períodos. Embora eles se reautentiquem, o ID da sessão não é alterado e, portanto, o ISE continua a passar o resultado de AuthZ para sua regra que corresponde ao status de conformidade.

Nesse caso, a reavaliação periódica precisa ser configurada para que a postura seja necessária para garantir que o endpoint permaneça em conformidade com as políticas corporativas em intervalos definidos.

Isso pode ser configurado em Centros de trabalho > Postura > Configurações > Configurações de reavaliação.