Dépannage de la gestion et de la position des sessions ISE

Introduction

Ce document décrit le problème courant des services de posture ISE (Identity Service Engine) : "Le module de posture ISE AnyConnect affiche conforme..."

Informations générales

Ce document décrit le problème courant des services de posture ISE (Identity Service Engine) - Le module de posture ISE AnyConnect affiche conforme alors que l'état de session sur ISE est en attente.

Bien que les symptômes soient toujours les mêmes, il peut y avoir plusieurs causes profondes à ce problème.

Souvent, le dépannage d'un tel problème prend énormément de temps, ce qui a de graves conséquences.

Ce document explique :

• Manifestation du problème du point de vue des utilisateurs finaux et des administrateurs ISE.
• Scénarios problématiques courants.
• Théorie sous-jacente à ISE, AnyConnect et aux opérations réseau qui déclenchent le problème.
• Algorithmes d’identification rapide des problèmes.
• Solutions classiques aux scénarios problématiques courants.
• Partage d'état de position sur le répertoire de session Radius.

Pour une meilleure explication des concepts décrits plus loin, reportez-vous à :

Problème

Expérience utilisateur final

Ce problème se manifeste normalement en l'absence d'accès réseau ou de redirections constantes vers le portail de mise en service du client ISE dans le navigateur, tandis que, dans le même temps, le module de posture ISE AnyConnect affiche l'état de posture comme Conforme.

Expérience utilisateur type :

Expérience administrateur ISE

Normalement, dans le triage initial de ce problème, l'administrateur ISE effectue une enquête sur les journaux Radius Live pour s'assurer qu'il y a une authentification réelle qui atteint l'ISE.

Le premier symptôme découvert à cette étape indique une non-correspondance dans un état de posture entre le terminal et ISE comme dans les journaux en direct ou les rapports d'authentification Radius la dernière authentification réussie pour le terminal indique l'état de posture en attente.

Expérience d'administration ISE type :

• Dernière authentification réussie pour Alice.
• L'état de la position de la session est En attente.
• Dernier événement de session pour Alice.
• L'événement de session affiche l'état de posture Conforme.

Remarque : c. et d. ne sont pas toujours présentés dans les journaux en direct lorsqu'ils sont décrits dans les manifestes de problèmes. Événement de session avec état de posture Conforme est plus fréquent pour les scénarios provoqués par les sessions obsolètes ou fantômes qui sont décrites plus loin dans ce document.

Scénarios problématiques courants

Ce problème se manifeste normalement dans deux scénarios problématiques et chacun d'entre eux a plusieurs causes profondes. Les scénarios :

• Le module de posture AnyConnect ISE a été mal informé par le noeud de service de stratégie (PSN) pendant le processus de posture, ce qui a entraîné l'affichage d'un état de posture incorrect. Dans ce cas, nous traitons normalement une session obsolète ou fantôme dans le cache de session PSN.
• AnyConnect ISE affiche l'état de posture du cycle de détection précédent, car l'authentification actuelle n'a pas déclenché de processus de détection. Le module de posture ISE d'AnyConnect comporte un nombre limité d'événements qui déclenchent le processus de détection et qui peuvent se produire lors de l'authentification ou de la réauthentification, aucun de ces événements n'ayant été détecté.

Problème de session obsolète/fantôme

Pour mieux comprendre le problème, étudiez la logique de gestion des sessions ISE et le processus de détection AnyConnect requis.

Logique de gestion de session ISE

Dans le déploiement ISE, deux personnes sont responsables du processus de gestion de session : PSN et Monitoring Node (MNT).

Pour dépanner et identifier correctement ce problème, il est essentiel de comprendre la théorie de la gestion des sessions sur les deux personnes.

MNT et gestion de session

Comme expliqué dans cette image, le noeud MNT crée des saisons en fonction des messages Syslog d'authentification passés qui proviennent des PSN.

L'état des sessions ultérieures peut être mis à jour par le Syslog pour la gestion des comptes.

La suppression de session sur MNT se produit dans 3 scénarios :

• Les sessions sans comptabilisation commencent à être supprimées environ 60 minutes après leur création. Une tâche cron est exécutée toutes les 5 minutes pour vérifier l'état de la session et la nettoyer.
• La session terminée a été supprimée environ 15 minutes après que l'arrêt de la comptabilité a été traité par la même tâche cron.
• Le même cron sur chaque exécution supprime aussi bien les sessions qui ont été dans l'état 'Started' pendant plus de 5 jours (120 heures). Un état démarré signifie que le noeud MNT a traité l'authentification et la gestion des comptes pour démarrer Syslog pour la session.

Exemples de messages Syslog de PSN. Ces messages sont consignés dans port-server.log lorsque le composant runtime-aaa est activé dans DEBUG. Les parties en gras peuvent être utilisées pour construire des expressions régulières de recherche.

Authentification réussie :

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

Début de la comptabilisation :

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

Mise à jour comptable provisoire :

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

Arrêt de la comptabilisation :

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 et gestion de session

Qu'est-ce que le cache de session PSN ?

Base de données en mémoire qui stocke toutes les sessions actives d'un PSN spécifique. Le cache de session est toujours local au noeud et aucun mécanisme dans ISE ne peut effectuer la réplication de l'état de session FULL d'un noeud à un autre.

Pour chaque ID de session active, PSN stocke tous les attributs collectés pendant la phase d'authentification/autorisation, tels que les groupes d'utilisateurs internes/externes, les attributs NAD (Network Access Device), les attributs de certificat, etc. Ces attributs sont utilisés par PSN pour sélectionner différents types de stratégie tels que l'authentification, l'autorisation, l'approvisionnement client, la position.

Le cache de session est complètement supprimé lorsque les services sur le noeud ou le noeud lui-même sont redémarrés.

