Problemen met ISE-sessiebeheer en -houding oplossen

Downloadopties

  • PDF     (2.1 MB)
    Met Adobe Reader op diverse apparaten bekijken
Bijgewerkt:25 augustus 2026
Document-id:215419

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

voorbeeld
Inleiding
Achtergrondinformatie
Probleem
eindgebruikerservaring
ISE Admin Experience
Gemeenschappelijke problematische scenario's
Probleem met verouderde/fantoomsessie
ISE Session Management Logic
MNT- en sessiebeheer
PSN en sessiebeheer
Verouderde sessie op PSN
Phantom-sessie op de PSN
Hoe Stale Session en Phantom Session het Posture-proces doorbreken
Ontdekkingsproces start niet bij een nieuwe verificatiepoging
Reauthenticatie op verschillende PSN
NAD genereert nieuwe sessie-ID bij herverificatie
Snelle manieren om te identificeren wanneer een probleem werd veroorzaakt door de Stale / Phantom-sessie
Voorafgaande probleemoplossing van een verouderde/fantoomsessie
DART-bundelcollectie
DART-bundelanalyse
Onderzoek naar ISE-logboeken
Onderzoek naar ISE-rapporten
Hoe te identificeren wanneer een probleem werd veroorzaakt door de afwezigheid van een Discovery Restart
Geavanceerde probleemoplossing: de afwezigheid van herstart van de detectie
Oplossing
Klassieke aanpak - probleemvermijding
Best practices die het aantal verouderde of fantoomsessies in de ISE-implementatie kunnen minimaliseren
Houding over VPN-use-case
Best practices kunnen worden geïmplementeerd om de impact van de afwezigheid van ISE-posturemodule Discovery Restart te minimaliseren
Implementatie van herverificatie
Omgevingen met load balancers
Moderne aanpak - posture state sharing
lichtgegevensdistributiearchitectuur
Houdingsstatus delen via RSD
Houdingsstatus delen via RSD - Stale/Phantom-sessie
Houdingsstatus delen via RSD - failover tussen PSN's

Inleiding

In dit document wordt het algemene probleem met de postuur-services van de Identity Service Engine (ISE) beschreven, zoals "AnyConnect ISE-postuur-module toont compatibel..."

Achtergrondinformatie

In dit document wordt het algemene probleem van de postuur-service-engine (ISE) voor identiteitsservice beschreven: "AnyConnect ISE-postuur-module geeft aan dat deze voldoet aan de eisen, terwijl de sessiestatus op ISE in behandeling is."

Hoewel de symptomen altijd hetzelfde zijn, zijn er meerdere oorzaken van dit probleem. Vaak wordt het oplossen van een probleem als dit extreem tijdrovend, wat ernstige gevolgen heeft.

Dit document legt uit:

  • Veel voorkomende problematische scenario’s.
  • Algoritmes voor snelle probleemidentificatie.
  • Klassieke oplossingen voor veelvoorkomende problematische scenario’s.
  • Houdingsstatus delen via de Radius-sessiemap.
  • Probleemmanifestatie vanuit het perspectief van eindgebruikers en ISE-beheerders.
  • De theorie achter ISE, AnyConnect en netwerkbewerkingen die het probleem veroorzaakt.

Voor een betere uitleg van de concepten die later worden beschreven, raadpleegt u ISE Posture Style Comparison for Pre and Post 2.2

Probleem

eindgebruikerservaring

Dit probleem manifesteert zich normaal gesproken in de afwezigheid van netwerktoegang of constante omleiding naar het ISE-clientprovideringsportaal in de browser, terwijl de AnyConnect ISE-posturingmodule tegelijkertijd de posturingstatus als compliant toont.

Typische eindgebruikerservaring:

Client Provisioning Portal

ISE Admin Experience

Wanneer dit probleem in eerste instantie wordt geactiveerd, begint een ISE-beheerder een onderzoek naar de Radius Live-logboeken om ervoor te zorgen dat een verificatie ISE raakt. Het eerste symptoom dat in deze fase werd ontdekt, duidt op een mismatch in een postuur tussen het eindpunt en ISE in de live logs. Of, de Radius-verificatierapporten voor de laatste succesvolle verificatie voor het eindpunt tonen de status van de wachtende houding.

Typische ISE Admin ervaring:

Client Provisioning Portal 2

  • Laatste succesvolle authenticatie voor Identity: Alice.
  • De status van de sessie is in behandeling.
  • Laatste sessie voor Identity: Alice.
  • De sessiegebeurtenis toont de status van de houding als compliant.

Opmerking: In het voorbeeld worden C en D niet altijd weergegeven in de live logs wanneer het beschreven probleem zich manifesteert. Een sessiegebeurtenis met een postuur status van Compliant is gebruikelijker voor scenario's die worden veroorzaakt door de verouderde of fantoomsessies (die later in dit document worden beschreven).

Gemeenschappelijke problematische scenario's

Dit probleem manifesteert zich normaal gesproken in twee problematische scenario's en elk van hen heeft meerdere onderliggende oorzaken. De scenario's:

  • De AnyConnect ISE-posturingmodule is tijdens het posturatieproces verkeerd geïnformeerd door de PSN (Policy Service Node), waardoor de verkeerde posturingstatus werd weergegeven. In dit geval werkt TAC normaal gesproken met een verouderde of fantoomsessie in de PSN-sessiecache.
  • AnyConnect ISE toont de status van de vorige opsporingscyclus omdat de huidige verificatie geen detectieproces heeft geactiveerd.

De ISE-posturingmodule in AnyConnect heeft een beperkt aantal gebeurtenissen die het detectieproces activeren. Het is mogelijk dat tijdens authenticatie of re-authenticatie geen van deze gebeurtenissen werd gedetecteerd.

Probleem met verouderde/fantoomsessie

Om het probleem beter te begrijpen, moet u de vereiste ISE-sessiebeheerlogica en het detectieproces van AnyConnect onderzoeken.

ISE Session Management Logic

Bij de implementatie van ISE zijn er twee personen verantwoordelijk voor het sessiebeheerproces: PSN en Monitoring Node (MNT). Om het probleem goed op te lossen en te identificeren, is het van cruciaal belang om de theorie van sessiemanagement op beide persona's te begrijpen.

MNT- en sessiebeheer

Client Provisioning Portal 3

Zoals uitgelegd in deze afbeelding, maakt de MNT-node seizoenen op basis van de doorgegeven authenticatie Syslog-berichten die afkomstig zijn van PSN's. De sessiestatus kan later worden bijgewerkt door de Syslog for accounting.

Sessieverwijdering op MNT gebeurt in drie scenario's:

