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 courant des services de posture ISE (Identity Service Engine) : "Le module de posture ISE AnyConnect affiche conforme..."
Ce document décrit le problème courant des services de posture ISE (Identity Service Engine) - Le module de posture ISE AnyConnect affiche conforme alors que l'état de session sur ISE est en attente.
Bien que les symptômes soient toujours les mêmes, il peut y avoir plusieurs causes profondes à ce problème.
Souvent, le dépannage d'un tel problème prend énormément de temps, ce qui a de graves conséquences.
Ce document explique :
Pour une meilleure explication des concepts décrits plus loin, reportez-vous à :
Ce problème se manifeste normalement en l'absence d'accès réseau ou de redirections constantes vers le portail de mise en service du client ISE dans le navigateur, tandis que, dans le même temps, le module de posture ISE AnyConnect affiche l'état de posture comme Conforme.
Expérience utilisateur type :
Normalement, dans le triage initial de ce problème, l'administrateur ISE effectue une enquête sur les journaux Radius Live pour s'assurer qu'il y a une authentification réelle qui atteint l'ISE.
Le premier symptôme découvert à cette étape indique une non-correspondance dans un état de posture entre le terminal et ISE comme dans les journaux en direct ou les rapports d'authentification Radius la dernière authentification réussie pour le terminal indique l'état de posture en attente.
Expérience d'administration ISE type :
Remarque : c. et d. ne sont pas toujours présentés dans les journaux en direct lorsqu'ils sont décrits dans les manifestes de problèmes. Événement de session avec état de posture Conforme est plus fréquent pour les scénarios provoqués par les sessions obsolètes ou fantômes qui sont décrites plus loin dans ce document.
Ce problème se manifeste normalement dans deux scénarios problématiques et chacun d'entre eux a plusieurs causes profondes. Les scénarios :
Pour mieux comprendre le problème, étudiez la logique de gestion des sessions ISE et le processus de détection AnyConnect requis.
Dans le déploiement ISE, deux personnes sont responsables du processus de gestion de session : PSN et Monitoring Node (MNT).
Pour dépanner et identifier correctement ce problème, il est essentiel de comprendre la théorie de la gestion des sessions sur les deux personnes.
Comme expliqué dans cette image, le noeud MNT crée des saisons en fonction des messages Syslog d'authentification passés qui proviennent des PSN.
L'état des sessions ultérieures peut être mis à jour par le Syslog pour la gestion des comptes.
La suppression de session sur MNT se produit dans 3 scénarios :
Exemples de messages Syslog de PSN. Ces messages sont consignés dans port-server.log lorsque le composant runtime-aaa est activé dans DEBUG. Les parties en gras peuvent être utilisées pour construire des expressions régulières de recherche.
Authentification réussie :
AcsLogs,2020-04-07 10:07:29,202,DEBUG,0x7fa0ada91700,cntx=0000629480,sesn=skuchere-ise26-1/375283310/10872,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:53:24.288 +02:00 0000423024 5200 NOTICE Passed-Authentication: Authentication succeeded, ConfigVersionId=87, Device IP Address=10.62.148.108, DestinationIPAddress=192.168.43.26, DestinationPort=1812, UserName=bob@example.com, Protocol=Radius, RequestLatency=45, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Service-Type=Framed, Framed-IP-Address=192.168.255.205, Framed-MTU=1472, State=37CPMSessionID=0A3E946C00000073559C0123\;42SessionID=skuchere-ise26-1/375283310/10872\;, Calling-Station-ID=00-50-56-B6-0B-C6, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, EAP-Key-Name=, cisco-av-pair=service-type=Framed, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, cisco-av-pair=client-iif-id=526638260, NetworkDeviceProfileName=Cisco, NetworkDeviceProfileId=b0699505-3150-4215-a80e-6753d45bf56c, IsThirdPartyDeviceFlow=false, RadiusFlowType=Wired802_1x, AcsSessionID=skuchere-ise26-1/375283310/10872, AuthenticationIdentityStore=EXAMPLE, AuthenticationMethod=MSCHAPV2, SelectedAccessService=Default Network Access, SelectedAuthorizationProfiles=PermitAccess, IsMachineAuthentication=false, IdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Step=11001, Step=11017, Step=15049, Step=15008, Step=15048, Step=15048, Step=15048, Step=11507, Step=12500, Step=12625, Step=11006, Step=11001, Step=11018, Step=12301, Step=12300, Step=12625, Step=11006, Step=11001, Step=11018, Step=12302, Step=12318, Step=12800, Step=12805, Step=12806, Step=12807, Step=12808, Step=12810, Step=12811, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12318, Step=12812, Step=12813, Step=12804, Step=12801, Step=12802, Step=12816, Step=12310, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12313, Step=11521, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11522, Step=11806, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11808, Step=15041, Step=22072, Step=15013, Step=24210, Step=24216, Step=15013, Step=24430, Step=24325, Step=24313, Step=24319, Step=24323, Step=24343, Step=24402, Step=22037, Step=11824, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11810, Step=11814, Step=11519, Step=12314, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=24715, Step=15036, Step=24209, Step=24211, Step=24432, Step=24325, Step=24313, Step=24319, Step=24323, Step=24355, Step=24416, Step=15048, Step=15016, Step=22081, Step=22080, Step=12306, Step=11503, Step=11002, SelectedAuthenticationIdentityStores=Internal Users, SelectedAuthenticationIdentityStores=All_AD_Join_Points, SelectedAuthenticationIdentityStores=Guest Users, AuthenticationStatus=AuthenticationPassed, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, IdentityPolicyMatchedRule=Dot1X, AuthorizationPolicyMatchedRule=Compliant-Wired, EapTunnel=PEAP, EapAuthentication=EAP-MSCHAPv2, CPMSessionID=0A3E946C00000073559C0123, EndPointMACAddress=00-50-56-B6-0B-C6, PostureAssessmentStatus=NotApplicable, EndPointMatchedProfile=Microsoft-Workstation, ISEPolicySetName=Default, IdentitySelectionMatchedRule=Dot1X, AD-User-Resolved-Identities=bob@example.com, AD-User-Candidate-Identities=bob@example.com, AD-User-Join-Point=EXAMPLE.COM, StepData=4= Radius.NAS-IP-Address, StepData=5= Cisco-VPN3000.CVPN3000/ASA/PIX7x-Tunnel-Group-Name, StepData=6= DEVICE.Device Type, StepData=77=All_User_ID_Stores, StepData=78=Internal Users, StepData=81=All_AD_Join_Points, StepData=82=All_AD_Join_Points, StepData=83=bob@example.com, StepData=84=example.com, StepData=85=example.com, StepData=87=bob@example.com, StepData=88=All_AD_Join_Points, StepData=109=EXAMPLE, StepData=110=bob@example.com, StepData=111=example.com, StepData=112=example.com, StepData=114=example.com, StepData=115=EXAMPLE, StepData=116= EXAMPLE.ExternalGroups, AD-User-Resolved-DNs=CN=bob\,CN=Users\,DC=example\,DC=com, AD-User-DNS-Domain=example.com, AD-Groups-Names=example.com/Users/Domain Users, AD-User-NetBios-Name=EXAMPLE, IsMachineIdentity=false, UserAccountControl=66048, AD-User-SamAccount-Name=bob, AD-User-Qualified-Name=bob@example.com, allowEasyWiredSession=false, TLSCipher=ECDHE-RSA-AES256-GCM-SHA384, TLSVersion=TLSv1.2, DTLSSupport=Unknown, HostIdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, IdentityAccessRestricted=false, PostureStatus=Compliant, Response={Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872; EAP-Key-Name=19:5e:8c:e9:13:0c:89:23:78:49:ad:2b:d4:31:63:51:27:81:db:e2:61:b1:51:36:6d:11:10:41:ce:3b:aa:cc:c6:66:4e:7c:92:f8:83:c5:06:84:ac:95:4c:5b:f1:b2:37:a2:f5:04:4e:9e:4d:08:79:55:b7:4d:9a:41:f5:b2:0a; MS-MPPE-Send-Key=****; MS-MPPE-Recv-Key=****; LicenseTypes=65541; },],MessageFormatter.cpp:107
Début de la comptabilisation :
AcsLogs,2020-04-07 10:07:30,202,DEBUG,0x7fa0ad68d700,cntx=0000561096,sesn=skuchere-ise26-1/375283310/10211,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 10:07:30.857 +02:00 0000382874 3000 NOTICE Radius-Accounting: RADIUS Accounting start request, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=7, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10210, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Start, Acct-Delay-Time=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Event-Timestamp=1586279242, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10211, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=15048, Step=22083, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
Mise à jour comptable provisoire :
AcsLogs,2020-04-07 22:57:48,642,DEBUG,0x7fa0adb92700,cntx=0000629843,sesn=skuchere-ise26-1/375283310/10877,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:57:48.650 +02:00 0000423268 3002 NOTICE Radius-Accounting: RADIUS Accounting watchdog update, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=8, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Interim-Update, Acct-Delay-Time=0, Acct-Input-Octets=2293926, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Input-Packets=15785, Acct-Output-Packets=0, Event-Timestamp=1586325462, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10877, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22085, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
Arrêt de la comptabilisation :
AcsLogs,2020-04-08 11:43:22,356,DEBUG,0x7fa0ad68d700,cntx=0000696242,sesn=skuchere-ise26-1/375283310/11515,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-08 11:43:22.368 +02:00 0000463071 3001 NOTICE Radius-Accounting: RADIUS Accounting stop request, ConfigVersionId=88, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=12, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/11503, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Stop, Acct-Delay-Time=0, Acct-Input-Octets=4147916, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Session-Time=92157, Acct-Input-Packets=29120, Acct-Output-Packets=0, Acct-Terminate-Cause=Lost Carrier, Event-Timestamp=1586371399, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, Framed-IPv6-Address=2001:10::100, Framed-IPv6-Address=2001:10::101, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/11515, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22084, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107
Qu'est-ce que le cache de session PSN ?
Base de données en mémoire qui stocke toutes les sessions actives d'un PSN spécifique. Le cache de session est toujours local au noeud et aucun mécanisme dans ISE ne peut effectuer la réplication de l'état de session FULL d'un noeud à un autre.
Pour chaque ID de session active, PSN stocke tous les attributs collectés pendant la phase d'authentification/autorisation, tels que les groupes d'utilisateurs internes/externes, les attributs NAD (Network Access Device), les attributs de certificat, etc. Ces attributs sont utilisés par PSN pour sélectionner différents types de stratégie tels que l'authentification, l'autorisation, l'approvisionnement client, la position.
Le cache de session est complètement supprimé lorsque les services sur le noeud ou le noeud lui-même sont redémarrés.
La logique de traitement de session actuelle crée une nouvelle entrée dans le cache de session dans deux scénarios, les détails ultérieurs des sessions existantes peuvent être mis à jour à partir des messages de comptabilité provenant des NAD :
En ce qui concerne la suppression de session, PSN met en oeuvre cette logique :
Dans le déploiement ISE, l'arrêt de la gestion des comptes pour une session existante a été traité par le PSN qui n'a pas effectué l'authentification réelle :
Exemple de session obsolète :
1. Une authentification réussie se produit sur PSN pour la session ABC.
2. PSN crée une entrée dans le cache de session.
3. L'évaluation de la posture se produit.
4. Session marquée comme Conforme.
5. Le changement d’autorisation (COA) déclenché par le changement d’état de la position entraîne une nouvelle authentification du terminal pour appliquer le niveau d’accès suivant.
6. Arrêt comptable pour la session ABC arrive sur PSN2.
Après la session de l'étape 6, ABC est bloqué dans l'état d'obsolescence sur le PSN1 car il n'y aurait pas de message d'arrêt de comptabilité traité sur ce PSN pour le supprimer. La session est supprimée pendant une longue période si le déploiement ne fait pas l'objet d'un nombre élevé de tentatives d'authentification.
La session obsolète apparaît dans le cache de session PSN dans les scénarios suivants :
Exemple de session obsolète dans l'environnement d'équilibrage de charge :
1. Authentification initiale pour la session ABC effectuée par PSN 1.
2. Cette authentification initie un compteur d'adhésion sur l'équilibreur de charge.
3. PSN 1 crée une entrée pour la session ABC dans le cache local.
4. Message Syslog pour l'authentification passée transféré au noeud MNT.
5. Entrée de la session ABC créée dans le répertoire de session MNT avec l'état Authenticated.
6. Message de début de compte pour la session ABC atterrit sur PSN 1.
7. Entrée du cache de session pour la session ABC mise à jour avec les informations de Accounting-Start.
8. Message Syslog pour Accounting-Start transféré au noeud MNT.
9. État de la session mis à jour en Démarré.
10. Le temporisateur de rémanence expire sur l'équilibreur de charge.
11. Accounting-Stop pour la session ABC transmise par l'équilibreur de charge à PSN 2.
12. Message Syslog pour Accounting-Stop transmis par PSN 2 à MNT.
13. La session ABC est marquée comme terminée sur MNT.
La session fantôme est un scénario dans lequel la mise à jour provisoire de la comptabilité arrive sur le PSN qui n'a pas effectué l'authentification pour cette session spécifique. Dans ce scénario, une nouvelle entrée est créée dans le cache de session PSN et si PSN n'obtient pas de message d'arrêt de comptabilisation pour cette session, l'entrée ne sera pas supprimée à moins que PSN n'atteigne la limite des sessions actives.
Exemple de session fantôme :
1. Les mêmes étapes que celles décrites dans l'exemple de session obsolète se produisent sur PSN1 pour la session ABC.
2. Le statut de la session ABC est Conforme dans le cache de session PSN1.
3. La mise à jour provisoire de la comptabilité pour la session ABC touche PSN2.
4. Entrée de session pour la session ABC créée sur PSN2. Depuis que l'entrée de session a été créée à partir du message de comptabilité, le nombre d'attributs est limité. Par exemple, l'état de position n'est pas disponible pour la session ABC. Des éléments tels que les groupes d'utilisateurs et d'autres attributs spécifiques d'autorisation sont également absents.
La session fantôme apparaît dans le cache de session PSN dans les scénarios suivants :
Exemple de session fantôme pour le scénario avec des problèmes temporaires sur le chemin réseau vers PSN1 :
1. Authentification initiale pour la session ABC effectuée par PSN.
2. PSN1 crée une entrée pour la session ABC dans le cache local.
3. Message Syslog pour l'authentification passée transféré au noeud MNT.
4. Entrée pour la session ABC créée dans la base de données TimesTen avec l'état Authenticated.
5. Message de début de compte pour la session ABC atterrit sur PSN 1.
6. Entrée du cache de session pour la session ABC mise à jour avec les informations de Accounting-Start.
7. Message Syslog pour Accounting-Start transféré au noeud MNT.
8. État de la session mis à jour en Démarré.
9. Mise à jour de la comptabilité provisoire pour la session ABC transmise à PSN2.
10. PSN2 crée une entrée pour la session ABC dans le cache local.
11. Accounting-Stop pour la session ABC transmise à PSN1.
12. L'entrée de la session ABC a été supprimée du cache de session sur PSN1.
13. Message Syslog pour Accounting-Stop transmis par PSN 1 à MNT.
14. La session ABC est marquée comme terminée sur MNT.
Le scénario de la session fantôme a été créé pour la connexion VPN à longue durée de vie :
1. Authentification initiale sur PSN1.
2. Session ABC créée dans le cache de session.
3. Accounting lance le message traité par le PSN.
4. Nouvelle adresse IP attribuée à l'adaptateur de réseau privé virtuel (VPN).
5. Mise à jour comptable provisoire avec informations d'adresse IP sur PSN.
6. Informations d’adresse IP ajoutées au cache de session.
7. L'évaluation de la position se produit avec PSN1.
8. État de la position mis à jour pendant la session.
9. L'émission de certificat d'authenticité exécutée par ISE déclenche l'attribution d'un nouveau niveau d'accès.
10. Panne sur le chemin réseau qui rend PSN1 inaccessible.
11. Après expiration de l'intervalle de mise à jour intermédiaire, ASA/FTD détecte que PSN1 est inaccessible.
12. Une mise à jour comptable intermédiaire est disponible sur PSN2.
13. Session fantôme créée dans le cache de session PSN2.
Si le PSN1 ultérieur devient accessible (14), tous les messages de comptabilité ultérieurs y sont transférés (15,16), ce qui laisse la session ABC dans le cache de session du PSN2 pendant une durée indéfinie.
Pour comprendre comment une session obsolète et une session fantôme rompent la position, vous pouvez consulter le processus de détection de module de position ISE AnyConnect :
Étape 1 Découverte :
Au cours de cette étape, le module de posture ISE exécute 4 problèmes simultanés pour localiser le PSN qui a effectué une authentification pour le terminal.
Premièrement, 3 sondes sur la figure sont basées sur la redirection (IP GW par défaut). Discovery host IP (si défini) et enroll.cisco.com IP) - Ces sondes pointent toujours l'agent vers le PSN droit, car l'URL de redirection est tirée du NAD lui-même.
La sonde numéro 4 est envoyée à tous les serveurs principaux présentés dans le fichier ConnectionData.xml. Ce fichier créé après la première tentative de posture réussie et le contenu du fichier ultérieur peut être mis à jour au cas où le client migre entre PSN. Sur les systèmes Windows, l'emplacement du fichier est : C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.
Puisque toutes les sondes de l'étape 1 sont exécutées simultanément, le résultat de la sonde 4 est utilisé uniquement si toutes les autres sondes 3 ont échoué ou si le module de posture ISE n'a pas pu établir une communication correcte avec PSN renvoyé dans l'URL de redirection dans les 5 secondes.
Lorsque la sonde 4 atterrit sur le PSN, elle contient une liste d'adresses IP et MAC actives découvertes sur le point d'extrémité. PSN utilise ces données pour rechercher une session pour ce point de terminaison dans le cache local. Si PSN a une session obsolète ou fantôme pour le terminal, cela peut entraîner un état de position incorrect affiché plus tard côté client.
Lorsqu'un agent obtient plusieurs réponses pour la sonde 4 (ConnectionData.xml peut contenir plusieurs PSN principaux), la réponse la plus rapide est toujours utilisée.
Étape 2 Découverte :
Toutes les sondes de détection de l'étape 2 sont sans redirection, ce qui signifie que chaque sonde déclenche une recherche de session sur le PSN de destination. Si PSN ne parvient pas à localiser la session dans le cache de session local, il doit effectuer une recherche MNT (basée uniquement sur l'adresse MAC) pour trouver un propriétaire de session et renvoyer le nom du propriétaire à l'agent.
Comme toutes les sondes déclenchent la recherche de session, la détection de l'étape 2 peut être encore plus affectée par les problèmes résultant de sessions obsolètes ou fantômes.
Si PSN passe à l'étape 2, la sonde de détection qui existe dans le cache de session crée une entrée obsolète ou fantôme pour le même terminal. Il en résulte un état de posture incorrect renvoyé à l'utilisateur final.
L'exemple montre comment la posture se produit lorsque PSN conserve une session obsolète ou une session fantôme :
Remarque : il est important de se rappeler que ce problème ne peut se manifester que lorsque toutes les sondes de détection basées sur la redirection échouent ou lorsque la position de non-redirection est implémentée.
1. L'une des sondes Find my session émises par le module de posture ISE.
2. PSN effectue une recherche de session dans le cache de session. Si la session est détectée, un problème de session obsolète ou fantôme se produit.
3. PSN exécute la sélection de stratégie de provisionnement du client. Dans ce cas, avec une session fantôme qui n'a pas d'attributs d'authentification/autorisation et toutes les stratégies configurées par le client sont très spécifiques (les stratégies sont créées pour des groupes Active Directory spécifiques, par exemple), PSN n'est pas en mesure d'attribuer une stratégie d'approvisionnement de client correcte. Cela peut se manifester par le message d'erreur suivant : « Ignorer l'analyse AnyConnect votre réseau est configuré pour utiliser Cisco NAC Agent ».
4. Pour le scénario de session fantôme, le module de posture ISE continue avec la demande de posture initiale. Cette demande contient des informations sur tous les produits de sécurité et de gestion des correctifs détectés sur le terminal.
5. PSN utilise les informations des attributs de requête et de session pour correspondre à la stratégie de position appropriée. Étant donné que la session fantôme ne dispose pas d'attributs à ce stade, nous n'avons pas de stratégie à mettre en correspondance. Dans ce cas, PSN répond au terminal qu'il est conforme, car il s'agit d'un comportement ISE par défaut en cas de non-correspondance de stratégie de position.
Remarque : lorsqu'une stratégie générique peut être sélectionnée à partir des attributs de session fantôme, passez à l'étape 6.
6. PSN renvoie les politiques de posture sélectionnées à l'agent.
Remarque : lorsqu'aucune stratégie ne peut être sélectionnée, PSN renvoie le statut Conforme.
7. L'agent retourne des statuts pour chaque règle/condition telle que réussie ou échouée.
8. L'évaluation du rapport se produit sur ISE et les changements d'état de session sur Conforme.
Remarque : en cas de problèmes de position causés par la session fantôme, l'administrateur ISE peut remarquer certains certificats d'authenticité de position ayant échoué, car dans ce cas, les demandes de certificat d'authenticité sont exécutées à partir de PSN et d'ID de session incorrects.
Module de posture ISE conçu pour surveiller un nombre limité d'événements sur le terminal afin de déclencher un processus de détection. Liste des événements qui déclenchent la détection :
Le module de posture ISE ne détecte pas la nouvelle authentification dot1x, le déverrouillage du PC ou le changement d'adresse IP.
Le module de posture ISE ne peut pas détecter une nouvelle tentative d'authentification ou de réauthentification dans les scénarios suivants :
Exemple de nouvelle authentification sur un PSN différent causée par la panne du PSN d'origine. Le scénario avec équilibreur de charge est très similaire. Dans le cas de LB, réauthentification dirigée vers le PSN différent à la suite de l'expiration du minuteur d'adhésion.
1. Authentification initiale sur PSN1.
2. Session ABC créée dans le cache de session PSN1.
3. Évaluation de la position effectuée avec PSN1.
4. Le statut de la position ABS de session passe à Conforme.
5. Le certificat d'authenticité déclenché par un changement d'état de position entraîne une nouvelle authentification du terminal pour appliquer le niveau d'accès suivant.
6. PSN1 devient indisponible.
7. La réauthentification de la session ABC est effectuée sur PSN2.
8. Puisqu'il s'agit d'une nouvelle session pour l'état de position PSN2 de la session devient En attente.
État de la position initiale attribué par PSN à la session :
Remarque : State-machine décrit uniquement une sélection initiale de l'état de posture. Chaque session initialement marquée comme Inconnue peut devenir plus tard Conforme ou Non Conforme en fonction de l'évaluation du rapport reçue du module de posture ISE.
Cela peut 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 qu'ISE PSN place toujours une nouvelle session dans l'état de position en attente, à moins que le bail de position ne soit configuré. Le bail de posture est décrit plus loin dans ce document.
Pour déterminer si AnyConnect est conforme lorsque l’état de redirection est dû à une session obsolète/fantôme, nous devons accéder au point d’extrémité lorsqu’il est à l’état problématique.
1. Appuyez sur l'icône de rapport dans l'interface utilisateur AnyConnect
2. Dans la nouvelle fenêtre, accédez à l'onglet Analyse système et au sous-onglet Statistiques
Dans ce cas, tenez compte de deux éléments :
Dans l'exemple donné, il y a une incohérence entre le nom qui est indiqué que PSN avec le nom ciscolive-ise2 détient une session obsolète ou fantôme pour ce terminal.
La démonstration montre l'enregistrement des étapes nécessaires à l'identification du problème :
L'exemple précédent est de différencier le problème d'une session obsolète ou fantôme du problème du processus de découverte qui n'a pas démarré. En même temps, nous devons identifier la session qui a déclenché le problème pour mieux comprendre comment exactement il devient un problème de session obsolète ou fantôme.
Bien que dans certains scénarios, les sessions obsolètes et fantômes ne peuvent pas être évitées. Nous devons nous assurer qu'il n'y a pas de sessions obsolètes/fantômes créées dans l'environnement en raison de certaines des meilleures pratiques qui ne sont pas mises en oeuvre.
Analysez un bundle DART pris à partir du terminal qui reproduit le problème.
Pour ce faire, l'utilitaire d'offre groupée DART doit démarrer en tant qu'administrateur et effectuer un nettoyage des journaux.
Une fois l'ensemble DART collecté, nous devons le désarchiver et nous concentrer sur le fichier AnyConnect_ISEPosture.txt situé dans le dossier Cisco AnyConnect ISE Posture Module. Ce fichier contient tous les événements liés à la détection.
1. Commencez le dépannage et identifiez tous les moments de redémarrage de la détection. Les mots clés à rechercher sont Redémarrage de la détection ou Détection HTTP. Dans ce cas, accédez à la ligne avec le redémarrage de la détection qui s'est produit au moment problématique :
2. Quelques lignes après le redémarrage de la détection, vous voyez une ligne qui contient : Sondage sur les cibles de stade MNT. Il s'agit d'un indicateur de début de détection de l'étape 1 :
Il est recommandé de mettre en surbrillance toutes les sondes basées sur la redirection avec la même couleur alors que les PSN précédemment connectés pris de ConnectionData.xml (Auth-Status cibles) doivent être mis en surbrillance dans des couleurs différentes car normalement les FQDN PSN sont très similaires et il est difficile de repérer la différence.
3. Lisez les fichiers journaux pour voir un résultat pour chaque sonde unique. Comme cela a déjà été dit dans le cas du problème causé par une session obsolète/fantôme, toutes les sondes basées sur la redirection doivent échouer. Voici un exemple de l'aspect de la sonde défaillante :
4. Quelque part dans le fichier après le redémarrage de détection pour l'étape 1 ou l'étape 2, vous voyez une réponse réussie d'un ou plusieurs PSN :
5. Quelques lignes plus loin, il y a une ligne avec le mot clé MSG_NS_SWISS_NEW_SESSION. Cette ligne contient un ID de session réel qui a été sélectionné par PSN à la suite de la recherche de session. Utilisez cet ID de session pour approfondir vos recherches sur ISE et découvrir comment cette session devient obsolète/fantôme :
Dans le fichier guest.log avec le composant clientwebapp activé dans DEBUG, le PSN qui répond avec la session Stale/Phantom peut être vu.
PSN reçoit une demande de l'agent de posture ISE. Vous pouvez voir qu'il s'agit d'une demande d'AnyConnect en raison de la valeur User-Agent :
cisco.cpm.client.posture.PostureStatusServlet -::- Got http request from 192.168.255.228 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.6.03049)
cisco.cpm.client.posture.PostureStatusServlet -::- mac_list from http request ==> C0:4A:00:1F:6B:39
cisco.cpm.client.posture.PostureStatusServlet -::- iplist from http request ==> 192.168.255.228
cisco.cpm.client.posture.PostureStatusServlet -::- Session id from http request - req.getParameter(sessionId) ==> null
La requête contient des tableaux d'adresses IP et d'adresses MAC. Dans cet exemple particulier, chaque tableau ne contient qu'une seule valeur. Le journal montre également que l'ID de session de la demande est null, ce qui indique qu'il s'agit d'une demande provenant de la sonde non basée sur la redirection.
Vous pourrez voir plus tard comment les valeurs des tableaux sont utilisées pour localiser un ID de session :
cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently processed in the for loop ==> 192.168.255.228
cpm.client.provisioning.utils.ProvisioningUtil -::- the ipAddress that matched the http request remote address ==> 192.168.255.228
cpm.client.provisioning.utils.ProvisioningUtil -::- the clientMac from the macarray list for the for loop index matching the ipAddress list index ==> C0-4A-00-1F-6B-39
cisco.cpm.client.posture.PostureStatusServlet -::- Found Client IP matching the remote IP 192.168.255.228, corresponding mac address C0-4A-00-1F-6B-39
cpm.client.provisioning.utils.ProvisioningUtil -::- Session = 0a3e949c000000495c216240
Après la ligne avec les mots-clés Sent http response, vous pouvez voir le contenu de la réponse réelle :
cisco.cpm.client.posture.PostureStatusServlet -::- Sent an http response to 192.168.255.228 with X-ISE-PDP=clemea19-ise1.demo.local.
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP value is clemea19-ise1.demo.local
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE value is /auth/perfigo_validate.jsp
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_PORT value is 8443
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_PORT value is 8443
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-GUESTFLOW value is false
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URL value is https://clemea19-ise1.demo.local:8443/auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URI value is /auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URL value is https://clemea19-ise1.demo.local:8443/auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URI value is /auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_VER value is 4.6.3049.0
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-STATUS_PATH value is /auth/status
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-BACKUP_SERVERS value is clemea19-ise2.demo.local
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-SessionId value is 0a3e949c000000495c216240
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PostureDomain value is posture_domain
cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_STATUS value is Unknown
Une fois que vous connaissez l'ID de la session obsolète/fantôme, vous pouvez examiner le rapport Radius Accounting pour mieux comprendre ce qui a provoqué l'obsolescence/fantôme de cette session :
Exemple d'un rapport qui montre comment une session obsolète a été laissée sur ciscolive-ise2 :
Ici, la même logique est applicable que pour le numéro précédent. La seule différence est que vous devez vous concentrer sur l'heure de début de la dernière analyse. Pour ce type de problème, l'horodatage de la dernière analyse est quelque part dans le passé.
Normalement, lorsque l'utilisateur final découvre un problème, une analyse qui s'est produite il y a quelque temps est observée. Dans les journaux ISE Radius Live, les tentatives d'authentification récentes du point d'extrémité problématique sont visibles.
La démonstration montre l'enregistrement des étapes nécessaires à l'identification du problème :
L'approche ici est très similaire à la section Advanced Troubleshoot Stale/Phantom Session. Le principal élément de dépannage est l'étude du bundle DART. À l'intérieur du bundle DART, vous pouvez rechercher des redémarrages de détection comme cela a été indiqué pour le problème précédent et confirmer qu'il n'y avait pas de redémarrage de détection au moment où le problème a été signalé.
Côté ISE, concentrez-vous sur le rapport Radius Live Logs/Radius authentication pour confirmer qu'il y a eu un basculement entre PSN ou qu'un nouvel ID de session a été généré par NAD.
Historiquement, aucune fonctionnalité d'ISE ne permettait de résoudre les problèmes décrits dans ce document. Par conséquent, la seule façon de procéder consistait à s'appuyer sur l'ensemble des meilleures pratiques mises en oeuvre sur le réseau et à minimiser les risques du côté d'ISE.
Toujours implémenter une posture basée sur la redirection si possible
Une mauvaise expérience de l'utilisateur est un argument souvent invoqué pour justifier cette recommandation, car des fenêtres contextuelles apparaissent dans le système d'exploitation ou les navigateurs, indiquant une redirection, tandis que le module de posture AnyConnect ISE effectue un processus d'évaluation en arrière-plan.
Pour résoudre ce problème, il est possible de rediriger UNIQUEMENT les sondes de détection de module de posture ISE et d'autoriser sélectivement tout autre trafic.
L'exemple montre une liste de contrôle d'accès de redirection conçue pour rediriger uniquement les requêtes HTTP vers l'hôte de découverte (10.1.1.1 dans cet exemple) et enroll.cisco.com (172.16.1.80) :
ip access-list extended REDIRECT-DH-ENROLL
permit tcp any host 10.1.1.1 eq www
permit tcp any host 172.16.1.80
deny ip any any
Pour maintenir un niveau de sécurité acceptable, une telle liste de contrôle d’accès de redirection peut être combinée à une liste DACL attribuée par ISE.
L'état En attente autorise uniquement les connexions à PSN lorsque le point de terminaison a été authentifié
Cette approche est utile pour les environnements où la redirection d'URL n'est pas prise en charge (par exemple, les implémentations avec les NAD tiers).
Comme solution, vous devez implémenter plusieurs stratégies d'autorisation PosturePending (une par PSN). Chaque stratégie doit contenir comme l'une des conditions le nom du PSN où l'authentification a eu lieu. Dans le profil d'autorisation affecté à chaque stratégie, l'accès à tous les PSN doit être bloqué, sauf au noeud où l'authentification a eu lieu.
Créer des politiques d'autorisation pour le déploiement de 2 noeuds :
1. Stratégie de mise en attente de position pour PSN1.
2. Nom PSN1 utilisé comme condition dans la stratégie.
3. Profil d'autorisation avec ACL qui bloque l'accès à tous les PSN à l'exception de PSN1.
4. Stratégie de mise en attente de position pour PSN2.
5. Nom PSN2 utilisé comme condition dans la stratégie.
6. Profil d'autorisation avec ACL qui bloque l'accès à tous les PSN à l'exception de PSN2.
7. Politique d’autorisation de la position « conforme ».
La figure explique le fonctionnement de cette approche :
1. L'authentification atteint PSN1.
2. En raison des stratégies d'autorisation configurées, PSN1 attribue un profil d'autorisation qui bloque l'accès à tous les autres noeuds à l'exception de PSN1.
3. Le module de posture AnyConnect ISE redémarre le processus de détection.
4. Sonde vers PSN2 bloquée par le NAD comme par une liste de contrôle d'accès attribuée précédemment.
5. Sonde vers PSN1 autorisée par l'ACL attribuée sur NAD.
Meilleures pratiques des équilibreurs de charge
Cas d'utilisation de Posture Over VPN
Cet exemple montre l'intervalle de mise à jour de la comptabilité intermédiaire configuré pour 20 heures. Cela n'empêche pas la mise à jour intermédiaire initiale qui transporte l'adresse IP attribuée au point d'extrémité.
aaa-server ISE protocol radius
interim-accounting-update periodic 20
group-policy SSL-VPN attributes
vpn-idle-timeout 1200
vpn-session-timeout 1200
Activer le bail de position
Il s'agit d'une fonctionnalité d'ISE qui marque le terminal comme étant conforme pendant une période définie (1 à 365 jours). La valeur de bail de position est un attribut de point d'extrémité, ce qui signifie qu'elle est stockée dans la base de données ISE. Tous les attributs de point d'extrémité qui incluent le bail de position sont répliqués sur tous les noeuds du déploiement ISE.
Lorsque PSN obtient une nouvelle session pour la position du terminal, le bail peut être utilisé pour marquer la session comme conforme immédiatement.
Pour prendre cette décision, PSN utilise 3 valeurs. Ces valeurs sont les suivantes :
Vous pouvez voir un PostureExpiry dans Context Visibility > Endpoints pendant que l'un des terminaux affichés est ouvert :
Cette valeur peut être convertie en l'horodatage lisible par l'homme, par exemple ici - https://www.epochconverter.com/
Lorsque l'authentification d'un terminal avec posture lease atteint PSN, il utilise PostureExpiry et la date système pour obtenir un nombre de jours qui se sont écoulés depuis la dernière vérification de posture réussie. Si la valeur de résultat est comprise dans un intervalle de bail de position défini dans les paramètres, la session obtient un état Conforme. Si la valeur du résultat est supérieure à la valeur du bail, la session obtient un état Inconnu. Cela déclenche la posture à exécuter à nouveau et une nouvelle valeur PostureExpiry peut être enregistrée.
La figure ci-contre explique le processus de basculement :
1. L'authentification initiale se produit avec PSN1.
2. Session ABC créée dans le cache de session.
3. L'évaluation de la posture se produit.
4. Changements d'état de session en Conforme
5. Le certificat d'authenticité déclenché par un changement d'état de position entraîne une nouvelle authentification du terminal pour appliquer le niveau d'accès suivant.
6. Valeur PostureExpiry enregistrée dans le point de terminaison.
7. Réplication des données des terminaux sur l'ensemble du déploiement.
8. La prochaine authentification atteint PSN2.
9. PSN2 vérifie si le point d'extrémité se trouve dans un bail de position valide.
11. La session a été ajoutée au cache de session en tant que conforme.
12. En raison de la validité du bail, la session a été créée avec le statut de posture Conforme.
Implémentation de la réauthentification
Toujours pousser le minuteur de réauthentification à partir d'ISE avec RADIUS-Request sélectionné dans Maintenir la connectivité pendant la réauthentification. Ce paramètre garantit que NAD conserve le même ID de session lors de la réauthentification.
.
Environnements avec équilibreurs de charge
Il est possible de mettre en oeuvre le même ensemble de meilleures pratiques que celles expliquées dans la section relative aux sessions obsolètes/fantômes.
Différents sous-réseaux peuvent être utilisés pour les états En attente et Conforme
Lorsque la conception du réseau offre la possibilité d'utiliser différents états de sous-réseaux En attente et Conforme, cette approche garantit que chaque changement d'état entraîne un changement de passerelle par défaut.
Évaluation de la position utilisée dans le même intervalle qu'un minuteur de réauthentification
L'évaluation de la position peut être activée avec un intervalle égal au minuteur de réauthentification. Dans ce cas, lorsque le PSN d'origine devient indisponible, l'échec PRA redémarre le processus de détection.
Dans le cadre d'une amélioration implémentée, décrite dans l'ID de bogue Cisco CSCvi35647patch 6 pour ISE 2.6 a obtenu une nouvelle fonctionnalité qui implémente le partage de l'état de la position de session sur tous les noeuds dans le déploiement ISE. Cette amélioration est intégrée dans les versions futures : ISE 2.7 correctifs 2 et ISE 3.0.
Cette nouvelle fonctionnalité est basée sur le mécanisme LSD (Light Session Directory) introduit dans ISE 2.6. Dans les versions plus récentes, cette fonctionnalité a été renommée en répertoire de session Radius LDD (Light Data Distribution). Light Data Distribution est activé par défaut et permet le partage d'un contexte de session limité entre les noeuds ISE. Il n'existe pas de réplication de contexte de session complète entre PSN, seulement une quantité limitée d'attributs partagés pour chaque session.
L'idée principale derrière Light Session Directory est de supprimer le besoin d'exécuter des appels d'API coûteux en ressources vers MNT quand l'un des noeuds dans le déploiement doit déterminer qui est le propriétaire actuel de la session. La recherche du propriétaire est généralement nécessaire lorsque le flux de certificat d'authenticité démarre. Avec LDD, chaque PSN peut trouver un propriétaire réel de la session à partir du cache local du répertoire de session Radius.
Cette fonctionnalité contient les éléments suivants :
Remarque : la terminologie et l'architecture de General RabbitMQ ne sont pas abordées dans ce document.
La figure explique comment le flux COA fonctionne avec le cache RSD :
1. L'authentification initiale se produit avec PSN1.
2. Session ABC créée dans le cache de session.
3. Les attributs requis sont enregistrés dans RSD.
4. Session partagée sur RabbitMQ avec tous les autres noeuds ISE.
5. La session est créée dans le cache RSD sur tous les noeuds ISE.
6. De nouvelles données de profil arrivent sur PSN2.
7. Le terminal est reprofilé et, en cas de modification nécessitant l'exécution du certificat d'authenticité, PSN2 passe à l'étape suivante.
8. Appel API interne soumis au cache RSD pour exécuter le certificat d'authenticité.
9. Données provenant du cache RSD utilisées pour préparer un message Proxy COA (un COA qui va d’un noeud ISE à un autre, il contient tous les détails que le noeud de destination peut utiliser pour émettre une requête CAO de retour à NAD). Le message de certificat d'authenticité est d'abord transféré en interne vers PRRT Runtime (serveur AAA réel dans ISE).
10. PSN2 envoie un message de certificat d'authenticité à PSN1.
11. PSN1 envoie un message de certificat d'authenticité à NAD.
Pour dépanner la communication sur LDD sur l'ISE, vous pouvez activer le composant Light Session Director dans DEBUG :
exemple de message de débogage du fichier lsd.log pour la création et la publication de session sur le PSN d'origine :
DEBUG [pool-45-thread-6][] cisco.cpm.lsd.service.LSDRedisClient -::::- Mapping Session ID 0a3e9498000008e05e071990 to session {"sessionID":"0a3e9498000008e05e071990","endpointMAC":"C0-4A-00-1F-6B-39","callingStationId":"c0-4a-00-1f-6b-39","ipv6AdressLst":[],"psnIP":"192.168.43.26","deviceIP":"192.168.255.102","destinationIP":"192.168.43.26","nasIP":"192.168.255.102","auditSessionID":"0a3e9498000008e05e071990","acctSessionID":"5e07197b/c0:4a:00:1f:6b:39/2299","timeStamp":1577523495,"status":"Started","id":"614f6c44-6c78-4289-b9fd-b352ff012ca4"}
DEBUG [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.LSDNetAccessEventListener -::::- Publishing session update for session 0a3e9498000008e05e071990
DEBUG [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.SessionPublisher -::::- Forwarding session 07a26b4b-ea13-438b-99b5-0bbadc9d8bac to batch manager
Sur tous les autres noeuds ISE, vous voyez comment une session a été utilisée :
[pool-35-thread-38][] cisco.cpm.lsd.service.SessionConsumer -::::- Consumer is processing : sessionID:[0a3e9498000008e05e071990] status:[Started] id:[614f6c44-6c78-4289-b9fd-b352ff012ca4] auditSessionID:[0a3e9498000008e05e071990] accountingSessionID:[5e07197b/c0:4a:00:1f:6b:39/2299] endpointMAC:[C0-4A-00-1F-6B-39] callingStationId: [c0-4a-00-1f-6b-39] endpointIP:[null], IPv6 : [[]], psnIP:[192.168.43.26] deviceIP:[192.168.255.102] destinationIP:[192.168.43.26] nasIP:[192.168.255.102] nasIPv6:[null] timeStamp:[1577523495]
Le partage de l'état de la position entre les noeuds résout le problème qui présente le symptôme comme « Le module de position AnyConnect ISE montre qu'il est conforme alors que l'état de la session sur ISE est en attente » lorsque la cause principale est soit une session obsolète/fantôme, soit une ré-authentification sur un PSN différent avec un ID de session d'origine qui n'a pas déclenché le redémarrage de la découverte. Dès que la session devient conforme, cette information est placée dans la session RSD, et plus tard elle peut être utilisée par chaque PSN dans le déploiement.
Il y a encore d'autres cas d'angle que la fonction décrite ne peut pas résoudre. Par exemple, un scénario dans lequel NAD exécute une nouvelle authentification sur le même PSN mais avec un ID de session différent. De tels scénarios peuvent être traités à l'aide des meilleures pratiques décrites dans ce document.
La figure illustre la topologie utilisée pour tester le partage de l'état de position :
Pour créer une session obsolète, l'authentification a été initialement effectuée sur skuchere-ise26-1 et NAD a été reconfiguré ultérieurement pour envoyer la comptabilité à skuchere-ise26-3. Une fois qu'un message de gestion des comptes a été transféré au PSN NAD incorrect, il a été reconfiguré pour renvoyer la gestion des comptes à skuchere-ise26-1.
La figure illustre un rapport comptable qui prouve la présence de la session fantôme sur skuchere-ise26-3 :
1. Messages Accounting-Start traités par skuchere-ise26-1.
2. Comptabilité provisoire - Mise à jour pour la même session traitée par skuchere-ise26-3.
3. La session se termine plus tard sur skuchere-ise26-1.
Après un certain temps, le point de terminaison se connecte de nouveau au réseau, mais la redirection ne fonctionne plus. Dans le journal guest.log de PSN - skuchere-ise26-3, vous pouvez voir ces messages de journal avec le composant client-webapp activé dans DEBUG :
2020-04-08 13:30:48,217 DEBUG [https-jsse-nio-192.168.43.226-8443-exec-4][] cisco.cpm.client.posture.Util -::- Local session 0A3E946C0000007D5B679296 is stale. Newer session for 00-50-56-B6-0B-C6 is 0A3E946C000000805B7C43A3. Owned by skuchere-ise26-1.example.com
Lorsque PSN détecte qu'il détient une session obsolète/fantôme pour le terminal, il ne répond pas au module de posture ISE et cela nous permet d'obtenir la bonne réponse du PSN où la dernière authentification a eu lieu.
Comme solution au problème de session obsolète/fantôme maintenant au moment de la recherche de session, PSN vérifie la présence de toute nouvelle session pour le terminal dans le RSD. Dans le cas où RSD contient un ID de session différent de celui de PSN dans le cache de session local, il suppose que la session présentée dans le cache de session est périmée.
Pour reproduire ce scénario, un temporisateur de réauthentification court a été activé dans le profil d'autorisation affecté au point d'extrémité dans l'état conforme. Plus tard, NAD a été reconfiguré pour envoyer l'authentification et la comptabilité à un autre PSN (skuchere-ise26-3). À l'expiration du minuteur de réauthentification, la même session n'a pas été authentifiée sur le PSN différent.
La figure illustre un rapport d'authentification qui montre le basculement pour la session saine de skuchere-ise26-1 vers skuchere-ise26-3 :
1. L'authentification se produit sur skuchere-ise26-1, le profil d'autorisation avec redirection est attribué.
2. L'ACO après une évaluation de posture réussie.
3. Authentification suivante lorsque le profil d'autorisation pour l'état conforme est attribué.
4. L'authentification atteint un PSN différent, mais elle obtient toujours le profil d'autorisation pour l'état conforme.
La session obtient l'état de conformité sur le nouveau PSN après le basculement dans ise-psc.log avec les composants epm-pip et nsf-session activés dans DEBUG :
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045 for attribute Session Session.PostureStatus
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.PIPManager -::::- Returning a PIP com.cisco.cpm.nsf.session.impl.SessionPIP for type SESSION and flow null
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [SessionLifecycleNotifier][] cpm.nsf.session.internal.LRUAgingAlogrithm -::::- Accessed session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Returning for session 0A3E946C000000896011D045 data Attrs: {SavedUserNames=[bob@example.com], Acs.LastStepTime=1586423202174, Acs.AD-User-Qualified-Name=bob@example.com, Acs.AD-User-Resolved-DNs=CN=bob,CN=Users,DC=example,DC=com, Acs.StepData=[110=EXAMPLE, 111=bob@example.com, 112=example.com, 113=example.com, 115=example.com, 116=EXAMPLE], Acs.AD-Log-Id=[1585911138/4778, 1585911138/4779], __IntIdGrps__=[Ljava.lang.String;@6d3c29b5, IdentityGroup.Description=[Ljava.lang.String;@3fca88fb, EXAMPLE.ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, Acs.AD-Groups-Names=example.com/Users/Domain Users, Acs.AuthenCPMSessionID=0A3E946C000000896011D045, Acs.IsMachineAuthentication=false, InternalEndpoint.IdentityGroup=[Ljava.lang.String;@6daf4c5, IDStoreUserQueryCache=[EXAMPLE#bob@example.com], Acs.CurrentIDStoreName=EXAMPLE, Acs.AD-User-Join-Point=EXAMPLE.COM, Acs.Step=[24432, 24325, 24313, 24319, 24323, 24355, 24416], Acs.CustomerMessageDuplicator=, Network Access.WasMachineAuthenticated=false, IdentityGroup.Name=[Ljava.lang.String;@570ab37a, Acs.StepDataStart=110, Acs.AD-User-DNS-Domain=example.com, Network Access.AuthenticationMethod=4, Acs.AD-User-Resolved-Identities=bob@example.com, InternalUser.IdentityGroup=[Ljava.lang.String;@51a6caed, Acs.AuthenticationMethod=4, Acs.AD-User-NetBios-Name=EXAMPLE, Normalised Radius.RadiusFlowType=0, Network Access.AuthenticationIdentityStore=EXAMPLE, EXAMPLE.IdentityAccessRestricted=false, Acs.AD-User-SamAccount-Name=bob}
IndexValues: {}
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- set postureStatus based on posture LSD dictionary: Compliant
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- PostureStatusPIP for mac 00-50-56-B6-0B-C6 - Attribute Session.PostureStatus value is Compliant
Le problème initial a été résolu avec l'ajout d'une logique supplémentaire dans le processus de sélection de l'état de posture. La figure illustre ce qui a été modifié (les modifications sont surlignées en rouge) :
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
31-May-2023 |
Recertification |
1.0 |
22-Apr-2020 |
Première publication |