Solucionar problemas de gerenciamento e postura de sessão do ISE

Introdução

Este documento descreve o problema comum de serviços de postura do Identity Service Engine (ISE): "O módulo de postura do ISE do AnyConnect mostra compatível..."

Informações de Apoio

Este documento descreve o problema comum de 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, pode haver várias causas raiz desse problema.

Frequentemente, a solução de problemas desse tipo consome muito tempo, o que causa um impacto sério.

Este documento explica:

• Manifestação de problemas da perspectiva do usuário final e do administrador do ISE.
• Cenários problemáticos comuns.
• A teoria por trás do ISE, AnyConnect e operações de rede que desencadeiam o problema.
• 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.

Para obter uma melhor explicação dos conceitos descritos mais adiante, consulte:

Problema

Experiência do usuário final

Esse problema normalmente se manifesta na ausência de acesso à rede ou redirecionamentos constantes 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

Normalmente, na triagem inicial desse problema, o administrador do ISE executa a investigação de registros do Radius Live para garantir que haja uma autenticação real que atinja o ISE.

O primeiro sintoma descoberto nesse estágio indica uma incompatibilidade em um status de postura entre o endpoint e o ISE, como nos registros em tempo real ou nos relatórios de autenticação Radius da última autenticação bem-sucedida para o endpoint mostra o status de postura Pending.

Experiência típica do administrador do ISE:

• Última autenticação bem-sucedida para Alice.
• O status da postura da sessão é Pendente.
• Evento da última sessão para Alice.
• O evento de sessão mostra o status da postura como Compatível.

Observação: c. e d. nem sempre são apresentados nos registros em tempo real quando descritos manifestos de problemas. O evento de sessão com status de postura Compatível é mais comum para cenários causados por sessões obsoletas ou fantasmas que são descritos mais adiante neste documento.

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 AnyConnect ISE foi mal informado pelo Policy Service Node (PSN) durante o processo de postura, o que fez com que o status de postura errado fosse exibido. Nesse caso, normalmente lidamos 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, pois 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 e possivelmente acontecem que, durante a autenticação ou a reautenticação, nenhum desses eventos foi detectado.

Problema de Sessão Obsoleta/Fantasma

Para entender melhor o problema, investigue a lógica de gerenciamento de sessão do ISE e o processo de descoberta do AnyConnect necessário.

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 Nó de monitoramento (MNT).

Para solucionar e identificar esse problema corretamente, é essencial 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 de sessão posterior pode ser atualizado pelo Syslog para contabilização.

A remoção de sessão no MNT acontece em 3 cenários:

• As sessões sem relatório começam 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.
• A sessão encerrada foi removida aproximadamente 15 minutos após a interrupção da contabilização ter sido processada pelo mesmo trabalho cron.
• O mesmo cron em cada execução também remove as sessões que estiveram 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 o Syslog para a sessão.

Exemplos de mensagens de Syslog do PSN. Essas mensagens são registradas em 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 que é o cache da sessão PSN?

Um banco de dados na memória que armazena todas as sessões ativas de PSN específico. O cache de sessão é sempre local para o nó e não há nenhum mecanismo no ISE que possa executar a replicação do estado de sessão FULL de um nó para outro.

Para cada ID de sessão ativa, o PSN armazena todos os atributos que foram coletados durante a fase de autenticação/autorização, como 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 clientes, Postura.

Cache de sessão removido completamente quando os serviços no nó ou no próprio 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 das sessões existentes podem ser atualizados a partir de mensagens de contabilidade que vêm de NADs :

• A sessão foi autenticada com êxito no PSN.
• O PSN recebeu uma atualização provisória de contabilização para a sessão que não existe no cache da sessão.

Quando se trata de remoção de sessão, a PSN implementa esta lógica:

• Entrada de cache de sessão removida imediatamente após o processamento da mensagem de interrupção de contabilização.
• A 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:

1. A autenticação bem-sucedida acontece no PSN para a sessão ABC.

2. A PSN cria uma entrada no cache da sessão.

