Gerenciamento e postura de sessão do ISE

Introduction

Este documento descreve o problema de serviços de postura do Identity Service Engine (ISE) comum - o módulo de postura do AnyConnect ISE mostra a conformidade enquanto o status da sessão no ISE está pendente. Esse problema se torna cada vez mais popular e, embora os sintomas sejam sempre os mesmos, pode haver várias causas reais desse problema. Frequentemente, a solução de um problema desse tipo torna-se extremamente demorada, o que pode causar um impacto grave.

Informações de Apoio

Este documento explica:

• Manifestação de problemas do usuário final e do administrador do ISE.
• Cenários problemáticos comuns.
• A teoria por trás das operações ISE, AnyConnect e de rede que pode desencadear 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 no diretório de sessão Radius.

Para uma melhor compreensão dos conceitos descritos posteriormente, é recomendável passar por:

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 provisionamento do cliente ISE no navegador, enquanto ao mesmo tempo o módulo de postura do AnyConnect ISE mostra o status de postura como Compatível.

Experiência típica do usuário final:

Experiência do administrador do ISE

Normalmente, durante a triagem inicial desse problema, o administrador do ISE executa a investigação de registros ao vivo do Radius para garantir que haja uma autenticação real que esteja atingindo o ISE. O primeiro sintoma descoberto durante este estágio indica uma incompatibilidade em um status de postura entre o endpoint e o ISE, como nos registros ao vivo ou nos relatórios de autenticação Radius, a última autenticação bem-sucedida para o endpoint mostra o status da postura Pendente.

Experiência de administração típica do ISE:

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

Note: c. e d. nem sempre são apresentados nos registros ao vivo quando descritos manifestos de problemas. 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 descritas mais adiante neste documento.

Cenários problemáticos comuns

Esse problema normalmente se manifesta em dois cenários problemáticos e cada um deles pode ter 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 causou a exibição do status de postura errado. Nesse caso, normalmente lidamos com uma sessão obsoleta ou fantasma no cache da sessão PSN.
• O AnyConnect ISE mostra o status da postura do ciclo de descoberta anterior, pois a autenticação atual não disparou 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 pode acontecer 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, insira-se profundamente na lógica de gerenciamento de sessão do ISE e no 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ões em ambos os personagens.

Gerenciamento de sessão e MNT

Como explicado na figura, o nó MNT cria estações com base nas mensagens Syslog de autenticação passadas provenientes de PSNs. O status da sessão posterior pode ser atualizado pelo Syslog para tarifação.

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

• As sessões sem relatório começam a ser removidas aproximadamente 60 minutos depois de terem sido criadas. Há um trabalho cron executado a cada 5 minutos para verificar o status da sessão e executar a limpeza.
• A sessão encerrada foi removida aproximadamente 15 minutos depois que a parada contábil foi processada pelo mesmo trabalho cron.
• O mesmo cron em cada execução é removido, bem como as sessões que estão no estado 'Iniciado' há mais de 5 dias (120 horas). Um estado iniciado significa que o nó MNT processou a autenticação e a contabilização para iniciar o Syslog para a sessão.

Exemplos de mensagens Syslog do PSN. Essas mensagens são registradas em port-server.log quando o componente runtime-aaa é ativado em DEBUG. As peças 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 Contabilidade:

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 temporária de relatório:

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

Parada de relatório:

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

Qual é 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 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 pelo PSN para selecionar diferentes tipos de política, como Autenticação, Autorização, Provisionamento de cliente, 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 da sessão em dois cenários, os detalhes posteriores das sessões existentes podem ser atualizados a partir de mensagens de relatório provenientes de NADs :

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

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

• Entrada de cache de sessão removida imediatamente após o processamento da mensagem de parada de contabilidade.
• O PSN começa a remover as sessões menos usadas recentemente quando um nó atinge o limite das sessões ativas.

Sessão obsoleta no PSN

Na implantação do ISE, a parada de contabilização de uma sessão existente foi processada pelo PSN, que não realizou a autenticação real:

Exemplo de sessão obsoleta:

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

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

3. A avaliação de postura acontece.

4. Sessão marcada como Compatível.

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