La logique de traitement de session actuelle crée une nouvelle entrée dans le cache de session dans deux scénarios, les détails ultérieurs des sessions existantes peuvent être mis à jour à partir des messages de comptabilité provenant des NAD :

• La session a été authentifiée sur le PSN.
• PSN a reçu une mise à jour intermédiaire de comptabilité pour la session qui n'existe pas dans le cache de session.

En ce qui concerne la suppression de session, PSN met en oeuvre cette logique :

• Entrée du cache de session supprimée immédiatement après le traitement du message d'arrêt de la gestion.
• PSN commence à supprimer les dernières sessions utilisées lorsqu'un noeud atteint la limite des sessions actives.

Session obsolète sur PSN

Dans le déploiement ISE, l'arrêt de la gestion des comptes pour une session existante a été traité par le PSN qui n'a pas effectué l'authentification réelle :

Exemple de session obsolète :

1. Une authentification réussie se produit sur PSN pour la session ABC.

2. PSN crée une entrée dans le cache de session.

3. L'évaluation de la posture se produit.

4. Session marquée comme Conforme.

5. Le changement d’autorisation (COA) déclenché par le changement d’état de la position entraîne une nouvelle authentification du terminal pour appliquer le niveau d’accès suivant.

6. Arrêt comptable pour la session ABC arrive sur PSN2.

Après la session de l'étape 6, ABC est bloqué dans l'état d'obsolescence sur le PSN1 car il n'y aurait pas de message d'arrêt de comptabilité traité sur ce PSN pour le supprimer. La session est supprimée pendant une longue période si le déploiement ne fait pas l'objet d'un nombre élevé de tentatives d'authentification.

La session obsolète apparaît dans le cache de session PSN dans les scénarios suivants :

• L'arrêt de la comptabilisation est arrivé au mauvais PSN en raison de l'expiration du minuteur d'adhésivité sur l'équilibreur de charge.
• La configuration incorrecte sur le NAD n'est pas le même PSN configuré pour l'authentification et la gestion des comptes.
• Problèmes de connectivité temporaires sur le chemin réseau qui entraînent le basculement NAD vers le PSN suivant.

Exemple de session obsolète dans l'environnement d'équilibrage de charge :

1. Authentification initiale pour la session ABC effectuée par PSN 1.

2. Cette authentification initie un compteur d'adhésion sur l'équilibreur de charge.

3. PSN 1 crée une entrée pour la session ABC dans le cache local.

4. Message Syslog pour l'authentification passée transféré au noeud MNT.

5. Entrée de la session ABC créée dans le répertoire de session MNT avec l'état Authenticated.

6. Message de début de compte pour la session ABC atterrit sur PSN 1.

7. Entrée du cache de session pour la session ABC mise à jour avec les informations de Accounting-Start.

8. Message Syslog pour Accounting-Start transféré au noeud MNT.

9. État de la session mis à jour en Démarré.

10. Le temporisateur de rémanence expire sur l'équilibreur de charge.

11. Accounting-Stop pour la session ABC transmise par l'équilibreur de charge à PSN 2.

12. Message Syslog pour Accounting-Stop transmis par PSN 2 à MNT.

13. La session ABC est marquée comme terminée sur MNT.

Session fantôme sur le PSN

La session fantôme est un scénario dans lequel la mise à jour provisoire de la comptabilité arrive sur le PSN qui n'a pas effectué l'authentification pour cette session spécifique. Dans ce scénario, une nouvelle entrée est créée dans le cache de session PSN et si PSN n'obtient pas de message d'arrêt de comptabilisation pour cette session, l'entrée ne sera pas supprimée à moins que PSN n'atteigne la limite des sessions actives.

Exemple de session fantôme :

1. Les mêmes étapes que celles décrites dans l'exemple de session obsolète se produisent sur PSN1 pour la session ABC.

2. Le statut de la session ABC est Conforme dans le cache de session PSN1.

3. La mise à jour provisoire de la comptabilité pour la session ABC touche PSN2.

4. Entrée de session pour la session ABC créée sur PSN2. Depuis que l'entrée de session a été créée à partir du message de comptabilité, le nombre d'attributs est limité. Par exemple, l'état de position n'est pas disponible pour la session ABC. Des éléments tels que les groupes d'utilisateurs et d'autres attributs spécifiques d'autorisation sont également absents.

La session fantôme apparaît dans le cache de session PSN dans les scénarios suivants :

• Interruption à court terme du transit réseau.
• Défaut de fonctionnement du périphérique d'accès réseau.
• Mauvais comportement ou configuration incorrecte sur l'équilibreur de charge.

Exemple de session fantôme pour le scénario avec des problèmes temporaires sur le chemin réseau vers PSN1 :

1. Authentification initiale pour la session ABC effectuée par PSN.

2. PSN1 crée une entrée pour la session ABC dans le cache local.

3. Message Syslog pour l'authentification passée transféré au noeud MNT.

4. Entrée pour la session ABC créée dans la base de données TimesTen avec l'état Authenticated.

5. Message de début de compte pour la session ABC atterrit sur PSN 1.

6. Entrée du cache de session pour la session ABC mise à jour avec les informations de Accounting-Start.

7. Message Syslog pour Accounting-Start transféré au noeud MNT.

8. État de la session mis à jour en Démarré.

9. Mise à jour de la comptabilité provisoire pour la session ABC transmise à PSN2.

10. PSN2 crée une entrée pour la session ABC dans le cache local.

11. Accounting-Stop pour la session ABC transmise à PSN1.

12. L'entrée de la session ABC a été supprimée du cache de session sur PSN1.

13. Message Syslog pour Accounting-Stop transmis par PSN 1 à MNT.

14. La session ABC est marquée comme terminée sur MNT.

