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

Opciones de descarga

  • PDF     (2.1 MB)
    Visualice con Adobe Reader en una variedad de dispositivos
Actualizado:25 de agosto de 2026
ID del documento:215419

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Vista previa
Introducción
Antecedentes
Problema
Experiencia del usuario final
Experiencia de administración de ISE
Escenarios problemáticos comunes
Problema de sesión fantasma/obsoleto
Lógica de ISE Session Management
MNT y gestión de sesiones
PSN y gestión de sesiones
Sesión obsoleta en PSN
Sesión fantasma en PSN
Cómo rompen el proceso de postura una sesión obsoleta y una sesión fantasma
El proceso de detección no se inicia en un nuevo intento de autenticación
Reautenticación en diferentes PSN
NAD genera un nuevo ID de sesión al volver a autenticar
Maneras rápidas de identificar cuándo la sesión fantasma/obsoleta causó un problema
Resolución de problemas avanzada de sesión obsoleta/fantasma
Colección de paquetes DART
Análisis del paquete DART
Investigación sobre registros de ISE
Investigación sobre los informes de ISE
Cómo identificar cuándo un problema fue causado por la ausencia de un reinicio de detección
Solución de problemas avanzada: ausencia de reinicio de detección
Solución
Enfoque clásico: evitar problemas
Prácticas recomendadas que pueden minimizar la cantidad de sesiones antiguas o fantasma en la implementación de ISE
Caso práctico de postura sobre VPN
Se pueden implementar las mejores prácticas para minimizar el impacto de la ausencia del reinicio del módulo de estado de ISE
Implementación de reautenticación
Entornos Con Equilibradores De Carga
Enfoque moderno: estado de la postura compartida
Arquitectura de distribución de datos ligeros
Uso compartido del estado de postura sobre RSD
Uso compartido de estado de postura sobre RSD: sesión fantasma/obsoleta
Uso compartido del estado de postura sobre RSD: conmutación por error entre PSN

Introducción

Este documento describe el problema común de los servicios de estado de Identity Service Engine (ISE), como "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 como este consume mucho tiempo, lo que causa un impacto grave.

Este documento explica:

  • Escenarios problemáticos comunes.
  • 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.
  • Manifestación del problema desde la perspectiva del usuario final y de la administración de ISE.
  • La teoría que subyace a ISE, AnyConnect y las operaciones de red que genera el problema.

Para obtener una mejor explicación de los conceptos descritos más adelante, consulte Comparación del estilo de postura de ISE para Pre y Post 2.2

Problema

Experiencia del usuario final

Este problema normalmente se manifiesta en la 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:

Client Provisioning Portal

Experiencia de administración de ISE

Al intentar este problema por primera vez, un administrador de ISE comienza una investigación de los registros de Radius Live para asegurarse de que la autenticación llegue a ISE. El primer síntoma detectado en esta etapa indica una discordancia en el estado de una postura entre el terminal e ISE en los registros activos. O bien, los informes de autenticación Radius muestran que la última autenticación correcta para el terminal muestra el estado Pendiente.

Experiencia típica de administrador de ISE:

Client Provisioning Portal 2

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

Nota: En el ejemplo, 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, el TAC normalmente funciona con una sesión obsoleta o fantasma en la memoria caché de la sesión 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 adecuadamente el problema e identificarlo, es fundamental entender la teoría de la administración de sesiones en ambas personas.

MNT y gestión de sesiones

Client Provisioning Portal 3

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 tres 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 verificar el estado de la sesión y limpiarlo.

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 las sesiones en el estado 'Iniciado' durante más de 5 días (120 horas). Un estado iniciado significa que el nodo MNT procesó la autenticación y la contabilidad para iniciar la sesión de Syslog.

note-icon

Nota: Estos son los temporizadores normales de limpieza MnT, no se garantiza el tiempo de eliminación del reloj de pared. La retirada puede retrasarse si:

  • SessionPurgeJob no se está ejecutando correctamente.
  • MnT se encuentra bajo presión de recursos o bases de datos.
  • La parada de contabilidad no se puede correlacionar con la sesión existente.

Ejemplos de mensajes Syslog de PSN:

Los mensajes se registran en el archivo port-server.log cuando el componente runtime-aaa está habilitado 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. ISE no dispone de ningún mecanismo que pueda replicar los estados de sesión COMPLETOS de un nodo a otro.

Para cada ID de sesión activa, PSN almacena todos los atributos recopilados 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).

