Gestion et positionnement des sessions ISE

Introduction

Ce document décrit le problème des services de posture ISE (Identity Service Engine) courants - Le module de posture ISE AnyConnect affiche une conformité pendant que l'état de session sur ISE est en attente. Ce problème devient de plus en plus populaire et même si les symptômes sont toujours les mêmes, il pourrait y avoir plusieurs causes profondes de ce problème. Souvent, le dépannage d'un tel problème prend beaucoup de temps, ce qui peut avoir des conséquences graves.

Informations générales

Ce document explique :

• Manifestation du problème du point de vue de l'utilisateur final et de l'administrateur ISE.
• Scénarios problématiques courants.
• Théorie derrière ISE, AnyConnect et les opérations réseau qui peuvent déclencher le problème.
• Algorithmes d'identification rapide des problèmes.
• Solutions classiques aux scénarios problématiques courants.
• Partage de l'état de la position sur le répertoire de session Radius.

Pour mieux comprendre les concepts décrits plus loin, il est recommandé de passer en revue les points suivants :

Problème

Expérience utilisateur final

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

Expérience utilisateur type :

Expérience d'administration ISE

Normalement, au cours du triage initial de ce problème, l'administrateur ISE effectue une analyse des journaux Radius Live pour s'assurer qu'il existe une authentification réelle qui touche ISE. Le premier symptôme découvert au cours de cette étape indique une non-correspondance dans l'état d'une position entre le point de terminaison et ISE, comme dans les journaux en direct ou les rapports d'authentification Radius de la dernière authentification réussie pour le point de terminaison montre l'état de position 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 la position comme Conforme.

Note: c. et d. ne sont pas toujours présentés dans les journaux en direct lorsque les manifestes de problèmes décrits sont décrits. Événement de session avec état Conforme est plus courant pour les scénarios causés par les sessions obsolètes ou fantômes qui sont décrits plus loin dans ce document.

Scénarios courants de problèmes

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

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

Problème de session statique

Pour mieux comprendre le problème, plongez-vous dans la logique de gestion des sessions ISE et dans le processus de découverte AnyConnect requis.

Logique de gestion des sessions ISE

Dans le déploiement ISE, deux personnes sont responsables du processus de gestion des sessions : PSN et MNT (Monitoring Node). 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 des sessions

Comme expliqué dans la figure, le noeud MNT crée des saisons basées sur les messages Syslog d'authentification passés provenant de PSN. L'état de session ultérieur peut être mis à jour par Syslog pour la comptabilité.

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

• Les sessions sans comptabilité 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 effectuer le nettoyage.
• La session interrompue a été supprimée environ 15 minutes après que l'arrêt de la comptabilité ait été traité par la même tâche cron.
• Le même cron pour chaque exécution supprime également les sessions qui sont à l'état 'Démarré' depuis plus de 5 jours (120 heures). Un état démarré signifie que le noeud MNT a traité à la fois l'authentification et la comptabilité pour démarrer Syslog pour la session.

Exemples de messages Syslog de PSN. Ces messages sont connectés à prrt-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 transmise :

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 comptabilité :

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 comptabilité :

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

Gestion des sessions et PSN

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

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

Pour chaque ID de session actif, PSN stocke tous les attributs qui ont été 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 Authentification, Autorisation, Provisioning client, Posture.

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 PSN.
• PSN a obtenu une mise à jour intermédiaire de comptabilité pour la session qui n'existe pas dans le cache de session.

Lorsqu'il s'agit de supprimer une session, PSN implémente la logique suivante :

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

Session périmée sur PSN

Dans le déploiement ISE, l'arrêt de comptabilisation d'une session existante a été traité par 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 a lieu.

4. Session marquée comme Conforme.

5. La modification de l'autorisation (COA) déclenchée par la modification de l'état de la position entraîne la réauthentification du point de terminaison pour appliquer le niveau d'accès suivant.

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

Après la session de l'étape 6, ABC se retrouve coincé dans l'état d'obsolescence sur PSN1, car aucun message d'arrêt de comptabilité n'est traité sur ce PSN pour le supprimer. La session ne peut pas être supprimée pendant longtemps si le déploiement ne connaît pas un grand nombre de tentatives d'authentification.

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

• L'arrêt de la comptabilité est arrivé au mauvais PSN en raison de l'expiration du compteur d'adhérence sur l'équilibreur de charge.
• La mauvaise configuration sur la NAD n'est pas le même PSN configuré pour l'authentification et la comptabilité.
• Problèmes de connectivité temporaires sur le chemin du réseau qui provoquent le basculement NAD vers le prochain PSN.