Le scénario de la session fantôme a été créé pour la connexion VPN à longue durée de vie :

1. Authentification initiale sur PSN1.

2. Session ABC créée dans le cache de session.

3. Accounting lance le message traité par le PSN.

4. Nouvelle adresse IP attribuée à l'adaptateur de réseau privé virtuel (VPN).

5. Mise à jour comptable provisoire avec informations d'adresse IP sur PSN.

6. Informations d’adresse IP ajoutées au cache de session.

7. L'évaluation de la position se produit avec PSN1.

8. État de la position mis à jour pendant la session.

9. L'émission de certificat d'authenticité exécutée par ISE déclenche l'attribution d'un nouveau niveau d'accès.

10. Panne sur le chemin réseau qui rend PSN1 inaccessible.

11. Après expiration de l'intervalle de mise à jour intermédiaire, ASA/FTD détecte que PSN1 est inaccessible. 

12. Une mise à jour comptable intermédiaire est disponible sur PSN2.

13. Session fantôme créée dans le cache de session PSN2.

Si le PSN1 ultérieur devient accessible (14), tous les messages de comptabilité ultérieurs y sont transférés (15,16), ce qui laisse la session ABC dans le cache de session du PSN2 pendant une durée indéfinie.

Comment une session obsolète et une session fantôme rompent le processus de posture ?

Pour comprendre comment une session obsolète et une session fantôme rompent la position, vous pouvez consulter le processus de détection de module de position ISE AnyConnect :

Étape 1 Découverte :

Au cours de cette étape, le module de posture ISE exécute 4 problèmes simultanés pour localiser le PSN qui a effectué une authentification pour le terminal.

Premièrement, 3 sondes sur la figure sont basées sur la redirection (IP GW par défaut). Discovery host IP (si défini) et enroll.cisco.com IP) - Ces sondes pointent toujours l'agent vers le PSN droit, car l'URL de redirection est tirée du NAD lui-même.

La sonde numéro 4 est envoyée à tous les serveurs principaux présentés dans le fichier ConnectionData.xml. Ce fichier créé après la première tentative de posture réussie et le contenu du fichier ultérieur peut être mis à jour au cas où le client migre entre PSN. Sur les systèmes Windows, l'emplacement du fichier est : C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Puisque toutes les sondes de l'étape 1 sont exécutées simultanément, le résultat de la sonde 4 est utilisé uniquement si toutes les autres sondes 3 ont échoué ou si le module de posture ISE n'a pas pu établir une communication correcte avec PSN renvoyé dans l'URL de redirection dans les 5 secondes.

Lorsque la sonde 4 atterrit sur le PSN, elle contient une liste d'adresses IP et MAC actives découvertes sur le point d'extrémité. PSN utilise ces données pour rechercher une session pour ce point de terminaison dans le cache local. Si PSN a une session obsolète ou fantôme pour le terminal, cela peut entraîner un état de position incorrect affiché plus tard côté client.

Lorsqu'un agent obtient plusieurs réponses pour la sonde 4 (ConnectionData.xml peut contenir plusieurs PSN principaux), la réponse la plus rapide est toujours utilisée.

Étape 2 Découverte :

Toutes les sondes de détection de l'étape 2 sont sans redirection, ce qui signifie que chaque sonde déclenche une recherche de session sur le PSN de destination. Si PSN ne parvient pas à localiser la session dans le cache de session local, il doit effectuer une recherche MNT (basée uniquement sur l'adresse MAC) pour trouver un propriétaire de session et renvoyer le nom du propriétaire à l'agent.

Comme toutes les sondes déclenchent la recherche de session, la détection de l'étape 2 peut être encore plus affectée par les problèmes résultant de sessions obsolètes ou fantômes.

Si PSN passe à l'étape 2, la sonde de détection qui existe dans le cache de session crée une entrée obsolète ou fantôme pour le même terminal. Il en résulte un état de posture incorrect renvoyé à l'utilisateur final.

L'exemple montre comment la posture se produit lorsque PSN conserve une session obsolète ou une session fantôme :

Remarque : il est important de se rappeler que ce problème ne peut se manifester que lorsque toutes les sondes de détection basées sur la redirection échouent ou lorsque la position de non-redirection est implémentée.

1. L'une des sondes Find my session émises par le module de posture ISE.

2. PSN effectue une recherche de session dans le cache de session. Si la session est détectée, un problème de session obsolète ou fantôme se produit.

3. PSN exécute la sélection de stratégie de provisionnement du client. Dans ce cas, avec une session fantôme qui n'a pas d'attributs d'authentification/autorisation et toutes les stratégies configurées par le client sont très spécifiques (les stratégies sont créées pour des groupes Active Directory spécifiques, par exemple), PSN n'est pas en mesure d'attribuer une stratégie d'approvisionnement de client correcte. Cela peut se manifester par le message d'erreur suivant : « Ignorer l'analyse AnyConnect votre réseau est configuré pour utiliser Cisco NAC Agent ».

• Dans le cas où les stratégies d'approvisionnement du client sont génériques (les attributs disponibles dans la session fantôme sont suffisants pour faire correspondre la stratégie avec la configuration AnyConnect), PSN répond avec les détails nécessaires à la poursuite du processus d'évaluation.
• À cette étape également, lorsque nous pouvons traiter les sessions obsolètes, PSN répond immédiatement avec l'état de posture Conforme et toutes les étapes suivantes ne sont pas effectuées. PSN n'envoie pas de certificat d'authenticité car il pense que la session est déjà conforme. Dans les journaux Radius Live, aucun événement de session n'est affiché avec l'état Conforme.

4. Pour le scénario de session fantôme, le module de posture ISE continue avec la demande de posture initiale. Cette demande contient des informations sur tous les produits de sécurité et de gestion des correctifs détectés sur le terminal.