Client Provisioning Portal 4

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 tiene una actualización provisional de cuentas para la sesión que no existe en la caché de la sesión. Con 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 el lí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 el PSN que no realizó la autenticación real:

Ejemplo de la sesión obsoleta:

Client Provisioning Portal 5

  1. La autenticación correcta se realiza en PSN para la sesión ABC.
  2. PSN crea una entrada en la caché de la sesión.
  3. Se realiza una evaluación de postura.
  4. La sesión se marca como Conforme.
  5. El cambio de autorización (COA) se activa cuando cambia el estado, lo que provoca la reautenticación del terminal para aplicar el siguiente nivel de acceso.
  6. La contabilidad se detiene para la sesión ABC en PSN2.

Posteriormente, ABC se bloquea en un estado obsoleto en PSN1, ya que no hay ningún mensaje de detención de contabilidad procesado en este PSN para eliminarlo. La sesión se elimina si la implementación no experimenta un número elevado de intentos de autenticación.

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

  • La detención de contabilización se envió al 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.
  • Los problemas de conectividad temporal en la trayectoria de red causaron la conmutación por error de NAD al siguiente PSN.

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

Client Provisioning Portal 6

  1. La autenticación inicial para la sesión ABC la realiza PSN1. Esta autenticación inicia un temporizador de conservación en el equilibrador de carga.
  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. La entrada para la sesión ABC se crea en el directorio de sesión MNT con el estado Authenticated.
  5. El mensaje de inicio de contabilidad para la sesión ABC aterriza en PSN1.
  6. La 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 sesión se actualiza a Iniciado.
  9. El temporizador de conservación caduca en el equilibrador de carga.
  10. El equilibrador de carga reenvía la detención de contabilidad para la sesión ABC a PSN2.
  11. PSN2 reenvía el mensaje de Syslog para Accounting-Stop a MNT.
  12. 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 a PSN y no realizó la autenticación para esa sesión. 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:

Client Provisioning Portal 7

  1. Los mismos pasos descritos en el ejemplo de sesión obsoleta se producen en PSN1 para la sesión ABC.
  2. La sesión ABC tiene el estado Conforme en la memoria caché de sesión de PSN1.
  3. Una actualización intermedia de contabilidad para la sesión ABC llega a PSN2.
  4. Se crea un registro de sesión para ABC en PSN2. Dado que el registro 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 y tampoco están disponibles los grupos de usuarios ni 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.
  • Comportamiento incorrecto o configuración incorrecta en el equilibrador de carga.

La siguiente captura de pantalla es un ejemplo de una sesión fantasma en la que se produjeron problemas temporales en la ruta de red hacia PSN1:

Client Provisioning Portal 8

  1. PSN realiza la autenticación inicial para la sesión ABC.
  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 de contabilidad para 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 para la sesión ABC se elimina de la caché de sesiones en PSN1.
  13. PSN1 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:

Client Provisioning Portal 9

  1. Autenticación inicial en PSN1.
  2. La sesión ABC se crea en la caché de sesiones.
  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 la información de la dirección IP aterriza en PSN.
  6. La información de la dirección IP se agrega a la caché de la sesión.
  7. La evaluación de la postura se realiza con PSN1.
  8. El estado del estado se actualiza en la sesión.
  9. ISE ejecuta una pulsación COA; esto activa un nuevo nivel de acceso que se asignará.
  10. Hay una interrupción en la ruta de red, lo que hace que PSN1 sea inaccesible.
  11. Después de la expiración de un intervalo de actualización provisional, ASA/FTD detecta que PSN1 es inaccesible.
  12. La actualización de la contabilidad provisional llega 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), se reenvían todos los mensajes de cuentas posteriores (15,16) 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 las sesiones antiguas y fantasma rompen el estado, puede revisar el proceso de detección del módulo de estado de AnyConnect ISE:

Client Provisioning Portal 10

Descubrimiento de la etapa 1:

Durante esta etapa, el módulo de estado de ISE ejecuta cuatro sondas simultáneas para localizar el PSN que autentica el terminal.

