Solución de problemas de administración y estado de sesiones de ISE

Introducción

Este documento describe el problema común de los servicios de estado de Identity Service Engine (ISE): "El módulo de estado de AnyConnect ISE muestra compatibilidad..."

Antecedentes

Este documento describe el problema común de los servicios de estado de Identity Service Engine (ISE): el módulo de estado de AnyConnect ISE muestra compatibilidad mientras el estado de la sesión en ISE está pendiente.

Si bien los síntomas son siempre los mismos, hay múltiples causas principales de este problema.

A menudo, la resolución de un problema de este tipo consume mucho tiempo, lo que causa un impacto grave.

Este documento explica:

• Manifestación del problema desde la perspectiva del usuario final y de la administración de ISE.
• Escenarios problemáticos comunes.
• La teoría que subyace a ISE, AnyConnect y las operaciones de red que desencadenan el problema.
• Algoritmos de identificación rápida de problemas.
• Soluciones clásicas a escenarios problemáticos comunes.
• Uso compartido del estado de postura en el directorio de sesión de Radius.

Para obtener una mejor explicación de los conceptos descritos más adelante, consulte:

Problema

Experiencia del usuario final

Este problema se manifiesta normalmente en ausencia de acceso a la red o redirección constante al portal de aprovisionamiento de clientes de ISE en el navegador, mientras que, al mismo tiempo, el módulo de estado de AnyConnect ISE muestra el estado como Conforme.

Experiencia típica del usuario final:

Experiencia de administración de ISE

Normalmente, en la selección inicial de este problema, el administrador de ISE realiza una investigación de los registros de Radius Live para asegurarse de que existe una autenticación real que llegue a ISE.

El primer síntoma detectado en esta etapa indica una discordancia en un estado entre el terminal e ISE como en los registros en vivo o los informes de autenticación Radius de la última autenticación exitosa para el terminal muestra el estado Pendiente.

Experiencia de administración típica de ISE:

• Última autenticación correcta para la identidad: alice.
• El estado de la sesión es Pendiente.
• Último evento de sesión para Identity: alice.
• El evento de sesión muestra el estado como Conforme.

Nota: c. y d. no siempre se presentan en los registros activos cuando se manifiesta el problema descrito. Un evento de sesión con un estado de cumplimiento es más común en los escenarios causados por las sesiones antiguas o fantasma (que se describen más adelante en este documento).

Escenarios problemáticos comunes

Este problema se manifiesta normalmente en dos situaciones problemáticas y cada una de ellas tiene múltiples causas principales. Los escenarios:

• El módulo de estado de AnyConnect ISE ha recibido información errónea por parte del nodo de servicios de políticas (PSN) durante el proceso de estado, lo que ha provocado que se muestre un estado incorrecto. 

En este caso, normalmente tratamos con una sesión obsoleta o fantasma en la memoria caché de sesión de PSN.

• AnyConnect ISE muestra el estado del ciclo de detección anterior porque la autenticación actual no activó un proceso de detección.

El módulo de estado de ISE de AnyConnect tiene un número limitado de eventos que activan el proceso de detección. Es posible que durante la autenticación o reautenticación no se detectara ninguno de estos eventos.

Problema de sesión fantasma/obsoleto

Para entender mejor el problema, investigue la lógica de administración de sesiones de ISE y el proceso de detección de AnyConnect necesarios.

Lógica de ISE Session Management

En la implementación de ISE, hay dos personas responsables del proceso de gestión de sesiones: PSN y el nodo de supervisión (MNT).

Para resolver e identificar este problema de forma adecuada, es fundamental entender la teoría de la gestión de sesiones en ambas personas.

MNT y gestión de sesiones

Como se explica en esta imagen, el nodo MNT crea temporadas basadas en los mensajes de Syslog de autenticación pasados que provienen de PSN.

El estado de la sesión se puede actualizar más tarde mediante el registro del sistema para la contabilidad.

La eliminación de sesiones en MNT ocurre en 3 escenarios:

1. Las sesiones sin inicio de contabilidad se eliminan aproximadamente 60 minutos después de que se hayan creado: hay un trabajo cron ejecutado cada 5 minutos para comprobar los estados de sesión y limpiar.

2. La sesión finalizada se ha eliminado aproximadamente 15 minutos después de que la parada contable haya sido procesada por la misma tarea cron.

3. El mismo cron en cada ejecución elimina también las sesiones que han estado en el estado 'Iniciado' durante más de 5 días (120 horas). Un estado iniciado significa que el nodo MNT procesó tanto la autenticación como la contabilización para iniciar Syslog para la sesión.

Ejemplos de mensajes Syslog de PSN:

Estos mensajes se registran en prt-server.log cuando el componente runtime-aaa se habilita en DEBUG. Las partes en negrita se pueden utilizar para construir expresiones regulares de búsqueda.

Autenticación superada:

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

Inicio de contabilización:

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

Actualización de contabilidad provisional:

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 Contabilización:

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 y gestión de sesiones

La memoria caché de sesiones de PSN es una base de datos en memoria que almacena todas las sesiones activas de PSN específico. La caché de sesión siempre es local para el nodo.

No existe ningún mecanismo en ISE que pueda realizar la replicación del estado de sesión COMPLETA de un nodo a otro.

Para cada ID de sesión activa, PSN almacena todos los atributos que se recopilaron durante la fase de autenticación/autorización (por ejemplo, grupos de usuarios internos/externos, atributos de dispositivo de acceso a la red (NAD), atributos de certificado, etc.). PSN utiliza estos atributos para seleccionar diferentes tipos de políticas (como autenticación, autorización, aprovisionamiento de clientes y estado).