1. Sessies zonder boekhouding worden ongeveer 60 minuten nadat ze zijn gemaakt verwijderd. Er wordt elke 5 minuten een cron-taak uitgevoerd om de sessiestatus te controleren en schoon te maken.

2. Beëindigde sessie verwijderd ongeveer 15 minuten nadat de boekhoudstop is verwerkt door dezelfde cron-taak.

3. Dezelfde cron op elke uitvoering verwijdert sessies in de 'Gestart'-status gedurende meer dan 5 dagen (120 uur). Een Begonnen status betekent dat de MNT-node zowel authenticatie als boekhouding verwerkt om de Syslog-sessie te starten.

note-icon

Opmerking: Dit zijn de normale MnT-opruimtimers, geen gegarandeerde verwijderingstijden voor wandklokken. De verwijdering kan worden uitgesteld als:

  • SessionPurgeJob wordt niet uitgevoerd.
  • MnT staat onder druk van bronnen of databases.
  • De Accounting-Stop kan niet worden gecorreleerd aan de bestaande sessie.

Voorbeelden van Syslog-berichten van PSN:

Berichten worden aangemeld bij het prrt-server.log wanneer de runtime-aaa-component is ingeschakeld bij DEBUG. Vetgedrukte onderdelen kunnen worden gebruikt om reguliere zoekexpressies te construeren.

Verificatie geslaagd:

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

Begin van de boekhouding:

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

Tussentijdse boekhoudkundige bijwerking:

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

Boekhoudstop:

AcsLogs,2020-04-08 11:43:22,356,DEBUG,0x7fa0ad68d700,cntx=0000696242,sesn=skuchere-ise26-1/375283310/11515,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-08 11:43:22.368 +02:00 0000463071 3001 NOTICE Radius-Accounting: RADIUS Accounting stop request, ConfigVersionId=88, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=12, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/11503, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Stop, Acct-Delay-Time=0, Acct-Input-Octets=4147916, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Session-Time=92157, Acct-Input-Packets=29120, Acct-Output-Packets=0, Acct-Terminate-Cause=Lost Carrier, Event-Timestamp=1586371399, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, Framed-IPv6-Address=2001:10::100, Framed-IPv6-Address=2001:10::101, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/11515, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22084, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

PSN en sessiebeheer

De PSN-sessiecache is een in-memory database die alle actieve sessies van specifieke PSN opslaat. De sessiecache is altijd lokaal voor de node. Er is geen mechanisme in ISE dat replicatie van VOLLEDIGE sessiestaten van de ene node naar de andere kan uitvoeren.

Voor elke actieve sessie-ID slaat PSN alle kenmerken op die tijdens de verificatie-/autorisatiefase zijn verzameld (bijvoorbeeld interne/externe gebruikersgroepen, NAD-kenmerken (Network Access Device), certificaatkenmerken, enzovoort). Deze kenmerken worden door PSN gebruikt om verschillende beleidstypen te selecteren, zoals verificatie, autorisatie, clientprovisioning en houding.

Sessiecache wordt volledig verwijderd wanneer de node (of services op de node) opnieuw worden opgestart.

Client Provisioning Portal 4

De huidige logica voor sessieverwerking maakt een nieuw item in de sessiecache in twee scenario's. Latere details van bestaande sessies kunnen worden bijgewerkt uit boekhoudkundige berichten, die afkomstig zijn van NAD's.

  • De sessie is met succes geverifieerd op de PSN.
  • PSN heeft een tussentijdse boekhoudkundige update voor de sessie die niet bestaat in de sessiecache. Met sessieverwijdering implementeert PSN deze logica:
    • De sessie cache wordt onmiddellijk verwijderd na het verwerken van het boekhoudstopbericht.
    • PSN begint met het verwijderen van de minst recent gebruikte sessies wanneer een node de limiet van actieve sessies bereikt.

Verouderde sessie op PSN

Bij de implementatie van ISE is de boekhoudstop voor een bestaande sessie verwerkt door het PSN dat de daadwerkelijke verificatie niet heeft uitgevoerd:

Voorbeeld van de stabiele sessie:

Client Provisioning Portal 5

  1. Succesvolle verificatie vindt plaats op PSN voor ABC-sessie.
  2. PSN maakt een item aan in de sessiecache.
  3. Houdingsbeoordeling vindt plaats.
  4. De sessie is gemarkeerd als Compliant.
  5. Verandering van autorisatie (COA) wordt geactiveerd door de wijziging van de status van de houding, wat leidt tot herverificatie van het eindpunt om het volgende toegangsniveau toe te passen.
  6. Boekhouding stopt voor sessie ABC naar PSN2.

Daarna raakt ABC vast in een stabiele staat op PSN1, omdat er geen boekhoudstopbericht op deze PSN is verwerkt om het te verwijderen. De sessie wordt verwijderd als er bij de implementatie geen groot aantal verificatiepogingen worden uitgevoerd.

De verouderde sessie wordt weergegeven in de cache van de PSN-sessie in de volgende scenario's:

  • De boekhoudstop werd naar het verkeerde PSN gestuurd vanwege het verlopen van de kleverige timer op de taakverdeler.
  • De verkeerde configuratie op de NAD is niet hetzelfde PSN dat is geconfigureerd voor verificatie en boekhouding.
  • Tijdelijke connectiviteitsproblemen op het netwerkpad veroorzaakten NAD-failover naar het volgende PSN.

Voorbeeld van de stabiele sessie in de Load Balancer (LB)-omgeving:

Client Provisioning Portal 6

  1. De eerste verificatie voor Session ABC wordt uitgevoerd door PSN1. Met deze verificatie wordt een stickiness-timer op de taakverdeler gestart.
  2. PSN1 maakt een item voor sessie ABC in de lokale cache.
  3. Het Syslog-bericht voor de doorgegeven verificatie wordt overgebracht naar de MNT-node.
  4. Het item voor sessie ABC wordt gemaakt in de MNT-sessiemap met de status Geverifieerd. (en).
  5. De boekhoudkundige startboodschap voor ABC-sessie landt op PSN1.
  6. De sessie cache-vermelding voor sessie ABC wordt bijgewerkt met informatie van Accounting-Start.
  7. Het Syslog-bericht voor Accounting-Start wordt overgebracht naar de MNT-node.
  8. De sessiestatus wordt bijgewerkt naar Begonnen.
  9. Stickiness timer verloopt op de load balancer.
  10. Accounting-Stop voor sessie ABC wordt door de load balancer doorgestuurd naar PSN2.
  11. Het Syslog-bericht voor Accounting-Stop wordt door PSN2 doorgestuurd naar MNT.
  12. Sessie ABC is gemarkeerd als beëindigd op MNT.

Phantom-sessie op de PSN