En primer lugar, tres sondeos de la figura se basan en la redirección (IP de 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 cuatro 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 si el cliente migra entre PSN.

En los 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, los resultados de la sonda cuatro se utilizan solo si los otros tres sondeos fallan o si el módulo de postura de ISE no puede establecer una comunicación adecuada con el PSN devuelto en la URL de redirección en 5 segundos.

Cuando la sonda cuatro 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 recibe varias respuestas para la sonda cuatro (ConnectionData.xml puede contener más de una 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 de MNT (sólo basada en direcciones MAC) para buscar un propietario de sesión y devolver el nombre del propietario al agente.

Como todos los sondeos activan la búsqueda de sesiones, la detección de la Etapa 2 puede verse afectada de forma significativa por problemas derivados de sesiones obsoletas o fantasma.

Si PSN pasa a la etapa 2, la sonda de detección que existe en la 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.

Este ejemplo muestra cómo aparece la postura cuando PSN mantiene una sesión obsoleta o una sesión fantasma:

Client Provisioning Portal 11

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 estado de 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íticas de aprovisionamiento de clientes. Si una sesión fantasma carece de atributos de autenticación/autorización y todas las políticas configuradas por usted son 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 correcta. Esto puede manifestarse en el mensaje de error: "Omitiendo el análisis de AnyConnect, su red no está configurada para utilizar Cisco NAC Agent".
    • 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 una configuración de AnyConnect), PSN responde con los detalles necesarios para continuar el proceso de evaluación.
    • En este paso, cuando se trabaja con sesiones obsoletas, PSN responde inmediatamente con el estado Conforme y no se completan 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. La sesión fantasma carece de atributos en este momento y no hay ninguna política que coincida. En este caso, PSN responde al terminal que cumple con la normativa. Este es el comportamiento predeterminado de ISE si la política de estado no coincide. 

Nota: Cuando hay una política genérica que se puede seleccionar de atributos de sesión fantasma, puede continuar 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 un estado Conforme.

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

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

Nota: Si la sesión fantasma provoca problemas de estado, el administrador de ISE puede detectar algunos COA de estado fallidos. Si es así, 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 CSCvo6957. El módulo de estado de ISE no detecta la nueva autenticación dot1x, el desbloqueo del 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 un PSN diferente (ya sea debido a decisiones de un LB o a problemas con el PSN original).
  • NAD genera un nuevo identificador de sesión al volver a autenticar.

Reautenticación en diferentes PSN

Este diagrama representa un ejemplo de reautenticación en un PSN diferente causada por la interrupción del PSN original. Un escenario con un equilibrador de carga tiene un aspecto 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.

Client Provisioning Portal 11

  1. Autenticación inicial en PSN1.
  2. La sesión ABC se crea en la caché de sesiones de PSN1.
  3. La evaluación de la postura se realiza con PSN1.
  4. El estado de postura ABC de la sesión pasa a Conforme.
  5. El COA se activa por el cambio de estado de la condición 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. Como se trata de una nueva sesión para PSN2, el estado de la sesión cambia a Pendiente.

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

Client Provisioning Portal 12

Nota: Estado-máquina describe solo una selección inicial del estado de postura. Cada sesión se marca inicialmente como Desconocida y posteriormente 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 puede 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).
  • Mala conducta del lado NAD; normalmente NAD mantiene el mismo ID de sesión durante el intento de reautenticación. Este es un comportamiento potencialmente irregular que debe investigarse en NAD.
    • El nuevo ID de sesión se puede generar en otros escenarios. Por ejemplo, en algunos casos, la itinerancia inalámbrica puede ser la causa.
    • 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.

Maneras rápidas de identificar cuándo la sesión fantasma/obsoleta causó un problema

Para identificar si AnyConnect muestra conformidad mientras se encuentra en el estado de redirección debido a una sesión obsoleta/fantasma. Debe obtener acceso al punto final mientras se encuentra en el estado problemático.

Investigar detalles del análisis del sistema

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

Client Provisioning Portal 13

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

Client Provisioning Portal 14

A continuación, preste atención a dos elementos importantes:

  • Hora de inicio del último análisis: La marca de tiempo debe ser cercana a la hora en que se descubrió el problema.
  • Servidor de políticas: Este campo indica el nombre del servidor de políticas que realiza una evaluación de estado para el terminal. El FQDN se debe comparar con el FQDN de la URL de redirección (para el estado de la base de redirección) o con el nombre PSN tomado del último intento de autenticación (para el estado sin redirección).
  1. Compare el FQDN del servidor de políticas de Estadísticas de análisis del sistema con el nombre del nodo que realizó la autenticación para el terminal:

Client Provisioning Portal 15

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 diferencia el problema de una sesión obsoleta o fantasma del problema del proceso de detección que no se inició. Al mismo tiempo, debe identificar la sesión real que desencadenó el problema para comprender cómo se convierte en un problema de sesión obsoleto o fantasma. Aunque en algunos escenarios no se pueden evitar las sesiones fantasma y obsoletas, debe asegurarse de que se implementan las prácticas recomendadas para evitar que se creen sesiones fantasma o obsoletas en un entorno.

Colección de paquetes DART

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

  1. Solo mantenga registros importantes en DART y se recomienda borrar los registros antes de que se reproduzca el problema.
  2. Para conseguirlo, la utilidad del paquete DART debe iniciarse como administrador y realizar la limpieza de registros.
  3. En Windows, desplácese hasta Inicio y comience a escribir DART > haga clic con el botón secundario y seleccione - Ejecutar como administrador.


Client Provisioning Portal 16

4. En la primera pantalla del asistente, haga clic en Next.

Client Provisioning Portal 17

5. En la siguiente pantalla del asistente, haga clic en Clear All Logs.

Client Provisioning Portal 18

6. Después de que el problema se reproduzca, DART se puede recopilar desde aquí; haga clic en Next.

Análisis del paquete DART

Una vez recopilado el paquete DART, desconfírmelo 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.

Client Provisioning Portal 19

1. Inicie la resolución de problemas e identifique todos los momentos de reinicio de detección. Las palabras clave de búsqueda son Reinicio de Detección o Detección HTTP. Navegue hasta la línea con reinicio de detección que ocurrió en el momento problemático:

CLI Output

2. Varias líneas después del reinicio de detección, hay una línea que contiene, Probing no MNT stage targets (esto es un indicador del inicio de detección de la Etapa 1):

CLI Output 2

3. 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 similares y puede ser difícil detectar la diferencia.

4. Lea los archivos log para ver los resultados de cada sondeo (este es un ejemplo de cómo se ve un sondeo fallido):

CLI Output 3

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

CLI Output 4

5. Varias líneas después, hay una línea con la palabra clave MSG_NS_SWISS_NEW_SESSION. Esta línea contiene un identificador 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 la sesión se ha quedado obsoleta o fantasma:

CLI Output 5

Investigación sobre registros de ISE

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

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

3. La solicitud contiene matrices de direcciones IP y direcciones MAC. En este ejemplo, cada matriz sólo contiene un valor. El registro muestra que el identificador de sesión de la solicitud es nulo, lo que indica que se trata de una solicitud de la sonda no basada en redirección. Más adelante, podrá ver cómo se utilizan los valores de las matrices para localizar un identificador 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

4. Después de la línea con las palabras clave Enviado http respuesta, puede ver el contenido de la respuesta:

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

Una vez que se conoce el ID de la sesión obsoleta/fantasma, puede investigar el informe de Contabilidad Radius para comprender mejor qué causó que la sesión se volviera obsoleta/fantasma:

  1. 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.

2. Este es un ejemplo de un informe que muestra cómo quedó la sesión obsoleta en ciscolive-ise2:

CLI Output 6

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

Cómo identificar cuándo un problema fue causado por la ausencia de un reinicio de detección

La misma lógica se aplica al problema anterior; sin embargo, 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 el pasado.

Normalmente, cuando un usuario final detecta un problema, se realiza un análisis. 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

Este enfoque es similar a la sección Resolución de problemas avanzada de sesiones antiguas/fantasma. 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 reinicios 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 funciones que resolvieran 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 argumento en contra común para esta recomendación es que una mala experiencia del usuario aparece en el SO o se ven 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, SOLO es posible redirigir las sondas de detección del módulo de posición 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, se puede combinar una ACL de redirección con una 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 URL (implementaciones con NAD de terceros).

Como solución, implemente varias políticas de autorización de estado pendiente (una por PSN). Cada política debe contener como una de las condiciones, el nombre de la PSN donde tuvo lugar la autenticación. En el perfil de autorización, se deben bloquear todos los PSN excepto el nodo en el que se ha producido la autenticación.

Cree directivas de autorización para dos nodos:

Authz Policy

 

  1. Política de estado pendiente para PSN1.
  2. El nombre PSN1 se utiliza como condición en la política.
  3. El perfil de autorización con ACL bloquea el acceso a todos los PSN excepto a PSN1.
  4. La política de estado pendiente para PSN2.
  5. El nombre PSN2 se utiliza como condición en la política.
  6. El perfil de autorización con ACL bloquea el acceso a todos los PSN excepto a PSN2.
  7. Política de autorización de condición 'Conforme'.

