Solucionar problemas de gerenciamento e postura de sessão do ISE
Contents
Introdução
Este documento descreve o problema comum de serviços de postura do Identity Service Engine (ISE) como "O módulo de postura do ISE do AnyConnect mostra compatível..."
Informações de Apoio
Este documento descreve o problema comum dos serviços de postura do Identity Service Engine (ISE): "O módulo de postura do AnyConnect ISE mostra compatível enquanto o status da sessão no ISE está pendente."
Embora os sintomas sejam sempre os mesmos, há várias causas raiz para esse problema. Frequentemente, a solução de problemas como esse consome muito tempo, causando sérios impactos.
Este documento explica:
- Cenários problemáticos comuns.
- Algoritmos de identificação rápida de problemas.
- Soluções clássicas para cenários problemáticos comuns.
- Compartilhamento de status de postura sobre o diretório de sessão Radius.
- Manifestação de problemas a partir das perspectivas do usuário final e do administrador do ISE.
- A teoria por trás do ISE, AnyConnect e operações de rede que desencadeia o problema.
Para obter uma melhor explicação dos conceitos descritos mais adiante, consulte Comparação de estilo de postura do ISE para Pré e Pós 2.2
Problema
Experiência do usuário final
Esse problema normalmente se manifesta na ausência de acesso à rede ou redirecionamento constante para o portal de provisão do cliente ISE no navegador enquanto, ao mesmo tempo, o módulo de postura do AnyConect ISE mostra o status de postura como Compatível.
Experiência de usuário final típica:
Experiência do administrador do ISE
Ao fazer a triagem inicial desse problema, um administrador do ISE inicia uma investigação dos logs do Radius Live para garantir que uma autenticação atinja o ISE. O primeiro sintoma descoberto nesse estágio indica uma incompatibilidade em um status de postura entre o endpoint e o ISE nos registros em tempo real. Ou, os relatórios de autenticação Radius da última autenticação bem-sucedida para o endpoint mostram o status de postura Pending.
Experiência típica do administrador do ISE:
- Última autenticação bem-sucedida para Identidade: alice.
- O status da postura da sessão é Pendente.
- Último evento de sessão para Identidade: alice.
- O evento de sessão mostra o status da postura como Compatível.
Cenários problemáticos comuns
Esse problema normalmente se manifesta em dois cenários problemáticos e cada um deles tem várias causas raiz. Os cenários:
- O módulo de postura do ISE do AnyConnect foi mal informado pelo Policy Service Node (PSN) durante o processo de postura que fez com que o status de postura errado fosse exibido. Nesse caso, o TAC normalmente funciona com uma sessão obsoleta ou fantasma no cache da sessão PSN.
- O AnyConnect ISE mostra o status de postura do ciclo de descoberta anterior porque a autenticação atual não acionou um processo de descoberta.
O módulo de postura do ISE no AnyConnect tem um número limitado de eventos que acionam o processo de descoberta. É possível que, durante a autenticação ou a reautenticação, nenhum desses eventos tenha sido detectado.
Problema de Sessão Obsoleta/Fantasma
Para entender melhor o problema, investigue a lógica de gerenciamento de sessão do ISE necessária e o processo de descoberta do AnyConnect.
Lógica de gerenciamento de sessão do ISE
Na implantação do ISE, há duas pessoas responsáveis pelo processo de gerenciamento de sessão: PSN e MNT (Monitoring Node, nó de monitoramento). Para solucionar e identificar corretamente o problema, é fundamental entender a teoria do gerenciamento de sessão em ambas as personas.
MNT e gerenciamento de sessão
Como explicado nesta imagem, o nó MNT cria estações com base nas mensagens de Syslog de autenticação aprovadas que vêm de PSNs. O status da sessão pode ser atualizado posteriormente pelo Syslog para contabilização.
A remoção de sessão no MNT acontece em três cenários:
1. As sessões sem início de contabilização foram removidas aproximadamente 60 minutos após terem sido criadas. Há um trabalho cron executado a cada 5 minutos para verificar o status da sessão e limpá-la.
2. A sessão encerrada foi removida aproximadamente 15 minutos após a interrupção da contabilidade ter sido processada pelo mesmo trabalho cron.
3. O mesmo cron em cada execução remove sessões no estado 'Iniciado' por mais de 5 dias (120 horas). Um estado iniciado significa que o nó MNT processou tanto a autenticação quanto a contabilidade para iniciar a sessão Syslog.
Note: Estes são os temporizadores normais de limpeza do MnT, não há garantia de tempo de exclusão do relógio de parede. A remoção pode ser atrasada se:
- SessionPurgeJob não está sendo executado com êxito.
- MnT está sob pressão de recursos ou banco de dados.
- O Accounting-Stop não pode ser correlacionado à sessão existente.
Exemplos de mensagens de Syslog do PSN:
As mensagens são registradas no prt-server.log quando o componente runtime-aaa é habilitado em DEBUG. As partes em negrito podem ser usadas para construir expressões regulares de pesquisa.
Autenticação aprovada:
AcsLogs,2020-04-07 10:07:29,202,DEBUG,0x7fa0ada91700,cntx=0000629480,sesn=skuchere-ise26-1/375283310/10872,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:53:24.288 +02:00 0000423024 5200 NOTICE Passed-Authentication: Authentication succeeded, ConfigVersionId=87, Device IP Address=10.62.148.108, DestinationIPAddress=192.168.43.26, DestinationPort=1812, UserName=bob@example.com, Protocol=Radius, RequestLatency=45, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Service-Type=Framed, Framed-IP-Address=192.168.255.205, Framed-MTU=1472, State=37CPMSessionID=0A3E946C00000073559C0123\;42SessionID=skuchere-ise26-1/375283310/10872\;, Calling-Station-ID=00-50-56-B6-0B-C6, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, EAP-Key-Name=, cisco-av-pair=service-type=Framed, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, cisco-av-pair=client-iif-id=526638260, NetworkDeviceProfileName=Cisco, NetworkDeviceProfileId=b0699505-3150-4215-a80e-6753d45bf56c, IsThirdPartyDeviceFlow=false, RadiusFlowType=Wired802_1x, AcsSessionID=skuchere-ise26-1/375283310/10872, AuthenticationIdentityStore=EXAMPLE, AuthenticationMethod=MSCHAPV2, SelectedAccessService=Default Network Access, SelectedAuthorizationProfiles=PermitAccess, IsMachineAuthentication=false, IdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Step=11001, Step=11017, Step=15049, Step=15008, Step=15048, Step=15048, Step=15048, Step=11507, Step=12500, Step=12625, Step=11006, Step=11001, Step=11018, Step=12301, Step=12300, Step=12625, Step=11006, Step=11001, Step=11018, Step=12302, Step=12318, Step=12800, Step=12805, Step=12806, Step=12807, Step=12808, Step=12810, Step=12811, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12318, Step=12812, Step=12813, Step=12804, Step=12801, Step=12802, Step=12816, Step=12310, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12313, Step=11521, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11522, Step=11806, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11808, Step=15041, Step=22072, Step=15013, Step=24210, Step=24216, Step=15013, Step=24430, Step=24325, Step=24313, Step=24319, Step=24323, Step=24343, Step=24402, Step=22037, Step=11824, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11810, Step=11814, Step=11519, Step=12314, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=24715, Step=15036, Step=24209, Step=24211, Step=24432, Step=24325, Step=24313, Step=24319, Step=24323, Step=24355, Step=24416, Step=15048, Step=15016, Step=22081, Step=22080, Step=12306, Step=11503, Step=11002, SelectedAuthenticationIdentityStores=Internal Users, SelectedAuthenticationIdentityStores=All_AD_Join_Points, SelectedAuthenticationIdentityStores=Guest Users, AuthenticationStatus=AuthenticationPassed, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, IdentityPolicyMatchedRule=Dot1X, AuthorizationPolicyMatchedRule=Compliant-Wired, EapTunnel=PEAP, EapAuthentication=EAP-MSCHAPv2, CPMSessionID=0A3E946C00000073559C0123, EndPointMACAddress=00-50-56-B6-0B-C6, PostureAssessmentStatus=NotApplicable, EndPointMatchedProfile=Microsoft-Workstation, ISEPolicySetName=Default, IdentitySelectionMatchedRule=Dot1X, AD-User-Resolved-Identities=bob@example.com, AD-User-Candidate-Identities=bob@example.com, AD-User-Join-Point=EXAMPLE.COM, StepData=4= Radius.NAS-IP-Address, StepData=5= Cisco-VPN3000.CVPN3000/ASA/PIX7x-Tunnel-Group-Name, StepData=6= DEVICE.Device Type, StepData=77=All_User_ID_Stores, StepData=78=Internal Users, StepData=81=All_AD_Join_Points, StepData=82=All_AD_Join_Points, StepData=83=bob@example.com, StepData=84=example.com, StepData=85=example.com, StepData=87=bob@example.com, StepData=88=All_AD_Join_Points, StepData=109=EXAMPLE, StepData=110=bob@example.com, StepData=111=example.com, StepData=112=example.com, StepData=114=example.com, StepData=115=EXAMPLE, StepData=116= EXAMPLE.ExternalGroups, AD-User-Resolved-DNs=CN=bob\,CN=Users\,DC=example\,DC=com, AD-User-DNS-Domain=example.com, AD-Groups-Names=example.com/Users/Domain Users, AD-User-NetBios-Name=EXAMPLE, IsMachineIdentity=false, UserAccountControl=66048, AD-User-SamAccount-Name=bob, AD-User-Qualified-Name=bob@example.com, allowEasyWiredSession=false, TLSCipher=ECDHE-RSA-AES256-GCM-SHA384, TLSVersion=TLSv1.2, DTLSSupport=Unknown, HostIdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, IdentityAccessRestricted=false, PostureStatus=Compliant, Response={Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872; EAP-Key-Name=19:5e:8c:e9:13:0c:89:23:78:49:ad:2b:d4:31:63:51:27:81:db:e2:61:b1:51:36:6d:11:10:41:ce:3b:aa:cc:c6:66:4e:7c:92:f8:83:c5:06:84:ac:95:4c:5b:f1:b2:37:a2:f5:04:4e:9e:4d:08:79:55:b7:4d:9a:41:f5:b2:0a; MS-MPPE-Send-Key=****; MS-MPPE-Recv-Key=****; LicenseTypes=65541; },],MessageFormatter.cpp:107
Início da Contabilização:
AcsLogs,2020-04-07 10:07:30,202,DEBUG,0x7fa0ad68d700,cntx=0000561096,sesn=skuchere-ise26-1/375283310/10211,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 10:07:30.857 +02:00 0000382874 3000 NOTICE Radius-Accounting: RADIUS Accounting start request, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=7, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10210, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Start, Acct-Delay-Time=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Event-Timestamp=1586279242, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10211, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=15048, Step=22083, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
Atualização Provisória de Contabilidade:
AcsLogs,2020-04-07 22:57:48,642,DEBUG,0x7fa0adb92700,cntx=0000629843,sesn=skuchere-ise26-1/375283310/10877,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:57:48.650 +02:00 0000423268 3002 NOTICE Radius-Accounting: RADIUS Accounting watchdog update, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=8, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Interim-Update, Acct-Delay-Time=0, Acct-Input-Octets=2293926, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Input-Packets=15785, Acct-Output-Packets=0, Event-Timestamp=1586325462, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10877, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22085, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
Interrupção da Contabilização:
AcsLogs,2020-04-08 11:43:22,356,DEBUG,0x7fa0ad68d700,cntx=0000696242,sesn=skuchere-ise26-1/375283310/11515,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-08 11:43:22.368 +02:00 0000463071 3001 NOTICE Radius-Accounting: RADIUS Accounting stop request, ConfigVersionId=88, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=12, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/11503, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Stop, Acct-Delay-Time=0, Acct-Input-Octets=4147916, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Session-Time=92157, Acct-Input-Packets=29120, Acct-Output-Packets=0, Acct-Terminate-Cause=Lost Carrier, Event-Timestamp=1586371399, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, Framed-IPv6-Address=2001:10::100, Framed-IPv6-Address=2001:10::101, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/11515, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22084, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
PSN e gerenciamento de sessão
O cache da sessão PSN é um banco de dados na memória que armazena todas as sessões ativas de PSN específicas. O cache da sessão é sempre local para o nó. Não há nenhum mecanismo no ISE que possa executar a replicação de estados de sessão FULL de um nó para outro.
Para cada ID de sessão ativa, o PSN armazena todos os atributos coletados durante a fase de autenticação/autorização (por exemplo, grupos de usuários internos/externos, atributos de dispositivo de acesso à rede (NAD), atributos de certificado e assim por diante). Esses atributos são usados pela PSN para selecionar diferentes tipos de política, como Autenticação, Autorização, Provisionamento de Cliente e Postura.
O cache da sessão é completamente removido quando o nó (ou serviços no nó) são reiniciados.
A lógica de processamento da sessão atual cria uma nova entrada no cache de sessão em dois cenários. Detalhes posteriores de sessões existentes podem ser atualizados a partir de mensagens de relatório, que vêm de NADs.
- A sessão foi autenticada com êxito no PSN.
- O PSN tem uma atualização provisória de contabilização para a sessão que não existe no cache da sessão. Com a remoção da sessão, a PSN implementa esta lógica:
- A entrada de cache da sessão é removida imediatamente após o processamento da mensagem de interrupção de contabilização.
- O PSN começa a remover as sessões menos usadas recentemente quando um nó atinge o limite de sessões ativas.
Sessão obsoleta no PSN
Na implantação do ISE, a interrupção da contabilização de uma sessão existente foi processada pelo PSN que não executou a autenticação real:
Exemplo da sessão obsoleta:
- A autenticação bem-sucedida acontece no PSN para a sessão ABC.
- A PSN cria uma entrada no cache da sessão.
- Ocorre avaliação de postura.
- A sessão está marcada como Compatível.
- A alteração de autorização (COA) é acionada pela alteração de status de postura, que leva à reautenticação do ponto final para aplicar o próximo nível de acesso.
- A contabilização para a sessão ABC para PSN2.
Depois, o ABC fica preso em um estado obsoleto no PSN1, pois não há nenhuma mensagem de parada de contabilização processada nesse PSN para removê-lo. A sessão será removida se a implantação não tiver um número alto de tentativas de autenticação.
A sessão obsoleta aparece no cache da sessão PSN nestes cenários:
- A parada de contabilização foi enviada para a PSN incorreta devido à expiração do temporizador de adesão no balanceador de carga.
- A configuração incorreta no NAD não é a mesma PSN configurada para autenticação e contabilização.
- Problemas de conectividade temporários no caminho de rede causaram failover de NAD para a próxima PSN.
Exemplo da sessão obsoleta no ambiente do Balanceador de Carga (LB):
- A autenticação inicial para a Sessão ABC é executada por PSN1. Essa autenticação inicia um temporizador de adesão no balanceador de carga.
- PSN1 cria uma entrada para a sessão ABC no cache local.
- A mensagem de Syslog para a autenticação passada é transferida para o nó MNT.
- A entrada para a sessão ABC é criada no diretório de sessão MNT com o estado Authenticated.
- A mensagem de início de contabilidade para a sessão ABC chega ao PSN1.
- A entrada do cache de sessão para a sessão ABC é atualizada com informações de Accounting-Start.
- A mensagem de Syslog para Accounting-Start é transferida para o nó MNT.
- O estado da sessão é atualizado para Iniciado.
- O temporizador de adesão expira no balanceador de carga.
- Accounting-Stop para a sessão ABC foi encaminhada pelo balanceador de carga para PSN2.
- A mensagem de Syslog para Accounting-Stop é encaminhada por PSN2 para MNT.
- A sessão ABC está marcada como terminada no MNT.
Sessão Fantasma na PSN
A sessão fantasma é um cenário em que a atualização temporária de contabilidade chega ao PSN e não executa a autenticação para essa sessão. Neste cenário, uma nova entrada é criada no cache da sessão PSN. Se o PSN não receber uma mensagem de interrupção de contabilização para essa sessão, a entrada não será removida, a menos que o PSN atinja o limite de sessões ativas.
Exemplo da sessão fantasma:
- As mesmas etapas descritas no exemplo de sessão obsoleta ocorrem em PSN1 para a sessão ABC.
- A sessão ABC tem um status de Compliant no cache da sessão PSN1.
- Uma atualização provisória contábil para a sessão ABC atinge PSN2.
- Uma entrada de sessão para ABC é criada em PSN2. Como a entrada de sessão é criada a partir da mensagem contábil, ela tem um número limitado de atributos. Por exemplo, o status da postura não está disponível para a sessão ABC e os grupos de usuários ou outros atributos específicos de autorização também estão ausentes.
A sessão fantasma aparece no cache da sessão PSN nestes cenários:
- Interrupção de curto prazo no trânsito da rede.
- Comportamento incorreto do dispositivo de acesso à rede.
- Erro de comportamento ou configuração incorreta no balanceador de carga.
A próxima captura de tela é um exemplo de uma sessão fantasma na qual problemas temporários no caminho da rede em direção ao PSN1:
- A autenticação inicial para a sessão ABC é realizada pelo PSN.
- PSN1 cria uma entrada para a sessão ABC no cache local.
- A mensagem de syslog para a autenticação passada é transferida para o nó MNT.
- Uma entrada para a sessão ABC é criada no TimesTen DB com o estado Authenticated.
- A mensagem de início de contabilidade para a sessão ABC chega à PSN 1.
- Uma entrada de cache de sessão para a sessão ABC é atualizada com informações de Accounting-Start.
- A mensagem de Syslog para Accounting-Start é transferida para o nó MNT.
- O estado da sessão é atualizado para Iniciado.
- A atualização de Contabilidade Provisória para a sessão ABC é encaminhada para PSN2.
- PSN2 cria uma entrada para a sessão ABC no cache local.
- O Accounting-Stop da sessão ABC é encaminhado para PSN1.
- A entrada para a sessão ABC é removida do cache de sessão em PSN1.
- Uma mensagem de Syslog para Accounting-Stop é encaminhada por PSN1 para MNT.
- A sessão ABC está marcada como terminada no MNT.
Isso representa um cenário da sessão fantasma criada para a conexão VPN de longa duração:
- Autenticação inicial em PSN1.
- A sessão ABC é criada no cache da sessão.
- A contabilização inicia a mensagem processada pelo PSN.
- O novo endereço IP é atribuído ao adaptador VPN (Virtual Private Network).
- Uma atualização contábil temporária com as informações de endereço IP é incluída na PSN.
- As informações de endereço IP são adicionadas ao cache da sessão.
- A avaliação de postura ocorre com PSN1.
- O status da postura é atualizado na sessão.
- Um envio de COA é executado pelo ISE; isso aciona um novo nível de acesso a ser atribuído.
- Há uma interrupção no caminho da rede, o que torna o PSN1 inacessível.
- Após a expiração de um intervalo de atualização temporária, o ASA/FTD detecta que o PSN1 está inacessível.
- A atualização de contabilidade provisória chega ao PSN2.
- A sessão fantasma é criada no cache da sessão PSN2.
Se a PSN1 se tornar acessível posteriormente (14), todas as mensagens de relatório subsequentes serão encaminhadas (15,16) e isso deixará a sessão ABC no cache da sessão PSN2 por um tempo indefinido.
Como uma sessão obsoleta e uma sessão fantasma quebram o processo de postura
Para entender como as sessões obsoletas e fantasmas interrompem a postura, você pode rever o processo de descoberta do módulo de postura do AnyConnect ISE:
Estágio 1 Descoberta:
Durante esse estágio, o módulo de postura do ISE executa quatro testes simultâneos para localizar a PSN que autentica o endpoint.
Primeiro, três sondas na figura são baseadas em redirecionamento (IP GW padrão, IP host de descoberta (se definido) e IP enroll.cisco.com); esses testes sempre apontam o agente para a PSN direita, pois a URL redirecionada é retirada do próprio NAD.
A prova quatro é enviada a todos os servidores primários apresentados no arquivo ConnectionData.xml. Esse arquivo é criado após a primeira tentativa de postura bem-sucedida. O conteúdo do arquivo poderá ser atualizado posteriormente se o cliente migrar entre PSNs.
Nos sistemas Windows, o local do arquivo é C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.
Como todos os testes do estágio 1 são executados simultaneamente, os resultados do teste 4 são usados somente se todos os outros três testes falharem ou se o módulo de postura do ISE não puder estabelecer comunicação adequada com a PSN retornada na URL de redirecionamento em 5 segundos.
Quando a sonda quatro chega à PSN, ela contém uma lista de endereços IP e MAC ativos descobertos no ponto final. A PSN usa esses dados para localizar uma sessão para esse ponto final no cache local. Se a PSN tiver uma sessão obsoleta ou fantasma para um endpoint, isso pode resultar em um status de postura incorreto exibido posteriormente no lado do cliente.
Quando um agente recebe várias respostas para a prova quatro (ConnectionData.xml pode conter mais de uma PSN primária), a resposta mais rápida é sempre usada.
Estágio 2 Descoberta:
Todos os testes de detecção do estágio 2 são sem redirecionamento, o que significa que cada teste aciona uma pesquisa de sessão na PSN de destino. Se o PSN não puder localizar a sessão no cache da sessão local, ele deverá executar uma pesquisa MNT (somente com base no endereço MAC) para localizar um proprietário da sessão e retornar o nome do proprietário para o agente.
Como todos os testes acionam a pesquisa de sessão, a descoberta do estágio 2 pode ser afetada significativamente por problemas como resultado de sessões obsoletas ou fantasmas.
Se o PSN for para o Estágio 2, a investigação de descoberta que existe no cache de sessão criará uma entrada obsoleta ou fantasma para o mesmo ponto final. Isso resulta no status de postura incorreto retornado ao usuário final.
Este exemplo mostra como a postura aparece quando o PSN mantém uma sessão obsoleta ou uma sessão fantasma:
- Qualquer um dos testes Find my session emitidos pelo módulo de postura do ISE.
- O PSN realiza uma pesquisa de sessão no cache de sessão. Se a sessão for encontrada, ocorrerá um problema de sessão obsoleta ou fantasma.
- O PSN executa a seleção da política de provisionamento do cliente. Se uma sessão fantasma tiver uma falta de atributos de autenticação/autorização e todas as políticas configuradas por você forem específicas (por exemplo, as políticas são criadas para grupos específicos do Ative Diretory), o PSN não poderá atribuir uma política de provisionamento de cliente correta. Isso pode se manifestar na mensagem de erro: "Ignorar a verificação do AnyConnect em sua rede não está configurado para usar o Cisco NAC Agent".
- Nos casos em que as políticas de provisionamento do cliente são genéricas (os atributos disponíveis na sessão fantasma são suficientes para corresponder à política com uma configuração do AnyConnect), a PSN responde com detalhes necessários para a continuação do processo de avaliação.
- Nesta etapa, ao trabalhar com sessões obsoletas, a PSN responde imediatamente com um status de postura de Compatível e todas as próximas etapas não são concluídas. A PSN não envia COA porque acredita que a sessão já está em conformidade. Nos logs do Radius Live, não há um evento de sessão exibido com o status Compliant.
4. Para o cenário de sessão fantasma, o módulo de postura do ISE continua com a solicitação de postura inicial. Essa solicitação contém informações sobre todos os produtos de gerenciamento de segurança e patches detectados no endpoint.
5. A PSN usa as informações dos atributos request e session para corresponder à política de postura apropriada. A sessão fantasma tem uma falta de atributos neste ponto e não há política para corresponder. Nesse caso, a PSN responde ao endpoint que está em conformidade. Esse é o comportamento padrão do ISE se a política de postura não corresponder.
6. A PSN retorna as políticas de postura selecionadas de volta para o agente.
7. O agente retorna status para cada política/requisito como "aprovado" ou "com falha".
8. A avaliação do relatório ocorre no ISE e o status da sessão é alterado para Compatível.
O processo de descoberta não é iniciado em uma nova tentativa de autenticação
O módulo de postura do ISE foi projetado para monitorar uma quantidade limitada de eventos no endpoint para acionar um processo de descoberta.
Eventos que disparam a descoberta:
- Instalação inicial do módulo de postura do ISE.
- Login do usuário.
- Eventos de energia.
- Mudança de status da interface.
- Retomar SO após suspensão.
- Alteração de gateway padrão (DG).
- Falha na Reavaliação de Postura (PRA), consulte o bug da Cisco ID CSCvo69557. A nova autenticação dot1x, o desbloqueio do PC e a alteração de endereço IP não são detectados pelo módulo de postura do ISE.
O módulo de postura do ISE não pode detectar uma nova tentativa de autenticação ou reautenticação nestes cenários:
- A reautenticação atinge uma PSN diferente (devido a decisões de LB ou problemas com a PSN original).
- O NAD gera uma nova ID de sessão na reautenticação.
Reautenticação em PSN diferente
Este diagrama representa um exemplo de reautenticação em uma PSN diferente causada pela interrupção da PSN original. Um cenário com um balanceador de carga é semelhante. No caso de um balanceador de carga, a reautenticação é direcionada para a PSN diferente como resultado de uma expiração do temporizador de adesão.
- Autenticação inicial em PSN1.
- A sessão ABC é criada no cache da sessão PSN1.
- A avaliação de postura é realizada com PSN1.
- O status da postura ABC da sessão é movido para Compatível.
- O COA é acionado pela alteração do status da postura e leva à reautenticação do endpoint para aplicar o próximo nível de acesso.
- A PSN1 fica indisponível.
- A reautenticação para a sessão ABC atinge PSN2.
- Como é uma nova sessão para PSN2, o status de postura da sessão muda para Pendente.
O status de postura inicial é atribuído pela PSN à sessão:
NAD gera nova ID de sessão na reautenticação
Isso pode acontecer nos dois cenários mais comuns:
- A reautenticação é configurada incorretamente no lado do ISE (a solução para esse problema é abordada mais adiante neste documento).
- Mau comportamento por parte da NAD; normalmente, o NAD mantém o mesmo ID de sessão durante a tentativa de reautenticação. Este é um comportamento possivelmente problemático que deve ser investigado no NAD.
- A nova ID de sessão pode ser gerada em alguns outros cenários. Por exemplo, em alguns casos, o roaming sem fio pode ser uma causa.
- A PSN do ISE sempre coloca uma nova sessão no estado Pendente de postura, a menos que o aluguel de postura esteja configurado. O aluguel de postura é explicado mais adiante neste documento.
Maneiras rápidas de identificar quando um problema foi causado pela sessão obsoleta/fantasma
Para identificar se o AnyConnect mostra conformidade enquanto estiver no estado de redirecionamento é causado pela sessão obsoleta/fantasma. Você deve obter acesso ao endpoint enquanto ele estiver no estado problemático.
Investigar detalhes da verificação do sistema
1. Clique no ícone de engrenagem na interface do usuário do AnyConnect.
2. Na nova janela, navegue até Varredura do sistema > Estatísticas.
Em seguida, preste atenção a dois elementos importantes:
- Hora de início da verificação mais recente: O carimbo de data/hora aqui deve ser fechado no momento em que o problema foi descoberto.
- Servidor de políticas: Esse campo indica o nome do servidor de políticas que executa uma avaliação de postura para o ponto final. O FQDN deve ser comparado com o FQDN da Redirect-URL (para postura de base de redirecionamento) ou com o nome PSN obtido da última tentativa de autenticação (para postura sem redirecionamento).
- Compare o FQDN do Servidor de políticas a partir das Estatísticas de Verificação do Sistema com o nome do nó que fez a autenticação para o ponto final:
A demonstração mostra o registro das etapas necessárias para a identificação do problema:
Solução avançada de problemas de sessão obsoleta/fantasma
O exemplo anterior diferencia o problema de uma sessão obsoleta ou fantasma do problema do processo de descoberta que não foi iniciado. Ao mesmo tempo, você deve identificar a sessão real que disparou o problema para entender como ele se torna um problema de sessão obsoleta ou fantasma. Embora em alguns cenários as sessões obsoletas e fantasmas não possam ser evitadas, você deve garantir que as melhores práticas sejam implementadas, para evitar que sessões obsoletas/fantasmas sejam criadas em um ambiente.
Coleção de pacotes DART
Analise um pacote DART retirado do endpoint que reproduz o problema.
- Mantenha apenas registros importantes no DART e é recomendável limpar os registros antes de reproduzir o problema.
- Para conseguir isso, o utilitário do pacote DART deve ser iniciado como um administrador e realizar a limpeza de registros.
- No Windows, navegue até Iniciar e comece a digitar DART > clique com o botão direito do mouse e escolha - Executar como administrador.
4. Na primeira tela do assistente, clique em Próximo.
5. Na próxima tela do assistente, clique em Limpar Todos os Logs.
6. Depois que o problema for reproduzido, o DART poderá ser coletado aqui; clique em Avançar.
Análise do pacote DART
Depois que o pacote DART tiver sido coletado, desarquive-o e concentre-se no arquivo AnyConnect_ISEPosture.txt localizado na pasta Cisco AnyConnect ISE Posture Module . Este arquivo contém todos os eventos relacionados à descoberta.
1. Inicie a solução de problemas e identifique todos os momentos de reinicialização da descoberta. As palavras-chave a serem pesquisadas são Reiniciando a Descoberta ou Descoberta HTTP. Navegue até a linha com reinicialização de descoberta que ocorreu no momento problemático:
2. Várias linhas após a reinicialização da descoberta, há uma linha que contém, Sondando destinos de estágio MNT (este é um indicador de início de descoberta do Estágio 1):
3. Recomenda-se realçar todos os testes baseados em redirecionamento com a mesma cor e PSNs previamente conectados tirados de ConnectionData.xml (alvos de status de autenticação) em uma cor diferente. Normalmente, os FQDNs PSN são semelhantes e podem ser difíceis de detectar a diferença.
4. Leia os arquivos de log para ver os resultados de cada teste (este é um exemplo de como um teste com falha se parece):
5. Em algum lugar do arquivo após a reinicialização da descoberta para o Estágio 1 ou Estágio 2, você verá uma resposta bem-sucedida de um ou mais PSNs:
5. Várias linhas depois, há uma linha com a palavra-chave MSG_NS_SWISS_NEW_SESSION. Essa linha contém um ID de sessão real que foi selecionado pelo PSN como resultado da pesquisa de sessão. Use esta ID de sessão para investigar mais no ISE para determinar como a sessão se tornou obsoleta/fantasma:
Investigação em registros ISE
1. No guest.log com o componente client-webapp habilitado em DEBUG, o PSN responde com a sessão Obsoleta/Fantasma, que pode ser vista.
2. A PSN recebe uma solicitação do agente de postura do ISE. Esta é uma solicitação do AnyConnect devido ao valor de agente de usuário:
cisco.cpm.client.posture.PostureStatusServlet -::- Got http request from 192.168.255.228 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.6.03049)
cisco.cpm.client.posture.PostureStatusServlet -::- mac_list from http request ==> C0:4A:00:1F:6B:39
cisco.cpm.client.posture.PostureStatusServlet -::- iplist from http request ==> 192.168.255.228
cisco.cpm.client.posture.PostureStatusServlet -::- Session id from http request - req.getParameter(sessionId) ==> null
3. A solicitação contém matrizes de endereços IP e endereços MAC. Neste exemplo, cada matriz contém apenas um valor. O log mostra que o ID da sessão da solicitação é nulo, o que indica que esta é uma solicitação da sonda baseada em não-redirecionamento. Posteriormente, você poderá ver como os valores das matrizes são usados para localizar um ID de sessão:
cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently processed in the for loop ==> 192.168.255.228
cpm.client.provisioning.utils.ProvisioningUtil -::- the ipAddress that matched the http request remote address ==> 192.168.255.228
cpm.client.provisioning.utils.ProvisioningUtil -::- the clientMac from the macarray list for the for loop index matching the ipAddress list index ==> C0-4A-00-1F-6B-39
cisco.cpm.client.posture.PostureStatusServlet -::- Found Client IP matching the remote IP 192.168.255.228, corresponding mac address C0-4A-00-1F-6B-39
cpm.client.provisioning.utils.ProvisioningUtil -::- Session = 0a3e949c000000495c216240
4. Após a linha com as palavras-chave Sent http response, você pode exibir o conteúdo da resposta:
cisco.cpm.client.posture.PostureStatusServlet -::- Sent an http response to 192.168.255.228 with X-ISE-PDP=clemea19-ise1.demo.local.
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP value is clemea19-ise1.demo.local
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE value is /auth/perfigo_validate.jsp
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_PORT value is 8443
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_PORT value is 8443
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-GUESTFLOW value is false
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URL value is https://clemea19-ise1.demo.local:8443/auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URI value is /auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URL value is https://clemea19-ise1.demo.local:8443/auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URI value is /auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_VER value is 4.6.3049.0
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-STATUS_PATH value is /auth/status
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-BACKUP_SERVERS value is clemea19-ise2.demo.local
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-SessionId value is 0a3e949c000000495c216240
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PostureDomain value is posture_domain
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_STATUS value is Unknown
Investigação sobre relatórios do ISE
Uma vez que o ID da sessão obsoleta/fantasma é conhecido, você pode investigar o relatório Radius Accounting para obter uma melhor compreensão do que fez com que a sessão se tornasse obsoleta/fantasma:
- Navegue para Operações > Relatórios > Pontos finais e Usuários > relatório de Contabilidade Radius e execute este relatório por 7 dias; use uma ID de ponto de extremidade como uma chave de filtro.
2. Este é um exemplo de um relatório que mostra como a sessão antiga foi deixada em ciscolive-ise2:
- O início da contabilização da sessão chegou ao PSN ciscolive-ise2.
- A atualização temporária da sessão foi processada no mesmo PSN.
- Uma mensagem de interrupção de tarifação para o ID de sessão problemático chegou a um PSN diferente (ciscolive-ise1.)
Como identificar quando um problema foi causado pela ausência de uma reinicialização de descoberta
A mesma lógica é aplicável ao problema anterior, mas a única diferença é que você deve se concentrar na hora de início da verificação mais recente. Para esse tipo de problema, o carimbo de data/hora da última verificação está no passado.
Normalmente, quando um usuário final descobre um problema, ocorre uma varredura. Nos registros ISE Radius Live, são vistas tentativas recentes de autenticação do endpoint problemático.
A demonstração mostra o registro das etapas necessárias para a identificação do problema:
Solução avançada de problemas A ausência de reinicialização de descoberta
Essa abordagem é semelhante à seção Advanced Troubleshoot Stale/Phantom Session. O principal elemento de solução de problemas é a investigação do pacote DART.
Dentro do pacote DART, você pode pesquisar reinicializações de descoberta (como mostrado para a edição anterior) e confirmar que não houve reinicializações de descoberta no momento em que o problema foi relatado.
No lado do ISE, concentre-se no relatório de autenticação Radius Live Logs/ Radius para confirmar se houve failover entre PSNs ou se uma nova ID de sessão foi gerada pelo NAD.
Solução
Abordagem clássica - Prevenção de problemas
Historicamente, não havia recursos no ISE que resolvessem problemas descritos neste documento, portanto, a única maneira era confiar no conjunto de práticas recomendadas implementadas na rede e no ISE para minimizar os riscos.
Práticas recomendadas que podem minimizar a quantidade de sessões obsoletas ou fantasmas na implantação do ISE
Sempre Implementar Postura Baseada em Redirecionamento Quando Possível
Um contra-argumento comum para essa recomendação é que uma experiência de usuário ruim aparece no SO ou navegadores são vistos. Isso indica redirecionamento enquanto o módulo de postura do AnyConnect ISE em segundo plano executa um processo de avaliação.
Como uma solução para isso, é possível redirecionar SOMENTE os testes de detecção do módulo de postura do ISE e permitir seletivamente todo o tráfego restante. Este exemplo mostra a ACL de redirecionamento projetada para redirecionar somente solicitações HTTP para o Host de Descoberta (10.1.1.1 neste exemplo) e enroll.cisco.com (172.16.1.80):
ip access-list extended REDIRECT-DH-ENROLL
permit tcp any host 10.1.1.1 eq www
permit tcp any host 172.16.1.80
deny ip any any
Para manter um nível aceitável de segurança, uma ACL de redirecionamento pode ser combinada com a DACL atribuída do ISE.
O Estado Pendente Permite Conexões Somente com a PSN em que o Ponto de Extremidade foi Autenticado
Essa abordagem é útil para ambientes onde o redirecionamento de URL não é suportado (implementações com NADs de terceiros).
Como solução, implemente várias políticas de autorização de pendência de postura (uma por PSN.) Cada política deve conter como uma das condições o nome da PSN onde a autenticação ocorreu. No perfil de autorização, todos os PSNs devem ser bloqueados, exceto o nó em que a autenticação ocorreu.
Crie políticas de autorização para dois nós:
- Política Posture Pending para PSN1.
- O nome PSN1 é usado como uma condição na política.
- O perfil de autorização com ACL bloqueia o acesso a todas as PSNs, exceto a PSN1.
- A política de Pendente de postura para PSN2.
- O nome PSN2 é usado como uma condição na política.
- O perfil de autorização com ACL bloqueia o acesso a todas as PSNs, exceto a PSN2.
- Política de autorização 'Compatível' de postura.
A próxima figura explica como a abordagem funciona:
- A autenticação atinge o PSN1.
- Como resultado das políticas de autorização configuradas, o PSN1 atribui o perfil de autorização, que bloqueia o acesso a todos os outros nós, exceto o PSN1.
- O módulo de postura do AnyConnect ISE reinicia o processo de descoberta.
- A sonda para PSN2 é bloqueada pelo NAD como por uma ACL atribuída anteriormente.
- A sonda para PSN1 é permitida pela ACL atribuída no NAD.
Práticas recomendadas de balanceador de carga
- Habilite a adesão no balanceador de carga para autenticação e contabilização com a ID de Estação de Chamada como uma chave de adesão. Consulte as melhores práticas para o ISE com o Guia de implantação da Cisco e da F5: Balanceamento de carga do ISE usando BIG-IP.
- Use um temporizador de adesão mais longo que um dia útil médio para cobrir o momento em que o PC entra no modo de espera (por exemplo, 10 horas em vez de 8 horas).
- Se a reautenticação for implementada, use o temporizador de reautenticação um pouco mais baixo que o temporizador de adesão (use 8 horas se a adesão estiver configurada para 10 horas). Isso garante que o intervalo de adesão seja prolongado por uma nova autenticação.
Caso de uso de postura sobre VPN
Verifique se o intervalo de atualização de accounting-interim está maior ou igual a vpn-session-timeout. Isso minimiza a oscilação de tarifação entre PSNs durante longas sessões de VPN. Este exemplo mostra o intervalo de atualização da contabilidade provisória configurado para 20 horas. Isso não impede a atualização temporária inicial que transporta o endereço IP atribuído ao ponto final.
aaa-server ISE protocol radius
interim-accounting-update periodic 20
group-policy SSL-VPN attributes
vpn-idle-timeout 1200
vpn-session-timeout 1200
As práticas recomendadas podem ser implementadas para minimizar o impacto da ausência de reinicialização da descoberta do módulo de postura do ISE
Habilitar concessão de postura
Esse é um recurso no ISE que marca o endpoint como compatível por um período definido (1 a 365 dias.) O valor de concessão de postura é um atributo de ponto final, o que significa que ele está armazenado no ISE DB. Todos os atributos de endpoint que incluem o leasing de postura são replicados em todos os nós na implantação do ISE.
Quando a PSN recebe uma nova sessão para o endpoint, o aluguel de postura pode ser utilizado para marcar a sessão como Compatível imediatamente. Para tomar essa decisão, a PSN usa 3 valores, que são:
- Quantidade de dias definida para locação de postura nas configurações do ISE: Navegue até Administração > Sistema > Postura > Configurações gerais:
2. O valor do atributo PostureExpiry é um atributo de ponto de extremidade que contém um carimbo de data/hora Epoch. O valor PostureExpiry é preenchido inicialmente na primeira tentativa de postura bem-sucedida para o ponto de extremidade após a concessão de postura habilitada pelo administrador do ISE. Posteriormente, esse valor é atualizado na próxima tentativa de postura bem-sucedida que ocorre após o vencimento do aluguel. Você pode ver PostureExpiry em Visibilidade de contexto > Pontos de extremidade enquanto um dos pontos de extremidade postulados está aberto:
3. Esse valor pode ser convertido no timestamp legível por humanos, por exemplo, aqui - https://www.epochconverter.com/
3. Quando a autenticação para um endpoint com concessão de postura atinge PSN, ela usa PostureExpiry e a data do sistema para recuperar o número de dias decorridos da última verificação de postura bem-sucedida. Se o valor do resultado estiver dentro de um intervalo de concessão de postura definido nas configurações, a sessão receberá um status Compliant. Se o valor do resultado for maior que o valor do aluguel, a sessão receberá um status Desconhecido. Isso dispara a postura para ser executada novamente e o novo valor PostureExpiry pode ser salvo.
Este diagrama descreve o processo quando ocorre o failover:
- A autenticação inicial ocorre com PSN1.
- A sessão ABC é criada no cache da sessão.
- A avaliação da postura ocorre.
- O status da sessão é alterado para Compatível.
- O COA é acionado pela alteração do status da postura e leva à reautenticação do endpoint para aplicar ao próximo nível de acesso.
- O valor PostureExpiry é salvo no ponto de extremidade.
- Os dados do endpoint são replicados durante a implantação.
- A próxima autenticação atinge PSN2.
- A PSN2 verifica se o endpoint está dentro de uma concessão de postura válida.
- A sessão é adicionada ao cache de sessão como Compatível.
- Devido ao aluguel válido, a sessão é criada com o status de postura de Compatível.
Implementação de reautenticação
Sempre envie por push o timer de reautenticação do ISE com a Solicitação RADIUS, selecionada em Manter Conectividade Durante Reautenticação. Essa configuração garante que o NAD mantenha a mesma ID de sessão na reautenticação.
Ambientes com balanceadores de carga
O mesmo conjunto de práticas recomendadas (explicado na seção de sessão obsoleta/fantasma) pode ser implementado.
Sub-redes diferentes podem ser usadas para estados Pendente e Compatível
Quando os projetos de rede oferecem a oportunidade de usar sub-redes diferentes, como os estados Pendente e Compatível, essa abordagem garante que cada alteração no status da postura resulte na alteração do Gateway Padrão.
Avaliação de postura usada no mesmo intervalo que um temporizador de reautenticação
A Avaliação de postura pode ser habilitada com o intervalo igual ao temporizador de reautenticação. Quando a PSN original não está disponível, a falha PRA reinicia o processo de descoberta.
Abordagem moderna - Compartilhamento de estado de postura
Como parte de um aprimoramento implementado (no bug da Cisco ID CSCvi35647) patch 6 para ISE 2.6, há um novo recurso que implementa o compartilhamento do status da postura da sessão em todos os nós na implantação do ISE.
Esse aprimoramento está integrado em versões futuras para patches 2 e 3.0 do ISE 2.7.
Esse novo recurso é baseado no mecanismo Light Session Diretory (LSD), que foi introduzido no ISE 2.6. Em versões mais recentes, essa funcionalidade foi renomeada para Light Data Distribution (LDD) Radius Session Diretory. A Distribuição de Dados Light é habilitada por padrão e permite o compartilhamento de um contexto de sessão limitado entre nós do ISE. Não há replicações completas de contexto de sessão entre PSNs, apenas uma quantidade limitada de atributos compartilhados para cada sessão.
O Diretório de Sessão Leve elimina a necessidade de executar chamadas de API de recursos dispendiosas para o MNT quando um dos nós na implantação deve determinar o proprietário da sessão atual. A pesquisa de proprietário é necessária quando o fluxo de COA é iniciado. Com o LDD, cada PSN pode encontrar um proprietário da sessão a partir do cache local do Diretório de Sessão Radius.
Arquitetura de distribuição de dados leves
Essa funcionalidade contém os seguintes elementos:
- Cache de Diretório de Sessão Radius (RSD): esse cache existe em todos os nós do ISE e armazena todas as sessões ativas apresentadas na implantação do ISE. Cada sessão tem uma quantidade limitada de atributos no cache. Estes são exemplos dos atributos armazenados no Diretório de sessão Radius para cada sessão:
- ID da sessão
- MAC de endpoint
- IDdaEstaçãoChamada
- IP do endpoint
- PSN IP - PSN onde a autenticação acontece
- FQDN PSN
- NAS-IP-Address
- NAS-IPv6-Address
- Estado - Autenticado, Iniciado, Parado
- RabbitMQ Exchange: Há uma troca formada em que o Publicador, a Fila relacionada e o Consumidor são apresentados em todos os nós na implantação do ISE. Isso garante as formas de topologia de malha completa entre todos os nós do ISE.
- Editor: o Diretório de Sessão Radius representa um editor. Quando uma nova autenticação bem-sucedida é processada por um PSN, uma nova sessão é criada no cache da sessão PSN. Para esta sessão, um conjunto limitado de atributos é colocado no Diretório de sessão Radius.
- Consumidor: Em todos os outros nós, o Diretório de Sessão Radius representa um consumidor.
Note: A terminologia e a arquitetura gerais do RabbitMQ estão fora do escopo deste documento.
O próximo exemplo explica como o fluxo de COA funciona com o cache RSD:
- A autenticação inicial ocorre com PSN1.
- A sessão ABC é criada no cache da sessão.
- Os atributos necessários são salvos no RSD.
- A sessão é compartilhada por RabbitMQ com todos os outros nós do ISE.
- A sessão é criada no cache RSD em todos os nós do ISE.
- Novos dados de perfil chegam no PSN2.
- O endpoint é recriado e (no caso de uma alteração que exija a execução do COA PSN2) continua com a próxima etapa.
- Uma chamada de API interna é enviada para o cache RSD para executar o COA.
- Os dados do cache RSD são usados para preparar uma mensagem COA de Proxy. Ele se move de um nó ISE para outro e contém todos os detalhes que o nó de destino pode usar para emitir uma solicitação CAO de volta ao NAD. A mensagem do COA é transferida internamente primeiro para o PRRT Runtime (servidor AAA real dentro do ISE).
- PSN2 envia uma mensagem COA para PSN1.
- PSN1 envia uma mensagem COA ao NAD.
Para solucionar problemas de comunicação por LDD no ISE, ative o componente Light-Session-Diretory no DEBUG:
Este é um exemplo de uma mensagem de depuração do arquivo lsd.log para uma criação de sessão e publicação no PSN original:
DEBUG [pool-45-thread-6][] cisco.cpm.lsd.service.LSDRedisClient -::::- Mapping Session ID 0a3e9498000008e05e071990 to session {"sessionID":"0a3e9498000008e05e071990","endpointMAC":"C0-4A-00-1F-6B-39","callingStationId":"c0-4a-00-1f-6b-39","ipv6AdressLst":[],"psnIP":"192.168.43.26","deviceIP":"192.168.255.102","destinationIP":"192.168.43.26","nasIP":"192.168.255.102","auditSessionID":"0a3e9498000008e05e071990","acctSessionID":"5e07197b/c0:4a:00:1f:6b:39/2299","timeStamp":1577523495,"status":"Started","id":"614f6c44-6c78-4289-b9fd-b352ff012ca4"}
DEBUG [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.LSDNetAccessEventListener -::::- Publishing session update for session 0a3e9498000008e05e071990
DEBUG [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.SessionPublisher -::::- Forwarding session 07a26b4b-ea13-438b-99b5-0bbadc9d8bac to batch manager
Em todos os outros nós do ISE, você verá como uma sessão foi consumida:
[pool-35-thread-38][] cisco.cpm.lsd.service.SessionConsumer -::::- Consumer is processing : sessionID:[0a3e9498000008e05e071990] status:[Started] id:[614f6c44-6c78-4289-b9fd-b352ff012ca4] auditSessionID:[0a3e9498000008e05e071990] accountingSessionID:[5e07197b/c0:4a:00:1f:6b:39/2299] endpointMAC:[C0-4A-00-1F-6B-39] callingStationId: [c0-4a-00-1f-6b-39] endpointIP:[null], IPv6 : [[]], psnIP:[192.168.43.26] deviceIP:[192.168.255.102] destinationIP:[192.168.43.26] nasIP:[192.168.255.102] nasIPv6:[null] timeStamp:[1577523495]
Compartilhamento de Status de Postura por RSD
O compartilhamento do status da postura resolve os problemas quando a causa raiz é uma sessão Obsoleta/Fantasma ou uma reautenticação em uma PSN diferente que não acionou a reinicialização da descoberta. Assim que a sessão estiver em conformidade, essas informações serão inseridas no RSD da sessão e, posteriormente, poderão ser usadas por cada PSN na implantação.
Há alguns outros casos de vértice que o recurso descrito não pode resolver. Por exemplo, quando o NAD executa a reautenticação no mesmo PSN, mas com um ID de sessão diferente. Esses cenários podem ser tratados com as práticas recomendadas descritas neste documento. Esta figura demonstra a topologia usada para um teste de compartilhamento de status de postura:
Compartilhamento de Status de Postura por RSD - Sessão Obsoleta/Fantasma
Para criar uma sessão obsoleta, a autenticação deve ser executada inicialmente em skuchere-ise26-1. Em seguida, o NAD deve ser reconfigurado para enviar a contabilidade para skuchere-ise26-3. Depois que uma mensagem de contabilidade tiver sido encaminhada para o PSN errado, o NAD deve ser reconfigurado (novamente) para enviar a contabilidade de volta para skuchere-ise26-1.
Esta imagem demonstra um relatório de contabilidade que comprova a presença da sessão fantasma em skuchere-ise26-3:
- Mensagens Accounting-Start processadas pelo skuchere-ise26-1.
- Contabilidade Provisória - Atualização para a mesma sessão processada por skuchere-ise26-3.
- A sessão termina mais tarde em skuchere-ise26-1.
O ponto final se conecta à rede, mas o redirecionamento não funciona mais. No guest.log do PSN para skuchere-ise26-3, você pode ver essas mensagens de log com o componente client-webapp habilitado em DEBUG:
2020-04-08 13:30:48,217 DEBUG [https-jsse-nio-192.168.43.226-8443-exec-4][] cisco.cpm.client.posture.Util -::- Local session 0A3E946C0000007D5B679296 is stale. Newer session for 00-50-56-B6-0B-C6 is 0A3E946C000000805B7C43A3. Owned by skuchere-ise26-1.example.com
Quando a PSN detecta que mantém uma sessão obsoleta/fantasma para o endpoint, ela não responde ao módulo de postura do ISE e isso permite que você obtenha informações da PSN onde ocorreu a autenticação mais recente.
Como uma solução para o problema de sessão obsoleta/fantasma no momento da consulta da sessão, a PSN verifica a presença de qualquer nova sessão para o endpoint no RSD. Se o RSD contiver um ID de sessão diferente do que o PSN possui no cache de sessão local, ele supõe que a sessão (apresentada no cache de sessão) está obsoleta.
Compartilhamento de status de postura sobre RSD - Failover entre PSNs
Para reproduzir esse cenário, um temporizador de reautenticação curto é ativado no perfil de autorização atribuído ao ponto de extremidade de estado compatível. Mais tarde, o NAD é reconfigurado para enviar autenticação e contabilização para outra PSN (skuchere-ise26-3.) Após a expiração do temporizador de reautenticação, a mesma sessão não é autenticada na PSN diferente.
A próxima figura demonstra um relatório de autenticação que mostra o failover para a mesma sessão de skuchere-ise26-1 para skuchere-ise26-3:
- A autenticação acontece em skuchere-ise26-1, o perfil de autorização com redirecionamento é atribuído.
- COA após avaliação de postura bem-sucedida.
- A próxima autenticação do perfil de autorização para o estado de conformidade é atribuída.
- A autenticação atinge uma PSN diferente, no entanto, ela ainda recebe um perfil de autorização para o estado de conformidade.
A sessão tem status de conformidade na nova PSN após o failover em ise-psc.log com os componentes epm-pip e nsf-session habilitados para DEBUG:
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045 for attribute Session Session.PostureStatus
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.PIPManager -::::- Returning a PIP com.cisco.cpm.nsf.session.impl.SessionPIP for type SESSION and flow null
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [SessionLifecycleNotifier][] cpm.nsf.session.internal.LRUAgingAlogrithm -::::- Accessed session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Returning for session 0A3E946C000000896011D045 data Attrs: {SavedUserNames=[bob@example.com], Acs.LastStepTime=1586423202174, Acs.AD-User-Qualified-Name=bob@example.com, Acs.AD-User-Resolved-DNs=CN=bob,CN=Users,DC=example,DC=com, Acs.StepData=[110=EXAMPLE, 111=bob@example.com, 112=example.com, 113=example.com, 115=example.com, 116=EXAMPLE], Acs.AD-Log-Id=[1585911138/4778, 1585911138/4779], __IntIdGrps__=[Ljava.lang.String;@6d3c29b5, IdentityGroup.Description=[Ljava.lang.String;@3fca88fb, EXAMPLE.ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, Acs.AD-Groups-Names=example.com/Users/Domain Users, Acs.AuthenCPMSessionID=0A3E946C000000896011D045, Acs.IsMachineAuthentication=false, InternalEndpoint.IdentityGroup=[Ljava.lang.String;@6daf4c5, IDStoreUserQueryCache=[EXAMPLE#bob@example.com], Acs.CurrentIDStoreName=EXAMPLE, Acs.AD-User-Join-Point=EXAMPLE.COM, Acs.Step=[24432, 24325, 24313, 24319, 24323, 24355, 24416], Acs.CustomerMessageDuplicator=, Network Access.WasMachineAuthenticated=false, IdentityGroup.Name=[Ljava.lang.String;@570ab37a, Acs.StepDataStart=110, Acs.AD-User-DNS-Domain=example.com, Network Access.AuthenticationMethod=4, Acs.AD-User-Resolved-Identities=bob@example.com, InternalUser.IdentityGroup=[Ljava.lang.String;@51a6caed, Acs.AuthenticationMethod=4, Acs.AD-User-NetBios-Name=EXAMPLE, Normalised Radius.RadiusFlowType=0, Network Access.AuthenticationIdentityStore=EXAMPLE, EXAMPLE.IdentityAccessRestricted=false, Acs.AD-User-SamAccount-Name=bob}
IndexValues: {}
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- set postureStatus based on posture LSD dictionary: Compliant
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- PostureStatusPIP for mac 00-50-56-B6-0B-C6 - Attribute Session.PostureStatus value is Compliant
O problema original é resolvido com a adição de lógica extra no processo de seleção do status da postura. Esta figura demonstra o que foi alterado (alterações destacadas em vermelho):
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
25-Aug-2026
|
Título, ortografia, gramática, linhas horizontais inseridas atualizadas para separar seções para legibilidade, URLs fixos, alertas do CCW e texto alternativo. |
2.0 |
31-May-2023
|
Recertificação |
1.0 |
22-Apr-2020
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)