Exemple de session obsolète dans l'environnement Load Balancer (LB) :

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

2. Cette authentification initie un minuteur d'adhérence 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 transmise transférée au noeud MNT.

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

6. Message de début de la comptabilisation pour la session ABC se trouve 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 sur Démarré.

10. Le minuteur d'étanchéité 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 transféré par PSN 2 à MNT.

13. Session ABC marquée comme terminée sur MNT.

Session fantôme sur PSN

La session fantôme est un scénario lorsque la mise à jour intermédiaire de la comptabilité arrive sur 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 ne reçoit pas de message d'arrêt de comptabilité pour cette session, l'entrée ne sera supprimée que 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. La session ABC a un statut Conforme dans le cache de session PSN1.

3. Mise à jour intermédiaire de la comptabilité pour la session ABC sur PSN2.

4. Entrée de session pour la session ABC créée sur PSN2. Depuis l'entrée de session créée à partir du message de comptabilisation, elle a un nombre limité d'attributs. Par exemple, l'état de la position n'est pas disponible pour la session ABC. Il manque également des groupes d'utilisateurs et d'autres attributs spécifiques à l'autorisation.

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

• Interruption à court terme sur le transit du réseau.
• Comportement incorrect du périphérique d'accès au réseau.
• Erreur de 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 du 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 transmise transférée au noeud MNT.

4. Entrée pour la session ABC créée dans TimesTen DB avec l'état Authorisé.

5. Message de début de la comptabilisation pour la session ABC se trouve 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 sur Démarré.

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

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

11. Arrêt de la comptabilité pour la session ABC transmise à PSN1.

12. Entrée de session ABC supprimée du cache de session sur PSN1.

13. Message Syslog pour Accounting-Stop transféré par PSN 1 à MNT.

14. Session ABC marquée comme terminée sur MNT.

Scénario de la session fantôme créée pour la connexion VPN longue durée :

1. Authentification initiale sur PSN1.

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

3. Comptabilité démarre le message traité par PSN.

4. Nouvelle adresse IP attribuée à la carte VPN (Virtual Private Network).

5. La mise à jour de la comptabilité provisoire avec les informations d'adresse IP s'arrête 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 dans la session.

9. Pression du mode d'action exécutée par ISE, cela déclenche l'attribution d'un nouveau niveau d'accès.

10. Panne sur le chemin du 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. La mise à jour de la comptabilité provisoire arrive sur PSN2.

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

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

Comment une session et une session fantômes peuvent-elles rompre le processus d'affichage ?

Pour comprendre comment la session obsolète et la session fantôme vont rompre la position, vous pouvez passer en revue le processus de découverte du module de posture ISE AnyConnect :

Découverte de l'étape 1 :

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