La siguiente figura explica cómo funciona el enfoque:

Client Provisioning Portal 20

  1. La autenticación llega a PSN1.
  2. Como resultado de las políticas de autorización configuradas, PSN1 asigna el perfil de autorización, que bloquea el acceso a todos los demás nodos excepto PSN1.
  3. El módulo de estado ISE de AnyConnect 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. Consulte las prácticas recomendadas para ISE con la Guía de implementación de Cisco y F5: Equilibrio de carga de ISE mediante BIG-IP.
  • 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 modo de suspensión (por ejemplo, 10 horas en lugar de 8 horas).
  • Si se implementa la reautenticación, utilice el temporizador de reautenticación ligeramente más bajo que el temporizador de conservación (utilice 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 provisional de cuentas 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 el terminal como conforme durante un período definido (de 1 a 365 días). El valor de arrendamiento de condición es un atributo de terminal, lo que significa que se almacena en la base de datos de ISE. Todos los atributos de terminal que incluyen la concesión de estado se replican en todos los nodos de la implementación de ISE.

Cuando PSN recibe una nueva sesión para el terminal, se puede utilizar la concesión de estado para marcar la sesión como conforme de forma inmediata. Para tomar esta decisión, PSN utiliza 3 valores, que son:

  1. Cantidad de días definidos para arrendamiento de estado en la configuración de ISE: Vaya a Administration > System > Posture > General Settings:

Client Provisioning Portal 21

2. El valor del atributo PostureExpiry es un atributo de terminal que contiene una marca de tiempo de Epoch. El valor de PostureExpiry se rellena inicialmente en el primer intento de estado correcto para el terminal después de que el administrador de ISE haya habilitado la concesión de estado. Más adelante, este valor se actualiza en el siguiente intento de estado correcto que se produce después de la expiración de la concesión. Puede ver un PostureExpiry en Context Visibility > Endpoints mientras se abre uno de los terminales posicionados:

Client Provisioning Portal 22

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

Client Provisioning Portal 23

3. Cuando la autenticación de un terminal con concesión de estado llega a PSN, utiliza PostureExpiry y la fecha del sistema para recuperar 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 recibe el estado Conforme. Si el valor del resultado es superior al valor del arrendamiento, la sesión recibe el estado Unknown. 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:

Client Provisioning Portal 24

  1. La autenticación inicial se produce con PSN1.
  2. La sesión ABC se crea en la caché de sesiones.
  3. Se lleva a cabo la evaluación de postura.
  4. El estado de la sesión cambia a Conforme.
  5. El COA se activa cuando cambia el estado y conduce a la reautenticación del terminal para aplicarlo al siguiente nivel de acceso.
  6. El valor de PostureExpiry se guarda en el extremo.
  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 una concesión de estado válida.
  10. La sesión se agrega a la memoria caché de la sesión como compatible.
  11. Debido a la concesión válida, la sesión se crea con el estado Conforme.

Implementación de reautenticación 

Siempre presione el temporizador de reautenticación desde ISE con la solicitud RADIUS, que se selecciona en Mantener conectividad durante la reautenticación. Esta configuración asegura que NAD mantenga el mismo ID de sesión en la reautenticación.

Client Provisioning Portal 25

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 los diseños de red proporcionan la oportunidad de utilizar diferentes subredes, como los estados Pendiente y Conforme, este enfoque garantiza que cada cambio en el estado de estado 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. Cuando el PSN original no está disponible, el fallo de PRA reinicia el proceso de detección.

Enfoque moderno: estado de la postura compartida

Como parte de una mejora implementada (en Cisco bug ID CSCvi35647) parche 6 para ISE 2.6, hay una nueva función que implementa el uso compartido del estado de la sesión en todos los nodos en la implementación de ISE.

Esta mejora se integra en futuras versiones de ISE 2.7 parches 2 e ISE 3.0.

Esta nueva función se basa en el mecanismo Light Session Directory (LSD), que se introdujo en ISE 2.6. En las versiones más recientes, esta funcionalidad se cambió de nombre 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 hay replicaciones 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 debe determinar el propietario de la sesión actual. Se requiere la búsqueda del propietario cuando se inicia el flujo de COA. Con LDD, cada PSN puede encontrar un propietario 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 directorio de sesión RADIUS (RSD): esta caché existe en todos los nodos 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é. Estos son ejemplos de los atributos almacenados en el directorio de sesión Radius para cada sesión:
    • ID de Sesión
    • MAC de terminal
    • CallingStationID
    • IP de terminal
    • PSN IP: PSN donde se realiza la autenticación
    • FQDN de PSN 
    • NAS-IP-Address
    • Dirección-IPv6-NAS
    • Estado: autenticado, iniciado, detenido
  • RabbitMQ Exchange: se forma un intercambio en el que el editor, la cola relacionada y el consumidor se presentan en todos los nodos de la implementación de ISE. Esto garantiza que se forme una topología de malla completa entre todos los nodos ISE.
  • Editor: el directorio de sesión Radius representa un editor. 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, el directorio de sesión Radius representa un consumidor.
note-icon

Nota: La terminología y la arquitectura generales de RabbitMQ quedan fuera del alcance de este documento.

El siguiente ejemplo explica cómo funciona el flujo COA con la memoria caché RSD:

Client Provisioning Portal 26

  1. La autenticación inicial se produce con PSN1.
  2. La sesión ABC se crea en la caché de sesiones.
  3. Los atributos requeridos se guardan en RSD.
  4. La sesión se comparte a través de RabbitMQ con todos los demás nodos de ISE.
  5. La sesión se crea en la caché de RSD en todos los nodos ISE.
  6. Llegan nuevos datos de perfiles a PSN2.
  7. El terminal se redefine y (en caso de un cambio que requiera la ejecución de COA en PSN2) continúa con el siguiente paso.
  8. Se envía una llamada de 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. Se mueve 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-Directory en DEBUG:

Client Provisioning Portal 27

Este es un ejemplo de un mensaje de depuración del archivo lsd.log para la creación y publicación de una sesión 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 obsoleta/fantasma o una reautenticación en un PSN diferente 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 cada PSN de la implementación puede utilizarla posteriormente.

Hay otros casos de esquina que la función descrita no puede resolver. Por ejemplo, cuando NAD ejecuta la reautenticación en el mismo PSN pero con un ID de sesión diferente. Estos escenarios se pueden manejar con las prácticas recomendadas descritas en este documento. Esta figura muestra la topología utilizada para una prueba de estado compartido:

Network

Uso compartido de estado de postura sobre RSD: sesión fantasma/obsoleta

Para crear una sesión obsoleta, la autenticación se debe realizar inicialmente en skuchere-ise26-1. Luego, NAD se debe reconfigurar para enviar la contabilización a skuchere-ise26-3. Después de reenviar un mensaje de contabilización al PSN incorrecto, NAD se debe reconfigurar (nuevamente) para enviar la contabilización de vuelta a skuchere-ise26-1.

Esta imagen muestra un informe de contabilidad que prueba la presencia de la sesión fantasma en skuchere-ise26-3:

Phantom Session Accounting Report

  1. Mensajes de inicio de contabilidad procesados por skuchere-ise26-1.
  2. Contabilización Provisional-Actualizar para la misma sesión procesada por skuchere-ise26-3.
  3. La sesión termina más tarde en skuchere-ise26-1.

El terminal se conecta a la red, pero la redirección ya no funciona. En el guest.log de PSN para 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 le permite obtener información de PSN donde se produjo la última autenticación.

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. Si RSD contiene un ID de sesión diferente del que PSN tiene en la memoria caché de sesión local, asume 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 de reautenticación corto en el perfil de autorización asignado al extremo de estado compatible. Más tarde, NAD se reconfigura para enviar la autenticación y la contabilización a otro PSN (skuchere-ise26-3.) Tras la expiración del temporizador de reautenticación, la misma sesión no se autentica en el PSN diferente. 

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

Failover Between PSNs

  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. Se asigna la siguiente autenticación para el perfil de autorización al estado de conformidad.
  4. La autenticación llega a un PSN diferente; sin embargo, aún recibe un 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. Esta figura muestra los cambios realizados (los cambios resaltados en rojo):

Process

Historial de revisiones

Revisión Fecha de publicación Comentarios
3.0
25-Aug-2026
Título actualizado, ortografía, gramática, líneas horizontales insertadas para separar secciones para facilitar la lectura, direcciones URL fijas, alertas de CCW y texto alternativo.
2.0
31-May-2023
Recertificación
1.0
22-Apr-2020
Versión inicial
TAC Authored

Con la colaboración de ingenieros de Cisco

  • Serhii Kucherenko

¿Resultó útil este documento?

FeedbackComentarios

Contacte a Cisco

Este documento se aplica a estos productos