6. A parada de contabilização da sessão ABC chega ao PSN2.

Após a sessão da etapa 6, ABC ficando preso no estado obsoleto no PSN1, pois não haveria uma mensagem de parada de contabilidade processada neste PSN para removê-lo. A sessão não pode ser removida por muito tempo se a implantação não tiver um número alto de tentativas de autenticação.

A sessão antiga pode aparecer no cache da sessão PSN nos cenários abaixo:

• A parada de contabilidade chegou ao PSN errado devido à expiração do temporizador de aderência no balanceador de carga.
• A configuração incorreta no NAD não é a mesma PSN configurada para autenticação e tarifação.
• Problemas temporários de conectividade no caminho da rede que causam failover de NAD para a próxima PSN.

Exemplo de sessão obsoleta no ambiente LB:

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

2. Essa autenticação inicia um temporizador de aderência no balanceador de carga.

3. O 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 sessão ABC criada no diretório de sessão MNT com o estado Authenticated.

6. Mensagem de início de contabilização para a sessão ABC aterrissa no PSN 1.

7. Entrada de cache de sessão para sessão ABC atualizada com informações de Accounting-Start.

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

9. Estado da sessão atualizado para Iniciado.

10. O temporizador de aderência expira no balanceador de carga.

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

12. Mensagem de syslog para Accounting-Stop encaminhada por PSN 2 para MNT.

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

Sessão fantasma no PSN

A sessão fantasma é um cenário em que a atualização provisória de contabilidade chega ao PSN que não executou autenticação para esta 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 contabilidade para esta sessão, a entrada não será removida, a menos que o PSN atinja o limite das sessões ativas.

Exemplo de sessão fantasma:

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

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

3. A atualização temporária de relatório para a sessão ABC atinge PSN2.

4. Entrada de sessão da sessão ABC criada no PSN2. Desde que a entrada de sessão foi criada a partir da mensagem contábil, 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 pode aparecer no cache da sessão PSN nos cenários abaixo:

• 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 da rede em direção ao PSN1:

1. Autenticação inicial para a Sessão ABC executada pela 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 Authenticated.

5. Mensagem de início de contabilização para a sessão ABC aterrissa no PSN 1.

6. Entrada de cache de sessão para sessão ABC atualizada com informações de Accounting-Start.

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

8. Estado da sessão atualizado para Iniciado.

9. Atualização de relatório temporário 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 sessão ABC encaminhada para PSN1.

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

13. Mensagem de 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 sendo criada para a conexão VPN de longa duração:

1. Autenticação inicial em PSN1.

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

3. A contabilização inicia a mensagem processada pelo PSN.

4. O novo endereço IP atribuído ao adaptador VPN (Virtual Private Network).

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

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

7. A avaliação de postura acontece com PSN1.

8. Status da postura atualizado na sessão.

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

10. Interrupção no caminho da rede que torna 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. Atualização contábil provisória chega ao PSN2.

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

Se PSN1 posterior se tornar acessível (14) todas as mensagens de contabilidade subsequentes serão encaminhadas (15,16) para lá e isso deixará a sessão ABC no cache da sessão PSN2 por um tempo indefinido.

Como a sessão antiga e a sessão fantasma podem quebrar o processo de postura?

Para entender como a sessão antiga e a sessão fantasma quebrarão a postura, você pode rever o processo de descoberta do módulo de postura do AnyConnect ISE:

Descoberta da fase 1:

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 ponto final.

Primeiro, 3 testadores na figura são baseados em redirecionamento (IP GW padrão. Discovery host IP (se definido) e enroll.cisco.com IP) - Esses testadores devem sempre apontar o agente para a PSN certa, pois a URL de redirecionamento é retirada do próprio NAD.

O teste número 4 é enviado para 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 do arquivo posterior podem ser atualizados caso o cliente migre entre PSNs. Em sistemas Windows, a localização do arquivo é - C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Como todos os testadores da fase 1 são executados simultaneamente, o resultado da prova 4 é usado somente se todos os outros 3 testadores falharem ou o módulo de postura do ISE não puder estabelecer uma comunicação adequada com PSN retornado em URL de redirecionamento em 5 segundos.