Premièrement, 3 sondes sur la figure sont basées sur la redirection (IP GW par défaut). Discovery host IP (si défini) and enroll.cisco.com IP (Adresse IP de l'hôte de découverte) : ces sondes doivent toujours pointer l'agent vers le PSN de droite, car l'URL de redirection provient de la NAD elle-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 de fichier ultérieur peuvent ê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 n'est utilisé que si les 3 autres sondes ont échoué ou si le module de posture ISE n'a pas pu établir une communication correcte avec PSN retourné dans l'URL de redirection dans les 5 secondes.

Lorsque l'analyseur 4 atterrit sur le PSN, il 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 le point de terminaison, cela peut entraîner un mauvais état de position affiché ultérieurement sur le 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.

Découverte de l'étape 2 :

Toutes les sondes de découverte 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écouverte de l'étape 2 peut être encore plus affectée par les problèmes provenant de sessions obsolètes ou fantômes.

Si PSN arrive à l'étape 2, la sonde de détection qui existe dans le cache de session créera une entrée fantôme ou obsolète pour le même point de terminaison. L'état de la position retournée à l'utilisateur final est incorrect.

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

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

1. Toutes les sondes de recherche de ma session émises par le module de posture ISE.

2. PSN effectue une recherche de session dans le cache de session. Si la session doit être trouvée, un problème de session fantôme ou obsolète se produit.

3. PSN exécute la sélection de la stratégie d'approvisionnement du client. Dans le cas d'une session fantôme qui n'a pas d'attributs d'authentification/autorisation et que 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 peut ne pas être en mesure d'attribuer une stratégie d'approvisionnement client appropriée. Ceci peut se manifester dans le message d'erreur « Ignorer AnyConnect scan your network is configure to use Cisco NAC Agent ».

• Si les stratégies d'approvisionnement client sont génériques (les attributs disponibles dans la session fantôme sont suffisants pour correspondre à la stratégie avec la configuration AnyConnect), PSN répondra avec les détails nécessaires à la poursuite du processus d'évaluation.
• À cette étape également lorsque nous pouvons traiter des 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 croit 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 poursuit 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 politique de position appropriée. Puisque la session fantôme n'a pas d'attributs à ce stade, il se peut que nous n'ayons pas de stratégie à mettre en correspondance. Dans ce cas, PSN répond au point de terminaison qu'il est conforme, car il s'agit d'un comportement ISE par défaut en cas de non-correspondance de stratégie de posture. 

Note: Lorsqu'il existe une stratégie générique qui peut être sélectionnée à partir des attributs de session fantôme, nous poursuivons avec l'étape 6.

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

Note: Lorsqu'aucune stratégie ne peut être sélectionnée, PSN renvoie l'état Conforme.

7. L'agent retourne les statuts de chaque stratégie/exigence tels qu'ils ont été passés ou ont échoué.

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

Note: En cas de problème de position causé par la session fantôme, l'administrateur ISE peut remarquer certains certificats d'authenticité de posture défectueux, car dans ce cas, les demandes de certificat d'authenticité sont exécutées à partir de PSN incorrects et pour des ID de session incorrects.

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

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

• Installation initiale du module de posture ISE.
• Connexion utilisateur.
• Événements d'alimentation.
• Modification de l'état de l'interface.
• Reprise du système d'exploitation après la mise en 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 ISE ne détecte pas de nouvelle authentification dot1x, de déverrouillage du PC et de changement d'adresse IP.

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

• La réauthentification touche différents PSN (soit en raison de décisions d'équilibrage de charge ou 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 autre PSN

Exemple de réauthentification sur différents PSN causée par la panne du PSN d'origine. Le scénario avec équilibrage de charge sera très similaire. Dans le cas de l'équilibrage de charge, réauthentification dirigée vers le PSN différent à la suite de l'expiration du compteur d'adhérence.

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. L'état de la position ABS de la session passe à Conforme.

5. Le certificat d'authenticité déclenché par le changement d'état de la position entraîne la réauthentification du point de terminaison pour appliquer le niveau d'accès suivant.

6. PSN1 devient indisponible.

7. La réauthentification de la session ABC touche PSN2.

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

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

Note: State-machine décrit uniquement une sélection initiale de l'état de la position. Chaque session initialement marquée comme Inconnue peut ultérieurement devenir Conforme ou Non Conforme en fonction de l'évaluation des rapports reçue du module ISE.

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

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

• La réauthentification n'est pas correctement configurée du côté ISE. La solution à ce problème sera traitée plus loin dans ce document.
• Comportement incorrect du côté NAD - normalement NAD doit conserver le même ID de session lors de la tentative de réauthentification. Au cas où vous découvririez que NAD modifie un ID de session lors de la réauthentification, il s'agit d'un comportement potentiellement bogué qui doit être étudié sur la NAD elle-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 que ISE PSN place toujours une nouvelle session dans l'état En attente, sauf si le bail de la posture est configuré. Le bail de posture sera expliqué plus loin dans ce document.

Méthode rapide d'identification du moment où le problème a été causé par la session périmée/fantôme

Pour déterminer si AnyConnect affiche la conformité lors de l'état de redirection est dû à la session obsolète/fantôme, nous devons accéder au point de terminaison lorsqu'il est dans l'état problématique.

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

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

   

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

   

           Ici, attention à deux éléments :

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

Dans l'exemple donné, il y a une non-correspondance entre le nom indiqué que PSN avec le nom ciscolive-ise2 contient une session obsolète ou fantôme pour ce point de terminaison.

La démo montre l'enregistrement des étapes nécessaires à l'identification des problèmes :

Dépannage avancé d'une session périmée/fantôme

L'exemple précédent est de différencier le problème d'une session stale ou fantôme du problème du processus de découverte qui n'a pas démarré. Dans le même temps, nous pouvons avoir besoin d'identifier la session réelle qui a déclenché le problème pour mieux comprendre comment exactement il devient un problème de session stale 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 de bundles DART

Analyser un bundle DART extrait du point de terminaison qui reproduit le problème.

• Conservez uniquement les journaux importants dans le DART. Il est recommandé d'effacer les journaux avant de reproduire le problème. 

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

1. Sous Windows Naviguez jusqu'à Démarrer et commencez à taper DART, puis faites un clic droit et choisissez - Exécuter en tant qu'administrateur
   
   
2. Dans le premier écran de l'assistant, appuyez sur Suivant
   
   
3. Sur l'écran suivant de l'assistant, appuyez sur Effacer tous les journaux
   
   
   
   
4. Après avoir reproduit le problème, vous pouvez récupérer le DART à partir d'ici, suivez l'assistant et appuyez sur Suivant.

Analyse du bundle DART

Une fois que le bundle DART a été 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écouverte.

1. Commencez le dépannage en identifiant tous les moments de redémarrage de la découverte. Les mots clés à rechercher sont Redémarrer la découverte ou la découverte HTTP. Ici, accédez à la ligne avec le redémarrage de découverte qui s'est produit au moment problématique :

2. Quelques lignes après le redémarrage de la découverte vous devriez voir une ligne qui contient - Probing no MNT stage target. Ceci est un indicateur du début de la découverte 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 provenant de ConnectionData.xml (cibles d'état d'authentification) 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.Suivez les fichiers journaux pour voir un résultat pour chaque sonde. Comme on l'a déjà dit en cas de problème causé par une session stale/fantôme, toutes les sondes redirigées 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 la détection pour l'étape 1 ou 2, vous devriez voir une réponse réussie d'un ou plusieurs PSN :

5. Quelques lignes plus tard, il devrait y avoir 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 plus d'informations sur ISE pour comprendre comment cette session devient obsolète/fantôme :

Enquête sur les journaux ISE

 Dans 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. De même, le journal indique que l'ID de session de la requête est null, ce qui indique qu'il s'agit d'une requête de la sonde non redirigée.

Vous verrez 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 being 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 Envoyé 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/l'obsolescence de cette session :

• Naviguez jusqu'à Operations > Reports > Endpoints and Users > Radius Accounting et exécutez ce rapport pendant 7 jours. Utilisez un ID de point de terminaison comme clé de filtre.

Exemple de rapport montrant comment une session obsolète a été abandonnée sur ciscolive-ise2 :

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

Un moyen rapide d'identifier quand le problème a été causé par l'absence de redémarrage de la détection

Ici, la même logique s'applique 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 se trouve 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 visible. Dans les journaux ISE Radius Live, des tentatives d'authentification récentes à partir du point de terminaison problématique sont visibles.

La démo ci-dessous montre l'enregistrement des étapes nécessaires à l'identification des problèmes :

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

L'approche ici est très similaire à la section Dépannage avancé des sessions obsolètes/fantômes. L'élément de dépannage principal est l'analyse du bundle DART. À l'intérieur du bundle DART, vous pouvez rechercher des redémarrages de découverte comme s'il avait été affiché pour le problème précédent et confirmer qu'il n'y avait pas de redémarrage de découverte au moment où le problème a été signalé.

Du côté ISE, concentrez-vous sur le rapport d'authentification Radius Live Logs/Radius pour confirmer qu'il y a eu 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, il n'existait aucune fonctionnalité sur ISE qui pouvait résoudre les problèmes décrits dans ce document, de sorte que la seule façon était de s'appuyer sur l'ensemble des meilleures pratiques mises en oeuvre sur le réseau et ISE côté réduction des risques.

Meilleures pratiques pouvant 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 lorsque possible

Un contre-argument courant à cette recommandation est une mauvaise expérience utilisateur car les utilisateurs voient des fenêtres publicitaires intempestives dans le système d'exploitation ou les navigateurs indiquant une redirection alors que le module de posture ISE d'AnyConnect en arrière-plan effectue un processus d'évaluation.

Pour y remédier, il est possible de rediriger UNIQUEMENT les sondes de découverte de module ISE Posture tout en autorisant 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 Discovery Host (1.1.1.1 dans cet exemple) et enroll.cisco.com (72.163.1.80) :

ip access-list extended REDIRECT-DH-ENROLL

 permit tcp any host 1.1.1.1 eq www

 permit tcp any host 72.163.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 de contrôle d’accès de déconnexion attribuée par ISE.

État En attente Autorise les connexions uniquement à PSN où 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 tant que solution, vous devez implémenter plusieurs stratégies d'autorisation PosturePending (une par PSN). Chaque politique doit contenir comme l'une des conditions le nom de PSN où l'authentification a eu lieu. Dans le profil d'autorisation attribué à chaque stratégie, l'accès à tous les PSN doit être bloqué, à l'exception du noeud où l'authentification s'est produite.

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

1. Stratégie Posture en attente 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 Posture en attente 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 'Conforme'.

La figure explique le fonctionnement de cette approche :

1. L'authentification touche PSN1.

2. En raison de 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 ISE AnyConnect redémarre le processus de découverte.

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

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

Meilleures pratiques d'équilibrage de charge

• Activation de l'adhérence sur LB pour l'authentification et la comptabilité à l'aide de Calling-Station-ID comme clé d'adhérence. Plus d'informations sur les meilleures pratiques de LB pour ISE ici.
• Utilisez un minuteur d'adhérence plus long qu'une journée de travail moyenne pour couvrir le moment où le PC se met en veille (par exemple 10 heures au lieu de 8 heures).
• Si la réauthentification est implémentée, utilisez le compteur de réauthentification légèrement inférieur au compteur de réauthentification (par exemple, 8 heures si la réauthentification est configurée pendant 10 heures). Cela permet de s'assurer que l'intervalle d'adhérence sera prolongé par une nouvelle authentification.

Cas d'utilisation de la position sur le VPN 

• Garantit que l'intervalle de mise à jour intermédiaire de comptabilité est supérieur ou égal à vpn-session-timeout. Cela protégera contre les battements de comptes entre les PSN sur les sessions VPN de longue durée. 

L'exemple ci-dessous montre l'intervalle de mise à jour de comptabilité provisoire configuré pour 20 heures. Cela n'empêchera pas la mise à jour intermédiaire initiale qui transporte l'adresse IP attribuée au point de terminaison.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

Les meilleures pratiques peuvent être mises en oeuvre pour minimiser l'impact de l'absence de redémarrage du module de découverte de la posture ISE

Activer le bail de position 

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

Lorsque PSN obtient une nouvelle session pour le bail de position de point de terminaison, vous pouvez l'utiliser 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 en naviguant jusqu'à Administration > System > Posture > General Settings :

• Valeur de l'attribut PostureExpiry : 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 point de terminaison après que l'administrateur ISE a activé le bail de posture. Plus tard, cette valeur a été mise à jour sur la prochaine tentative de posture réussie qui se produit après l'expiration du bail.

            Vous pouvez voir un PostureExpiry dans Visibilité contextuelle > Terminaux lors de l'ouverture d'un des terminaux en attente :

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

• Heure système PSN au moment de la nouvelle authentification

Lorsque l'authentification d'un point de terminaison avec bail de posture atteint PSN, elle utilise PostureExpiry et la date système pour obtenir un nombre de jours qui ont passé à partir de la dernière vérification de posture réussie. Si la valeur résultante se trouve dans un intervalle de bail de posture défini dans les paramètres, la session obtient un état Conforme. Si la valeur résultante 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 explique le processus en cas 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 a lieu.

4. Modification de l'état de la session en Conforme

5. Le certificat d'authenticité déclenché par le changement d'état de la position entraîne la réauthentification du point de terminaison pour appliquer le niveau d'accès suivant.

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

7. Données de point de terminaison répliquées sur l'ensemble du déploiement.

8. L'authentification suivante atteint PSN2.

9. PSN2 vérifie si le point de terminaison se trouve dans un bail de posture valide.

11. Session ajoutée au cache de session en tant que Conforme.

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

Mise en oeuvre de la réauthentification

Toujours pousser le compteur 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 peut être mis en oeuvre qui ont été 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 permet d'utiliser différents sous-réseaux à l'état En attente et Conforme, cette approche garantit que chaque changement d'état de position entraîne une modification de la passerelle par défaut.

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

L'évaluation de la posture peut être activée avec l'intervalle égal au compteur de réauthentification. Dans ce cas, lorsque le PSN d'origine n'est plus disponible, la défaillance PRA redémarre le processus de détection.

Approche moderne - Partage de l'état de posture

Dans le cadre de la mise en oeuvre d'une amélioration, décrite dans CSCvi35647 patch 6 pour ISE 2.6 a obtenu une nouvelle fonctionnalité qui met en oeuvre le partage de l'état de la position de session sur tous les noeuds dans le déploiement ISE. Cette amélioration sera également 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) qui a été introduit dans ISE 2.6. Dans les versions plus récentes, cette fonctionnalité a été renommée en Light Data Distribution (LDD) Radius Session Directory.  La distribution des données légères est activée par défaut et permet le partage d'un contexte de session limité entre les noeuds ISE. Il n'y a pas de réplication de contexte de session complète entre PSN, seulement un nombre limité d'attributs partagés pour chaque session.

L'idée principale qui sous-tend le Light Session Directory est de supprimer 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 qui est le propriétaire de la session actuelle. La recherche du propriétaire est surtout nécessaire au démarrage du flux du certificat d'authenticité. Avec LDD, chaque PSN peut trouver un propriétaire réel de la session à partir du cache du répertoire de session Radius local. 

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

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 un nombre limité d'attributs dans le cache. Exemples d'attributs stockés dans le répertoire de session Radius pour chaque session :
  
  
  • ID de session.
  • Adresse MAC du point de terminaison.
  • CallingStationID.
  • Adresse IP du point de terminaison.
  • PSN IP - PSN où l'authentification s'est produite.
  • PSN FQDN - identique à ce qui précède.
  • Adresse IP NAS.
  • Adresse IPv6 NAS.
  • État - Authentifié, Démarré, Arrêté.

• Échange RabbitMQ - Il existe un échange dans lequel Publisher, Queue correspondante et Consumer sont présentés sur chaque noeud du déploiement ISE. Cela garantit que la topologie à maillage global se forme entre tous les noeuds ISE.

• Publisher : le répertoire de session Radius représente un éditeur ici. Lorsqu'une nouvelle authentification réussie traitée par PSN 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, Radius Session Directory représente un consommateur.

Remarque : la terminologie et l'architecture générales RabbitMQ ne sont pas comprises dans ce document. 

La figure explique comment fonctionne le flux de COA 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 profilage arrivent sur PSN2.

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

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

9. Données du cache RSD utilisées pour préparer un message d'ACO proxy (un ACO qui va d'un noeud ISE à un autre, il contient tous les détails que le noeud de destination peut utiliser pour renvoyer une demande CAO à NAD). Message de certificat d'authenticité transféré en interne au PRRT Runtime (serveur AAA réel à l'intérieur d'ISE).