3. Ocorre a avaliação de postura.

4. Sessão marcada como Compatível.

5. A alteração de autorização (COA) disparada pela alteração de status de postura leva à reautenticação do ponto final para aplicar o próximo nível de acesso.

6. A parada contábil para a sessão ABC chega ao PSN2.

Após a sessão da etapa 6, o ABC fica preso no estado obsoleto no PSN1, pois não haveria uma mensagem de parada de relatório processada nesse PSN para removê-lo. A sessão será removida por muito tempo 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 veio 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 temporários de conectividade no caminho de rede que causam o failover de NAD para a próxima PSN.

Exemplo da sessão obsoleta no ambiente do Balanceador de Carga (LB):

1. Autenticação inicial para a Sessão ABC executada pelo PSN 1.

2. Esta autenticação inicia um temporizador de adesão no balanceador de carga.

3. A PSN 1 cria uma entrada para a sessão ABC no cache local.

4. Mensagem de syslog para autenticação passada transferida para o nó MNT.

5. Entrada para a sessão ABC criada no diretório de sessão MNT com o estado Autenticado.

6. A mensagem de início contábil para a sessão ABC chega ao PSN 1.

7. Entrada de cache de sessão para a sessão ABC atualizada com informações de Contabilidade-Início.

8. Mensagem de Syslog para Accounting-Start transferida para o nó MNT.

9. Estado da sessão atualizado para Iniciado.

10. O temporizador de adesão expira no balanceador de carga.

11. Accounting-Stop para a sessão ABC encaminhada pelo balanceador de carga para a PSN 2.

12. Mensagem de Syslog para Accounting-Stop encaminhada pela PSN 2 à MNT.

13. Sessão ABC marcada como terminada em 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 que não executou autenticação para essa sessão específica. Nesse cenário, uma nova entrada é criada no cache da sessão PSN e, 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:

1. As mesmas etapas descritas no exemplo de sessão obsoleta acontecem em PSN1 para a sessão ABC.

2. A Sessão ABC tem um status Compatível no cache da sessão PSN1.

3. Atualização provisória contábil para sessão ABC atinge PSN2.

4. Entrada de sessão para a sessão ABC criada no PSN2. Como a entrada de sessão criada a partir da mensagem de relatório, ela tem números limitados de atributos. Por exemplo, o status da postura não está disponível para a sessão ABC. Coisas como grupos de usuários e 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.

Exemplo de uma sessão fantasma para o cenário com problemas temporários no caminho de rede em direção a PSN1:

1. Autenticação inicial para a Sessão ABC executada pelo PSN.

2. PSN1 cria uma entrada para a sessão ABC no cache local.

3. Mensagem de Syslog para autenticação passada transferida para o nó MNT.

4. Entrada para a sessão ABC criada no TimesTen DB com o estado Autenticado.

5. A mensagem de início contábil para a sessão ABC chega à PSN 1.

6. Entrada de cache de sessão para a sessão ABC atualizada com informações de Contabilidade-Início.

7. Mensagem de Syslog para Accounting-Start transferida para o nó MNT.

8. Estado da sessão atualizado para Iniciado.

9. Atualização de Contabilidade Provisória para a sessão ABC encaminhada para PSN2.

10. PSN2 cria uma entrada para a sessão ABC no cache local.

11. Accounting-Stop para a sessão ABC encaminhada para PSN1.

12. Entrada para a sessão ABC removida do cache de sessão em PSN1.

13. Mensagem Syslog para Accounting-Stop encaminhada por PSN 1 para MNT.

14. Sessão ABC marcada como terminada em MNT.

O cenário da sessão fantasma criado para a conexão VPN de longa duração:

1. Autenticação inicial no PSN1.

2. Sessão ABC criada no cache da sessão.

3. A contabilidade inicia a mensagem processada pelo PSN.

4. O novo endereço IP atribuído ao adaptador de Rede Virtual Privada (VPN).

5. Atualização de contabilidade provisória com informações de endereço IP chega ao PSN.