Quando a prova 4 chega na PSN, ela contém uma lista de endereços IP e MAC ativos descobertos no endpoint. O PSN usa esses dados para localizar uma sessão para esse endpoint no cache local. Se PSN tiver uma sessão obsoleta ou fantasma para o endpoint, isso pode resultar em status de postura errado 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), sempre é usada a resposta mais rápida.

Descoberta da fase 2:

Todas as sondas de descoberta da fase 2 são sem redirecionamento, o que significa que cada sonda dispara 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 precisará executar a pesquisa do MNT (somente com base no endereço MAC) para localizar um proprietário da sessão e devolver o nome do proprietário ao agente.

Como todas as sondas disparam a pesquisa de sessão, a descoberta da fase 2 pode ser ainda mais afetada por problemas provenientes de sessões obsoletas ou fantasma.

Se o PSN chegar ao estágio 2, a sonda de descoberta que existe no cache da sessão criará uma entrada obsoleta ou fantasma para o mesmo endpoint. Isso resultará no status de postura errado retornado ao usuário final.

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

Note: É importante lembrar que esse problema pode se manifestar somente quando todas as sondas de descoberta baseadas em redirecionamento estiverem falhando ou quando a postura não redirecionada estiver implementada.

1. Qualquer um dos testes Encontre minha sessão emitidos pelo módulo de postura do ISE.

2. O PSN executa a pesquisa de sessão no cache da sessão. Se a sessão for encontrada, ocorrerá um problema de sessão obsoleta ou fantasma.

3. O 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 (as políticas são criadas para grupos específicos do Ative Diretory, por exemplo), a PSN pode não ser capaz de 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".

• Caso as políticas de provisionamento do cliente sejam genéricas (os atributos disponíveis na sessão fantasma são suficientes para corresponder a política com a configuração do AnyConnect), a PSN responderá com os detalhes necessários para a continuação do processo de avaliação.
• Nesta etapa também, quando podemos lidar com sessões antigas, as respostas da PSN imediatamente com status de postura Compatível e todas as próximas etapas não são executadas. O PSN não envia o COA porque acredita que a sessão já está em conformidade. Nos registros do Radius Live não haverá um evento de sessão exibido com o status Compatível.

4. Para o cenário de sessão fantasma, o módulo de postura do ISE continuará com a solicitação de postura inicial. Esta solicitação contém informações sobre todos os produtos de gerenciamento de segurança e patches detectados no endpoint.

5. O PSN usa informações dos atributos de solicitação e sessão para corresponder à política de postura apropriada. Como a sessão fantasma tem uma falta de atributos neste momento, talvez não tenhamos uma política para corresponder. Nesse caso, a PSN responde ao endpoint que está em conformidade, pois esse é um comportamento padrão do ISE no caso de não correspondência de política de postura. 

Note: Quando houver alguma política genérica que possa ser selecionada dos atributos de sessão fantasma, continuaremos com a etapa 6.

6. O PSN retorna as políticas de postura selecionadas de volta ao agente.

Note: Quando nenhuma política pode ser selecionada, o PSN retorna o status Compatível.

7. O agente retorna status para cada política/requisito como passado ou com falha.

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

Note: Em caso de problemas de postura causados pela sessão fantasma, o administrador do ISE pode observar alguns COAs de postura com falha, pois nesse caso as solicitações COA são executadas de PSNs errados 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 acionar 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.
• Alteração do status da interface.
• O SO continua após a suspensão.
• Alteração do gateway padrão (DG).
• Falha na reavaliação da postura (PRA), consulte o bug da Cisco ID CSCvo69557

Nova autenticação dot1x, desbloqueio de PC, alteração de endereço IP não são detectadas pelo módulo de postura ISE.

O módulo de postura do ISE não consegue detectar uma nova autenticação ou tentativa de reautenticação nestes cenários :

• A reautenticação atinge diferentes PSN (devido a decisões LB ou problemas com PSN original).
• O NAD gera um novo ID de sessão na reautenticação.

Reautenticação em PSN diferente

Exemplo de reautenticação em PSN diferente causada pela interrupção da PSN original. O cenário com balanceador de carga será muito semelhante. No caso de LB, reautenticação direcionada para o PSN diferente como resultado da expiração do temporizador de aderência.