La caché de sesión se quita por completo cuando se reinicia el nodo (o los servicios del nodo).

La lógica de procesamiento de sesión actual crea una nueva entrada en la caché de sesión en dos escenarios. Los detalles posteriores de las sesiones existentes se pueden actualizar a partir de los mensajes de cuentas que provienen de los NAD.

• La sesión se ha autenticado correctamente en PSN.
• PSN obtuvo una actualización intermedia de contabilidad para la sesión que no existe en la memoria caché de la sesión.

Cuando se trata de la eliminación de sesiones, PSN implementa esta lógica:

• La entrada de caché de sesión se elimina inmediatamente después de procesar el mensaje de detención de cuentas.
• PSN comienza a eliminar las sesiones utilizadas menos recientemente cuando un nodo alcanza ellímite de sesiones activas.

Sesión obsoleta en PSN

En la implementación de ISE, la detención de cuentas de una sesión existente ha sido procesada por PSN, que no realizó la autenticación real:

Ejemplo de la sesión obsoleta:

1. La autenticación exitosa ocurre en PSN para la sesión ABC.

2. PSN crea una entrada en la caché de sesión.

3. La evaluación de la postura ocurre.

4. La sesión se marca como Conforme.

5. El cambio de autorización (COA) (provocado por el cambio de estado) lleva a la reautenticación del terminal para aplicar el siguiente nivel de acceso.

6. La parada contable de la sesión ABC llega a PSN2.

Después de eso, ABC se atasca en el estado obsoleto en PSN1 porque no hay ningún mensaje de detención de contabilización procesado en este PSN para eliminarlo.

La sesión se elimina durante mucho tiempo si la implementación no experimenta un gran número de intentos de autenticación.

La sesión obsoleta aparece en la memoria caché de sesión de PSN en estos escenarios:

• La detención de la contabilización se produjo en el PSN incorrecto debido a la expiración del temporizador de conservación en el equilibrador de carga.
• La configuración incorrecta en el NAD no es la misma PSN configurada para la autenticación y la contabilización.
• Problemas de conectividad temporal en la ruta de red que provoca la conmutación por error de NAD al siguiente PSN.

Ejemplo de la sesión obsoleta en el entorno del equilibrador de carga (LB):

1. PSN 1 realiza la autenticación inicial para la sesión ABC.

2. Esta autenticación inicia un temporizador de conservación en el equilibrador de carga.

3. PSN 1 crea una entrada para la sesión ABC en la caché local.

4. Mensaje de registro del sistema para la autenticación pasada transferido al nodo MNT.

5. La entrada para la sesión ABC se crea en el directorio de sesión MNT con el estado Autenticado.

6. El mensaje de inicio contable de la sesión ABC aterriza en PSN 1.

7. La entrada de caché de sesión para la sesión ABC se actualiza con información de Inicio Contable.

8. El mensaje de Syslog para Accounting-Start se transfiere al nodo MNT.

9. El estado de sesión se actualiza a Iniciado.

10. El temporizador de conservación caduca en el equilibrador de carga.

11. El equilibrador de carga reenvía la parada contable de la sesión ABC a PSN 2.

12. PSN 2 reenvía el mensaje de registro del sistema para la parada de contabilidad a MNT.

13. La sesión ABC se marca como finalizada en MNT.

Sesión fantasma en PSN

La sesión fantasma es un escenario en el que la actualización provisional de cuentas llega al PSN que no realizó la autenticación para esta sesión específica. En este escenario, se crea una nueva entrada en la memoria caché de sesión de PSN.

Si PSN no recibe un mensaje de detención de contabilización para esta sesión, la entrada no se elimina a menos que PSN alcance el límite de sesiones activas.

Ejemplo de la sesión fantasma:

1. Los mismos pasos que se describen en el ejemplo de sesión obsoleta se realizan en PSN1 para la sesión ABC.

2. La sesión ABC tiene un estado Conforme en la caché de sesión de PSN1.

3. Una actualización provisional de contabilidad para la sesión ABC llega a PSN2.

4. Se crea una entrada de sesión para la sesión ABC en PSN2. Dado que la entrada de sesión se crea a partir del mensaje de contabilidad, tiene un número limitado de atributos. Por ejemplo, el estado no está disponible para la sesión ABC. También faltan elementos como los grupos de usuarios y otros atributos específicos de autorización.

La sesión fantasma aparece en la memoria caché de la sesión PSN en estos escenarios:

• Interrupción a corto plazo en el tránsito de la red.
• Mal comportamiento del dispositivo de acceso a la red.
• Mala conducta o configuración incorrecta en el equilibrador de carga.

Este es un ejemplo de una sesión fantasma para el escenario con problemas temporales en la trayectoria de red hacia PSN1:

1. La autenticación inicial para la sesión ABC la realiza el PSN.

2. PSN1 crea una entrada para la sesión ABC en la caché local.

3. El mensaje syslog para la autenticación pasada se transfiere al nodo MNT.

4. Se crea una entrada para la sesión ABC en TimesTen DB con el estado Authenticated.

5. El mensaje de inicio contable de la sesión ABC aterriza en PSN 1.

6. Una entrada de caché de sesión para la sesión ABC se actualiza con información de Accounting-Start.

7. El mensaje Syslog para Accounting-Start se transfiere al nodo MNT.