6. Informações de endereço IP adicionadas ao cache da sessão.

7. A avaliação de postura ocorre com a PSN1.

8. Status da postura atualizado na sessão.

9. Envio de COA executado pelo ISE, aciona o novo nível de acesso a ser atribuído.

10. Interrupção no caminho da rede que torna o PSN1 inacessível.

11. Após a expiração do intervalo de atualização temporária, o ASA/FTD detecta que o PSN1 está inacessível. 

12. A atualização da contabilidade provisória chega ao PSN2.

13. A sessão fantasma criada no cache da sessão PSN2.

Se mais tarde a PSN1 se tornar acessível (14), todas as mensagens de relatório subsequentes serão encaminhadas (15,16) lá 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 a sessão obsoleta e a sessão fantasma quebram 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 4 problemas simultâneos para localizar a PSN que fez uma autenticação para o endpoint.

Primeiro, 3 testes na figura são baseados em redirecionamento (IP GW padrão. IP do host de descoberta (se definido) e IP de enroll.cisco.com) - Essas sondas sempre apontam o agente para a PSN direita, pois a URL de redirecionamento é retirada do próprio NAD.

A sonda número 4 é enviada a todos os servidores primários apresentados no arquivo ConnectionData.xml. Esse arquivo criado após a primeira tentativa de postura bem-sucedida e o conteúdo posterior do arquivo podem ser atualizados caso o cliente migre entre PSNs. Em 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, o resultado do teste 4 é usado somente se todos os outros 3 testes falharem ou se o módulo de postura do ISE não conseguir estabelecer comunicação adequada com o PSN retornado na URL de redirecionamento em 5 segundos.

Quando a sonda 4 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 o endpoint, isso pode resultar em um status de postura incorreto exibido posteriormente no lado do cliente.

Quando um agente obtém várias respostas para a prova 4 (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 dispara uma pesquisa de sessão na PSN de destino. Se o PSN não puder localizar a sessão no cache de sessão local, ele deverá executar uma pesquisa MNT (somente com base no endereço MAC) para localizar um proprietário de 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 ainda mais afetada por problemas como resultado de sessões obsoletas ou fantasmas.

Se a PSN chegar ao 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.

O exemplo mostra como a postura ocorre quando o PSN mantém uma sessão obsoleta ou uma sessão fantasma:

Observação: é importante lembrar que esse problema pode se manifestar somente quando todos os testes de descoberta baseados em redirecionamento falham ou quando a postura de não-redirecionamento é implementada.

1. Qualquer um dos testes Find my session emitidos pelo módulo de postura do ISE.

2. A 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.

3. A PSN executa a seleção da política de provisionamento do cliente. No caso, com uma sessão fantasma que tem uma falta de atributos de autenticação/autorização e todas as políticas configuradas pelo cliente são muito específicas (políticas são criadas para grupos específicos do Ative Diretory, por exemplo), a PSN não pode atribuir uma política de provisionamento de cliente correta. Isso pode se manifestar na mensagem de erro: "Ignorando a verificação do AnyConnect, sua rede está configurada para usar o Cisco NAC Agent".

• Quando 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 a configuração do AnyConnect), a PSN responde com detalhes necessários para a continuação do processo de avaliação.
• Nesta etapa também, quando podemos lidar com sessões obsoletas, a PSN responde imediatamente com o status de postura Compatível e todas as próximas etapas não são executadas. 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. Como a sessão fantasma tem uma falta de atributos neste ponto, não temos nenhuma política para corresponder. Nesse caso, a PSN responde ao endpoint que está em conformidade, pois esse é um comportamento padrão do ISE em caso de não correspondência de política de postura. 

Observação: quando há alguma política genérica que pode ser selecionada nos atributos da sessão fantasma, continuamos com a etapa 6.

6. A PSN retorna as políticas de postura selecionadas de volta para o agente.

Observação: quando nenhuma política pode ser selecionada, a PSN retorna o status Compliant (Compatível).