1. Autenticação inicial em 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 é movido para Compatível.

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

6. PSN1 fica indisponível.

7. A reautenticação para a sessão ABC atinge PSN2.

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

Status da postura inicial atribuído pelo PSN à sessão:

Note: State-machine descreve apenas uma seleção inicial do status da postura. Cada sessão marcada inicialmente como Desconhecida pode posteriormente se tornar Compatível ou Não Compatível com base na avaliação de 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 lado do ISE. A solução para esse problema será abordada posteriormente neste documento.
• Comportamento incorreto do lado do NAD - normalmente o NAD deve manter o mesmo ID de sessão durante a tentativa de reautenticação. Caso você tenha descoberto que o NAD está alterando uma ID de sessão na reautenticação, esse é um comportamento potencialmente incorreto 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 uma causa disso. O principal aqui é que o ISE PSN sempre colocará uma nova sessão no estado Pendente, a menos que o aluguel de postura esteja configurado. O aluguel de postura será explicado mais adiante neste documento.

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

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

1.  Investigue os detalhes de verificação do sistema:
   
   

     1. Pressione o ícone da engrenagem na IU do AnyConnect

   

         2. Na nova janela, navegue até a guia System Scan (Verificação do sistema) e a subguia Statistics (Estatísticas da subguia)

   

           Aqui, preste atenção em dois elementos:

   •   Hora de início da verificação mais recente - o timestamp aqui deve ser fechado quando o problema foi descoberto.
   •   Servidor de política - este campo indicou o nome do servidor de política que fez uma avaliação de postura para o endpoint. O FQDN daqui precisa ser comparado com o FQDN da URL de redirecionamento (para postura de base de redirecionamento) ou com o nome PSN retirado da última tentativa de autenticação (para postura sem redirecionamento).
2. Compare o FQDN do Servidor de Políticas das Estatísticas de Verificação do Sistema com o nome do nó que fez a autenticação para o ponto final:

No exemplo fornecido, há uma incompatibilidade entre o nome que é indicado que PSN com o nome ciscolive-ise2 contém uma sessão obsoleta ou fantasma para este ponto de extremidade.

A demonstração mostra a gravação das etapas necessárias para a identificação do problema:

Solução avançada de problemas de sessão obsoleta/fantasma

O exemplo anterior é diferenciar o problema de uma sessão obsoleta ou fantasma do problema do processo de descoberta que não foi iniciado. Ao mesmo tempo, podemos precisar identificar a sessão real que disparou o problema para entender melhor como ela se torna exatamente um problema de sessão obsoleta ou fantasma.

Embora em alguns cenários sessões obsoletas e fantasma não possam ser evitadas. Precisamos garantir que não haja sessões obsoletas/fantasmas criadas no ambiente devido a algumas das melhores práticas não estarem sendo implementadas.

Coleção de pacotes DART

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

• Mantenha somente registros importantes no DART. Recomenda-se limpar os registros antes de reproduzir o problema. 

Para isso, o utilitário de pacote DART precisa iniciar como administrador e executar a limpeza de log. 

1. No Windows, vá 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 registros
   
   
   
   
4. Depois de reproduzir o problema, o DART pode ser coletado aqui, siga o assistente e pressione Avançar.

análise de pacote DART

Depois que o pacote DART tiver sido coletado, precisamos removê-lo e focar 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 identificando todos os momentos de reinicialização da descoberta. As palavras-chave a pesquisar são Reiniciando a descoberta ou a descoberta de HTTP. Aqui, navegue até a linha de reinicialização da descoberta que aconteceu no momento problemático:

2. Algumas linhas após o reinício da descoberta devem ser exibidas em uma linha que contém - não detectando nenhum destino de estágio MNT. Este é um indicador do início da descoberta do Estágio 1:

Recomenda-se destacar todas as sondas baseadas em redirecionamento com a mesma cor enquanto PSNs conectadas anteriormente obtidas do ConnectionData.xml (alvos de Status Auth) precisam ser realçadas em cores diferentes, pois normalmente os FQDNs PSN são muito semelhantes e é difícil identificar a diferença.