8. El estado de la sesión se actualiza a Iniciado.

9. La actualización de la contabilidad intermedia para la sesión ABC se reenvía a PSN2.

10. PSN2 crea una entrada para la sesión ABC en la caché local.

11. La parada contable de la sesión ABC se reenvía a PSN1.

12. La entrada de la sesión ABC se elimina de la caché de sesiones en PSN1.

13. PSN 1 reenvía un mensaje de syslog para Accounting-Stop a MNT.

14. La sesión ABC se marca como finalizada en MNT.

Esto representa un escenario de la sesión fantasma creada para la conexión VPN de larga duración:

1. Autenticación inicial en PSN1.

2. La sesión ABC se crea en la caché de la sesión.

3. La contabilidad inicia el mensaje procesado por PSN.

4. La nueva dirección IP se asigna al adaptador de red privada virtual (VPN).

5. Una actualización contable provisional con información de dirección IP aterriza en PSN.

6. La información de la dirección IP se agrega a la memoria caché de la sesión.

7. La evaluación de la postura se realiza con PSN1.

8. El estado se actualiza en la sesión.

9. ISE ejecuta una inserción de COA; esto activa la asignación de un nuevo nivel de acceso.

10. Hay una interrupción en la ruta de red que hace que PSN1 sea inaccesible.

11. Tras la expiración de un intervalo de actualización provisional, ASA/FTD detecta que PSN1 es inaccesible. 

12. La actualización contable provisional se refiere a PSN2.

13. La sesión fantasma se crea en la caché de sesión de PSN2.

Si se puede acceder a PSN1 más tarde (14), todos los mensajes de cuentas posteriores se reenvían (15,16) allí y esto deja la sesión ABC en la caché de sesiones de PSN2 durante un tiempo no definido.

Cómo rompen el proceso de postura una sesión obsoleta y una sesión fantasma

Para comprender cómo la sesión obsoleta y la sesión fantasma rompen el estado, puede revisar el proceso de detección del módulo de estado de AnyConnect ISE:

Descubrimiento de la etapa 1:

Durante esta etapa, el módulo de estado de ISE ejecuta 4 problemas simultáneos para localizar el PSN que realizó una autenticación para el terminal.

En primer lugar, 3 sondeos de la figura se basan en la redirección (IP GW predeterminada. IP de host de detección (si se define) e IP de enroll.cisco.com) ; estos sondeos siempre señalan al agente al PSN correcto, ya que la URL redirigida se toma del propio NAD.

El sondeo número 4 se envía a todos los servidores principales que se presentan en el archivo ConnectionData.xml. Este archivo se crea después del primer intento de postura correcto. El contenido del archivo se puede actualizar más adelante en caso de que el cliente migre entre PSN.

En sistemas Windows, la ubicación del archivo es C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Dado que todos los sondeos de la etapa 1 se ejecutan simultáneamente, el resultado del sondeo 4 se utiliza solo si los otros 3 sondeos fallaron o si el módulo de postura de ISE no pudo establecer una comunicación adecuada con el PSN devuelto en la URL de redirección en 5 segundos.

Cuando la sonda 4 aterriza en el PSN, contiene una lista de direcciones IP y MAC activas detectadas en el terminal. PSN utiliza estos datos para buscar una sesión para este extremo en la caché local.

Si PSN tiene una sesión obsoleta o fantasma para un terminal, esto puede dar lugar a un estado incorrecto que se muestra más adelante en el lado del cliente.

Cuando un agente obtiene varias respuestas para la sonda 4 (ConnectionData.xml puede contener más de un PSN principal), siempre se utiliza la respuesta más rápida.

Descubrimiento de la etapa 2:

Todos los sondeos de detección de etapa 2 son sin redirección, lo que significa que cada sondeo activa una búsqueda de sesión en el PSN de destino.

Si el PSN no puede localizar la sesión en la caché de sesión local, debe realizar una búsqueda MNT (sólo basada en direcciones MAC) para buscar un propietario de sesión y devolver el nombre de propietario al agente.

Dado que todos los sondeos activan la búsqueda de sesiones, la detección de la etapa 2 puede verse aún más afectada por los problemas derivados de sesiones antiguas o fantasma.

Si PSN llega a la etapa 2, la sonda de detección que existe en la memoria caché de la sesión crea una entrada obsoleta o fantasma para el mismo terminal. El resultado es que se devuelve al usuario final un estado de postura incorrecto.

El ejemplo muestra cómo se produce el estado cuando PSN mantiene una sesión obsoleta o una sesión fantasma:

Nota: Este problema sólo se puede manifestar cuando todos los sondeos de detección basados en redirección fallan o cuando se implementa la postura de no redirección.

1. Cualquiera de las sondas Find my session emitidas por el módulo de postura ISE.

2. PSN realiza la búsqueda de sesión en la caché de sesión. Si se encuentra la sesión, se produce un problema de sesión obsoleta o fantasma.

3. PSN ejecuta la selección de política de aprovisionamiento de clientes. En un caso en el que una sesión fantasma que carece de atributos de autenticación/autorización y todas las políticas configuradas por el cliente son muy específicas (por ejemplo, las políticas se crean para grupos específicos de Active Directory), PSN no puede asignar una política de aprovisionamiento de cliente adecuada. Esto puede manifestarse en el mensaje de error: "Omitiendo el análisis de AnyConnect su red está configurada para utilizar el agente Cisco NAC".