7. O agente retorna status para cada política/requisito como aprovado ou reprovado.

8. A avaliação do relatório acontece no ISE e o status da sessão muda para Compatível.

Observação: no caso de problemas de postura causados pela sessão fantasma, o administrador do ISE possivelmente percebe alguns COAs de postura com falha, pois nesse caso as solicitações de COA são executadas a partir de PSNs erradas e para IDs de sessão erradas.

O processo de descoberta não é iniciado em uma nova tentativa de autenticação

Módulo de postura do ISE projetado para monitorar uma quantidade limitada de eventos no endpoint para disparar um processo de descoberta. Lista de 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, desbloqueio de PC, alteração de endereço IP não são detectadas 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 diferentes PSNs (devido a decisões LB ou problemas com a PSN original).
• O NAD gera uma nova ID de sessão na reautenticação.

Reautenticação em PSN diferente

Exemplo de reautenticação em diferentes PSNs causada pela interrupção da PSN original. O cenário com balanceador de carga é muito semelhante. No caso de LB, a reautenticação é direcionada para a PSN diferente como resultado da expiração do temporizador de adesão.

1. Autenticação inicial no PSN1.

2. Sessão ABC criada no cache de sessão PSN1.

3. Avaliação de postura realizada com PSN1.

4. O status da postura do ABS da sessão passa para Compatível.

5. O COA acionado pela alteração do status da postura leva à reautenticação do endpoint para aplicar o próximo nível de acesso.

6. A PSN1 fica indisponível.

7. Reautenticação para sessão ABC atinge PSN2.

8. Como é uma nova sessão, o status de postura PSN2 da sessão torna-se Pendente.

Status de postura inicial atribuído pela PSN à sessão:

Observação: a máquina de estado descreve apenas uma seleção inicial do status da postura. Cada sessão inicialmente marcada como Desconhecida pode mais tarde se tornar Compatível ou Não Compatível com base na avaliação do relatório recebida do módulo de postura do ISE.

NAD gera nova ID de sessão na reautenticação

Isso pode acontecer nos dois cenários mais comuns:

• A reautenticação está configurada incorretamente no ISE. A solução para esse problema é abordada mais adiante neste documento.
• Comportamento incorreto do lado NAD - normalmente, o NAD mantém a mesma ID de sessão durante a tentativa de reautenticação. Caso você tenha descoberto que o NAD alterou uma ID de sessão na reautenticação, esse é um comportamento com bugs em potencial que precisa ser investigado no próprio NAD.

A nova ID de sessão pode ser gerada em alguns outros cenários de casos de canto. Por exemplo, em alguns casos, o roaming sem fio pode ser a causa disso. O principal aqui é que o ISE PSN sempre coloca uma nova sessão no estado Pending, a menos que o aluguel de postura seja configurado. O aluguel de postura é explicado mais adiante neste documento.

Maneira rápida de identificar quando o problema foi causado pela sessão obsoleta/fantasma

Para identificar se o AnyConnect mostra conformidade enquanto está no estado de redirecionamento causado pela sessão obsoleta/fantasma, precisamos obter acesso ao endpoint enquanto ele estiver no estado problemático.

1.  investigue Detalhes da verificação do sistema:
   
   

     1. Pressione o ícone de engrenagem na interface do usuário do AnyConnect

   

         2. Na nova janela, navegue até a guia Varredura do sistema e subguia Estatísticas

   

           Aqui, preste atenção a dois elementos:

   •   Hora de Início da Verificação Mais Recente - o carimbo de data/hora aqui deve ser fechado quando o problema foi descoberto.
   •   Servidor de políticas - este campo indicou o nome do servidor de políticas que fez uma avaliação de postura para o ponto de extremidade. O FQDN daqui precisa ser comparado com o FQDN da URL de Redirecionamento (para postura de base de redirecionamento) ou com o nome PSN obtido da última tentativa de autenticação (para postura sem redirecionamento).
2. 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 do ponto de extremidade:

No exemplo dado, há uma incompatibilidade entre o nome que é indicado que o PSN com o nome ciscolive-ise2 mantém uma sessão obsoleta ou fantasma para esse 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 é para diferenciar o problema de uma sessão obsoleta ou fantasma do problema do processo de descoberta que não foi iniciado. Ao mesmo tempo, precisamos identificar a sessão real que disparou o problema para entender melhor como exatamente ele se torna um problema de sessão obsoleta ou fantasma.

Em alguns cenários, sessões obsoletas e fantasmas não podem ser evitadas. Precisamos garantir que não sejam criadas sessões obsoletas/fantasmas no ambiente devido a algumas das melhores práticas que não são implementadas.

Coleção de pacotes DART

Analise um pacote DART retirado do endpoint que reproduz o problema.

• Mantenha somente os registros importantes no DART. É recomendável limpar os registros antes de reproduzir o problema. 

Para conseguir isso, o utilitário do pacote DART precisa ser iniciado como um administrador e realizar a limpeza do registro. 

1. No Windows Navegue até Iniciar e comece a digitar DART, clique com o botão direito do mouse e escolha - Executar como administrador
   
   
2. Na primeira tela do assistente, pressione Avançar
   
   
3. Na próxima tela do assistente, pressione Limpar Todos os Logs
   
   
   
   
4. Após a reprodução do problema, o DART pode ser coletado aqui; pressione Avançar.

análise de pacote DART

Após a coleta do pacote DART, precisamos desarquivá-lo e nos concentrar 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. Aqui, navegue até a linha com reinicialização de descoberta que aconteceu no momento problemático:

2. Algumas linhas após a reinicialização da descoberta, você verá uma linha que contém - Sondando destinos de estágio MNT. Este é um indicador do início da descoberta do estágio 1:

É recomendável realçar todos os testes baseados em redirecionamento com a mesma cor, enquanto as PSNs conectadas anteriormente obtidas de ConnectionData.xml (destinos de status de autenticação) precisam ser realçadas em cores diferentes, pois os FQDNs de PSN normalmente são muito semelhantes e é difícil identificar a diferença.

3. Leia os arquivos de registro para ver um resultado para cada sonda. Como já foi dito, no caso do problema causado por uma sessão obsoleta/fantasma, todos os testes baseados em redirecionamento precisam falhar. Este é um exemplo de como é o teste com falha:

4. 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. Algumas linhas depois há uma linha com a palavra-chave MSG_NS_SWISS_NEW_SESSION. Essa linha contém uma ID de sessão real que foi selecionada pelo PSN como resultado da pesquisa de sessão. Use esta ID de sessão para investigar mais sobre o ISE e descobrir como esta sessão se torna obsoleta/fantasma:

Investigação em registros ISE

 No guest.log com o componente clientwebapp habilitado em DEBUG, o PSN que responde com a sessão Obsoleta/Fantasma pode ser visto.

A PSN recebe uma solicitação do agente de postura do ISE. Você pode ver que esta é uma solicitação do AnyConnect devido ao valor do 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

A solicitação contém matrizes de endereços IP e endereços MAC. Neste exemplo específico, cada matriz contém apenas um valor. Além disso, o log mostra que o ID da sessão da solicitação é nulo, o que indica que essa é uma solicitação da sonda baseada em não redirecionamento.

Mais tarde, você pode ver como os valores de arrays 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

Após a linha com as palavras-chave Sent http response você pode ver o conteúdo da resposta real:

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

Depois de saber a ID da sessão obsoleta/fantasma, você pode investigar o relatório de Contabilidade Radius para obter uma melhor compreensão do que fez com que essa sessão se tornasse obsoleta/fantasma:

• Navegue até 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.

Exemplo de um relatório que mostra como uma sessão obsoleta sobrou no ciscolive-ise2:

1. O início da contabilização da sessão chegou ao PSN ciscolive-ise2
2. A atualização temporária da sessão foi processada no mesmo PSN.
3. A mensagem de parada de contabilização para o ID de sessão problemático chegou a um PSN diferente (ciscolive-ise1).