3. Siga os arquivos de log para ver um resultado para cada sonda. Como já foi dito, no caso do problema causado pela sessão obsoleta/fantasma, todas as sondas baseadas em redirecionamento têm que falhar. Abaixo está um exemplo de como a sonda com falha se parece:

4. Em algum lugar no arquivo após a reinicialização da descoberta para a etapa 1 ou a etapa 2, você deve ver uma resposta bem-sucedida de um ou mais PSNs:

5. Algumas linhas depois devem ter uma linha com a palavra-chave MSG_NS_SWISS_NEW_SESSION. Esta 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 uma investigação mais detalhada sobre o ISE para 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 Stale/Phantom pode ser visto.

O PSN recebe uma solicitação do agente de postura do ISE. Você pode ver que esta é uma solicitação do AnyConnect devido ao valor User-Agent:

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 array tem apenas um valor. O log também mostra que a ID da sessão da solicitação é nula, o que indica que essa é uma solicitação da prova baseada em não-redirecionamento.

Mais tarde, você pode ver como os valores dos arrays são usados para localizar um ID de sessão:

cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being 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

Depois da linha com palavras-chave Enviado resposta http, 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 entender melhor o que fez com que esta sessão se tornasse obsoleta/fantasma:

• Navegue até Operações > Relatórios > Endpoints e Usuários > Relatório de Contabilidade Radius e execute esse relatório por 7 dias. O usuário e a ID do endpoint como uma chave de filtro.

Exemplo de um relatório que mostra como uma sessão antiga foi deixada no ciscolive-ise2:

1. O início contábil da sessão veio para o 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 da ID de sessão problemática veio para PSN diferente (ciscolive-ise1).

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

Aqui a mesma lógica é aplicável à 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 e hora da última verificação estará em algum lugar no passado.

Normalmente, quando o usuário final descobre um problema, uma verificação que aconteceu há algum tempo é exibida. Enquanto nos registros ISE Radius Live, tentativas recentes de autenticação do endpoint problemático são vistas.

A demonstração abaixo mostra a gravação das etapas necessárias para a identificação do problema:

Solução de problemas avançada da ausência de reinicialização da 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 por reinicializações de descoberta como se ele tivesse sido mostrado para o problema anterior e confirmar que não houve reinicialização de descoberta no momento em que o problema foi relatado.

No lado ISE, concentre-se no relatório de autenticação Radius Live Logs/ Radius para confirmar que houve failover entre PSNs ou que o novo ID de sessão foi gerado 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 melhores práticas que estão sendo 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

Implemente sempre postura baseada em redirecionamento quando possível

Um contraponto comum a esta recomendação é uma experiência de usuário ruim, pois os usuários veem pop-ups no SO ou nos navegadores indicando redirecionamento enquanto o módulo de postura do AnyConnect ISE em segundo plano executa um processo de avaliação.

Como solução para isso, é possível redirecionar SOMENTE sondas de descoberta do módulo de postura do ISE enquanto permite seletivamente todo o tráfego restante.

O exemplo mostra a ACL de redirecionamento projetada para redirecionar somente solicitações HTTP para o Host de descoberta (1.1.1.1 neste exemplo) e enroll.cisco.com (72.163.1.80):

ip access-list extended REDIRECT-DH-ENROLL

 permit tcp any host 1.1.1.1 eq www

 permit tcp any host 72.163.1.80

 deny   ip any any

Para manter um nível aceitável de segurança, essa ACL de redirecionamento pode ser combinada com DACL atribuído do ISE.

Estado pendente permite conexões somente com a PSN onde o endpoint foi autenticado

Essa abordagem é útil para os ambientes em que 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 ocorreu a autenticação. No perfil de autorização atribuído a cada política, o acesso a todos os PSNs deve ser bloqueado, exceto o nó onde a autenticação ocorreu.

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

1. Política de postura pendente 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 PSN1.

4. Política de postura pendente 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 PSN2.

7. Postura política de autorização 'em conformidade'.

A figura explica como essa abordagem funciona:

1. A autenticação atinge PSN1.

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

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

4. Teste para PSN2 bloqueado pelo NAD como por uma ACL atribuída anteriormente.