• En los casos en los que las políticas de aprovisionamiento del cliente son genéricas (los atributos disponibles en la sesión fantasma son suficientes para hacer coincidir la política con la configuración de AnyConnect), PSN responde con los detalles necesarios para la continuación del proceso de evaluación.
• En este paso, cuando podemos lidiar con sesiones obsoletas, PSN responde inmediatamente con un estado de Conforme y no se realizan todos los pasos siguientes. PSN no envía COA porque cree que la sesión ya cumple los requisitos. En los registros de Radius Live, no se muestra ningún evento de sesión con el estado Conforme.

4. Para el escenario de sesión fantasma, el módulo de estado de ISE continúa con la solicitud de estado inicial. Esta solicitud contiene información sobre todos los productos de administración de parches y seguridad detectados en el terminal.

5. PSN utiliza la información de los atributos de solicitud y de sesión para hacer coincidir la política de estado adecuada. Debido a que la sesión fantasma carece de atributos en este momento, no tenemos ninguna política que coincida. En tal caso, PSN responde al terminal que es compatible. Se trata de un comportamiento predeterminado de ISE en el caso de que la política de estado no coincida. 

Nota: Si hay alguna política genérica que se puede seleccionar de atributos de sesión fantasma, continuamos con el paso 6.

6. PSN devuelve al agente las políticas de estado seleccionadas.

Nota: Cuando no se puede seleccionar ninguna política, PSN devuelve el estado Conforme.

7. El agente devuelve los estados de cada política/requisito como "superado" o "fallido".

8. La evaluación de informes se realiza en ISE y el estado de la sesión cambia a Conforme.

Nota: En caso de problemas de estado causados por la sesión fantasma, es posible que el administrador de ISE detecte algunos COA de estado fallidos. En estos casos, las solicitudes COA se ejecutan desde los PSN incorrectos y para los ID de sesión incorrectos.

El proceso de detección no se inicia en un nuevo intento de autenticación

El módulo de estado de ISE está diseñado para supervisar una cantidad limitada de eventos en el terminal para activar un proceso de detección.

Eventos que activan la detección:

• Instalación inicial del módulo de estado de ISE.
• Inicio de sesión de usuario.
• Eventos de alimentación.
• Cambio del estado de la interfaz.
• OS se reanuda después de la suspensión.
• Cambio de gateway predeterminado (DG).
• Error en la reevaluación de estado (PRA), consulte el ID de error de Cisco CSCvo69557

El módulo de estado de ISE no detecta la nueva autenticación dot1x, el desbloqueo de PC ni el cambio de dirección IP.

El módulo de estado de ISE no puede detectar un nuevo intento de autenticación o reautenticación en estos escenarios :

• La reautenticación llega a diferentes PSN (ya sea debido a decisiones de LB o a problemas con PSN original).
• NAD genera un nuevo Id. de sesión al volver a autenticar.

Reautenticación en diferentes PSN

Este diagrama representa un ejemplo de reautenticación en diferentes PSN causada por la interrupción del PSN original. Un escenario con un equilibrador de carga es muy similar.

En el caso de un balanceador de carga, la reautenticación se dirige a los diferentes PSN como resultado de un vencimiento del temporizador de conservación.

1. Autenticación inicial en PSN1

2. La sesión ABC se crea en la caché de sesión de PSN1.

3. La evaluación de la postura se realiza con PSN1.

4. El estado de la postura ABS de la sesión pasa a Conforme.

5. El COA se activa por un cambio de estado y conduce a la reautenticación del terminal para aplicar el siguiente nivel de acceso.

6. PSN1 deja de estar disponible.

7. La reautenticación para la sesión ABC llega a PSN2.

8. Dado que se trata de una nueva sesión de PSN2, el estado de la sesión pasa a ser Pendiente.

PSN asigna el estado de postura inicial a la sesión:

Nota: State-machine describe solo una selección inicial del estado de la postura. Cada sesión que se marca inicialmente como Desconocida puede pasar a ser Conforme o No conforme en función de la evaluación de informe recibida del módulo de estado de ISE.

NAD genera un nuevo ID de sesión al volver a autenticar

Esto podría ocurrir en los dos escenarios más comunes:

• La reautenticación está configurada incorrectamente en el lado de ISE. La solución a este problema se trata más adelante en este documento.
• Error de comportamiento del lado NAD; normalmente NAD mantiene el mismo ID de sesión durante el intento de reautenticación. Se trata de un comportamiento potencialmente irregular que debe investigarse en el propio NAD.

El nuevo ID de sesión se puede generar en algunos otros escenarios de casos extremos. Por ejemplo, en algunos casos, la itinerancia inalámbrica puede ser la causa.

Lo principal aquí es que ISE PSN siempre coloca una nueva sesión en el estado Pendiente a menos que se configure la concesión de estado. La concesión del estado se explica más adelante en este documento.

Manera rápida de identificar cuándo el problema fue causado por la sesión obsoleta/fantasma

Para identificar si AnyConnect muestra cumplimiento mientras está en estado de redirección, la sesión obsoleta/fantasma es la causa. Tenemos que obtener acceso al terminal mientras se encuentra en el estado problemático.