De fantoomsessie is een scenario waarin de tussentijdse boekhoudupdate naar de PSN komt en deze geen verificatie voor die sessie heeft uitgevoerd. In dit scenario wordt een nieuw item gemaakt in de PSN-sessiecache. Als PSN voor deze sessie geen bericht met een boekhoudstop ontvangt, wordt de vermelding niet verwijderd tenzij PSN de limiet van actieve sessies bereikt.

Voorbeeld van de fantoomsessie:

Client Provisioning Portal 7

  1. Dezelfde stappen die in het voorbeeld van de stabiele sessie worden beschreven, vinden plaats op PSN1 voor de ABC-sessie.
  2. Sessie ABC heeft de status Compliant in de PSN1-sessiecache.
  3. Een tussentijdse boekhoudkundige update voor ABC-sessie raakt PSN2.
  4. Een sessie-item voor ABC wordt gemaakt op PSN2. Aangezien de sessievermelding wordt gemaakt op basis van het boekhoudbericht, heeft deze een beperkt aantal kenmerken. De status van de positie is bijvoorbeeld niet beschikbaar voor sessie-ABC en gebruikersgroepen of andere autorisatiespecifieke kenmerken ontbreken ook.

De fantoomsessie verschijnt in de cache van de PSN-sessie in de volgende scenario's:

  • Korte termijn storing op het transitnetwerk.
  • Wangedrag van netwerktoegangsapparaat.
  • Wangedrag of verkeerde configuratie op de taakverdeler.

De volgende schermafbeelding is een voorbeeld van een fantoomsessie waarbij tijdelijke problemen op het netwerkpad naar PSN1 optreden:

Client Provisioning Portal 8

  1. De eerste verificatie voor ABC-sessie wordt uitgevoerd door PSN.
  2. PSN1 maakt een item voor sessie ABC in de lokale cache.
  3. Het syslog-bericht voor doorgegeven verificatie wordt overgebracht naar de MNT-node.
  4. Een vermelding voor sessie ABC wordt gemaakt in TimesTen DB met de status Geverifieerd.
  5. De boekhoudkundige startboodschap voor ABC-sessie landt op PSN 1.
  6. Een sessie cache-vermelding voor sessie ABC wordt bijgewerkt met informatie van Accounting-Start.
  7. Het Syslog-bericht voor Accounting-Start wordt overgebracht naar de MNT-node.
  8. De sessiestatus wordt bijgewerkt naar Begonnen.
  9. De tussentijdse boekhoudkundige update voor ABC-sessie wordt doorgestuurd naar PSN2.
  10. PSN2 maakt een item voor de sessie ABC in de lokale cache.
  11. De Accounting-Stop voor ABC-sessie wordt doorgestuurd naar PSN1.
  12. De vermelding voor sessie ABC wordt verwijderd uit de sessiecache op PSN1.
  13. Een Syslog-bericht voor Accounting-Stop wordt door PSN1 doorgestuurd naar MNT.
  14. Sessie ABC is gemarkeerd als beëindigd op MNT.

Dit toont een scenario van de fantoomsessie zoals gemaakt voor de langlevende VPN-verbinding:

Client Provisioning Portal 9

  1. Eerste verificatie op PSN1.
  2. Sessie-ABC wordt gemaakt in de sessiecache.
  3. Accounting start het bericht dat door de PSN wordt verwerkt.
  4. Het nieuwe IP-adres wordt toegewezen aan de Virtual Private Network (VPN)-adapter.
  5. Een tussentijdse boekhoudkundige update met de IP-adresgegevens komt op het PSN terecht.
  6. De IP-adresgegevens worden toegevoegd aan de sessiecache.
  7. Houdingsbeoordeling vindt plaats met PSN1.
  8. De status van de houding wordt bijgewerkt in de sessie.
  9. Een COA-push wordt uitgevoerd door ISE; dit triggert een nieuw toegangsniveau dat moet worden toegewezen.
  10. Er is een storing op het netwerkpad, waardoor PSN1 ontoegankelijk is.
  11. Na het verstrijken van een tussentijds updateinterval detecteert ASA/FTD dat PSN1 ontoegankelijk is.
  12. De tussentijdse boekhoudkundige update komt naar PSN2.
  13. De fantoomsessie wordt gemaakt in de PSN2-sessiecache.

Als PSN1 later toegankelijk wordt (14), worden alle volgende boekhoudberichten doorgestuurd (15,16) en blijft ABC-sessie gedurende een ongedefinieerde tijd in de PSN2-sessiecache.

Hoe Stale Session en Phantom Session het Posture-proces doorbreken

Om te begrijpen hoe de oude en de fantoomsessies de houding verbreken, kunt u het detectieproces van de AnyConnect ISE-houdingsmodule bekijken:

Client Provisioning Portal 10

Discovery fase 1:

Tijdens deze fase voert de ISE-houdingsmodule vier gelijktijdige sondes uit om het PSN te vinden dat het eindpunt verifieert.

Ten eerste zijn drie sondes op de figuur redirect-based (Default GW IP, Discovery host IP (indien gedefinieerd) en enroll.cisco.com IP); die sondes wijzen de agent altijd naar de juiste PSN als de omgeleide URL wordt genomen van de NAD zelf.

Probe vier wordt verzonden naar alle primaire servers in het bestand ConnectionData.xml. Dit bestand wordt gemaakt na de eerste geslaagde postuur poging. De bestandsinhoud kan later worden bijgewerkt als de client tussen PSN's migreert.

Op de Windows-systemen is de bestandslocatie C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Aangezien alle fase 1-sondes gelijktijdig worden uitgevoerd, worden de resultaten van de vierde sonde alleen gebruikt als alle andere drie de sondes uitvallen of als de ISE-posturemodule niet binnen 5 seconden de juiste communicatie met de PSN kan vaststellen die in de redirect-URL wordt geretourneerd.

Wanneer de sonde vier landt op de PSN, bevat deze een lijst met actieve IP- en MAC-adressen die op het eindpunt zijn ontdekt. PSN gebruikt deze gegevens om een sessie voor dit eindpunt in de lokale cache te vinden. Als PSN een verouderde of fantoomsessie voor een eindpunt heeft, kan dit leiden tot een verkeerde status van de positie die later aan de clientzijde wordt weergegeven.

Wanneer een agent meerdere antwoorden ontvangt voor probe vier (ConnectionData.xml kan meer dan één primair PSN bevatten), wordt altijd het snelste antwoord gebruikt.

Discovery fase 2:

Alle detectiesondes in fase 2 zijn zonder omleiding, wat betekent dat elke sonde een sessieopzoeking op de PSN-bestemming activeert. Als de PSN de sessie niet in de lokale sessiecache kan vinden, moet deze een MNT-zoekopdracht uitvoeren (alleen op basis van MAC-adres) om een eigenaar van de sessie te vinden en de naam van de eigenaar aan de agent terug te geven.