5. PSN utilise les informations des attributs de requête et de session pour correspondre à la stratégie de position appropriée. Étant donné que la session fantôme ne dispose pas d'attributs à ce stade, nous n'avons pas de stratégie à mettre en correspondance. Dans ce cas, PSN répond au terminal qu'il est conforme, car il s'agit d'un comportement ISE par défaut en cas de non-correspondance de stratégie de position. 

Remarque : lorsqu'une stratégie générique peut être sélectionnée à partir des attributs de session fantôme, passez à l'étape 6.

6. PSN renvoie les politiques de posture sélectionnées à l'agent.

Remarque : lorsqu'aucune stratégie ne peut être sélectionnée, PSN renvoie le statut Conforme.

7. L'agent retourne des statuts pour chaque règle/condition telle que réussie ou échouée.

8. L'évaluation du rapport se produit sur ISE et les changements d'état de session sur Conforme.

Remarque : en cas de problèmes de position causés par la session fantôme, l'administrateur ISE peut remarquer certains certificats d'authenticité de position ayant échoué, car dans ce cas, les demandes de certificat d'authenticité sont exécutées à partir de PSN et d'ID de session incorrects.

Le processus de découverte ne démarre pas lors d'une nouvelle tentative d'authentification

Module de posture ISE conçu pour surveiller un nombre limité d'événements sur le terminal afin de déclencher un processus de détection. Liste des événements qui déclenchent la détection :

• Installation initiale du module de posture ISE.
• Connexion utilisateur.
• Événements d'alimentation.
• Changement d’état d’interface.
• Reprise du système d'exploitation après veille.
• Modification de la passerelle par défaut (DG)
• Échec de la réévaluation de la position (PRA), voir ID de bogue Cisco CSCvo69557

Le module de posture ISE ne détecte pas la nouvelle authentification dot1x, le déverrouillage du PC ou le changement d'adresse IP.

Le module de posture ISE ne peut pas détecter une nouvelle tentative d'authentification ou de réauthentification dans les scénarios suivants :