1.  Investigar detalles del análisis del sistema:
   
   

     1. Haga clic en el icono de engranaje en la interfaz de usuario de AnyConnect

   

         2. En la nueva ventana, navegue hasta Análisis del sistema > Estadísticas

   

           Aquí, preste atención a dos elementos:

   •   Última hora de inicio del análisis: la marca de tiempo debe estar cerrada a la hora en que se detectó el problema.
   •   Servidor de políticas: este campo indica el nombre del servidor de políticas que realizó una evaluación de estado para el terminal. El FQDN de aquí debe compararse con el FQDN de URL de redirección (para estado de base de redirección) o con el nombre PSN tomado del último intento de autenticación (para estado sin redirección).
2. Compare el FQDN del servidor de directivas desde Estadísticas de análisis del sistema con el nombre del nodo que realizó la autenticación para el terminal:

La demostración muestra la grabación de los pasos necesarios para la identificación del problema:

Resolución de problemas avanzada de sesión obsoleta/fantasma

El ejemplo anterior sirve para diferenciar el problema de una sesión obsoleta o fantasma del problema del proceso de detección que no se inició.

Al mismo tiempo, necesitamos identificar la sesión real que desencadenó el problema para entender mejor cómo se convierte exactamente en un problema de sesión obsoleto o fantasma.

Si bien en algunos escenarios no se pueden evitar las sesiones fantasma y obsoletas, necesitamos asegurarnos de que se implementan las mejores prácticas para que no se creen sesiones fantasma o obsoletas en el entorno.

Colección de paquetes DART

Analice un paquete DART tomado del terminal que reproduce el problema.

• Mantenga sólo los registros importantes en el DART. Se recomienda borrar los registros antes de que se reproduzca el problema. 

Para conseguirlo, la utilidad del paquete DART debe iniciarse como administrador y llevar a cabo la limpieza de registros. 

1. En Windows, vaya a Inicio y empiece a escribir DART, haga clic con el botón secundario y seleccione - Ejecutar como administrador
   
   
2. En la primera pantalla del asistente, haga clic en Siguiente.
   
   
3. En la siguiente pantalla del asistente, haga clic en Clear All Logs (Borrar todos los registros).
   
   

4. Una vez reproducido el problema, puede recopilar DART desde aquí; haga clic en Next (Siguiente).

análisis de paquetes DART

Una vez recopilado el paquete DART, anule su archivado y céntrese en el archivo AnyConnect_ISEPosture.txt que se encuentra en la carpeta Cisco AnyConnect ISE Posture Module. Este archivo contiene todos los eventos relacionados con la detección.

1. Inicie la resolución de problemas e identifique todos los momentos de reinicio de detección. Las palabras clave que se deben buscar son Reinicio de la detección o HTTP Discovery. Aquí, navegue hasta la línea con reinicio de detección que ocurrió en el momento problemático:

2. Varias líneas después del reinicio de detección, hay una línea que contiene - Sondeo de no MNT objetivos de etapa. Este es un indicador del inicio de la detección de la Etapa 1:

Se recomienda resaltar todos los sondeos basados en redirección con el mismo color y PSN previamente conectados tomados de ConnectionData.xml (destinos de estado de autenticación) en un color diferente.

Normalmente, los FQDN de PSN son muy similares y es difícil detectar la diferencia.

3.Lea los archivos de registro para ver un resultado para cada sondeo individual. Este es un ejemplo de cómo se ve el sondeo fallido:

4. En algún lugar del archivo después de reiniciar la detección para la etapa 1 o la etapa 2, verá una respuesta exitosa de uno o más PSN:

5. Varias líneas más adelante, hay una línea con la palabra clave MSG_NS_SWISS_NEW_SESSION.

Esta línea contiene un ID de sesión real que PSN ha seleccionado como resultado de la búsqueda de sesión.

Utilice este ID de sesión para investigar más a fondo sobre ISE y determinar cómo se queda obsoleta/fantasma esta sesión:

Investigación sobre registros de ISE

 En el guest.log con el componente clientwebapp habilitado en DEBUG, se puede ver el PSN que responde con la sesión Stale/Phantom.

PSN recibe una solicitud del agente de estado de ISE. Se trata de una solicitud de AnyConnect debido al 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

La solicitud contiene matrices de direcciones IP y direcciones MAC. En este ejemplo concreto, cada matriz contiene sólo un valor.

El registro muestra que el ID de sesión de la solicitud es nulo, lo que indica que se trata de una solicitud de la sonda no basada en redireccionamiento.

Más adelante podrá ver cómo se utilizan los valores de las matrices para localizar un ID de sesión:

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

Después de la línea con las palabras clave Sent http response, puede ver el contenido de la respuesta 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

Investigación sobre los informes de ISE

Después de conocer el ID de la sesión obsoleta/fantasma, puede investigar el informe de Contabilidad Radius para comprender mejor qué causó que esta sesión se volviera obsoleta/fantasma:

• Navegue hasta Operaciones > Informes > Terminales y Usuarios > Informe de Radius Accounting y ejecute este informe durante 7 días. Utilice un ID de terminal como clave de filtro.

Aquí hay un ejemplo de un informe que muestra cómo la sesión obsoleta ha quedado en ciscolive-ise2:

1. El inicio de contabilidad de la sesión llegó a PSN ciscolive-ise2.
2. La actualización provisional de la sesión se procesó en el mismo PSN.
3. Un mensaje de detención de contabilización para el ID de sesión problemática llegó a un PSN diferente (ciscolive-ise1).

Una manera rápida de identificar cuándo el problema fue causado por la ausencia de reinicio de detección

En este caso, se aplica la misma lógica que para el número anterior. La única diferencia es que debe centrarse en la última hora de inicio del análisis. Para este tipo de problema, la marca de tiempo del último escaneo está en algún lugar del pasado.

