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 existe 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 redirection constante vers le portail de mise à disposition 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 l'identité : Alice.
• L'état de la position de la session est En attente.
• Dernier événement de session pour Identity : 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 lorsque le problème décrit se manifeste. Un événement de session avec l'état de position Conforme est plus courant pour les scénarios provoqués par les sessions obsolètes ou fantômes (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 du mauvais état de posture. 

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. Il est possible qu'aucun de ces événements n'ait été détecté lors de l'authentification ou de la nouvelle authentification.

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 de la session peut être mis à jour ultérieurement par le Syslog pour la comptabilisation.

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

1. 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 des sessions et les nettoyer.

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

3. Le même cron sur chaque exécution supprime aussi bien les sessions qui ont été dans l'état "Démarré" 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

Le cache de session PSN est une 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.

ISE ne dispose d'aucun mécanisme permettant d'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 (par exemple, 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 (comme l'authentification, l'autorisation, l'approvisionnement client et la position).

Le cache de session est complètement supprimé lorsque le noeud (ou les services sur le noeud) 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 :

• L'entrée du cache de session est 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. La session est marquée comme conforme.

5. Le changement d’autorisation (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 cela, ABC est bloqué dans l'état d'obsolescence sur le PSN1 parce qu'il n'y a aucun 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. L'authentification initiale pour la session ABC est 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. L'entrée pour la session ABC est 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. L'entrée du cache de session pour la session ABC est mise à jour avec les informations de Accounting-Start.

8. Le message Syslog pour Accounting-Start est transféré au noeud MNT.

9. L'état de la session est mis à jour en Démarré.

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

11. Accounting-Stop pour la session ABC est transféré par l'équilibreur de charge vers PSN 2.

12. Le message Syslog pour Accounting-Stop est 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.

Si PSN n'obtient pas de message d'arrêt de comptabilisation pour cette session, l'entrée n'est pas supprimée sauf si PSN atteint 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. Une mise à jour intermédiaire comptable pour la session ABC frappe PSN2.

4. Une entrée de session pour la session ABC est créée sur PSN2. Comme l'entrée de session est créée à partir du message de comptabilité, elle possède un nombre limité d'attributs. 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.

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

1. L'authentification initiale pour la session ABC est effectuée par le PSN.

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

3. Le message syslog pour l'authentification réussie est transféré au noeud MNT.

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

5. Le message de début de comptabilisation pour la session ABC atterrit sur PSN 1.

6. Une entrée de cache de session pour la session ABC est mise à jour avec les informations de Accounting-Start.

7. Le message Syslog pour Accounting-Start est transféré au noeud MNT.

8. L'état de la session est mis à jour en Démarré.

9. La mise à jour de la comptabilité intermédiaire pour la session ABC est transmise à PSN2.

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

11. Le compte-arrêt de la session ABC est transmis à PSN1.

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

13. Un message syslog pour Accounting-Stop est transmis par PSN 1 à MNT.

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

Ceci décrit un scénario de la session fantôme telle que créée pour la connexion VPN à vie longue :

1. Authentification initiale sur PSN1.

2. La session ABC est créée dans le cache de session.

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

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

5. Une mise à jour comptable intermédiaire contenant des informations d’adresse IP atterrit sur PSN.

6. Les informations d’adresse IP sont ajoutées au cache de session.

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

8. L'état de la position est mis à jour dans la session.

9. Une poussée de certificat d’authenticité est exécutée par ISE ; cela déclenche l’attribution d’un nouveau niveau d’accès.

10. Il existe une panne sur le chemin réseau qui rend PSN1 inaccessible.

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

12. La mise à jour comptable intermédiaire arrive sur PSN2.

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

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

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

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

É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 dirigent toujours l'agent vers le PSN droit, car l'URL redirigée est extraite 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 est créé après la première tentative de positionnement réussie. Le contenu du fichier peut être mis à jour ultérieurement si 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\.

Comme 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 de l'étape 3 ont échoué ou si le module de posture ISE n'a pas pu établir une communication correcte avec le 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 dispose d'une session obsolète ou fantôme pour un terminal, cela peut entraîner l'affichage d'un état de position incorrect plus tard du 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 le PSN ne peut 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 : 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 d'approvisionnement du client. Dans le cas où une session fantôme ne dispose pas d'attributs d'authentification/autorisation et où toutes les stratégies configurées par le client sont très spécifiques (par exemple, des stratégies sont créées pour des groupes Active Directory spécifiques), PSN ne peut pas attribuer une stratégie d'approvisionnement de client appropriée. 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 les 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 à la configuration AnyConnect), PSN répond en fournissant les détails nécessaires à la poursuite du processus d'évaluation.
• À cette étape, lorsque nous pouvons traiter les sessions obsolètes, PSN répond immédiatement avec un statut de position 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. Il s'agit d'un comportement ISE par défaut dans le cas d'une stratégie de posture ne correspondant pas. 

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 : si aucune stratégie ne peut être sélectionnée, PSN renvoie l'état Conforme.

7. L'agent retourne les statuts de chaque règle/condition comme étant « réussi » ou « échoué ».

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 posture causés par la session fantôme, l'administrateur ISE remarque peut-être certains COA de posture défaillants. 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

Le module de posture ISE est conçu pour surveiller un nombre limité d'événements sur le terminal afin de déclencher un processus de détection.

Événements qui déclenchent la découverte :

• 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 et 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

Ce schéma illustre un exemple de ré-authentification sur différents PSN provoquée par la panne du PSN d'origine. Un scénario avec un équilibreur de charge semble très similaire.

Dans le cas d'un équilibreur de charge, la ré-authentification est dirigée vers le PSN différent à la suite d'une expiration de temporisateur d'adhésivité.

1. Authentification initiale sur PSN1

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

3. L'évaluation de la posture est effectuée avec PSN1.

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

5. Le certificat d'authenticité est déclenché par un changement d'état de position et 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. Comme il s'agit d'une nouvelle session pour PSN2, l'état de la session devient En attente.

L'état de la position initiale est 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 de 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, NAD conserve le même ID de session lors de la tentative de 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 affiche la conformité alors qu’il est à l’état de redirection, il faut tenir compte de la session obsolète/fantôme. Nous devons avoir accès au terminal tant qu'il est dans l'état problématique.

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

     1. Cliquez sur l'icône d'engrenage dans l'interface utilisateur AnyConnect

   

         2. Dans la nouvelle fenêtre, accédez à Analyse système > 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 :

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 permet de différencier le problème d'une session obsolète ou fantôme du problème du processus de détection 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 cas, les sessions obsolètes et fantômes ne puissent pas être évitées, nous devons nous assurer que les meilleures pratiques sont mises en oeuvre afin qu'aucune session obsolète/fantôme ne soit créée dans l'environnement.

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. Dans le premier écran de l'assistant, cliquez sur Suivant.
   
   
3. Dans l'écran suivant de l'assistant, cliquez sur Effacer tous les journaux.
   
   

4. Une fois le problème reproduit, DART peut être collecté à partir d'ici ; cliquez sur Next.

analyse des bundles DART

Une fois l'ensemble DART collecté, déarchivez-le et concentrez-vous 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. Plusieurs lignes après le redémarrage de la détection, il y a une ligne qui contient - Sondage sur les cibles d'étape 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 et les PSN précédemment connectés provenant de ConnectionData.xml (cibles d'état d'authentification) dans une couleur différente.

Normalement, les FQDN PSN sont très similaires et il est difficile de faire la différence.

3. Lisez les fichiers journaux pour voir un résultat pour chaque sonde unique. 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. Plusieurs 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 les recherches sur ISE et déterminer comment cette session devient obsolète/fantôme :

Enquête sur les journaux ISE

 Dans le journal 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. 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 indique 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 contenant 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. Utilisez un ID de point de terminaison comme clé de filtre.

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

1. Le début de la comptabilisation de la session est arrivé sur le PSN ciscolive-ise2.
2. La mise à jour intermédiaire de la session a été traitée sur le même PSN.
3. Un message d'arrêt de la gestion des comptes pour l'ID de session problématique est arrivé à un PSN différent (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.

Dans l'ensemble DART, vous pouvez rechercher des redémarrages de détection (comme indiqué pour le problème précédent) et confirmer qu'il n'y a pas eu de redémarrage de détection au moment où le problème a été signalé.

Côté ISE, concentrez-vous sur le rapport d'authentification Radius Live Logs/Radius 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 fréquent en faveur de cette recommandation ; des fenêtres intempestives du système d'exploitation ou des navigateurs s'affichent. Cela indique une redirection tandis que le module de posture AnyConnect ISE en arrière-plan effectue un processus d'évaluation.

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.

Cet 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 avec une liste de contrôle d'accès 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).

En guise de solution, implémentez 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. La sonde vers PSN2 est bloquée par le NAD comme par une liste de contrôle d'accès attribuée précédemment.

5. L'analyse de PSN1 est autorisée par la liste de contrôle d'accès attribuée sur NAD.

Meilleures pratiques des équilibreurs de charge

• Activez la rémanence sur l'équilibreur de charge pour l'authentification et la comptabilité avec Calling-Station-ID comme clé de rémanence. 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 

• Assurez-vous que l'intervalle de mise à jour intermédiaire de la gestion des comptes est supérieur ou égal à vpn-session-timeout. Cela minimise le battement de compte entre les PSN pendant de longues sessions VPN. 

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 les terminaux comme conformes pour 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 point d'extrémité, 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 :

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

2. La valeur de l'attribut PostureExpiry est 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 horodatage lisible par l'utilisateur, par exemple, ici - https://www.epochconverter.com/

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

Lorsque l'authentification d'un point de terminaison avec posture lease atteint PSN, elle utilise PostureExpiry et la date système pour obtenir le nombre de jours écoulés depuis la dernière vérification de posture réussie.

Si la valeur de résultat se situe 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 la nouvelle valeur PostureExpiry peut être enregistrée.

Ce schéma décrit le processus de basculement :

1. L'authentification initiale se produit avec PSN1.

2. La session ABC est 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é est déclenché par un changement d'état de position et entraîne une nouvelle authentification du terminal pour appliquer le niveau d'accès suivant.

6. La valeur PostureExpiry est enregistrée dans le terminal.

7. Les données des terminaux sont répliquées dans le 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 est ajoutée au cache de session en tant que conforme.

12. En raison de la validité du bail, la session est 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

Le même ensemble de meilleures pratiques (expliqué dans la section session obsolète/fantôme) peut être mis en oeuvre.

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 n'est plus disponible, 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 CSCvi35647 ), le patch 6 pour ISE 2.6 a 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.

Light Session Directory supprime la nécessité d'exécuter des appels d'API coûteux en ressources vers MNT lorsque l'un des noeuds du déploiement doit déterminer le propriétaire actuel de la session.

En général, la recherche du propriétaire est 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 du répertoire de session Radius (RSD)

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. 

Voici des exemples des 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 
• Adresse IP du NAS
• NAS-IPv6-Address
• État : authentifié, démarré, arrêté

• central 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 est traitée par un 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.

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

1. L'authentification initiale se produit avec PSN1.

2. La session ABC est créée dans le cache de session.

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

4. La session est 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 point de terminaison est reprofilé et (en cas de modification nécessitant l'exécution du certificat d'authenticité, PSN2) passe à l'étape suivante.

8. Un appel d'API interne est envoyé au cache RSD pour exécuter le certificat d'authenticité.

9. Les données du cache RSD sont utilisées pour préparer un message Proxy COA. Il passe d’un noeud ISE à un autre et contient tous les détails que le noeud de destination peut utiliser pour renvoyer une requête CAO à NAD. Le message COA 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, activez le composant Light Session Director dans DEBUG :

Voici un exemple d'un message de débogage provenant du fichier lsd.log pour la création et la publication d'une 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 d'état de posture résout les problèmes lorsque la cause principale est une session obsolète/fantôme ou une ré-authentification sur un PSN différent qui n'a pas déclenché le redémarrage de la détection.

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.

Cette 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 doit être initialement effectuée sur le skuchere-ise26-1. Ensuite, NAD doit être reconfiguré pour envoyer la comptabilisation à skuchere-ise26-3.

Une fois qu'un message de gestion des comptes a été transféré au PSN incorrect, NAD doit être reconfiguré (à nouveau) 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 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 est activé dans le profil d'autorisation affecté au point d'extrémité d'état conforme.

Par la suite, NAD est 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'est pas authentifiée sur le PSN différent.

La figure illustre un rapport d'authentification qui montre le basculement pour la même session 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 a 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 est résolu par l'ajout d'une logique supplémentaire dans le processus de sélection de l'état de posture.

Cette figure illustre ce qui a été modifié (les modifications sont surlignées en rouge) :