• La réauthentification frappe différents PSN (soit en raison de décisions LB, soit de problèmes avec le PSN d'origine).
• NAD génère un nouvel ID de session lors de la réauthentification.

Réauthentification sur un PSN différent

Exemple de nouvelle authentification sur un PSN différent causée par la panne du PSN d'origine. Le scénario avec équilibreur de charge est très similaire. Dans le cas de LB, réauthentification dirigée vers le PSN différent à la suite de l'expiration du minuteur d'adhésion.

1. Authentification initiale sur PSN1.

2. Session ABC créée dans le cache de session PSN1.

3. Évaluation de la position effectuée avec PSN1.

4. Le statut de la position ABS de session passe à Conforme.

5. Le certificat d'authenticité déclenché par un changement d'état de position entraîne une nouvelle authentification du terminal pour appliquer le niveau d'accès suivant.

6. PSN1 devient indisponible.

7. La réauthentification de la session ABC est effectuée sur PSN2.

8. Puisqu'il s'agit d'une nouvelle session pour l'état de position PSN2 de la session devient En attente.

État de la position initiale attribué par PSN à la session :

Remarque : State-machine décrit uniquement une sélection initiale de l'état de posture. Chaque session initialement marquée comme Inconnue peut devenir plus tard Conforme ou Non Conforme en fonction de l'évaluation du rapport reçue du module de posture ISE.

NAD génère un nouvel ID de session lors de la réauthentification

Cela peut se produire dans les deux scénarios les plus courants :

• La réauthentification n'est pas correctement configurée côté ISE. La solution à ce problème est traitée plus loin dans ce document.
• Mauvais comportement du côté NAD : normalement, le NAD conserve le même ID de session lors de la tentative de réauthentification. Si vous découvrez que NAD a modifié un ID de session lors de la réauthentification, il s'agit d'un comportement potentiellement bogué qui doit être étudié sur le NAD lui-même.

Le nouvel ID de session peut être généré dans d'autres scénarios d'angle. Par exemple, dans certains cas, l'itinérance sans fil peut en être la cause. L'essentiel ici est qu'ISE PSN place toujours une nouvelle session dans l'état de position en attente, à moins que le bail de position ne soit configuré. Le bail de posture est décrit plus loin dans ce document.

Méthode rapide d'identification du problème causé par la session obsolète/fantôme

Pour déterminer si AnyConnect est conforme lorsque l’état de redirection est dû à une session obsolète/fantôme, nous devons accéder au point d’extrémité lorsqu’il est à l’état problématique.

1.  étudier les détails de l'analyse système :
   
   

     1. Appuyez sur l'icône de rapport dans l'interface utilisateur AnyConnect

   

         2. Dans la nouvelle fenêtre, accédez à l'onglet Analyse système et au sous-onglet Statistiques

   

           Dans ce cas, tenez compte de deux éléments :

   •   Heure de début de la dernière analyse : l'horodatage doit être proche de l'heure à laquelle le problème a été détecté.
   •   Serveur de stratégie : ce champ indique le nom du serveur de stratégie qui a effectué une évaluation de la position du point de terminaison. Le nom de domaine complet d'ici doit être comparé au nom de domaine complet de Redirect-URL (pour la position de base de redirection) ou au nom PSN tiré de la dernière tentative d'authentification (pour la position sans redirection).
2. Comparez le nom de domaine complet du serveur de stratégies des statistiques d'analyse système avec le nom du noeud qui a authentifié le point de terminaison :

Dans l'exemple donné, il y a une incohérence entre le nom qui est indiqué que PSN avec le nom ciscolive-ise2 détient une session obsolète ou fantôme pour ce terminal.

La démonstration montre l'enregistrement des étapes nécessaires à l'identification du problème :

Dépannage avancé des sessions obsolètes/fantômes

L'exemple précédent est de différencier le problème d'une session obsolète ou fantôme du problème du processus de découverte qui n'a pas démarré. En même temps, nous devons identifier la session qui a déclenché le problème pour mieux comprendre comment exactement il devient un problème de session obsolète ou fantôme.

Bien que dans certains scénarios, les sessions obsolètes et fantômes ne peuvent pas être évitées. Nous devons nous assurer qu'il n'y a pas de sessions obsolètes/fantômes créées dans l'environnement en raison de certaines des meilleures pratiques qui ne sont pas mises en oeuvre.

Collection d'offres groupées DART

Analysez un bundle DART pris à partir du terminal qui reproduit le problème.

• Ne conservez que les journaux importants dans le DART. Il est recommandé d'effacer les journaux avant que le problème ne soit reproduit. 

Pour ce faire, l'utilitaire d'offre groupée DART doit démarrer en tant qu'administrateur et effectuer un nettoyage des journaux. 

1. Sous Windows, accédez à Démarrer et commencez à taper DART, cliquez avec le bouton droit de la souris et choisissez - Exécuter en tant qu'administrateur
   
   
2. Sur le premier écran de l'assistant, appuyez sur Suivant
   
   
3. Sur l'écran suivant de l'assistant, appuyez sur Effacer tous les journaux
   
   
   
   
4. Une fois le problème reproduit, vous pouvez récupérer le DART à partir d'ici ; appuyez sur Next.

analyse des bundles DART

Une fois l'ensemble DART collecté, nous devons le désarchiver et nous concentrer sur le fichier AnyConnect_ISEPosture.txt situé dans le dossier Cisco AnyConnect ISE Posture Module. Ce fichier contient tous les événements liés à la détection.

1. Commencez le dépannage et identifiez tous les moments de redémarrage de la détection. Les mots clés à rechercher sont Redémarrage de la détection ou Détection HTTP. Dans ce cas, accédez à la ligne avec le redémarrage de la détection qui s'est produit au moment problématique :

2. Quelques lignes après le redémarrage de la détection, vous voyez une ligne qui contient : Sondage sur les cibles de stade MNT. Il s'agit d'un indicateur de début de détection de l'étape 1 :

Il est recommandé de mettre en surbrillance toutes les sondes basées sur la redirection avec la même couleur alors que les PSN précédemment connectés pris de ConnectionData.xml (Auth-Status cibles) doivent être mis en surbrillance dans des couleurs différentes car normalement les FQDN PSN sont très similaires et il est difficile de repérer la différence.

3. Lisez les fichiers journaux pour voir un résultat pour chaque sonde unique. Comme cela a déjà été dit dans le cas du problème causé par une session obsolète/fantôme, toutes les sondes basées sur la redirection doivent échouer. Voici un exemple de l'aspect de la sonde défaillante :

4. Quelque part dans le fichier après le redémarrage de détection pour l'étape 1 ou l'étape 2, vous voyez une réponse réussie d'un ou plusieurs PSN :

5. Quelques lignes plus loin, il y a une ligne avec le mot clé MSG_NS_SWISS_NEW_SESSION. Cette ligne contient un ID de session réel qui a été sélectionné par PSN à la suite de la recherche de session. Utilisez cet ID de session pour approfondir vos recherches sur ISE et découvrir comment cette session devient obsolète/fantôme :

Enquête sur les journaux ISE

 Dans le fichier guest.log avec le composant clientwebapp activé dans DEBUG, le PSN qui répond avec la session Stale/Phantom peut être vu.

PSN reçoit une demande de l'agent de posture ISE. Vous pouvez voir qu'il s'agit d'une demande d'AnyConnect en raison de la valeur 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 requête contient des tableaux d'adresses IP et d'adresses MAC. Dans cet exemple particulier, chaque tableau ne contient qu'une seule valeur. Le journal montre également que l'ID de session de la demande est null, ce qui indique qu'il s'agit d'une demande provenant de la sonde non basée sur la redirection.

Vous pourrez voir plus tard comment les valeurs des tableaux sont utilisées pour localiser un ID de session :

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

Après la ligne avec les mots-clés Sent http response, vous pouvez voir le contenu de la réponse réelle :

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

Enquête sur les rapports ISE

Une fois que vous connaissez l'ID de la session obsolète/fantôme, vous pouvez examiner le rapport Radius Accounting pour mieux comprendre ce qui a provoqué l'obsolescence/fantôme de cette session :

• Accédez à Operations > Reports > Endpoints and Users > Radius Accounting report et exécutez ce rapport pendant 7 jours. L'utilisateur a un ID de point de terminaison comme clé de filtre.

Exemple d'un rapport qui montre comment une session obsolète a été laissée sur ciscolive-ise2 :

1. Le début comptable de la session est arrivé au PSN ciscolive-ise2
2. La mise à jour intermédiaire de la session a été traitée sur le même PSN.
3. Le message d'arrêt de la gestion de l'ID de session problématique est arrivé à un autre PSN (ciscolive-ise1).

Méthode rapide permettant d'identifier le moment où le problème a été causé par l'absence de redémarrage de la détection

Ici, la même logique est applicable que pour le numéro précédent. La seule différence est que vous devez vous concentrer sur l'heure de début de la dernière analyse. Pour ce type de problème, l'horodatage de la dernière analyse est quelque part dans le passé.

Normalement, lorsque l'utilisateur final découvre un problème, une analyse qui s'est produite il y a quelque temps est observée. Dans les journaux ISE Radius Live, les tentatives d'authentification récentes du point d'extrémité problématique sont visibles.

La démonstration montre l'enregistrement des étapes nécessaires à l'identification du problème :

Dépannage avancé de l'absence de redémarrage de la détection

L'approche ici est très similaire à la section Advanced Troubleshoot Stale/Phantom Session. Le principal élément de dépannage est l'étude du bundle DART. À l'intérieur du bundle DART, vous pouvez rechercher des redémarrages de détection comme cela a été indiqué pour le problème précédent et confirmer qu'il n'y avait pas de redémarrage de détection au moment où le problème a été signalé.

Côté ISE, concentrez-vous sur le rapport Radius Live Logs/Radius authentication pour confirmer qu'il y a eu un basculement entre PSN ou qu'un nouvel ID de session a été généré par NAD.

Solution

Approche classique - Évitement des problèmes

Historiquement, aucune fonctionnalité d'ISE ne permettait de résoudre les problèmes décrits dans ce document. Par conséquent, la seule façon de procéder consistait à s'appuyer sur l'ensemble des meilleures pratiques mises en oeuvre sur le réseau et à minimiser les risques du côté d'ISE.

Meilleures pratiques permettant de réduire le nombre de sessions obsolètes ou fantômes dans le déploiement ISE

Toujours implémenter une posture basée sur la redirection si possible

Une mauvaise expérience de l'utilisateur est un argument souvent invoqué pour justifier cette recommandation, car des fenêtres contextuelles apparaissent dans le système d'exploitation ou les navigateurs, indiquant une redirection, tandis que le module de posture AnyConnect ISE effectue un processus d'évaluation en arrière-plan.

Pour résoudre ce problème, il est possible de rediriger UNIQUEMENT les sondes de détection de module de posture ISE et d'autoriser sélectivement tout autre trafic.

L'exemple montre une liste de contrôle d'accès de redirection conçue pour rediriger uniquement les requêtes HTTP vers l'hôte de découverte (10.1.1.1 dans cet exemple) et 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

Pour maintenir un niveau de sécurité acceptable, une telle liste de contrôle d’accès de redirection peut être combinée à une liste DACL attribuée par ISE.

L'état En attente autorise uniquement les connexions à PSN lorsque le point de terminaison a été authentifié

Cette approche est utile pour les environnements où la redirection d'URL n'est pas prise en charge (par exemple, les implémentations avec les NAD tiers).

Comme solution, vous devez implémenter plusieurs stratégies d'autorisation PosturePending (une par PSN). Chaque stratégie doit contenir comme l'une des conditions le nom du PSN où l'authentification a eu lieu. Dans le profil d'autorisation affecté à chaque stratégie, l'accès à tous les PSN doit être bloqué, sauf au noeud où l'authentification a eu lieu.

Créer des politiques d'autorisation pour le déploiement de 2 noeuds :

 

1. Stratégie de mise en attente de position pour PSN1.

2. Nom PSN1 utilisé comme condition dans la stratégie.

3. Profil d'autorisation avec ACL qui bloque l'accès à tous les PSN à l'exception de PSN1.

4. Stratégie de mise en attente de position pour PSN2.

5. Nom PSN2 utilisé comme condition dans la stratégie.

6. Profil d'autorisation avec ACL qui bloque l'accès à tous les PSN à l'exception de PSN2.

7. Politique d’autorisation de la position « conforme ».

La figure explique le fonctionnement de cette approche :

1. L'authentification atteint PSN1.

2. En raison des stratégies d'autorisation configurées, PSN1 attribue un profil d'autorisation qui bloque l'accès à tous les autres noeuds à l'exception de PSN1.

3. Le module de posture AnyConnect ISE redémarre le processus de détection.

4. Sonde vers PSN2 bloquée par le NAD comme par une liste de contrôle d'accès attribuée précédemment.

5. Sonde vers PSN1 autorisée par l'ACL attribuée sur NAD.

Meilleures pratiques des équilibreurs de charge

• Activation de l'adhésion sur LB pour l'authentification et la comptabilité avec Calling-Station-ID comme clé d'adhésion. Plus d'informations sur les meilleures pratiques LB pour ISE sont disponibles ici.
• Utilisez un compteur d'adhésivité plus long qu'une journée de travail moyenne pour couvrir le moment où le PC passe en veille (par exemple 10 heures au lieu de 8 heures).
• Dans le cas où la ré-authentification est implémentée, utilisez un compteur de ré-authentification légèrement inférieur au compteur d'adhésion (par exemple 8 heures si l'adhésion est configurée pendant 10 heures). Cela permet de prolonger l'intervalle de rémanence par une nouvelle authentification.