Normalmente, cuando el usuario final descubre un problema, se ve un análisis que ocurrió hace algún tiempo. Mientras se encuentran en los registros de ISE Radius Live, se observan intentos de autenticación recientes desde el terminal problemático.

La demostración muestra la grabación de los pasos necesarios para la identificación del problema:

Solución de problemas avanzada: ausencia de reinicio de detección

El enfoque aquí es muy similar a la sección Solución de Problemas Avanzados de Sesión Fantasma/Anticuada. El principal elemento de solución de problemas es la investigación del paquete DART.

Dentro del paquete DART, puede buscar reinicios de detección (como se muestra para el problema anterior) y confirmar que no hubo reinicio de detección en el momento en que se notificó el problema.

En el lado de ISE, céntrese en el informe de autenticación Radius Live Logs/ Radius para confirmar que hubo failover entre PSN o que NAD generó un nuevo ID de sesión.

Solución

Enfoque clásico: evitar problemas

Tradicionalmente, ISE no contaba con ninguna función que pudiera solucionar los problemas descritos en este documento, por lo que la única forma era confiar en el conjunto de prácticas recomendadas que se implementan en la red y en ISE para minimizar los riesgos.

Prácticas recomendadas que pueden minimizar la cantidad de sesiones antiguas o fantasma en la implementación de ISE

Implemente siempre la postura basada en la redirección cuando sea posible

Un contraargumento común a esta recomendación es una mala experiencia del usuario; se ven ventanas emergentes en el SO o los navegadores. Esto indica redirección mientras el módulo de estado de AnyConnect ISE realiza en segundo plano un proceso de evaluación.

Como solución a esto, es posible redirigir SOLO las sondas de detección del módulo de postura ISE y permitir selectivamente el resto del tráfico.

Este ejemplo muestra la ACL de redirección diseñada para redirigir solamente las solicitudes HTTP al Host de detección (10.1.1.1 en este ejemplo) y 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 mantener un nivel de seguridad aceptable, dicha ACL de redirección se puede combinar con la DACL asignada desde ISE.

El estado pendiente permite conexiones sólo a PSN donde se autenticó el extremo

Este enfoque es útil para los entornos en los que no se admite la redirección de url (por ejemplo, implementaciones con NAD de terceros).

Como solución, implemente varias políticas de autorización PosturePending (una por PSN). Cada política debe contener como una de las condiciones el nombre de PSN donde tuvo lugar la autenticación.

En el perfil de autorización asignado a cada política, el acceso a todos los PSN debe estar bloqueado, excepto el nodo en el que se ha producido la autenticación.

Cree políticas de autorización para la implementación de 2 nodos:

 

1. Política de estado pendiente para PSN1

2. El nombre PSN1 se utiliza como condición en la política.

3. Perfil de autorización con ACL que bloquea el acceso a todos los PSN excepto PSN1.

4. Política de estado pendiente para PSN2.

5. El nombre PSN2 se utiliza como condición en la política.

6. Perfil de autorización con ACL que bloquea el acceso a todos los PSN excepto PSN2.

7. Política de autorización de condición 'Conforme'.

La figura explica cómo funciona este enfoque:

1. La autenticación llega a PSN1.

2. Como resultado de las políticas de autorización configuradas, PSN1 asigna un perfil de autorización que bloquea el acceso a todos los demás nodos excepto PSN1.

3. El módulo de estado de AnyConnect ISE reinicia el proceso de detección.

4. La sonda a PSN2 está bloqueada por el NAD como por una ACL asignada anteriormente.

5. La ACL asignada en NAD permite la sonda a PSN1.

Prácticas recomendadas del equilibrador de carga

• Habilite la adherencia en el balanceador de carga para la autenticación y la contabilización con el ID de la estación de llamada como clave de adherencia. Puede encontrar más información sobre las prácticas recomendadas de LB para ISE aquí.
• Utilice un temporizador de conservación más largo que un día de trabajo promedio para cubrir el momento en que el PC entra en suspensión (por ejemplo, 10 horas en lugar de 8 horas).
• En caso de que se implemente la reautenticación, utilice un temporizador de reautenticación ligeramente inferior al temporizador de conservación (por ejemplo, 8 horas si la conservación está configurada para 10 horas). Esto garantiza que el intervalo de permanencia se prolongue mediante la reautenticación.

Caso práctico de postura sobre VPN 

• Asegúrese de que el intervalo de actualización de cuentas provisionales sea mayor o igual a vpn-session-timeout. Esto minimiza las oscilaciones de cuentas entre PSNs durante sesiones VPN largas. 

Este ejemplo muestra el intervalo de actualización de cuentas provisionales configurado para 20 horas. Esto no impide la actualización provisional inicial que lleva la dirección IP asignada al terminal.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

Se pueden implementar las mejores prácticas para minimizar el impacto de la ausencia del reinicio del módulo de estado de ISE

Habilitar concesión de estado 

Se trata de una función de ISE que marca los terminales como conformes durante un período definido (de 1 a 365 días). El valor de arrendamiento de condición es un atributo de terminal que significa que se almacena en la base de datos de ISE.

Todos los atributos de terminal que incluyen concesión de estado se replican en todos los nodos de la implementación de ISE.

Cuando PSN obtenga una nueva sesión para el estado del terminal, se puede utilizar para marcar la sesión como conforme de inmediato.

Para tomar esta decisión, PSN utiliza 3 valores. Estos valores son:

1. Cantidad de días definidos para arrendamiento de estado en la configuración de ISE: Vaya a Administración > Sistema > Estado > Configuración general:

2. El valor del atributo PostureExpiry es un atributo de extremo real que contiene una marca de tiempo Epoch. El valor de PostureExpiry se cumplimenta inicialmente en el primer intento de estado correcto para el terminal después de que el administrador de ISE haya activado el arrendamiento de estado.

Más adelante, este valor se actualizará en el siguiente intento de estado correcto que tenga lugar después de la expiración del arrendamiento.

            Puede ver un PostureExpiry en Context Visibility > Endpoints mientras se abre uno de los terminales posicionados:

           Este valor se puede convertir en la marca de tiempo legible por el usuario, por ejemplo, aquí: https://www.epochconverter.com/

3. Tiempo del sistema PSN en el momento en que se produce la nueva autenticación

Cuando la autenticación de un terminal con concesión de estado llega a PSN, utiliza PostureExpiry y la fecha del sistema para obtener el número de días transcurridos desde la última comprobación de estado correcta.

Si el valor del resultado se encuentra dentro de un intervalo de concesión de estado definido en la configuración, la sesión obtiene el estado Conforme.

Si el valor del resultado es superior al valor del arrendamiento, la sesión obtiene el estado Desconocido.

Esto desencadena la postura que se va a ejecutar de nuevo y el nuevo valor PostureExpiry se puede guardar.

Este diagrama representa el proceso cuando ocurre la conmutación por fallas:

1. La autenticación inicial se realiza con PSN1.

2. La sesión ABC se crea en la caché de la sesión.

3. La evaluación de la postura ocurre.

4. El estado de la sesión cambia a Conforme

5. El COA se activa por un cambio de estado y conduce a la reautenticación del terminal para aplicar el siguiente nivel de acceso.

6. El valor PostureExpiry se guarda en el punto final.

7. Los datos de los terminales se replican en toda la implementación.

8. La siguiente autenticación llega a PSN2.

9. PSN2 comprueba si el terminal se encuentra dentro de un arrendamiento de estado válido.

11. La sesión se agrega a la caché de sesión como Conforme.

12. Debido a la concesión válida, la sesión se crea con el estado Conforme al estado.

Implementación de reautenticación 

Siempre presione el temporizador de reautenticación desde ISE con RADIUS-Request, seleccionado en Mantener conectividad durante la reautenticación. Esta configuración garantiza que NAD mantenga el mismo ID de sesión en la reautenticación.

.

Entornos Con Equilibradores De Carga

Se puede implementar el mismo conjunto de prácticas recomendadas (explicadas en la sección de sesiones antiguas/fantasma).

Se pueden utilizar diferentes subredes para los estados pendientes y conformes

Cuando el diseño de la red ofrece la oportunidad de utilizar diferentes subredes con los estados Pendiente y Conforme, este enfoque garantiza que cada cambio en el estado de la postura se traduzca en el cambio de Gateway predeterminado.

Evaluación de estado utilizada en el mismo intervalo que un temporizador de reautenticación

La evaluación de estado se puede habilitar con un intervalo igual al temporizador de reautenticación. En tal caso, cuando el PSN original deja de estar disponible, la falla PRA reinicia el proceso de detección.

Enfoque moderno: estado de la postura compartida

Como parte de una mejora implementada (descrita en el ID de error de Cisco CSCvi35647 ), el parche 6 para ISE 2.6 cuenta con una nueva función que permite compartir el estado de la sesión en todos los nodos de la implementación de ISE.

Esta mejora se integrará en futuras versiones: ISE 2.7 parches 2 e ISE 3.0.

Esta nueva función se basa en el mecanismo Light Session Directory (LSD) que se ha introducido en ISE 2.6. En las versiones más recientes, esta funcionalidad se ha renombrado a Light Data Distribution (LDD) Radius Session Directory.  Light Data Distribution está habilitado de forma predeterminada y permite compartir un contexto de sesión limitado entre nodos ISE. No existe la replicación de contexto de sesión completa entre PSN, solo una cantidad limitada de atributos compartidos para cada sesión.

Light Session Directory elimina la necesidad de ejecutar llamadas API costosas de recursos a MNT cuando uno de los nodos de la implementación tiene que determinar el propietario de la sesión actual.

Principalmente, la búsqueda del propietario es necesaria cuando comienza el flujo de COA. Con LDD, cada PSN puede encontrar un propietario real de la sesión desde la memoria caché local del directorio de sesiones Radius. 

Arquitectura de distribución de datos ligeros

Esta funcionalidad contiene estos elementos:

• Caché de Radius Session Directory (RSD)

Esta caché existe en cada nodo de ISE y almacena todas las sesiones activas presentadas en la implementación de ISE. Cada sesión tiene una cantidad limitada de atributos en la memoria caché. 

A continuación se muestran ejemplos de los atributos almacenados en el directorio de sesión de Radius para cada sesión:

• ID de Sesión
• MAC de terminal
• CallingStationID
• IP de terminal
• PSN IP: PSN donde se ha producido la autenticación
• FQDN de PSN 
• NAS-IP-Address
• Dirección-IPv6-NAS
• Estado: autenticado, iniciado, detenido

• intercambio RabbitMQ

Se forma un intercambio en el que Publisher, la cola relacionada y los consumidores se presentan en cada nodo de la implementación de ISE. Esto garantiza que la topología de malla completa se forme entre todos los nodos ISE.