Omdat alle sondes het opzoeken van sessies activeren, kan de detectie van fase 2 aanzienlijk worden beïnvloed door problemen als gevolg van verouderde of fantoomsessies.

Als PSN naar fase 2 wordt verplaatst, maakt de detectiesonde in de sessiecache een verouderde of fantoomingang voor hetzelfde eindpunt. Dit resulteert in een verkeerde houding die wordt teruggegeven aan de eindgebruiker.

Dit voorbeeld laat zien hoe de houding wordt weergegeven wanneer PSN een verouderde sessie of fantoomsessie houdt:

Client Provisioning Portal 11

Opmerking: dit probleem kan zich alleen voordoen wanneer alle detectiesondes op basis van redirect mislukken of wanneer de niet-redirect-houding is geïmplementeerd.

  1. Een van Zoek mijn sessie sondes uitgegeven door de ISE houding module.
  2. PSN voert het opzoeken van sessies uit in de sessiecache. Als de sessie moet worden gevonden, treedt een verouderd of fantoomsessieprobleem op.
  3. PSN voert de beleidskeuze voor clientprovisioning uit. Als een fantoomsessie geen verificatie-/autorisatiekenmerken heeft en alle door u geconfigureerde beleidsregels specifiek zijn (er worden bijvoorbeeld beleidsregels gemaakt voor specifieke Active Directory-groepen), kan PSN geen correct beleid voor clientprovisioning toewijzen. Dit kan zich manifesteren in de foutmelding: "Het omzeilen van AnyConnect-scan op uw netwerk is niet geconfigureerd om Cisco NAC Agent te gebruiken".
    • In gevallen waarin het beleid voor clientprovisioning algemeen is (de beschikbare kenmerken in de fantoomsessie zijn voldoende om het beleid aan te passen aan een AnyConnect-configuratie), antwoordt PSN met de vereiste gegevens voor de voortzetting van het beoordelingsproces.
    • Bij deze stap, bij het werken met verouderde sessies, antwoordt PSN onmiddellijk met een posturele status van Compliant en alle volgende stappen zijn niet voltooid. PSN stuurt geen COA omdat het van mening is dat de sessie al voldoet. In Radius Live-logboeken wordt geen sessiegebeurtenis weergegeven met de status Compliant.

4. Voor het fantoomsessiescenario gaat de ISE-houdingsmodule verder met het initiële houdingsverzoek. Dit verzoek bevat informatie over alle beveiligings- en patchbeheerproducten die op het eindpunt zijn gedetecteerd.

5. PSN gebruikt informatie uit de eigenschappen request en session om te voldoen aan het juiste houdingsbeleid. De fantoomsessie heeft op dit moment een gebrek aan kenmerken en er is geen beleid dat overeenkomt. In dit geval antwoordt PSN op het eindpunt dat het voldoet. Dit is standaard ISE-gedrag als het houdingsbeleid niet overeenkomt. 

Opmerking: Als er een algemeen beleid is dat kan worden geselecteerd uit fantoomsessiekenmerken, kunt u doorgaan naar stap 6.

6. PSN retourneert het geselecteerde houdingsbeleid terug naar de agent.

Opmerking: wanneer er geen beleid kan worden geselecteerd, keert PSN terug met de status Compliant.

7. De agent retourneert statussen voor elk beleid/vereiste als "geslaagd" of "mislukt".

8. Het evaluatieverslag vindt plaats op ISE en de sessiestatus verandert in Compliant.

Opmerking: als er houdingsproblemen worden veroorzaakt door de fantoomsessie, kan de ISE-beheerder enkele mislukte COA's voor de houding opmerken. Als dat zo is, worden de COA-verzoeken uitgevoerd vanuit de onjuiste PSN's en voor de verkeerde sessie-ID's.

Ontdekkingsproces start niet bij een nieuwe verificatiepoging

De ISE-houdingsmodule is ontworpen om een beperkte hoeveelheid gebeurtenissen op het eindpunt te monitoren om een ontdekkingsproces te activeren.

Gebeurtenissen die ontdekking veroorzaken:

  • Initiële installatie van de ISE-houdingsmodule.
  • Gebruiker login.
  • Machtsgebeurtenissen.
  • Interface statuswijziging.
  • OS hervat na het slapen.
  • Wijziging standaardgateway (DG).
  • Fout bij het opnieuw beoordelen van de houding (PRA), zie Cisco bug ID CSCvo69557. Nieuwe dot1x-verificatie, pc-ontgrendeling en wijziging van het IP-adres worden niet gedetecteerd door de ISE-posturingmodule.

De ISE-posturemodule kan in deze scenario's geen nieuwe verificatie- of herverificatiepoging detecteren:

  • Herauthenticatie raakt een ander PSN (hetzij vanwege een LB-beslissing of problemen met het oorspronkelijke PSN.)
  • NAD genereert een nieuwe sessie-id voor herverificatie.

Reauthenticatie op verschillende PSN

Dit diagram toont een voorbeeld van herverificatie op een ander PSN veroorzaakt door de storing van het oorspronkelijke PSN. Een scenario met een load balancer ziet er hetzelfde uit. In het geval van een load balancer wordt de herverificatie naar de verschillende PSN gestuurd als gevolg van een vervaldatum van de stickiness timer.

Client Provisioning Portal 11

  1. Eerste verificatie op PSN1.
  2. Sessie-ABC wordt gemaakt in de PSN1-sessiecache.
  3. Houdingsbeoordeling wordt uitgevoerd met PSN1.
  4. De status van de ABC-positie van de sessie wordt verplaatst naar Compliant.
  5. COA wordt geactiveerd door de verandering van de status van de houding en leidt tot herverificatie van het eindpunt om het volgende toegangsniveau toe te passen.
  6. PSN1 is niet meer beschikbaar.
  7. Opnieuw verifiëren voor ABC-sessie raakt PSN2.
  8. Omdat het een nieuwe sessie is voor PSN2, verandert de postuur status van de sessie in Bezig.

De status van de beginhouding wordt door PSN aan de sessie toegewezen:

Client Provisioning Portal 12

Opmerking: het statussysteem beschrijft alleen een eerste selectie van de status van de houding. Elke sessie is in eerste instantie gemarkeerd als Onbekend en kan later compliant of non-compliant worden op basis van de evaluatie van het rapport die is ontvangen van de ISE-houdingsmodule.

NAD genereert nieuwe sessie-ID bij herverificatie