Uma maneira rápida de identificar quando o problema foi causado pela ausência de reinicialização da descoberta

Aqui, aplica-se a mesma lógica que para a edição anterior. A única diferença é que você precisa 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á em algum lugar no passado.

Normalmente, quando o usuário final descobre um problema, uma verificação que aconteceu há algum tempo é vista. 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

A abordagem aqui é muito 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 as mostradas para o problema anterior e confirmar que não houve reinicialização 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 que houve failover entre PSNs ou que uma nova ID de sessão foi gerada pelo NAD.

Solução

Abordagem clássica - Prevenção de problemas

Historicamente, não havia nenhum recurso no ISE que pudesse resolver 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 a essa recomendação é uma experiência de usuário ruim, pois pop-ups no sistema operacional ou navegadores são vistos, o que 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 sondas de descoberta de módulo de postura do ISE e permitir seletivamente qualquer outro tráfego.

O 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, a ACL de redirecionamento pode ser combinada com a DACL atribuída no 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 (por exemplo, implementações com NADs de terceiros).

Como solução, você precisa implementar várias políticas de autorização PosturePending (uma por PSN). Cada política precisa conter como uma das condições o nome da PSN onde a autenticação ocorreu. No perfil de autorização atribuído a cada política, o acesso a todas as PSNs deve ser bloqueado, exceto ao nó onde ocorreu a autenticação.

Criar políticas de autorização para implantação de 2 nós:

 

1. Postura Pendente política para PSN1.

2. Nome PSN1 usado como uma condição na política.

3. Perfil de autorização com ACL que bloqueia o acesso a todas as PSNs, exceto a PSN1.

4. Postura Pendente política para PSN2.

5. Nome PSN2 usado como uma condição na política.

6. Perfil de autorização com ACL que bloqueia o acesso a todas as PSNs, exceto a PSN2.

7. Política de autorização de conformidade.

A figura explica como essa abordagem funciona:

1. A autenticação atinge o PSN1.

2. Como resultado das políticas de autorização configuradas, o PSN1 atribui um perfil de autorização que bloqueia o acesso a todos os outros nós, exceto o PSN1.

3. O módulo de postura do AnyConnect ISE reinicia o processo de descoberta.

4. Sonde a PSN2 bloqueada pelo NAD como por uma ACL atribuída anteriormente.

5. Sonde a PSN1 permitida pela ACL atribuída no NAD.

Práticas recomendadas de balanceador de carga