Cas d'utilisation de Posture Over VPN 

• Vérifie que l'intervalle de mise à jour intermédiaire de la comptabilité est supérieur ou égal à vpn-session-timeout. Cela permet d'éviter les oscillations de comptabilité entre les PSN sur les sessions VPN de longue durée. 

Cet exemple montre l'intervalle de mise à jour de la comptabilité intermédiaire configuré pour 20 heures. Cela n'empêche pas la mise à jour intermédiaire initiale qui transporte l'adresse IP attribuée au point d'extrémité.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

Les Méthodes Recommandées peuvent être mises en oeuvre pour minimiser l'impact de l'absence de redémarrage du module de détection de position ISE

Activer le bail de position 

Il s'agit d'une fonctionnalité d'ISE qui marque le terminal comme étant conforme pendant une période définie (1 à 365 jours). La valeur de bail de position est un attribut de point d'extrémité, ce qui signifie qu'elle est stockée dans la base de données ISE. Tous les attributs de point d'extrémité qui incluent le bail de position sont répliqués sur tous les noeuds du déploiement ISE.

Lorsque PSN obtient une nouvelle session pour la position du terminal, le bail peut être utilisé pour marquer la session comme conforme immédiatement.

Pour prendre cette décision, PSN utilise 3 valeurs. Ces valeurs sont les suivantes :

