Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
Ce document explique :
Pour mieux comprendre les concepts décrits plus loin, il est recommandé de passer en revue les points suivants :
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 :
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 :
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.
Ce problème se manifeste normalement dans deux scénarios problématiques et chacun d'eux peut avoir plusieurs causes profondes. Les scénarios :
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.
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.
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 :
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
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 :
Lorsqu'il s'agit de supprimer une session, PSN implémente la logique suivante :
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 :
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.
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 :
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.
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 ».
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.
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 :
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 :
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.
Cela pourrait se produire dans les deux scénarios les plus courants :
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.
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. 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 :
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 :
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.
Analyser un bundle DART extrait du point de terminaison qui reproduit le problème.
Pour ce faire, l'utilitaire DART doit démarrer en tant qu'administrateur et effectuer le nettoyage des journaux.
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 :
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
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 :
Exemple de rapport montrant comment une session obsolète a été abandonnée sur ciscolive-ise2 :
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 :
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.
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.
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.
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.
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
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 :
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/
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.
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.
.
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.
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.
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.
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.
Cette fonctionnalité contient les éléments suivants :
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]
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 :
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.
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) :