• Editor

Radius Session Directory representa un editor aquí. Cuando un PSN procesa una nueva autenticación correcta, se crea una nueva sesión en la caché de sesión de PSN.

Para esta sesión, se coloca un conjunto limitado de atributos en el directorio de sesión de Radius.

• Consumidor: en todos los demás nodos; Radius Session Directory representa un consumidor.

La figura explica cómo funciona el flujo COA con la memoria caché RSD:

1. La autenticación inicial se realiza con PSN1.

2. La sesión ABC se crea en la caché de la sesión.

3. Los atributos necesarios se guardan en RSD.

4. La sesión se comparte a través de RabbitMQ con todos los demás nodos ISE.

5. La sesión se crea en la caché de RSD en todos los nodos ISE.

6. Llegan nuevos datos del perfil en PSN2.

7. El terminal se vuelve a perfilar y (en caso de un cambio que requiera la ejecución de COA PSN2) continúa con el siguiente paso.

8. Se envía una llamada API interna a la caché de RSD para ejecutar el COA.

9. Los datos de la memoria caché de RSD se utilizan para preparar un mensaje COA de proxy. Va de un nodo ISE a otro y contiene todos los detalles que el nodo de destino puede utilizar para enviar una solicitud CAO de vuelta a NAD. El mensaje COA se transfiere primero internamente a PRRT Runtime (servidor AAA real dentro de ISE).

10. PSN2 envía un mensaje COA a PSN1.

11. PSN1 envía un mensaje COA a NAD.

Para resolver problemas de comunicación sobre LDD en ISE, habilite el componente Light Session Director en DEBUG:

A continuación se muestra un ejemplo de un mensaje de depuración del archivo lsd.log para la creación y publicación de sesiones en el 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

En todos los demás nodos ISE, verá cómo se consume una sesión:

[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]

Uso compartido del estado de postura sobre RSD

El uso compartido del estado de postura resuelve los problemas cuando la causa raíz es una sesión Phantom/antigua o una reautenticación en diferentes PSN que no activó el reinicio de detección.

Tan pronto como la sesión se convierte en compatible, esta información se coloca en el RSD de la sesión y, posteriormente, cada PSN de la implementación puede utilizarla.

Todavía hay algunos otros casos de esquina que la función descrita no puede resolver. Por ejemplo, un escenario en el que NAD ejecuta la reautenticación en el mismo PSN pero con un ID de sesión diferente.

Estos escenarios pueden manejarse con las prácticas recomendadas descritas en este documento.

Esta figura muestra la topología utilizada para una prueba de estado compartido:

Uso compartido del estado de la posición sobre RSD: sesión fantasma/obsoleta

Para crear una sesión obsoleta, la autenticación se debe realizar inicialmente en el skuchere-ise26-1. Luego, NAD debe ser reconfigurado para enviar la contabilización a skuchere-ise26-3.

Después de reenviar un mensaje de contabilización al PSN incorrecto, NAD debe ser reconfigurado (otra vez) para enviar la contabilización de vuelta a skuchere-ise26-1.

La figura muestra un informe contable que prueba la presencia de la sesión fantasma en skuchere-ise26-3:

1. Mensajes de inicio de contabilidad procesados por skuchere-ise26-1.

2. Contabilidad provisional-Actualización para la misma sesión procesada por skuchere-ise26-3.

3. La sesión termina más tarde en skuchere-ise26-1.

Después de un tiempo, el terminal se conecta de nuevo a la red, pero la redirección ya no funciona. En el guest.log de PSN - skuchere-ise26-3, puede ver estos mensajes de registro con el componente client-webapp habilitado en 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

Cuando PSN detecta que mantiene una sesión obsoleta/fantasma para el terminal, no responde al módulo de estado de ISE, lo que nos permite obtener la respuesta correcta de PSN donde se realizó la autenticación más reciente.

Como solución al problema de la sesión obsoleta/fantasma en el momento de la búsqueda de la sesión, PSN verifica la presencia de cualquier sesión nueva para el terminal en el RSD.

En caso de que RSD contenga un ID de sesión diferente del que PSN tiene en la memoria caché de sesión local, se supone que la sesión (presentada en la memoria caché de sesión) está obsoleta.

Uso compartido del estado de postura sobre RSD: conmutación por error entre PSN

Para reproducir este escenario, se habilita un temporizador corto de reautenticación en el perfil de autorización asignado al extremo de estado compatible.

Posteriormente, NAD se reconfigura para enviar la autenticación y la contabilidad a otro PSN (skuchere-ise26-3).

Al expirar el temporizador de reautenticación, la misma sesión no se autentica en el PSN diferente.

La figura muestra un informe de autenticación que muestra failover para la misma sesión desde skuchere-ise26-1 a skuchere-ise26-3:

1. La autenticación ocurre en skuchere-ise26-1, se asigna el perfil de autorización con redirección.

2. COA después de una evaluación de postura exitosa.

3. Próxima autenticación cuando se asigna el perfil de autorización para el estado de conformidad.

4. La autenticación llega a diferentes PSN pero aún así obtiene el perfil de autorización para el estado de conformidad.

La sesión tiene el estado de conformidad en el nuevo PSN después de la conmutación por error en ise-psc.log con los componentes epm-pip y nsf-session habilitados en 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

El problema original se resuelve con la adición de lógica adicional en el proceso de selección de estado de postura.

En esta figura se muestra lo que se ha cambiado (los cambios aparecen resaltados en rojo):