• Nombre de jours définis pour le bail de position dans les paramètres ISE : Accédez à Administration > System > Posture > General Settings :

• Valeur de l'attribut PostureExpiry - il s'agit d'un attribut de point de terminaison réel qui contient un horodatage Epoch. La valeur PostureExpiry est initialement renseignée lors de la première tentative de posture réussie pour le terminal après l'activation du bail de posture par l'administrateur ISE. Plus tard, cette valeur a été mise à jour lors de la prochaine tentative de posture réussie qui se produit après l'expiration du bail.

            Vous pouvez voir un PostureExpiry dans Context Visibility > Endpoints pendant que l'un des terminaux affichés est ouvert :

           Cette valeur peut être convertie en l'horodatage lisible par l'homme, par exemple ici - https://www.epochconverter.com/

• Heure système PSN au moment où une nouvelle authentification a lieu

Lorsque l'authentification d'un terminal avec posture lease atteint PSN, il utilise PostureExpiry et la date système pour obtenir un nombre de jours qui se sont écoulés depuis la dernière vérification de posture réussie. Si la valeur de résultat est comprise dans un intervalle de bail de position défini dans les paramètres, la session obtient un état Conforme. Si la valeur du résultat est supérieure à la valeur du bail, la session obtient un état Inconnu. Cela déclenche la posture à exécuter à nouveau et une nouvelle valeur PostureExpiry peut être enregistrée.

La figure ci-contre explique le processus de basculement :

1. L'authentification initiale se produit avec PSN1.

2. Session ABC créée dans le cache de session.

3. L'évaluation de la posture se produit.

4. Changements d'état de session en Conforme

5. Le certificat d'authenticité déclenché par un changement d'état de position entraîne une nouvelle authentification du terminal pour appliquer le niveau d'accès suivant.

6. Valeur PostureExpiry enregistrée dans le point de terminaison.

7. Réplication des données des terminaux sur l'ensemble du déploiement.

8. La prochaine authentification atteint PSN2.

9. PSN2 vérifie si le point d'extrémité se trouve dans un bail de position valide.

11. La session a été ajoutée au cache de session en tant que conforme.

12. En raison de la validité du bail, la session a été créée avec le statut de posture Conforme.

Implémentation de la réauthentification 

Toujours pousser le minuteur de réauthentification à partir d'ISE avec RADIUS-Request sélectionné dans Maintenir la connectivité pendant la réauthentification. Ce paramètre garantit que NAD conserve le même ID de session lors de la réauthentification.

.

Environnements avec équilibreurs de charge

Il est possible de mettre en oeuvre le même ensemble de meilleures pratiques que celles expliquées dans la section relative aux sessions obsolètes/fantômes.

Différents sous-réseaux peuvent être utilisés pour les états En attente et Conforme

Lorsque la conception du réseau offre la possibilité d'utiliser différents états de sous-réseaux En attente et Conforme, cette approche garantit que chaque changement d'état entraîne un changement de passerelle par défaut.

Évaluation de la position utilisée dans le même intervalle qu'un minuteur de réauthentification

L'évaluation de la position peut être activée avec un intervalle égal au minuteur de réauthentification. Dans ce cas, lorsque le PSN d'origine devient indisponible, l'échec PRA redémarre le processus de détection.

Approche moderne - Partage d'état de posture

Dans le cadre d'une amélioration implémentée, décrite dans l'ID de bogue Cisco CSCvi35647patch 6 pour ISE 2.6 a obtenu une nouvelle fonctionnalité qui implémente le partage de l'état de la position de session sur tous les noeuds dans le déploiement ISE. Cette amélioration est intégrée dans les versions futures : ISE 2.7 correctifs 2 et ISE 3.0.

Cette nouvelle fonctionnalité est basée sur le mécanisme LSD (Light Session Directory) introduit dans ISE 2.6. Dans les versions plus récentes, cette fonctionnalité a été renommée en répertoire de session Radius LDD (Light Data Distribution).  Light Data Distribution est activé par défaut et permet le partage d'un contexte de session limité entre les noeuds ISE. Il n'existe pas de réplication de contexte de session complète entre PSN, seulement une quantité limitée d'attributs partagés pour chaque session.

L'idée principale derrière Light Session Directory est de supprimer le besoin d'exécuter des appels d'API coûteux en ressources vers MNT quand l'un des noeuds dans le déploiement doit déterminer qui est le propriétaire actuel de la session. La recherche du propriétaire est généralement nécessaire lorsque le flux de certificat d'authenticité démarre. Avec LDD, chaque PSN peut trouver un propriétaire réel de la session à partir du cache local du répertoire de session Radius. 

Architecture de distribution de données légères

Cette fonctionnalité contient les éléments suivants :

• Cache RSD (Radius Session Directory) : ce cache existe sur chaque noeud ISE et stocke toutes les sessions actives présentées dans le déploiement ISE. Chaque session a une quantité limitée d'attributs dans le cache. Exemples d'attributs stockés dans le répertoire de session Radius pour chaque session :
  
  
  • ID de session.
  • MAC du terminal.
  • CallingStationID.
  • Adresse IP du terminal.
  • PSN IP - PSN où l'authentification a eu lieu.
  • FQDN PSN - identique à celui ci-dessus.
  • Adresse IP du NAS.
  • NAS-IPv6-Address.
  • État : authentifié, démarré, arrêté.

• Échange RabbitMQ : il existe un échange dans lequel le serveur de publication, la file d'attente associée et le consommateur sont présentés sur chaque noeud du déploiement ISE. Cela garantit que la topologie à maillage global est formée entre tous les noeuds ISE.

