Contenido
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, podría haber 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 redirecciones constantes 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 Alice.
- El estado de la sesión es Pendiente.
- Último evento de sesión para Alice.
- El evento de sesión muestra el estado como Conforme.
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 estado del ciclo de detección anterior, ya que 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 y, posiblemente, se producen cuando no se detecta ninguno de estos eventos durante la autenticación o la reautenticación.
Problema de sesión fantasma/obsoleto
Para comprender mejor el problema, investigue la lógica de administración de sesiones de ISE y el proceso de detección de AnyConnect necesario.
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 Syslog puede actualizar el estado de sesión posterior para la contabilidad.
La eliminación de sesiones en MNT ocurre en 3 escenarios:
- Las sesiones sin inicio de cuentas 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.
- La sesión finalizada se eliminó aproximadamente 15 minutos después de que la detención de contabilidad haya sido procesada por el mismo trabajo cron.
- 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. Esos mensajes se registran en prrt-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
¿Qué es la caché de sesión de PSN?
Una base de datos en memoria que almacena todas las sesiones activas de PSN específico. La caché de sesiones siempre es local para el nodo y no hay 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, como grupos de usuarios internos/externos, atributos del dispositivo de acceso a la red (NAD), atributos de certificado, etc. PSN utiliza esos atributos para seleccionar diferentes tipos de políticas como Autenticación, Autorización, Aprovisionamiento del cliente y Estado.
La caché de sesión se elimina por completo cuando se reinician los servicios del nodo o del propio nodo.
La lógica de procesamiento de sesión actual crea una nueva entrada en la memoria 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 eliminó 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 correcta se realiza en PSN para la sesión ABC.
2. PSN crea una entrada en la caché de la sesión.
3. La evaluación de la postura se realiza.
4. Sesión marcada 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 detención de la contabilidad para la sesión ABC llega a PSN2.
Después del paso 6 de la sesión, ABC se bloquea en el estado obsoleto en PSN1, ya que no habría un mensaje de detención de contabilidad 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. Autenticación inicial para la sesión ABC realizada por PSN 1.
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. Entrada para la sesión ABC creada 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. Registro de caché de sesión para la sesión ABC actualizado con información de Inicio Contable.
8. Mensaje de Syslog para Accounting-Start transferido al nodo MNT.
9. Estado de sesión actualizado a Iniciado.
10. El temporizador de conservación caduca en el equilibrador de carga.
11. Contabilización-Parada de la sesión ABC reenviada por el equilibrador de carga a PSN 2.
12. Mensaje de registro del sistema para la parada de contabilidad reenviado por PSN 2 a MNT.
13. Sesión ABC marcada como terminada 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 y si PSN no obtiene un mensaje de detención de contabilización para esta sesión, la entrada no se eliminará 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 memoria caché de sesión de PSN1.
3. La actualización provisional de contabilidad para la sesión ABC llega a PSN2.
4. Entrada de sesión para la sesión ABC creada en PSN2. Desde la entrada de sesión creada 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.
Ejemplo de una sesión fantasma para el escenario con problemas temporales en la ruta de red hacia PSN1:
1. Autenticación inicial para la sesión ABC realizada por PSN.
2. PSN1 crea una entrada para la sesión ABC en la caché local.
3. Mensaje de registro del sistema para la autenticación pasada transferido al nodo MNT.
4. Entrada para la sesión ABC creada en TimesTen DB con el estado Autenticado.
5. El mensaje de inicio contable de la sesión ABC aterriza en PSN 1.
6. Registro de caché de sesión para la sesión ABC actualizado con información de Inicio Contable.
7. Mensaje de Syslog para Accounting-Start transferido al nodo MNT.
8. Estado de sesión actualizado a Iniciado.
9. Actualización de contabilidad intermedia para la sesión ABC reenviada a PSN2.
10. PSN2 crea una entrada para la sesión ABC en la caché local.
11. Contabilización: parada de la sesión ABC reenviada a PSN1.
12. Entrada de la sesión ABC eliminada de la caché de sesión en PSN1.
13. Mensaje de registro del sistema para la parada de contabilidad reenviado por PSN 1 a MNT.
14. Sesión ABC marcada como terminada en MNT.
El escenario de la sesión fantasma se creó para la conexión VPN de larga duración:
1. Autenticación inicial en PSN1.
2. Sesión ABC creada en la caché de sesiones.
3. La contabilidad inicia el mensaje procesado por PSN.
4. La nueva dirección IP asignada al adaptador de red privada virtual (VPN).
5. La actualización de contabilidad provisional con información de dirección IP aterriza en PSN.
6. Información de dirección IP agregada a la caché de sesión.
7. La evaluación de estado se realiza con PSN1.
8. Estado de postura actualizado en la sesión.
9. La inserción de COA ejecutada por ISE activa un nuevo nivel de acceso que se debe asignar.
10. Interrupción en la ruta de red que hace que PSN1 sea inaccesible.
11. Después de la expiración del intervalo de actualización provisional, ASA/FTD detecta que PSN1 es inaccesible.
12. La actualización de la contabilidad provisional llega a PSN2.
13. Sesión fantasma creada en la caché de sesión de PSN2.
Si más tarde se puede acceder a PSN1 (14), todos los mensajes de cuentas posteriores se reenvían allí (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 la sesión antigua y la sesión fantasma rompen la postura, puede revisar el proceso de detección del módulo de postura 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 a la PSN correcta, ya que la URL de redirección se toma de la propia NAD.
El sondeo número 4 se envía a todos los servidores principales que se presentan en el archivo ConnectionData.xml. Este archivo creado después del primer intento de estado correcto y el contenido posterior del archivo se puede actualizar 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 de la sonda 4 se utiliza solo si los otros 3 sondeos fallaron o el módulo de postura ISE no pudo establecer una comunicación adecuada con 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 el terminal, el estado de la postura que se muestra más adelante en el cliente puede ser incorrecto.
Cuando un agente obtiene varias respuestas para la sonda 4 (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 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 encontrar un propietario de sesión y devolver el nombre del 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:
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. En este caso, con 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 (las políticas se crean para grupos específicos de Active Directory, por ejemplo), 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 el caso de que las políticas de aprovisionamiento del cliente sean 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, también, cuando podemos tratar con sesiones obsoletas, PSN responde de inmediato con estado de postura 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 sesión y solicitud para coincidir con 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 cumple con las normas, ya que se trata de un comportamiento predeterminado de ISE en caso de que no coincidan las políticas de estado.
6. PSN devuelve al agente las directivas de estado seleccionadas.
7. El agente devuelve los estados de cada directiva o requisito tal como se ha superado o no se ha superado.
8. La evaluación del informe se realiza en ISE y el estado de la sesión cambia a Conforme.
El proceso de detección no se inicia en un nuevo intento de autenticación
Módulo de estado de ISE diseñado para supervisar una cantidad limitada de eventos en el terminal para activar un proceso de detección. Lista de 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
Ejemplo de reautenticación en diferentes PSN causada por la interrupción del PSN original. La situación con el equilibrador de carga es muy similar. En el caso de LB, reautenticación dirigida a los diferentes PSN como resultado de la expiración del temporizador de conservación.
1. Autenticación inicial en PSN1.
2. Sesión ABC creada en la caché de sesión de PSN1.
3. Evaluación de la postura realizada con PSN1.
4. El estado de la postura ABS de la sesión pasa a Conforme.
5. El COA activado por el cambio de estado del estado lleva 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 pasa a ser Pendiente.
Estado de postura inicial asignado por PSN a la sesión:
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. En caso de que haya descubierto que NAD cambió un ID de sesión al volver a autenticarse, este es 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 debido a la sesión obsoleta/fantasma, necesitamos obtener acceso al terminal mientras está en estado problemático.
- Investigar detalles del análisis del sistema:
1. Pulse el icono de engranaje en la interfaz de usuario de AnyConnect
2. En la nueva ventana, acceda a la pestaña Análisis del sistema y a la subpestaña 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).
- 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:
En el ejemplo dado hay una discordancia entre el nombre que se indica que PSN con el nombre ciscolive-ise2 mantiene una sesión obsoleta o fantasma para este punto final.
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 es 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.
Mientras que en algunos escenarios las sesiones obsoletas y fantasmas no se pueden evitar. Tenemos que asegurarnos de que no se creen sesiones antiguas/fantasma en el entorno debido a algunas de las prácticas recomendadas que no se implementan.
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.
- En Windows, vaya a Inicio y empiece a escribir DART, haga clic con el botón secundario y seleccione - Ejecutar como administrador
- En la primera pantalla del asistente, pulse Siguiente
- En la siguiente pantalla del asistente, pulse Borrar todos los registros
- Una vez reproducido el problema, puede recopilar datos de DART desde aquí; pulse Siguiente.
análisis de paquetes DART
Una vez recopilado el paquete DART, debemos desarchivarlo y centrarnos 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. Un par de líneas después del reinicio de detección, verá una línea que contiene - Sondeo de destinos de etapa MNT. 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, mientras que los PSN previamente conectados tomados de ConnectionData.xml (destinos de estado de autenticación) deben resaltarse en diferentes colores, ya que 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. Como ya se ha dicho en el caso del problema causado por una sesión obsoleta/fantasma, todos los sondeos basados en redireccionamiento deben fallar. 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. Un par de 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 averiguar cómo esta sesión se vuelve obsoleta o fantasma:
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. Puede ver que 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. Además, 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 basada en no 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 contabilidad Radius y ejecute este informe durante 7 días. El usuario tiene un ID de terminal como clave de filtro.
Ejemplo de un informe que muestra cómo se ha dejado una sesión obsoleta en ciscolive-ise2:
- El inicio de la contabilidad de la sesión llegó a PSN CiscoLive-ise2
- La actualización provisional de la sesión se procesó en el mismo PSN.
- El mensaje de detención de la contabilidad para el ID de sesión problemática llegó a PSN diferente (ciscolive-ise1).
Una manera rápida de identificar cuándo el problema fue causado por la ausencia de reinicio de detección
Aquí 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 avanzada de problemas de sesión fantasma/obsoleta. 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 ha mostrado para el problema anterior y confirmar que no hubo reinicio de detección en el momento en que se informó del problema.
En el lado de ISE, céntrese en el informe de autenticación Radius Live Logs/Radius para confirmar que hubo conmutación por error 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 e 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 habitual de esta recomendación es una mala experiencia del usuario, ya que se ven ventanas emergentes en el sistema operativo o los navegadores que indican 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.
El 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, debe implementar 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 ISE de AnyConnect reinicia el proceso de detección.
4. Sondeo de PSN2 bloqueado por el NAD como por una ACL asignada anteriormente.
5. Sondeo de PSN1 permitido por ACL asignado en NAD.
Prácticas recomendadas del equilibrador de carga
- Se habilitó la conservación en el LB para la autenticación y la contabilidad con el ID de la estación de llamada como clave de conservación. 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
- Asegura que el intervalo de actualización contable provisional es mayor o igual a vpn-session-timeout. Esto evita que la contabilidad se inestable entre PSN en sesiones VPN de larga duración.
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, lo que significa que se almacena en ISE DB. 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 obtiene una nueva sesión para el arrendamiento de 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:
- Cantidad de días definidos para arrendamiento de estado en la configuración de ISE: Vaya a Administración > Sistema > Estado > Configuración general:
- Valor del atributo PostureExpiry: se trata de un atributo de extremo real que contiene una marca de tiempo de 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 una 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/
- Hora 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 un 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 mayor que el valor del arrendamiento, la sesión obtiene el estado Desconocido. Esto activa la postura que se va a ejecutar de nuevo y se puede guardar el nuevo valor PostureExpiry.
La figura explica el proceso cuando ocurre la conmutación por fallas:
1. La autenticación inicial se realiza con PSN1.
2. Sesión ABC creada en la caché de sesiones.
3. La evaluación de la postura se realiza.
4. El estado de la sesión cambia a Conforme
5. El COA activado por el cambio de estado del estado lleva a la reautenticación del terminal para aplicar el siguiente nivel de acceso.
6. Valor de PostureExpiry guardado en el extremo.
7. Datos de terminales replicados 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.
11. Sesión agregada a la caché de sesión como Conforme.
12. Debido a la concesión válida, la sesión creada 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 que se explicaron 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 la puerta de enlace predeterminada.
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 no está 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 CSCvi35647parche 6 para ISE 2.6, se obtuvo una nueva función que implementa el uso compartido del estado de 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.
La idea principal detrás de Light Session Directory es eliminar la necesidad de ejecutar llamadas API costosas de recursos a MNT cuando uno de los nodos en la implementación tiene que averiguar quién es el propietario de la sesión actual. La búsqueda de propietarios es necesaria principalmente 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 todos los nodos 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é. Ejemplos de los atributos almacenados en el directorio de sesión Radius para cada sesión:
- ID de Sesión.
- MAC de terminal.
- ID de la estación de llamada.
- IP de terminal.
- PSN IP: PSN donde se ha producido la autenticación.
- FQDN de PSN: igual que el anterior.
- Dirección IP de NAS.
- Dirección-IPv6-NAS.
- Estado: autenticado, iniciado, detenido.
- Intercambio de RabbitMQ: existe un intercambio formado en el que Publisher, la cola relacionada y Consumer 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.
- Publisher: el directorio de sesión Radius representa un editor aquí. Cuando se crea una nueva autenticación correcta procesada por PSN, 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 otros nodos Radius Session Directory representa un consumidor.
Nota: La terminología y la arquitectura generales de RabbitMQ quedan fuera del alcance de este documento.
La figura explica cómo funciona el flujo COA con la memoria caché RSD:
1. La autenticación inicial se realiza con PSN1.
2. Sesión ABC creada en la caché de sesiones.
3. Los atributos requeridos se guardan en RSD.
4. Sesión compartida 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 que se produzca el cambio, que requiere la ejecución del COA, PSN2 continúa con el siguiente paso.
8. Una llamada de API interna enviada a la memoria caché de RSD para ejecutar el COA.
9. Datos de la caché de RSD utilizados para preparar un mensaje COA de proxy (un COA que va de un nodo ISE a otro, contiene todos los detalles que el nodo de destino puede utilizar para emitir una solicitud CAO de vuelta a NAD). El mensaje COA se transfirió 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 el ISE, puede habilitar el componente Light Session Director en DEBUG:
ejemplo de 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 la postura entre los nodos resuelve el problema que tiene el síntoma 'El módulo de estado de AnyConnect ISE muestra conformidad mientras el estado de la sesión en ISE está pendiente' cuando la causa raíz es una sesión obsoleta/fantasma o reautenticación en diferentes PSN con un ID de sesión original que no activó el reinicio de la 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.
La 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 ha realizado inicialmente en el skuchere-ise26-1 y posteriormente NAD se ha reconfigurado para enviar la contabilización al skuchere-ise26-3. Después de reenviar un mensaje de contabilización al PSN incorrecto, NAD se ha reconfigurado nuevamente para enviar la contabilización nuevamente 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 ahora en el momento de la búsqueda de la sesión, PSN verifica la presencia de cualquier nueva sesión para el terminal en el RSD. En caso de que RSD contenga un ID de sesión diferente de lo 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 ha habilitado un temporizador de reautenticación corto en el perfil de autorización asignado al terminal en el estado de conformidad. Posteriormente, NAD se reconfiguró 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 autenticó en el PSN diferente.
La figura muestra un informe de autenticación que muestra el failover para la sesión cuerda de 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 obtiene el estado de conformidad en el nuevo PSN después del failover 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 ha resuelto con la adición de lógica adicional en el proceso de selección del estado de la postura. En la figura se muestra lo que se ha cambiado (los cambios aparecen resaltados en rojo):