Dit kan gebeuren in de twee meest voorkomende scenario's:

  • Herverificatie is niet correct geconfigureerd aan de kant van de ISE (de oplossing voor dit probleem wordt later in dit document behandeld).
  • Misgedrag van de NAD-kant; normaal gesproken houdt NAD dezelfde sessie-ID bij tijdens de herverificatiepoging. Dit is een potentieel buggy gedrag dat moet worden onderzocht op NAD.
    • De nieuwe sessie-ID kan in andere scenario's worden gegenereerd. In sommige gevallen kan bijvoorbeeld draadloze roaming een oorzaak zijn.
    • ISE PSN plaatst altijd een nieuwe sessie in de wachtstand, tenzij de leasepositie is geconfigureerd. De houding lease wordt verderop in dit document uitgelegd.

Snelle manieren om te identificeren wanneer een probleem werd veroorzaakt door de Stale / Phantom-sessie

Om vast te stellen of AnyConnect naleving vertoont terwijl de redirect-status wordt veroorzaakt door de verouderde/fantoomsessie. U moet toegang krijgen tot het eindpunt terwijl het zich in de problematische toestand bevindt.

Details van systeemscan onderzoeken

1. Klik op het tandwielpictogram in de AnyConnect-gebruikersinterface.

Client Provisioning Portal 13

2. Navigeer in het nieuwe venster naar Systeemscan > Statistieken.

Client Provisioning Portal 14

Let vervolgens op twee belangrijke elementen:

  • Laatste begintijd scannen: de tijdstempel hier moet dicht bij de tijd zijn waarop het probleem werd ontdekt.
  • Beleidsserver: Dit veld geeft de naam aan van de beleidsserver die een houdingsevaluatie voor het eindpunt uitvoert. De FQDN moet worden vergeleken met de FQDN van de Redirect-URL (voor redirect-basishouding) of met de PSN-naam die is overgenomen van de laatste verificatiepoging (voor redirect-loze houding).
  1. Vergelijk de Policy Server FQDN uit de System Scan Statistics met de nodenaam die de verificatie voor het eindpunt heeft uitgevoerd:

Client Provisioning Portal 15

De demo toont de registratie van de stappen die nodig zijn voor identificatie van het probleem:

Voorafgaande probleemoplossing van een verouderde/fantoomsessie

In het vorige voorbeeld wordt het probleem van een verouderde of fantoomsessie onderscheiden van het probleem van het detectieproces dat niet is gestart. Tegelijkertijd moet u de eigenlijke sessie identificeren die het probleem heeft veroorzaakt om te begrijpen hoe het een verouderd of fantoomsessieprobleem wordt. Hoewel in sommige scenario's verouderde en fantoomsessies niet kunnen worden vermeden, moet u ervoor zorgen dat best practices worden geïmplementeerd om te voorkomen dat verouderde / fantoomsessies in een omgeving worden gemaakt.

DART-bundelcollectie

Analyseer een DART-bundel die is genomen vanaf het eindpunt dat het probleem reproduceert.

  1. Bewaar alleen belangrijke logs in DART en het wordt aanbevolen om logs te wissen voordat het probleem wordt gereproduceerd.
  2. Om dit te bereiken, moet het DART-bundelhulpprogramma starten als een beheerder en logopruiming uitvoeren.
  3. Navigeer in Windows naar Start en begin met het typen van DART > klik met de rechtermuisknop en kies - Uitvoeren als beheerder.


Client Provisioning Portal 16

4. Klik in het eerste wizardscherm op Volgende.

Client Provisioning Portal 17

5. Klik in het volgende wizardscherm op Alle logboeken wissen.

Client Provisioning Portal 18

6. Nadat het probleem is gereproduceerd, kan DART hier worden verzameld; klik op Volgende.

DART-bundelanalyse

Nadat de DART-bundel is verzameld, dearchiveert u deze en concentreert u zich op het bestand AnyConnect_ISEPosture.txt in de map Cisco AnyConnect ISE Posture Module. Dit bestand bevat alle ontdekkingsgerelateerde gebeurtenissen.

Client Provisioning Portal 19

1. Begin met het oplossen van problemen en identificeer alle momenten van herstart van de ontdekking. Trefwoorden om te zoeken zijn Discovery opnieuw starten of HTTP Discovery. Navigeer naar de regel met detectie-herstart die op het problematische moment plaatsvond:

CLI Output

2. Na de herstart van de detectie bestaat er een regel die geen MNT-stadiumdoelen bevat (dit is een indicator voor het begin van de detectie in fase 1):

CLI Output 2

3. Het wordt aanbevolen om alle op redirect gebaseerde sondes met dezelfde kleur en eerder aangesloten PSN's die zijn gemaakt van ConnectionData.xml (doelen Auth-Status) in een andere kleur te markeren. Normaal gesproken PSN FQDN's zijn vergelijkbaar en kan moeilijk zijn om het verschil te herkennen.

4. Lees de logbestanden om de resultaten voor elke sonde te zien (dit is een voorbeeld van hoe een mislukte sonde eruit ziet):

CLI Output 3

5. Ergens in het bestand na het opsporen en opnieuw opstarten voor fase 1 of fase 2 ziet u een succesvol antwoord van een of meer PSN's:

CLI Output 4

5. Enkele regels later is er een regel met het trefwoord MSG_NS_SWISS_NEW_SESSION. Deze regel bevat een echte sessie-ID die door PSN is geselecteerd als gevolg van het opzoeken van de sessie. Gebruik deze sessie-ID voor verder onderzoek naar ISE om te bepalen hoe de sessie muf/fantoomachtig is geworden:

CLI Output 5

Onderzoek naar ISE-logboeken

1. In het guest.log met de component client-webapp ingeschakeld voor DEBUG, antwoordt de PSN met de sessie Stale/Phantom, die te zien is.

2. PSN ontvangt een verzoek van de ISE posture agent. Dit is een aanvraag van AnyConnect vanwege de waarde voor de 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

3. Het verzoek bevat arrays van IP-adressen en MAC-adressen. In dit voorbeeld heeft elke array slechts één waarde. Het log toont de sessie-ID van het verzoek is null, wat aangeeft dat dit een verzoek van de niet-redirect-gebaseerde sonde is. Later kunt u zien hoe waarden van arrays worden gebruikt om een sessie-ID te vinden:

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

4. Na de regel met trefwoorden Verzonden http-antwoord, kunt u de inhoud van het antwoord bekijken:

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

Onderzoek naar ISE-rapporten

Zodra de ID van de verouderde / fantoomsessie bekend is, kunt u het Radius Accounting-rapport onderzoeken om een beter begrip te krijgen van wat de sessie heeft veroorzaakt om verouderd / fantoomeffect te worden:

  1. Navigeer naar Operations > Reports > Endpoints and Users > Radius Accounting report en voer dit rapport gedurende 7 dagen uit. Gebruik een eindpunt-ID als filtersleutel.