• Habilitado stickiness no LB para autenticação e tarifação com Calling-Station-ID como uma chave stickiness. Mais detalhes sobre as melhores práticas de LB para ISE disponíveis aqui.
• Use um temporizador de adesão mais longo que um dia útil médio para cobrir o momento em que o PC entra em suspensão (por exemplo, 10 horas em vez de 8 horas).
• Caso a reautenticação seja implementada, use um temporizador de reautenticação ligeiramente inferior ao temporizador de adesão (por exemplo, 8 horas se a adesão for 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 

• Garante que o intervalo de atualização de accounting-interim seja maior ou igual a vpn-session-timeout. Isso protege contra oscilação de contabilidade entre PSNs em sessões de VPN de longa duração. 

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 leasing de postura são replicados em todos os nós na implantação do ISE.

Quando a PSN obtém uma nova sessão para o aluguel de postura de endpoint, pode ser usado para marcar a sessão como Compatível imediatamente.

Para tomar essa decisão, a PSN usa 3 valores. Esses valores 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:

• Valor do atributo PostureExpiry - este é um atributo de ponto final real 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 da concessão.

            Você pode ver PostureExpiry em Visibilidade de contexto > Pontos de extremidade enquanto um dos pontos de extremidade postulados estiver aberto:

           Esse valor pode ser convertido no carimbo de data/hora legível por humanos, por exemplo, aqui - https://www.epochconverter.com/

• Hora do sistema PSN no momento em que ocorre a nova autenticação

Quando a autenticação de um endpoint com concessão de postura atinge a PSN, ela usa PostureExpiry e a data do sistema para obter um número de dias que passaram 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 obterá um status Compatível. Se o valor do resultado for maior que o valor do aluguel, a sessão obterá um status Desconhecido. Isso dispara a postura para ser executada novamente e o novo valor PostureExpiry pode ser salvo.

A figura explica o processo quando ocorre o failover:

1. A autenticação inicial acontece com o PSN1.

2. Sessão ABC criada no cache da sessão.

3. Ocorre a avaliação de postura.

4. O status da sessão muda para Compatível

5. O COA acionado pela alteração do status da postura leva à reautenticação do endpoint para aplicar o próximo nível de acesso.

6. Valor PostureExpiry salvo no ponto final.

7. Dados de endpoint replicados durante a implantação.

8. Próxima autenticação atinge PSN2.

9. A PSN2 verifica se o endpoint está dentro de um aluguel de postura válido.

11. Sessão adicionada ao cache de sessão como Compatível.

12. Devido ao leasing válido, a sessão criada com o status de postura Compatível.

Implementação de reautenticação 

Sempre envie por push o temporizador de reautenticação do ISE com RADIUS-Request selecionado em Manter a conectividade durante a reautenticação. Essa configuração garante que o NAD mantenha a mesma ID de sessão na reautenticação.

.

Ambientes com balanceadores de carga

É possível implementar o mesmo conjunto de práticas recomendadas explicadas na seção de sessão obsoleta/fantasma.

Sub-redes Diferentes Podem Ser Usadas para Estados Pendente e Em Conformidade

Quando o projeto de rede fornece a oportunidade de usar diferentes sub-redes nos 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. Nesse caso, quando a PSN original não estiver disponível, a falha PRA reiniciará o processo de descoberta.

Abordagem moderna - Compartilhamento de estado de postura

Como parte de um aprimoramento implementado, descrito no bug da Cisco ID CSCvi35647patch 6 para ISE 2.6 obteve 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: ISE 2.7 patches 2 e ISE 3.0.

Esse novo recurso é baseado no mecanismo Light Session Diretory (LSD), que foi introduzido no ISE 2.6. Nas versões mais recentes, esta funcionalidade foi renomeada para Light Data Distribution (LDD) Radius Session Diretory.  A Distribuição de dados leves é ativada por padrão e permite o compartilhamento de um contexto de sessão limitado entre nós do ISE. Não há replicação de contexto de sessão completa entre PSNs, apenas uma quantidade limitada de atributos compartilhados para cada sessão.

A ideia principal por trás do Diretório de Sessão Light é remover a necessidade de executar chamadas de API de recursos dispendiosas para o MNT quando um dos nós na implantação tem que descobrir quem é 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 real da sessão no cache local do Diretório de sessão do Radius. 

Arquitetura de distribuição de dados leves

Essa funcionalidade contém os seguintes elementos:

• Cache do 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. Exemplos dos atributos armazenados no Diretório de Sessão Radius para cada sessão:
  
  
  • ID da sessão.
  • MAC de endpoint.
  • CallingStationID
  • Endpoint IP (IP do endpoint).
  • PSN IP - PSN onde a autenticação ocorreu.
  • FQDN PSN - o mesmo que acima.
  • NAS-IP-Address (Endereço IP NAS).
  • NAS-IPv6-Address
  • Estado - Autenticado, Iniciado, Parado.

• Troca de RabbitMQ - há uma troca formada na qual o Publicador, a Fila e o Consumidor relacionados são apresentados em cada nó na implantação do ISE. Isso garante que a topologia de malha completa seja formada entre todos os nós do ISE.

• Editor - o Diretório de sessão Radius representa um editor aqui. Quando uma nova autenticação bem-sucedida processada pelo 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.

Observação: a terminologia e a arquitetura da General RabbitMQ estão fora do escopo deste documento. 

A figura explica como o fluxo do COA funciona com o cache RSD:

1. A autenticação inicial acontece com o PSN1.

2. Sessão ABC criada no cache da sessão.

3. Os atributos obrigatórios são salvos no RSD.

4. Sessão compartilhada sobre RabbitMQ com todos os outros nós do ISE.

5. A sessão é criada no cache RSD em todos os nós do ISE.

6. Novos dados de perfil chegam ao PSN2.

7. O endpoint é recriado e, no caso da alteração que exige a execução do COA, a PSN2 continua com a próxima etapa.

8. Uma chamada de API interna enviada ao cache RSD para executar o COA.

9. Dados do cache RSD usados para preparar uma mensagem de Proxy COA (um COA que vai de um nó ISE para outro, ele contém todos os detalhes que o nó de destino pode usar para enviar uma solicitação de CAO de volta ao NAD). A mensagem COA é transferida internamente primeiro para PRRT Runtime (servidor AAA real dentro do ISE).

10. PSN2 envia uma mensagem COA para PSN1.

11. PSN1 envia uma mensagem COA ao NAD.

Para solucionar problemas de comunicação por LDD no ISE, você pode habilitar o componente Light Session Diretor no DEBUG:

 exemplo de mensagem de depuração do arquivo lsd.log para 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 entre os nós resolve o problema que tem o sintoma como 'O módulo de postura do AnyConnect ISE mostra compatível enquanto o status da sessão no ISE está pendente' quando a causa raiz é uma sessão Obsoleta/Fantasma ou Reautenticação em PSN diferente com uma ID de sessão original 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.

Ainda há alguns outros casos de canto que o recurso descrito não pode resolver. Por exemplo, um cenário em que o NAD executa uma nova autenticação no mesmo PSN, mas com um ID de sessão diferente. Tais cenários podem ser tratados com as práticas recomendadas descritas neste documento.

A 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 foi executada inicialmente no skuchere-ise26-1 e, posteriormente, o NAD foi reconfigurado para enviar a contabilidade para o skuchere-ise26-3. Após uma mensagem de relatório ter sido encaminhada para a PSN e a NAD errada terem sido reconfiguradas novamente para enviar a contabilidade de volta para skuchere-ise26-1.

A figura demonstra um relatório de contabilidade que comprova a presença da sessão fantasma no skuchere-ise26-3:

1. Mensagens Accounting-Start processadas pelo skuchere-ise26-1.

2. Contabilidade Provisória - Atualização para a mesma sessão processada por skuchere-ise26-3.

3. A sessão termina mais tarde no skuchere-ise26-1.

Depois de algum tempo, o endpoint se conecta novamente à rede, mas o redirecionamento não funciona mais. No guest.log de PSN - 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 nos permite obter a resposta correta da PSN onde a autenticação mais recente aconteceu.

Como uma solução para o problema de sessão obsoleta/fantasma agora no momento da consulta da sessão, o PSN verifica a presença de qualquer nova sessão para o endpoint no RSD. Caso o RSD contenha um ID de sessão diferente do que o PSN tem no cache de sessão local, ele presume 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 foi ativado no perfil de autorização atribuído ao ponto final no estado de conformidade. Mais tarde, o NAD foi 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 foi autenticada na PSN diferente.

A figura demonstra um relatório de autenticação que mostra o failover da sessão normal de skuchere-ise26-1 para skuchere-ise26-3:

1. A autenticação acontece no skuchere-ise26-1, o perfil de autorização com redirecionamento é atribuído.

2. COA após avaliação de postura bem-sucedida.

3. Próxima autenticação quando o perfil de autorização para o estado de conformidade for atribuído.

4. A autenticação atinge diferentes PSNs, mas ainda obtém o perfil de autorização para o estado de conformidade.

A sessão obtém o status de conformidade na nova PSN após o failover em ise-psc.log com os componentes epm-pip e nsf-session ativados em 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 foi resolvido com a adição de lógica extra no processo de seleção do status da postura. A figura demonstra o que foi alterado (alterações destacadas em vermelho):