10. PSN2 envoie un message COA à PSN1.

11. PSN1 envoie un message COA à 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 sessions 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 devez voir comment une session a été consommé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 de l'état de la posture sur RSD

Le partage de l'état de la posture entre les noeuds résout le problème qui présente le symptôme comme 'Le module de posture ISE AnyConnect affiche conforme alors que l'état de la session sur ISE est en attente' lorsque la cause principale sous-jacente est Stale/Phantom session ou Re-authentication sur un autre PSN 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, ces informations sont placées dans la RSD de la session, et plus tard, elles peuvent être utilisées par chaque PSN dans le déploiement.

Il reste d'autres cas d'angle que la fonctionnalité décrite ne peut pas résoudre. Par exemple, un scénario où 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 gérés en mettant en oeuvre les meilleures pratiques décrites dans ce document.

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

Partage de l'état de la posture sur RSD - Session périmée/fantôme

Pour créer une authentification de session obsolète a été initialement effectuée sur skuchere-ise26-1 et NAD a été reconfiguré pour envoyer la comptabilité à skuchere-ise26-3. Une fois qu'un message de comptabilisation a été transféré au mauvais NAD PSN a été reconfiguré pour renvoyer la comptabilité à 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. Compte provisoire - Mise à jour pour la même session traitée par skuchere-ise26-3.

3. La session se termine ultérieurement sur skuchere-ise26-1.

Après un certain temps, le point de terminaison se connecte à nouveau au réseau, mais la redirection ne fonctionne plus. Dans le fichier guest.log de PSN - skuchere-ise26-3, vous pouvez voir les messages de journal suivants 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 tient une session périmée/fantôme pour le point de terminaison, il ne répond pas au module de posture ISE et cela nous permet d'obtenir la bonne réponse du PSN où s'est produite la dernière authentification.

En tant que 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 point de terminaison dans le RSD. Si 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 obsolète.

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

Pour reproduire ce scénario, un compteur de réauthentification court a été activé dans le profil d'autorisation affecté au point de terminaison dans l'état de conformité. Plus tard, NAD a été reconfiguré pour envoyer l'authentification et la comptabilité à un autre PSN (skuchere-ise26-3). À l'expiration du compteur 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 à skuchere-ise26-3 :

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

2. Certificat d'authenticité après évaluation de la posture.

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

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

La session obtient l'état conforme sur le nouveau PSN après 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 en ajoutant une logique supplémentaire au processus de sélection de l'état de la position. La figure illustre les modifications apportées (modifications surlignées en rouge) :