• Éditeur : le répertoire de session Radius représente ici un éditeur. Lorsqu'une nouvelle authentification réussie traitée par PSN, une nouvelle session est créée dans le cache de session PSN. Pour cette session, un ensemble limité d'attributs est placé dans le répertoire de session Radius.

• Consommateur : sur tous les autres noeuds, le répertoire de session Radius représente un consommateur.

Remarque : la terminologie et l'architecture de General RabbitMQ ne sont pas abordées dans ce document. 

La figure explique comment le flux COA fonctionne avec le cache RSD :

1. L'authentification initiale se produit avec PSN1.

2. Session ABC créée dans le cache de session.

3. Les attributs requis sont enregistrés dans RSD.

4. Session partagée sur RabbitMQ avec tous les autres noeuds ISE.

5. La session est créée dans le cache RSD sur tous les noeuds ISE.

6. De nouvelles données de profil arrivent sur PSN2.

7. Le terminal est reprofilé et, en cas de modification nécessitant l'exécution du certificat d'authenticité, PSN2 passe à l'étape suivante.

8. Appel API interne soumis au cache RSD pour exécuter le certificat d'authenticité.

9. Données provenant du cache RSD utilisées pour préparer un message Proxy COA (un COA qui va d’un noeud ISE à un autre, il contient tous les détails que le noeud de destination peut utiliser pour émettre une requête CAO de retour à NAD). Le message de certificat d'authenticité est d'abord transféré en interne vers PRRT Runtime (serveur AAA réel dans ISE).

10. PSN2 envoie un message de certificat d'authenticité à PSN1.

11. PSN1 envoie un message de certificat d'authenticité à NAD.

Pour dépanner la communication sur LDD sur l'ISE, vous pouvez activer le composant Light Session Director dans DEBUG :

 exemple de message de débogage du fichier lsd.log pour la création et la publication de session sur le PSN d'origine :

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

Sur tous les autres noeuds ISE, vous voyez comment une session a été utilisée :

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

Partage d'état de posture sur RSD

Le partage de l'état de la position entre les noeuds résout le problème qui présente le symptôme comme « Le module de position AnyConnect ISE montre qu'il est conforme alors que l'état de la session sur ISE est en attente » lorsque la cause principale est soit une session obsolète/fantôme, soit une ré-authentification sur un PSN différent avec un ID de session d'origine qui n'a pas déclenché le redémarrage de la découverte. Dès que la session devient conforme, cette information est placée dans la session RSD, et plus tard elle peut être utilisée par chaque PSN dans le déploiement.

Il y a encore d'autres cas d'angle que la fonction décrite ne peut pas résoudre. Par exemple, un scénario dans lequel NAD exécute une nouvelle authentification sur le même PSN mais avec un ID de session différent. De tels scénarios peuvent être traités à l'aide des meilleures pratiques décrites dans ce document.

La figure illustre la topologie utilisée pour tester le partage de l'état de position :

Partage de l'état de la position sur RSD - Session obsolète/fantôme

Pour créer une session obsolète, l'authentification a été initialement effectuée sur skuchere-ise26-1 et NAD a été reconfiguré ultérieurement pour envoyer la comptabilité à skuchere-ise26-3. Une fois qu'un message de gestion des comptes a été transféré au PSN NAD incorrect, il a été reconfiguré pour renvoyer la gestion des comptes à skuchere-ise26-1.

La figure illustre un rapport comptable qui prouve la présence de la session fantôme sur skuchere-ise26-3 :

1. Messages Accounting-Start traités par skuchere-ise26-1.

2. Comptabilité provisoire - Mise à jour pour la même session traitée par skuchere-ise26-3.

3. La session se termine plus tard sur skuchere-ise26-1.

Après un certain temps, le point de terminaison se connecte de nouveau au réseau, mais la redirection ne fonctionne plus. Dans le journal guest.log de PSN - skuchere-ise26-3, vous pouvez voir ces messages de journal avec le composant client-webapp activé dans 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

Lorsque PSN détecte qu'il détient une session obsolète/fantôme pour le terminal, il ne répond pas au module de posture ISE et cela nous permet d'obtenir la bonne réponse du PSN où la dernière authentification a eu lieu.

Comme solution au problème de session obsolète/fantôme maintenant au moment de la recherche de session, PSN vérifie la présence de toute nouvelle session pour le terminal dans le RSD. Dans le cas où RSD contient un ID de session différent de celui de PSN dans le cache de session local, il suppose que la session présentée dans le cache de session est périmée.

Partage d'état de position sur RSD - Basculement entre PSN

Pour reproduire ce scénario, un temporisateur de réauthentification court a été activé dans le profil d'autorisation affecté au point d'extrémité dans l'état conforme. Plus tard, NAD a été reconfiguré pour envoyer l'authentification et la comptabilité à un autre PSN (skuchere-ise26-3). À l'expiration du minuteur de réauthentification, la même session n'a pas été authentifiée sur le PSN différent.

La figure illustre un rapport d'authentification qui montre le basculement pour la session saine de skuchere-ise26-1 vers skuchere-ise26-3 :

1. L'authentification se produit sur skuchere-ise26-1, le profil d'autorisation avec redirection est attribué.

2. L'ACO après une évaluation de posture réussie.

3. Authentification suivante lorsque le profil d'autorisation pour l'état conforme est attribué.

4. L'authentification atteint un PSN différent, mais elle obtient toujours le profil d'autorisation pour l'état conforme.

La session obtient l'état de conformité sur le nouveau PSN après le basculement dans ise-psc.log avec les composants epm-pip et nsf-session activés dans 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

Le problème initial a été résolu avec l'ajout d'une logique supplémentaire dans le processus de sélection de l'état de posture. La figure illustre ce qui a été modifié (les modifications sont surlignées en rouge) :