5. Teste para PSN1 permitido pela ACL atribuída em NAD.

Práticas recomendadas para balanceador de carga

• Ativada a autossuficiência em LB para autenticação e tarifação usando Calling-Station-ID como chave de adesão. Mais detalhes sobre as melhores práticas LB para ISE estão disponíveis aqui.
• Use o temporizador de fidelidade por mais tempo que um dia útil médio para cobrir o momento em que o PC entra em modo de espera (por exemplo, 10 horas em vez de 8 horas).
• Caso a reautenticação seja implementada, use o temporizador de reautenticação ligeiramente inferior ao temporizador de aderência (por exemplo, 8 horas se a aderência for configurada para 10 horas). Isso garantirá que o intervalo de aderência seja prolongado pela reautenticação.

Postura sobre caso de uso de VPN 

• Garante que o intervalo de atualização de relatório temporário seja maior ou igual a vpn-session-timeout. Isso protegerá contra oscilações de contabilidade entre PSNs em sessões de VPN com vida longa. 

O exemplo abaixo mostra o intervalo de atualização de relatório temporário configurado para 20 horas. Isso não impedirá a atualização temporária inicial que transporta o endereço IP atribuído ao endpoint.

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 do módulo de descoberta de postura do ISE

Habilitar aluguel 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 do aluguel de postura é um atributo de endpoint que significa que ele está armazenado no ISE DB. Todos os atributos de endpoint, incluindo o aluguel de postura, estão sendo replicados em todos os nós na implantação do ISE.

Quando o PSN recebe uma nova sessão para a postura do endpoint, o leasing pode ser utilizado para marcar a sessão como Compatível imediatamente.

Para tomar essa decisão, o PSN usa 3 valores. Esses valores são:

• Quantidade de dias definida para locação de postura nas configurações do ISE navegando 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 e hora da época. O valor PostureExpiry é preenchido inicialmente na primeira tentativa bem-sucedida de postura para endpoint após o aluguel de postura habilitado pelo administrador do ISE. Posteriormente, esse valor foi atualizado na próxima tentativa de postura bem-sucedida que acontece após o vencimento do leasing.

            Você pode ver um PostureExpiry em Context Visibility > Endpoints ao abrir um dos endpoints posturados:

           Este valor pode ser convertido no timestamp legível para humanos, por exemplo aqui - https://www.epochconverter.com/

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

Quando a autenticação para um endpoint com aluguel de postura atinge o 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 resultante estiver dentro de um intervalo de locação de postura definido nas configurações, a sessão obterá um status Compatível. Se o valor resultante for maior que o valor do leasing, a sessão obterá um status Desconhecido. Isso aciona a postura a ser executada novamente e o novo valor PostureExpiry pode ser salvo.

A figura explica o processo quando ocorre failover:

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

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

3. A avaliação de postura acontece.

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

5. O COA disparado 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 na implantação.

8. A próxima autenticação atinge PSN2.

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

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

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

Implementação de reautenticação

Sempre envie o temporizador de reautenticação do ISE com RADIUS-Request selecionado em Manter 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 que foram explicadas na seção de sessão obsoleta/fantasma.

Sub-redes diferentes podem ser usadas para estados pendentes e compatíveis

Quando o projeto de rede oferece a oportunidade de usar diferentes sub-redes Pendentes e Compatíveis, essa abordagem garante que cada alteração no status de postura resulta na alteração do Gateway Padrão.

Avaliação de postura usada no mesmo intervalo de 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 ficar disponível, a falha de PRA reiniciará o processo de descoberta.

Abordagem moderna - Compartilhamento de estado de postura

Como parte da implementação de um aprimoramento, descrito no CSCvi35647 patch 6 para o 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. Essa melhoria também será integrada em versões futuras: Os 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. Nas versões mais recentes, essa funcionalidade foi renomeada para Light Data Distribution (LDD) Radius Session Diretory.  Por padrão, a Distribuição de Dados Leves é habilitada e permite o compartilhamento de um contexto de sessão limitado entre nós ISE. Não existe uma 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 Light Session Diretory é remover a necessidade de executar chamadas de API caras de recursos para o MNT quando um dos nós na implantação precisa descobrir quem é o proprietário da sessão atual. A maior parte da pesquisa do proprietário é necessária quando o fluxo do COA é iniciado. Com o LDD, cada PSN pode encontrar um proprietário real da sessão do cache do Diretório de Sessão Radius local. 