2. Dit is een voorbeeld van een verslag dat laat zien hoe de verouderde sessie was overgebleven op ciscolive-ise2:

CLI Output 6

  • De boekhoudkundige start van de sessie kwam naar PSN ciscolive-ise2.
  • De tussentijdse update voor de sessie werd verwerkt op hetzelfde PSN.
  • Een boekhoudstopbericht voor de problematische sessie-ID kwam naar een ander PSN (ciscolive-ise1).

Hoe te identificeren wanneer een probleem werd veroorzaakt door de afwezigheid van een Discovery Restart

Dezelfde logica is van toepassing op het vorige probleem, maar het enige verschil is dat u zich moet concentreren op de starttijd van de nieuwste scan. Voor dit soort problemen ligt de tijdstempel van de laatste scan in het verleden.

Normaal gesproken wanneer een eindgebruiker een probleem ontdekt, is er een scan uitgevoerd. In de ISE Radius Live-logs worden recente verificatiepogingen van het problematische eindpunt gezien.

De demo toont de registratie van de stappen die nodig zijn voor identificatie van het probleem:

Geavanceerde probleemoplossing: de afwezigheid van herstart van de detectie

Deze benadering is vergelijkbaar met de sectie Geavanceerde probleemoplossing voor stabiele/fantoomsessie. Het belangrijkste element voor probleemoplossing is het DART-bundelonderzoek.

In de DART-bundel kunt u zoeken naar herstart van ontdekking (zoals getoond voor het vorige probleem) en bevestigen dat er geen herstart van ontdekking was op het moment dat het probleem werd gemeld.

Richt u aan de kant van ISE op het verificatierapport Radius Live Logs/ Radius om te bevestigen dat er een failover was tussen PSN's of dat er een nieuwe sessie-ID werd gegenereerd door NAD.

Oplossing

Klassieke aanpak - probleemvermijding

Historisch gezien waren er geen functies op ISE die problemen beschreven in dit document oplosten, dus de enige manier was om te vertrouwen op de set van best practices die worden geïmplementeerd op het netwerk en de ISE-kant om risico's te minimaliseren.

Best practices die het aantal verouderde of fantoomsessies in de ISE-implementatie kunnen minimaliseren

Implementeer altijd een redirect-gebaseerde houding indien mogelijk

Een veel voorkomend tegenargument voor deze aanbeveling is een slechte gebruikerservaring die wordt weergegeven in het besturingssysteem of browsers die worden weergegeven. Dit duidt op omleiding terwijl de AnyConnect ISE-posturingmodule op de achtergrond een beoordelingsproces uitvoert.

Als oplossing hiervoor is het mogelijk om ALLEEN ISE Posture module detectiesondes om te leiden en selectief al het andere verkeer toe te staan. In dit voorbeeld wordt een ACL-redirect weergegeven die is ontworpen om alleen HTTP-verzoeken om te leiden naar Discovery Host (10.1.1.1 in dit voorbeeld) en 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

Om een acceptabel beveiligingsniveau te behouden, kan een redirect ACL worden gecombineerd met DACL toegewezen vanuit ISE.

Staat in behandeling Staat alleen verbindingen met PSN toe waar Endpoint is geverifieerd