Arquitetura de distribuição de dados leve

Essa funcionalidade contém os seguintes elementos:

• Cache RSD (Radius Session Diretory) - esse cache existe em cada nó 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
  • IP do endpoint.
  • PSN IP - PSN onde aconteceu a autenticação.
  • PSN FQDN - o mesmo que acima.
  • NAS-IP-Address (Endereço IP NAS).
  • NAS-IPv6-Address (Endereço NAS-IPv6).
  • Estado - Autenticado, Iniciado, Interrompido.

• Troca RabbitMQ - Há uma troca formada na qual Publisher, correspondente fila e consumidor 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.

• Publisher - 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 da 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 geral do RabbitMQ estão fora do escopo deste documento. 

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

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

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

3. Os atributos necessários são salvos no RSD.

4. Sessão compartilhada no 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 no PSN2.

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

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

9. Os dados do cache RSD usados para preparar uma mensagem de COA de Proxy (um COA que vai de um nó ISE a outro, contém todos os detalhes que o nó de destino pode usar para emitir uma solicitação de CAO de volta ao NAD). Mensagem COA transferida primeiramente para PRRT Runtime (servidor AAA real dentro do ISE).

10. PSN2 envia uma mensagem COA para PSN1.

11. PSN1 envia uma mensagem COA para NAD.

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

 exemplo de mensagem de depuração do arquivo lsd.log para criação e publicação de sessã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ê deve 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 sobre RSD

O compartilhamento de status de postura entre os nós resolve o problema que tem o sintoma como 'O módulo de postura do AnyConnect ISE mostra a conformidade enquanto o status da sessão no ISE está pendente' quando a causa raiz subjacente é a sessão Stale/Phantom ou Re-authentication em PSN diferente com uma ID de sessão original que não acionou o reinício da descoberta. Assim que a sessão se tornar Compatível, 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 a reautenticação no mesmo PSN, mas com uma ID de sessão diferente. Tais cenários podem ser tratados com a implementação das melhores práticas descritas neste documento.

A figura demonstra a topologia usada para testar o compartilhamento do status da postura:

Compartilhamento de status de postura por RSD - Sessão obsoleta/fantasma

Para criar uma autenticação de sessão obsoleta, foi inicialmente executada no skuchere-ise26-1 e depois o NAD foi reconfigurado para enviar a contabilidade para skuchere-ise26-3. Depois que uma mensagem contábil tiver sido encaminhada para a PSN incorreta, a NAD foi reconfigurada novamente para enviar a contabilidade de volta para skuchere-ise26-1.

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

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

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

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

Depois de algum tempo, o endpoint se conecta novamente à rede, mas o redirecionamento não está mais funcionando. No guest.log do PSN - skuchere-ise26-3, você pode ver as seguintes mensagens de log com o componente client-webapp ativado 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 o PSN detecta que ele tem uma sessão obsoleta/fantasma para o endpoint, ele não responde ao módulo de postura do ISE e isso nos permite obter a resposta certa do PSN onde ocorreu a autenticação mais recente.

Como uma solução para o problema de sessão obsoleta/fantasma agora 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 ID de sessão diferente do que o PSN tem no cache de sessão local, ele assumirá 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 curto temporizador de reautenticação foi ativado no perfil de autorização atribuído ao endpoint no estado de conformidade. Posteriormente, o NAD foi reconfigurado para enviar autenticação e tarifação para outro PSN (skuchere-ise26-3). Após a expiração do temporizador de reautenticação, a mesma sessão não foi autenticada no PSN diferente.

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

1. A autenticação acontece em 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 PSN diferente, mas ainda está recebendo perfil de autorização para o estado em conformidade.

A sessão está obtendo status de conformidade no novo PSN após failover em ise-psc.log com epm-pip e nsf-session componentes 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 adicionando uma lógica extra ao processo de seleção do status da postura. A figura demonstra o que foi alterado (alterações destacadas em vermelho):