Deze aanpak is handig voor omgevingen waar URL-omleiding niet wordt ondersteund (implementaties met de NAD's van de derde partij).

Implementeer als oplossing meerdere Posture Pending-autorisatiemaatregelen (één per PSN). Elk beleid moet als een van de voorwaarden de naam bevatten van het PSN waar de authenticatie plaatsvond. In het autorisatieprofiel moeten alle PSN's worden geblokkeerd, behalve het knooppunt waar de verificatie heeft plaatsgevonden.

Maken van autorisatiebeleid voor twee knooppunten:

Authz Policy

 

  1. Houding in behandeling voor PSN1.
  2. PSN1 naam wordt gebruikt als een voorwaarde in het beleid.
  3. Het autorisatieprofiel met ACL blokkeert de toegang tot alle PSN's behalve PSN1.
  4. De houding in behandeling beleid voor PSN2.
  5. PSN2 naam wordt gebruikt als een voorwaarde in het beleid.
  6. Het autorisatieprofiel met ACL blokkeert de toegang tot alle PSN's behalve PSN2.
  7. Houding 'Compliant' autorisatiebeleid.

De volgende figuur legt uit hoe de aanpak werkt:

Client Provisioning Portal 20

  1. Verificatie raakt PSN1.
  2. Als gevolg van geconfigureerd autorisatiebeleid wijst PSN1 het autorisatieprofiel toe, dat de toegang tot alle andere knooppunten behalve PSN1 blokkeert.
  3. De AnyConnect ISE-posturingmodule start het detectieproces opnieuw op.
  4. De sonde naar PSN2 wordt geblokkeerd door de NAD, zoals eerder is toegewezen door een ACL.
  5. Probe naar PSN1 is toegestaan door ACL toegewezen op NAD.

Best practices voor de taakverdeling

  • Schakel de stickiness op de load balancer in voor authenticatie en boekhouding met Calling-Station-ID als stickiness-sleutel. Raadpleeg de best practices voor ISE met de Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP.
  • Gebruik een stickiness-timer die langer is dan een gemiddelde werkdag om het moment te dekken waarop de pc in de slaapstand wordt gezet (bijvoorbeeld 10 uur in plaats van 8 uur).
  • Als herverificatie is geïmplementeerd, gebruikt u de herverificatietimer iets lager dan de stickiness-timer (gebruik 8 uur als stickiness gedurende 10 uur is geconfigureerd). Dit zorgt ervoor dat het kleverigheidsinterval wordt verlengd door herverificatie.

Houding over VPN-use-case 

Zorg ervoor dat de accounting-interim update interval hoger of gelijk is aan de VPN-sessie-time-out. Dit minimaliseert boekhoudkundige fladdering tussen PSN's tijdens lange VPN-sessies.  In dit voorbeeld wordt het tussentijds bijwerkinterval voor de boekhouding gedurende 20 uur geconfigureerd. Dit belet niet dat de initiële tussentijdse update een IP-adres bevat dat aan het eindpunt is toegewezen.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

Best practices kunnen worden geïmplementeerd om de impact van de afwezigheid van ISE-posturemodule Discovery Restart te minimaliseren

Houdingslease inschakelen 

Dit is een functie op ISE die het eindpunt markeert als conform voor een bepaalde periode (1-365 dagen). De leasewaarde is een eindpuntkenmerk, wat betekent dat deze wordt opgeslagen op de ISE DB. Alle eindpuntkenmerken die de leasepositie bevatten, worden gerepliceerd voor alle nodes in de ISE-implementatie.

Wanneer PSN een nieuwe sessie voor het eindpunt ontvangt, kan de houdinglease worden gebruikt om de sessie onmiddellijk als compliant te markeren. Om deze beslissing te nemen, gebruikt PSN 3 waarden en die waarden zijn:

  1. Aantal dagen gedefinieerd voor houdingslease in ISE-instellingen: Navigeer naar Beheer > Systeem > Houding > Algemene instellingen:

Client Provisioning Portal 21

2. Waarde van het PostureExpiry-kenmerk is een eindpuntkenmerk dat een tijdstempel Epoch bevat. De waarde PostureExiry wordt in eerste instantie ingevuld bij de eerste geslaagde postureerpoging voor het eindpunt nadat de door de ISE-beheerder ingeschakelde postuurlease is uitgevoerd. Later wordt deze waarde bijgewerkt bij de volgende succesvolle postuur poging die gebeurt na het verstrijken van de lease. U kunt een PostureExiry zien in Context Visibility > Endpoints terwijl een van de gepostureerde eindpunten wordt geopend:

Client Provisioning Portal 22

3. Deze waarde kan worden omgezet in de voor mensen leesbare tijdstempel, bijvoorbeeld hier - https://www.epochconverter.com/

Client Provisioning Portal 23

3. Wanneer de verificatie voor een eindpunt met leasepositie PSN bereikt, gebruikt het PostureExiry en de systeemdatum om het aantal dagen op te halen dat is verstreken na de laatste geslaagde houdingscontrole. Als de resultaatwaarde binnen een houdingsinterval ligt dat is gedefinieerd in instellingen, krijgt de sessie de status Compliant. Als de resultaatwaarde hoger is dan de leasewaarde, krijgt de sessie de status Onbekend. Dit activeert de houding die opnieuw moet worden uitgevoerd en de nieuwe PostureExiry-waarde kan worden opgeslagen.

Dit diagram geeft het proces weer wanneer failover plaatsvindt:

Client Provisioning Portal 24

  1. De eerste verificatie vindt plaats met PSN1.
  2. Sessie-ABC wordt gemaakt in de sessiecache.
  3. Houdingsbeoordeling vindt plaats.
  4. Sessiestatus verandert in Voldoet aan.
  5. COA wordt geactiveerd door verandering van de status van de houding en leidt tot herverificatie van het eindpunt om toe te passen op het volgende toegangsniveau.
  6. De waarde PostureExiry wordt opgeslagen in het eindpunt.
  7. Eindpuntgegevens worden gedurende de implementatie gerepliceerd.
  8. De volgende verificatie wordt uitgevoerd op PSN2.
  9. PSN2 controleert of het eindpunt binnen een geldige leasehouding valt.
  10. Sessie wordt toegevoegd aan de sessiecache als compliant.
  11. Vanwege het geldige huurcontract wordt de sessie gemaakt met de postuur status van Compliant.

Implementatie van herverificatie 

Druk altijd op de reauthenticatietimer van ISE met de RADIUS-Request, die is geselecteerd in Connectiviteit behouden tijdens reauthenticatie. Deze instelling zorgt ervoor dat NAD dezelfde sessie-ID behoudt bij herverificatie.

Client Provisioning Portal 25

Omgevingen met load balancers

Dezelfde set best practices (uitgelegd in de sectie Stale/Phantom-sessie) kan worden geïmplementeerd.

Verschillende subnetten kunnen worden gebruikt voor hangende en de compliante staten

Wanneer netwerkontwerpen de mogelijkheid bieden om verschillende subnetten te gebruiken, zoals Aanhangende en Voldoende toestanden, garandeert deze benadering elke verandering in de postuur status resulteert in de Standaard Gateway verandering.

Houdingsevaluatie gebruikt in hetzelfde interval als een herverificatietimer

Houdingsbeoordeling kan worden ingeschakeld met het interval dat gelijk is aan de herverificatietimer. Wanneer het oorspronkelijke PSN niet beschikbaar is, wordt het detectieproces opnieuw opgestart wanneer de PRA-fout is opgetreden.

Moderne aanpak - posture state sharing

Als onderdeel van een geïmplementeerde verbetering (in Cisco bug ID CSCvi35647) van patch 6 voor ISE 2.6, is er een nieuwe functie die het delen van de sessiestatus over alle nodes in ISE-implementatie implementeert.

Deze verbetering is geïntegreerd in toekomstige releases voor ISE 2.7-patches 2 en ISE 3.0.

Deze nieuwe functie is gebaseerd op het Light Session Directory (LSD)-mechanisme dat is geïntroduceerd in ISE 2.6. In nieuwere versies werd deze functionaliteit omgedoopt tot Light Data Distribution (LDD) Radius Session Directory. Light Data Distribution is standaard ingeschakeld en maakt het delen van een beperkte sessiecontext tussen ISE-nodes mogelijk. Er zijn geen volledige sessiecontextreplicaties tussen PSN's, slechts een beperkte hoeveelheid attributen die voor elke sessie worden gedeeld.

Light Session Directory verwijdert de noodzaak om dure API-oproepen naar MNT uit te voeren wanneer een van de knooppunten in de implementatie de huidige sessiehouder moet bepalen. Eigenaar opzoeken is vereist wanneer COA stroom begint. Met LDD kan elke PSN een eigenaar van de sessie vinden in de lokale Radius Session Directory-cache. 

lichtgegevensdistributiearchitectuur

Deze functionaliteit bevat de volgende elementen:

  • Radius Session Directory (RSD) Cache: Deze cache bestaat op elke ISE-node en slaat alle actieve sessies op die worden gepresenteerd in ISE-implementatie. Elke sessie heeft een beperkte hoeveelheid attributen in de cache. Dit zijn voorbeelden van de attributen die voor elke sessie in de Radius Session Directory zijn opgeslagen:
    • Sessie-ID
    • Endpoint MAC
    • CallingStationID
    • IP-eindpunt
    • PSN IP - PSN waar authenticatie plaatsvindt
    • PSN FQDN 
    • NAS-IP-adres
    • NAS-IPv6-adres
    • Staat - geverifieerd, gestart, gestopt
  • RabbitMQ Exchange: Er is een uitwisseling gevormd waarbij de Publisher, gerelateerde Queue en Consumer worden gepresenteerd op elk knooppunt in de ISE-implementatie. Dit zorgt ervoor dat de topologievormen met volledige mazen tussen alle ISE-knooppunten ontstaan.
  • Uitgever: De Radius Session Directory vertegenwoordigt een uitgever. Wanneer een nieuwe succesvolle verificatie wordt verwerkt door een PSN, wordt een nieuwe sessie gemaakt in de PSN-sessiecache. Voor deze sessie wordt een beperkte set kenmerken in de directory Radius-sessie geplaatst.
  • Consument: Op alle andere knooppunten vertegenwoordigt de Radius Session Directory een consument.
note-icon

Opmerking: Algemene RabbitMQ-terminologie en -architectuur vallen buiten dit documentbereik.

In het volgende voorbeeld wordt uitgelegd hoe COA-stroom werkt met RSD-cache:

Client Provisioning Portal 26

  1. De eerste verificatie vindt plaats met PSN1.
  2. Sessie-ABC wordt gemaakt in de sessiecache.
  3. Vereiste attributen worden opgeslagen in RSD.
  4. Sessie wordt gedeeld via RabbitMQ met alle andere ISE-nodes.
  5. Sessie wordt gemaakt in RSD-cache op alle ISE-nodes.
  6. Nieuwe profielgegevens komen op PSN2.
  7. Endpoint wordt opnieuw geprofileerd en (in het geval van een wijziging die COA uitvoering PSN2 vereist) gaat verder met de volgende stap.
  8. Er wordt een interne API-aanroep naar de RSD-cache verzonden om COA uit te voeren.
  9. Gegevens uit de RSD-cache worden gebruikt om een Proxy COA-bericht voor te bereiden. Het verplaatst van de ene ISE-node naar de andere en bevat alle details die de bestemmingsknode kan gebruiken om een CAO-verzoek terug te sturen naar NAD. Het COA-bericht wordt eerst intern overgebracht naar PRRT Runtime (werkelijke AAA-server binnen ISE).
  10. PSN2 stuurt een COA-bericht naar PSN1.
  11. PSN1 stuurt een COA-bericht naar NAD.

Als u problemen wilt oplossen met de communicatie via LDD op de ISE, schakelt u de component Light-Session-Directory in bij DEBUG:

Client Provisioning Portal 27

Dit is een voorbeeld van een foutopsporingsbericht uit het bestand lsd.log voor het maken en publiceren van een sessie op het oorspronkelijke PSN:

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

Op alle andere ISE-nodes ziet u hoe een sessie werd verbruikt:

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

Houdingsstatus delen via RSD

Het delen van de status lost problemen op wanneer de hoofdoorzaak een Stale/Phantom-sessie is of een herverificatie op een ander PSN waarbij de herstart van de detectie niet is geactiveerd. Zodra de sessie compliant wordt, wordt deze informatie in de sessie RSD geplaatst en kan later door elke PSN in de implementatie worden gebruikt.

Er zijn enkele andere hoekgevallen die de beschreven functie niet kan oplossen. Bijvoorbeeld wanneer NAD herverificatie uitvoert op hetzelfde PSN, maar met een andere sessie-ID. Deze scenario's kunnen worden afgehandeld met best practices die in dit document worden beschreven. Deze figuur toont de topologie die wordt gebruikt voor een test van het delen van de houdingsstatus:

Network

Houdingsstatus delen via RSD - Stale/Phantom-sessie

Om een verouderde sessie te maken, moet de verificatie eerst worden uitgevoerd op skuchere-ise26-1. Vervolgens moet NAD opnieuw worden geconfigureerd om de boekhouding naar skuchere-ise26-3 te sturen. Nadat één boekhoudbericht is doorgestuurd naar het verkeerde PSN, moet NAD (opnieuw) worden geconfigureerd om de boekhouding terug te sturen naar skuchere-ise26-1.

Deze afbeelding toont een boekhoudkundig rapport dat de aanwezigheid van de fantoomsessie op skuchere-ise26-3 bewijst:

Phantom Session Accounting Report

  1. Boekhouding-Start berichten verwerkt door skuchere-ise26-1.
  2. Interim Accounting-Update voor dezelfde sessie verwerkt door skuchere-ise26-3.
  3. De sessie eindigt later op skuchere-ise26-1.

Het eindpunt maakt verbinding met het netwerk, maar de omleiding werkt niet meer. In het guest.log van PSN voor skuchere-ise26-3, kunt u deze logberichten zien met client-webapp component ingeschakeld in 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

Wanneer PSN detecteert dat het een verouderde / fantoomsessie voor het eindpunt bevat, reageert het niet op de ISE-houdingsmodule en kunt u informatie verkrijgen van PSN waar de nieuwste verificatie heeft plaatsgevonden.

Als oplossing voor het probleem van de verouderde/fantoomsessie op het moment van het opzoeken van de sessie controleert PSN de aanwezigheid van een nieuwe sessie voor het eindpunt in de RSD. Als RSD een andere sessie-ID bevat dan PSN in de lokale sessiecache heeft, wordt ervan uitgegaan dat de sessie (die in de sessiecache wordt weergegeven) muf is.

Houdingsstatus delen via RSD - failover tussen PSN's

Om dit scenario te reproduceren, wordt een korte herverificatietimer ingeschakeld in het autorisatieprofiel dat is toegewezen aan het eindpunt van de compliante status. Later wordt NAD opnieuw geconfigureerd om verificatie en boekhouding naar een ander PSN te verzenden (skuchere-ise26-3). Bij het verlopen van de reauthenticatietimer wordt dezelfde sessie niet geverifieerd op de verschillende PSN's. 

De volgende afbeelding toont een verificatierapport met failover voor dezelfde sessie van skuchere-ise26-1 tot skuchere-ise26-3:

Failover Between PSNs

  1. Authenticatie gebeurt op skuchere-ise26-1, het autorisatieprofiel met omleiding wordt toegewezen.
  2. COA na succesvolle postuur beoordeling.
  3. De volgende verificatie voor het autorisatieprofiel wordt toegewezen aan de status die aan de vereisten voldoet.
  4. Authenticatie raakt een ander PSN, maar het ontvangt nog steeds een autorisatieprofiel voor de conforme staat.

De sessie heeft de compliant status op het nieuwe PSN na failover in ise-psc.log met epm-pip en nsf-sessie componenten ingeschakeld in 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

Het oorspronkelijke probleem wordt opgelost door extra logica toe te voegen aan het proces voor het selecteren van de postuur. Deze figuur laat zien wat er veranderd is (veranderingen rood gemarkeerd):

Process

Revisiegeschiedenis

Revisie Publicatiedatum Opmerkingen
3.0
25-Aug-2026
Bijgewerkte titel, spelling, grammatica, ingevoegde horizontale lijnen naar afzonderlijke secties voor leesbaarheid, vaste URL's, CCW-waarschuwingen en alt-tekst.
2.0
31-May-2023
hercertificering
1.0
22-Apr-2020
Eerste vrijgave
TAC Authored

Bijgedragen door Cisco-engineers

  • Serhii Kucherenko

Was dit document nuttig?

FeedbackFeedback

Contact Cisco

Dit document is van toepassing op deze producten