Probleemoplossing voor ISE-sessiebeheer en -houding

Inleiding

Dit document beschrijft het probleem met de gemeenschappelijke posterijen van Identity Service Engine (ISE): "AnyConnect ISE-postermodule toont compatibele..."

Achtergrondinformatie

Dit document beschrijft het probleem met de gemeenschappelijke posterijen van Identity Service Engine (ISE) - AnyConnect ISE-postermodule toont compatibiliteit terwijl de sessiestatus van ISE in behandeling is.

Hoewel de symptomen altijd hetzelfde zijn, zijn er meerdere grondoorzaken van dit probleem.

Vaak wordt het oplossen van problemen bij een dergelijk probleem extreem tijdrovend, wat ernstige gevolgen heeft.

Dit document verklaart:

• Probleemmanifestatie vanuit het perspectief van de eindgebruiker en de beheerder van ISE.
• Gemeenschappelijke problematische scenario's.
• De theorie achter ISE, AnyConnect en netwerkbewerkingen die het probleem veroorzaken.
• Algoritmen voor snelle probleemidentificatie.
• Klassieke oplossingen voor veelvoorkomende probleemscenario's.
• Posture status delen via de Radius sessiemap.

Voor een betere uitleg van de later beschreven concepten raadpleegt u:

Probleem

Ervaring voor eindgebruiker

Deze kwestie komt normaal gesproken tot uiting in de afwezigheid van netwerktoegang of constante omleiding naar het ISE-client provisioningportal in de browser, terwijl AnyConect ISE-postermodule posterstatus als conform toont.

Typische eindgebruikerservaring:

ISE-beheerervaring

Normaal, in eerste triage van deze kwestie, voert ISE admin Radius Live logboeken onderzoek uit om ervoor te zorgen dat er een daadwerkelijke authenticatie is die de ISE raakt.

Het eerste symptoom dat in deze fase wordt ontdekt wijst op een wanverhouding in een postuur status tussen endpoint en ISE zoals in de bewegende logboeken of de rapporten van de Radiusverificatie laatste succesvolle authentificatie voor het eindpunt toont Hangende postuur status.

Typische ISE-beheerervaring:

• Laatste succesvolle verificatie voor Identity: alice.
• De status van de sessie is hangend.
• Laatste sessie voor Identity: alice.
• De sessie gebeurtenis toont de status van de houding als conform.

Opmerking: c. en d. worden niet altijd in de bewegende logbestanden getoond wanneer het beschreven probleem zich manifesteert. Een sessie-event met een postuur status van Compliant is gebruikelijker voor scenario's die worden veroorzaakt door de stapelbare of spooksessies (later beschreven in dit document).

Veelvoorkomende probleemscenario's

Deze kwestie manifesteert zich normaal in twee problematische scenario's en elk van hen heeft meerdere grondoorzaken. De scenario's:

• AnyConnect ISE-postermodule is verkeerd geïnformeerd door het Policy Service Node (PSN) tijdens het posteringsproces dat heeft geleid tot het weergeven van de verkeerde posterstatus. 

In dit geval behandelen we normaal gesproken een verouderde of spooksessie in het PSN-sessiecache.

• AnyConnect ISE toont de status van de houding van de vorige ontdekkingscyclus omdat de huidige verificatie geen detectieproces heeft geactiveerd.

ISE postermodule in AnyConnect heeft een beperkt aantal gebeurtenissen die het detectieproces activeren. Het is mogelijk dat tijdens de authenticatie of herauthenticatie geen van deze gebeurtenissen is gedetecteerd.

Probleem met statische/fysieke sessie

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

ISE-sessiebeheerlogica

In ISE-implementatie zijn twee personen verantwoordelijk voor het sessiebeheerproces: PSN en Monitoring Node (MNT).

Om dit probleem goed op te lossen en te identificeren, is het van cruciaal belang om de theorie van sessiebeheer op beide persona's te begrijpen.

MNT- en sessiebeheer

Zoals uitgelegd in deze afbeelding, MNT-knooppunt maakt seizoenen op basis van de doorgegeven authenticatie Syslog-berichten die afkomstig zijn van PSN's.

De sessiestatus kan later worden bijgewerkt door Syslog voor accounting.

Session verwijdering op MNT gebeurt in 3 scenario's:

1. Sessies zonder accounting start verwijderd ongeveer 60 minuten nadat ze zijn gemaakt: Er is een cron taak uitgevoerd elke 5 minuten om sessiestatus te controleren en schoon.

2. Afgesloten sessie verwijderd ongeveer 15 minuten nadat de accounting stop is verwerkt door dezelfde cron job.

3. Hetzelfde patroon op elke uitvoering verwijdert ook sessies die meer dan 5 dagen (120 uur) in de 'Begonnen' staat zijn geweest. Een begintoestand betekent dat de MNT-knooppunt zowel verificatie als accounting verwerkt om Syslog voor de sessie te starten.

Voorbeelden van Syslog-berichten van PSN:

Die berichten worden ingelogd op poortserver.log wanneer de runtime-aaa component is ingeschakeld in DEBUG. De delen in vet kunnen worden gebruikt om onderzoek regelmatige uitdrukkingen te construeren.

Verificatie succesvol doorlopen:

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 accounting:

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

Voorlopige 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

Het PSN-sessiecache is een in-memory database waarin alle actieve sessies van specifieke PSN worden opgeslagen. Session cache is altijd lokaal voor het knooppunt.

Er is geen mechanisme in ISE dat replicatie van de volledige sessiestatus van het ene knooppunt naar het andere kan uitvoeren.

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

Session cache wordt volledig verwijderd wanneer het knooppunt (of de services op het knooppunt) opnieuw wordt gestart.

De huidige logica van de zittingsverwerking leidt tot een nieuwe ingang in het zittingscachegeheugen in twee scenario's. Latere details van bestaande sessies kunnen worden bijgewerkt via boekhoudberichten die afkomstig zijn van NAD's.

• De sessie is op het PSN geverifieerd.
• PSN kreeg een tussentijdse boekhoudkundige update voor de sessie die niet bestaat in het sessiecache.

Als het gaat om sessieverwijdering, implementeert PSN deze logica:

• Session cache-ingang wordt verwijderd onmiddellijk na verwerking van het accounting stop bericht.
• PSN begint de minst recent gebruikte sessies te verwijderen wanneer een knooppunt de limiet van actieve sessies bereikt.

Verouderde sessie op PSN

Bij ISE-implementatie is de boekhoudstop voor een bestaande sessie verwerkt door de PSN, die de werkelijke verificatie niet heeft uitgevoerd:

Voorbeeld van de vervelende sessie:

1. Succesvolle verificatie vindt plaats op PSN voor ABC-sessie.

2. PSN maakt een ingang in het sessiecache.

3. De beoordeling van de houding gebeurt.

4. Sessie is gemarkeerd als conform.

5. Een wijziging van de autorisatie (COA) (veroorzaakt door wijziging van de postuur status) leidt tot een nieuwe authenticatie van het eindpunt om het volgende toegangsniveau toe te passen.

6. Accounting stop voor sessie ABC komt naar PSN2.

Daarna wordt ABC vastgezet in de verouderde staat op de PSN1 omdat er geen boekhoudkundig stopbericht is verwerkt op dit PSN om het te verwijderen.

De sessie wordt lange tijd verwijderd als de implementatie geen hoge aantal verificatiepogingen ondervindt.

De verouderde sessie verschijnt in het PSN-sessiecache in deze scenario's:

• De boekhoudstop kwam tot de verkeerde PSN toe te schrijven aan het verloop van de stickiness tijdopnemer op de ladingsverdeler.
• De verkeerde configuratie op het NAD is niet dezelfde PSN geconfigureerd voor verificatie en accounting.
• Tijdelijke connectiviteitsproblemen op het netwerkpad dat NAD-failover naar het volgende PSN veroorzaakt.

Voorbeeld van een verouderde sessie in een taakverdeling (LB)-omgeving:

1. De eerste verificatie voor de sessie ABC wordt uitgevoerd door PSN 1.

2. Met deze verificatie wordt een kleverheidstimer op de taakverdeling gestart.

3. PSN 1 maakt een ingang voor de sessie ABC in de lokale cache.

4. Syslog-bericht voor doorgegeven verificatie naar MNT-knooppunt.

5. Entry for Session ABC wordt aangemaakt in de MNT sessiemap met de status Authenticated.

6. Boekhoudkundige start-bericht voor sessie ABC landt op PSN 1.

7. Session cache-ingang voor de sessie ABC wordt bijgewerkt met informatie van Accounting-Start.

8. Syslog-bericht voor accounting-start wordt overgebracht naar MNT-knooppunt.

9. De sessiestatus wordt geactualiseerd om te beginnen.

10. De kleverheidstimer verloopt op de taakverdeling.

11. Accounting-Stop voor sessie ABC wordt door de taakverdeler doorgestuurd naar PSN 2.

12. Syslog-bericht voor accounting-stop wordt door PSN 2 naar MNT doorgestuurd.

13. Session ABC is gemarkeerd als beëindigd op MNT.

Fantoomsessie op het PSN

De fantoomsessie is een scenario wanneer de tussentijdse boekhoudkundige update naar de PSN komt die geen verificatie voor deze specifieke sessie uitvoerde. In dit scenario wordt een nieuwe ingang gemaakt in het PSN-sessiecache.

Als PSN geen accountingstop-bericht krijgt voor deze sessie, wordt de vermelding niet verwijderd tenzij PSN de limiet van actieve sessies bereikt.

Voorbeeld van de fantoomsessie:

1. Dezelfde stappen als beschreven in het voorbeeld van een verouderde sessie vindt plaats op PSN1 voor de sessie ABC.

2. Session ABC heeft een status conform in het PSN1-sessiecache.

3. Een tussentijdse boekhoudkundige update voor sessie ABC raakt PSN2.

4. Op PSN2 wordt een sessie-item voor ABC-sessie aangemaakt. Omdat de sessie is gemaakt op basis van het boekhoudingsbericht, heeft het een beperkt aantal attributen. Posterstatus is bijvoorbeeld niet beschikbaar voor ABC-sessie. Ook zaken als gebruikersgroepen en andere specifieke kenmerken van vergunningen ontbreken.

De spooksessie verschijnt in het PSN-sessiecache in deze scenario's:

• Korte onderbreking van de netwerkdoorvoer.
• Misbruik van netwerktoegangsapparaat.
• Fout bij gedrag of verkeerde configuratie bij taakverdeling.

Hier is een voorbeeld van een spooksessie voor het scenario met tijdelijke problemen op het netwerkpad naar PSN1:

1. De eerste verificatie voor de sessie ABC wordt uitgevoerd door het PSN.

2. PSN1 maakt een ingang voor de sessie ABC in de lokale cache.

3. Het syslogbericht voor doorgegeven verificatie wordt naar het MNT-knooppunt verzonden.

4. Een vermelding voor sessie ABC wordt aangemaakt in TimesTen DB met de status geverifieerd.

5. Het bericht waarmee de accounting wordt gestart voor de sessie ABC landt op PSN 1.

6. Een sessie-cache-ingang voor ABC-sessie wordt bijgewerkt met informatie van Accounting-Start.

7. Het Syslog-bericht voor accounting-start wordt naar de MNT-knooppunt overgebracht.

8. De sessiestatus wordt bijgewerkt tot Begonnen.

9. De tussentijdse boekhoudkundige update voor de ABC-sessie wordt doorgestuurd naar PSN2.

10. PSN2 maakt een ingang voor de sessie ABC in de lokale cache.

11. De Accounting-Stop voor de ABC-sessie wordt doorgestuurd naar PSN1.

12. De vermelding voor ABC-sessie wordt verwijderd uit de sessiecache op PSN1.

13. Een syslogbericht voor Accounting-Stop wordt door PSN 1 naar MNT verzonden.

14. De sessie ABC wordt gemarkeerd als beëindigd op MNT.

Dit is een scenario van de fantoomsessie zoals deze is gemaakt voor de langdurige VPN-verbinding:

1. Eerste verificatie op PSN1.

2. Session ABC wordt in het sessiecache gemaakt.

3. Boekhouding start het bericht dat door het PSN wordt verwerkt.

4. Het nieuwe IP-adres wordt toegewezen aan de Virtual Private Network (VPN)-adapter.

5. Een tussentijdse boekhoudkundige update met IP-adresinformatie vindt plaats op PSN.

6. IP-adresinformatie wordt toegevoegd aan het sessiecache.

7. Bij PSN1 wordt de houding beoordeeld.

8. De status van de houding wordt bijgewerkt in de sessie.

9. Een Cacao-push wordt uitgevoerd door ISE, waardoor een nieuw toegangsniveau wordt toegewezen.

10. Er is een stroomonderbreking op het netwerkpad die PSN1 ontoegankelijk maakt.

11. Na het verstrijken van een interim-update-interval detecteert ASA/FTD dat PSN1 ontoegankelijk is. 

12. De tussentijdse boekhoudkundige actualisering heeft betrekking op PSN2.

13. De spooksessie wordt gemaakt in het PSN2-sessiecache.

Als PSN1 later toegankelijk wordt (14), worden alle volgende boekhoudberichten doorgestuurd (15,16) en dit laat sessie ABC in het PSN2 sessiecache voor een onbepaalde tijd.

Hoe Stale Session en Phantom Session het postuur-proces doorbreken

Om te begrijpen hoe de verouderde sessie en de fantoomsessie de postuur verbreken, kunt u het AnyConnect ISE-poortdetectieproces bekijken:

Fase 1 ontdekking :

Tijdens deze fase, de postuur module van ISE 4 gelijktijdige problemen om van PSN te vinden die een authentificatie voor het eindpunt uitvoerden.

Ten eerste zijn 3 sondes in het getal gebaseerd op omleiding (standaard GW IP). IP van de ontdekkingsgastheer (indien bepaald) en enroll.cisco.com IP); Die sondes richten altijd de agent aan het recht PSN zoals opnieuw gerichte URL wordt genomen van NAD zelf.

Probe nummer 4 wordt naar alle primaire servers verzonden die in het ConnectionData.xml-bestand worden gepresenteerd. Dit bestand wordt gemaakt na de eerste succesvolle poging tot postuur. Bestandsinhoud kan later worden bijgewerkt als de client tussen PSN's migreert.

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

Aangezien alle fase 1 sondes gelijktijdig worden uitgevoerd, wordt het resultaat van sonde 4 slechts gebruikt als alle andere 3 sondes ontbraken of als de module van de houding van ISE niet in staat was om juiste communicatie met het PSN te vestigen dat in redirect URL binnen 5 seconden terugkwam.

Wanneer sonde 4 op PSN landt, bevat het een lijst van actieve IP en van MAC adressen die op het eindpunt worden ontdekt. PSN gebruikt deze gegevens om een sessie voor dit eindpunt te vinden in de lokale cache.

Als PSN een verouderde of fantoomsessie voor een eindpunt heeft, kan dit resulteren in een verkeerde houding status die later op de client-side wordt weergegeven.

Wanneer een agent meerdere antwoorden krijgt voor sonde 4 (ConnectionData.xml kan meer dan één primaire PSN bevatten), wordt het snelste antwoord altijd gebruikt.

Detectie fase 2:

Alle fase 2 detectiesondes zijn redirect-less, wat betekent dat elke sonde een sessie-lookup op de bestemming PSN teweegbrengt.

Als de PSN de sessie niet kan vinden in het lokale sessiecache, moet het een MNT lookup (alleen op MAC-adres gebaseerd) uitvoeren om een sessieeigenaar te vinden en de naam van de eigenaar terug te geven aan de agent.

Aangezien alle sondes sessieraadpleging veroorzaken, kan fase 2 ontdekking nog meer worden beïnvloed door problemen als gevolg van verouderde of fantoomsessies.

Als PSN aan stadium 2 krijgt, leidt de ontdekkingssonde die in het zittingscachegeheugen bestaat tot een verouderde of spookingang voor het zelfde eindpunt. Dit resulteert in de verkeerde postuur status die aan de eindgebruiker is geretourneerd.

In het voorbeeld wordt getoond hoe houding zich voordoet als PSN een verouderde sessie of fantoomsessie houdt:

Opmerking: dit probleem kan alleen optreden wanneer alle op redirect gebaseerde detectiesondes falen of wanneer non-redirect postuur is geïmplementeerd.

1. Elk van Find mijn sessie sondes uitgegeven door de ISE postuur module.

2. PSN voert sessielaadpleging uit in het sessiecache. Als de sessie gevonden moet worden, doet zich een verouderde of spooksessie voor.

3. PSN voert de selectie van het clientprovisioningbeleid uit. In een geval waar een spooksessie die een gebrek aan authenticatie/autorisatie kenmerken heeft en alle beleid dat door de klant is geconfigureerd zeer specifiek is (bijvoorbeeld, beleid wordt gemaakt voor specifieke Active Directory groepen), is PSN niet in staat om een juiste client provisioning beleid toe te wijzen. Dit kan zich manifesteren in de foutmelding: "Bypassing AnyConnect scan uw netwerk is geconfigureerd om Cisco NAC Agent te gebruiken".

• In gevallen waarin het beleid van de cliëntlevering generisch is (de attributen beschikbaar in de spookzitting zijn genoeg om beleid met configuratie aan te passen AnyConnect) antwoorden PSN met details nodig voor de voortzetting van het beoordelingsproces.
• Bij deze stap, wanneer we kunnen omgaan met verouderde sessies, PSN antwoordt onmiddellijk met een postuur status van Voldoet en alle volgende stappen worden niet uitgevoerd. PSN stuurt geen COA omdat het van mening is dat de sessie al in overeenstemming is. In Radius Live-logbestanden wordt er geen sessie-event weergegeven met de status Compliant.

4. Voor het scenario van de spooksessie gaat de ISE-poortmodule verder met het verzoek voor de eerste postuur. Dit verzoek bevat informatie over alle security en patchbeheerproducten die op het eindpunt zijn gedetecteerd.

5. PSN gebruikt informatie uit de aanvraag en sessiekenmerken om goed postuur beleid aan te passen. Omdat de fantoomsessie op dit moment een gebrek aan attributen heeft, hebben we geen beleid om bij te passen. In een dergelijk geval antwoordt PSN op het eindpunt dat het voldoet. Dit is een standaard ISE-gedrag bij een postuur die niet overeenkomt. 

Opmerking: wanneer er een of ander generiek beleid is dat kan worden geselecteerd uit spooksessiekenmerken, gaan we verder met stap 6.

6. PSN retourneert het geselecteerde postuur beleid terug naar de agent.

Opmerking: wanneer geen beleid kan worden geselecteerd, geeft PSN de status Compliant terug.

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

8. De evaluatie van het rapport gebeurt op ISE en sessiestatuswijzigingen in Conforme.

Opmerking: In het geval van postuur problemen veroorzaakt door de fantoomsessie, merkt de ISE-beheerder mogelijk enkele mislukte postuur-COA's op. In dergelijke gevallen worden COA-verzoeken uitgevoerd vanuit de verkeerde PSN's en voor verkeerde sessie-ID's.

Detectieproces start niet op een nieuwe verificatiepoging

De ISE postermodule is ontworpen om een beperkte hoeveelheid gebeurtenissen op het eindpunt te monitoren om een detectieproces te starten.

Gebeurtenissen die aanleiding geven tot ontdekking:

• Eerste installatie van de ISE-poortmodule.
• Aanmelden door gebruiker.
• Aan de macht.
• Verandering van interfacestatus.
• Ga verder na de slaap.
• Standaard gateway (DG) wijzigen.
• Zie Herbeoordeling van de houding (PRA) falen Cisco bug-id CSCvo69557

Nieuwe dot1x-verificatie, pc-ontgrendeling en IP-adreswijziging worden niet gedetecteerd door de ISE-poortmodule.

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

• Herauthenticatie raakt verschillende PSN (door LB beslissingen of problemen met originele PSN).
• NAD genereert nieuwe sessie-id bij herverificatie.

Verificatie opnieuw op verschillende PSN

In dit diagram wordt een voorbeeld getoond van herverificatie op verschillende PSN die door de stroomonderbreking van het oorspronkelijke PSN is veroorzaakt. Een scenario met een lastverdeler lijkt erg op elkaar.

In het geval van een lastverdeler, wordt opnieuw-authentificatie geleid aan verschillende PSN als resultaat van een stickiness tijdopnemerverloopdatum.

1. Eerste verificatie op PSN1

2. Session ABC wordt in het PSN1-sessiecache gemaakt.

3. De beoordeling van de houding wordt uitgevoerd met PSN1.

4. De ABS van de zitting positiestatus beweegt zich aan Volgzaam.

5. COA wordt geactiveerd door wijziging van de postuur status en leidt tot opnieuw authenticeren van het eindpunt om het volgende toegangsniveau toe te passen.

6. PSN1 wordt niet meer beschikbaar.

7. Herverificatie voor sessie ABC hits PSN2.

8. Omdat het een nieuwe sessie voor PSN2 is, wordt de postuur status van de sessie hangend.

De status van de eerste houding wordt door PSN toegewezen aan de sessie:

Opmerking: State-machine beschrijft alleen een eerste selectie van de postuur status. Elke sessie die aanvankelijk als Onbekend is gemarkeerd, kan later conform of niet-conform worden op basis van de evaluatie van het rapport die van de ISE-postermodule is ontvangen.

NAD genereert nieuwe sessie-id bij herverificatie

Dit zou kunnen gebeuren in de twee meest voorkomende scenario's:

• Herverificatie is niet correct geconfigureerd aan de ISE-zijde. De oplossing voor dit probleem wordt later in dit document besproken.
• Misgedrag van NAD-kant; normaal houdt NAD dezelfde sessie-ID bij tijdens de poging tot herverificatie. Dit is een mogelijk buggy gedrag dat moet worden onderzocht op de NAD zelf.

De nieuwe sessie-ID kan worden gegenereerd in een aantal andere hoekscenario's. Draadloze roaming kan bijvoorbeeld in sommige gevallen een oorzaak zijn.

Het belangrijkste is dat ISE PSN altijd een nieuwe sessie in postuur hangende staat plaatst tenzij de postuur lease is geconfigureerd. De posterijen worden later in dit document beschreven.

Snelle manier om vast te stellen wanneer het probleem is veroorzaakt door de Stale/Phantom-sessie

Om vast te stellen of AnyConnect tijdens de omleidingsfase aan de voorwaarden voldoet, wordt veroorzaakt door de stapelbare/spooksessie. We moeten toegang krijgen tot het eindpunt terwijl het in de problematische staat is.

1.  Systeemscangegevens onderzoeken:
   
   

     1. Klik op het tandwielpictogram in AnyConnect UI

   

         2. Navigeer in het nieuwe venster naar System Scan > Statistics

   

           Let hier op twee elementen:

   •   Nieuwste starttijd voor scannen - het tijdstempel hier moet sluiten op het tijdstip waarop het probleem is ontdekt.
   •   Policy Server - dit veld gaf de naam aan van de beleidsserver die een postuur beoordeling deed voor het eindpunt. De FQDN moet vanuit hier worden vergeleken met FQDN van Redirect-URL (voor basispostuur omleiden) of met de PSN-naam die is ontleend aan de laatste verificatiepoging (voor een postuur zonder omleiding).
2. Vergelijk Policy Server FQDN van System Scan Statistics met de nodenaam die verificatie deed voor endpoint:

In de demo zijn de stappen opgenomen die nodig zijn voor de identificatie van het probleem:

Geavanceerde probleemoplossing van statische/spooksessie

Het vorige voorbeeld dient om de kwestie van een vervelende of spookzitting te onderscheiden van het probleem van het ontdekkingsproces dat niet begon.

Tegelijkertijd moeten we de sessie identificeren die het probleem heeft veroorzaakt, om beter te begrijpen hoe het nu precies een vervelende of spooksessie wordt.

Hoewel in sommige scenario's vervelende en spooksessies niet kunnen worden vermeden, moeten we ervoor zorgen dat best practices worden geïmplementeerd zodat er geen vervelende/spooksessies worden gecreëerd in de omgeving.

DART-bundelverzameling

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

• Houd alleen belangrijke logbestanden in het DART. Het wordt aanbevolen om de logbestanden te wissen voordat het probleem wordt gereproduceerd. 

Om dit te bereiken, moet het DART bundelhulpprogramma beginnen als beheerder en logopmaak uitvoeren. 

1. Op Windows Navigate om te beginnen en te beginnen met het typen van DART, klik met de rechtermuisknop en kies - Uitvoeren als beheerder
   
   
2. Klik in het eerste tovenaarsscherm op Volgende.
   
   
3. Klik in het volgende scherm van de wizard op Alle logbestanden wissen.
   
   

4. Nadat het probleem wordt gereproduceerd, kan DART worden verzameld van hier; klik op Volgende.

DART-bundelanalyse

Nadat de DART-bundel is verzameld, verwijdert u de archivering en concentreert u zich op het bestand AnyConnect_ISEPosture.txt in de map Cisco AnyConnect ISE-poortmodule. Dit bestand bevat alle gebeurtenissen die met de ontdekking te maken hebben.

1. Start probleemoplossing en identificeer alle momenten waarop de detectie opnieuw wordt gestart. De trefwoorden die u wilt zoeken, zijn Discovery of HTTP-detectie opnieuw starten. Blader hier naar de lijn met de herstart van de ontdekking die op het problematische moment plaatsvond:

2. Verscheidene lijnen na ontdekking herstart, is er een lijn die - Probing geen MNT stadiumdoelstellingen bevat. Dit is een indicator van stadium 1 ontdekkingsbegin:

Aanbevolen wordt om alle op omleiding gebaseerde sondes met dezelfde kleur en eerder verbonden PSNs uit ConnectionData.xml (Auth-Status targets) in een andere kleur te markeren.

Normaal gesproken zijn PSN FQDN's zeer vergelijkbaar en het is moeilijk om het verschil te zien.

3.Lees de logbestanden om een resultaat te zien voor elke sonde. Dit is een voorbeeld van hoe de mislukte sonde eruit ziet:

4. Ergens in het bestand na de ontdekking van de herstart voor fase 1 of fase 2, ziet u een succesvol antwoord van een of meer PSN's:

5. Verschillende regels later is er een regel met het trefwoord MSG_NS_SWISS_NEW_SESSION.

Deze regel bevat een feitelijke sessie-ID die door PSN is geselecteerd als resultaat van het zoeken naar de sessie.

Gebruik deze sessie-ID voor verder onderzoek naar ISE om te bepalen hoe deze sessie oud/fantoomloos wordt:

Onderzoek op ISE-logbestanden

 In de guest.log met de component clientwebapp ingeschakeld in DEBUG, kan de PSN die met de Stale/Phantom sessie antwoordt worden gezien.

PSN krijgt een verzoek van de ISE postuur agent. Dit is een verzoek van AnyConnect vanwege de User-Agent-waarde:

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

Het verzoek bevat arrays van IP adressen en MAC adressen. In dit voorbeeld heeft elke array slechts één waarde.

Het logboek toont aan dat de sessie-ID van het verzoek ongeldig is, wat aangeeft dat dit een verzoek is van de niet-redirect-gebaseerde sonde.

Later kunt u zien hoe waarden uit 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

Na de regel met de trefwoorden Verzonden http response, kunt u de inhoud zien van het echte antwoord:

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-verslagen

Nadat u het ID van de vervelende/fantoomsessie kent, kunt u het Radius-accountingrapport onderzoeken om een beter begrip te krijgen van wat deze sessie heeft veroorzaakt tot vervelend/spookbeeld:

• Navigeer naar Operations > Reports > Endpoints en Gebruikers > Radius-accounting rapport en voer dit rapport 7 dagen uit. Gebruik een endpoint-id als filtertoets.

Hier is een voorbeeld van een rapport dat laat zien hoe ouderwetse sessie nog over is op ciscolive-ise2:

1. De boekhoudkundige start van de sessie kwam bij de PSN ciscolive-ise2.
2. De tussentijdse update voor de sessie werd op hetzelfde PSN verwerkt.
3. Een boekhoudkundig stopbericht voor de problematische sessie-ID kwam tot een andere PSN (ciscolive-ise1).

Een snelle manier om te bepalen wanneer het probleem is veroorzaakt door het ontbreken van een herstart van de detectie

Hier is dezelfde logica van toepassing als bij de vorige kwestie. Het enige verschil is dat u zich moet richten op de laatste starttijd voor scannen. Voor dit soort problemen is de tijdstempel van de laatste scan ergens in het verleden.

Normaal gesproken wanneer de eindgebruiker een probleem ontdekt, wordt er een scan gezien die enige tijd geleden heeft plaatsgevonden. Tijdens de Live-logbestanden van de ISE-straal worden recente verificatiepogingen vanaf het problematische eindpunt waargenomen.

In de demo zijn de stappen opgenomen die nodig zijn voor de identificatie van het probleem:

Geavanceerde probleemoplossing - geen herstart van detectie

De benadering hier is zeer gelijkaardig aan de Geavanceerde sectie van de Oplossing van het Probleem/Spookzitting. Het belangrijkste element van probleemoplossing is het DART bundelonderzoek.

Binnen de DART bundel, kunt u zoeken naar ontdekkingsherstart (zoals getoond voor de vorige kwestie) en bevestigen dat er geen ontdekkingsherstart was op het moment dat het probleem werd gemeld.

Aan de kant van ISE, focus op het verificatierapport Radius Live Logs/Radius om te bevestigen dat er failover tussen PSNs was of dat nieuwe sessie-ID is gegenereerd door NAD.

Oplossing

Klassieke benadering - emissievermijding

Van oudsher was er geen eigenschap op ISE die problemen kon oplossen die in dit document worden beschreven, dus de enige manier was om te vertrouwen op de reeks beste praktijken die worden geïmplementeerd op het netwerk en de ISE-zijde de minimaliseren risico's.

Beste praktijken die de hoeveelheid verhaal of spooksessies in de plaatsing van ISE kunnen minimaliseren

Voer waar mogelijk altijd een omleidingsgerichte houding uit

Een tegenargument tegen deze aanbeveling is een slechte gebruikerservaring; pop-ups in het OS of Browsers worden gezien. Dit geeft een omleiding aan terwijl AnyConnect ISE-poortmodule op de achtergrond een beoordelingsproces uitvoert.

Als oplossing hiervoor is het mogelijk om alleen ISE Posture module detectietests om te leiden en selectief al het andere verkeer toe te laten.

Dit voorbeeld laat zien hoe ACL alleen kan worden gebruikt om HTTP-verzoeken naar Discovery Host te sturen (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, kunnen dergelijke omleidingen van ACL worden gecombineerd met DACL die is toegewezen via ISE.

In wachtstand kunt u alleen verbindingen maken met PSN waarbij eindpunt is geverifieerd

Deze benadering is nuttig voor omgevingen waar url-omleiding niet wordt ondersteund (bijvoorbeeld implementaties met de NAD's van derden).

Als oplossing, implementeren van meerdere PosturePending autorisatiebeleid (één per PSN). Elk beleid moet als één van de voorwaarden de naam van PSN bevatten waar de authentificatie plaatsvond.

In het autorisatieprofiel dat is toegewezen aan elke beleidstoegang, moeten alle PSN's worden geblokkeerd, behalve de knooppunt waar de verificatie heeft plaatsgevonden.

Beleid voor autorisatie maken voor implementatie van 2 knooppunten:

 

1. Positie hangende beleid voor PSN1

2. De naam PSN1 wordt als voorwaarde in de polis gebruikt.

3. Autorisatieprofiel met ACL die de toegang tot alle PSN behalve PSN1 blokkeert.

4. Positie hangende beleid voor PSN2.

5. De naam PSN2 wordt als voorwaarde in de polis gebruikt.

6. Autorisatieprofiel met ACL die de toegang tot alle PSN behalve PSN2 blokkeert.

7. Beleid van de post "conform" vergunning.

In deze afbeelding wordt uitgelegd hoe deze benadering werkt:

1. Verificatiehits PSN1.

2. Als gevolg van een geconfigureerd autorisatiebeleid kent PSN1 een autorisatieprofiel toe dat de toegang tot alle andere knooppunten behalve PSN1 blokkeert.

3. AnyConnect ISE-poortmodule start het detectieproces opnieuw.

4. Sonde naar PSN2 wordt geblokkeerd door het NAD zoals door een eerder toegewezen ACL.

5. Sonde aan PSN1 wordt toegestaan door ACL die op NAD wordt toegewezen.

Best practices voor taakverdeling

• Schakel stickiness op de load balancer in voor authenticatie en accounting met Calling-Station-ID als stickiness-toets. Klik hier voor meer informatie over de best practices van LB voor ISE.
• Gebruik een stickiness timer langer dan een gemiddelde werkdag om het moment te bedekken waarop de pc in slaap valt (bijvoorbeeld 10 uur in plaats van 8 uur).
• Als opnieuw authenticeren is geïmplementeerd, gebruikt u een herverificatietimer die iets lager is dan de stickiness timer (bijvoorbeeld 8 uur als de stickiness 10 uur is ingesteld). Dit waarborgt dat het kleverheidsinterval door re-authentificatie wordt verlengd.

Posture over VPN use-case 

• Zorg ervoor dat de accounting-interim update interval hoger of gelijk is aan de VPN-sessie-timeout. Dit minimaliseert accounting flapping tussen PSNs tijdens lange VPN sessies. 

Dit voorbeeld toont het tussentijdse boekhoudkundige updateinterval dat voor 20 uren wordt gevormd. Dit voorkomt niet dat de eerste tussentijdse update die IP-adres draagt dat is toegewezen aan het eindpunt.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

Er kunnen best practices worden geïmplementeerd om de impact van de afwezigheid van de herstart van de detectie van de ISE-poortmodule te minimaliseren

Posture lease inschakelen 

Dit is een functie op ISE die eindpunt markeert als conform voor een bepaalde periode (1-365 dagen). Posture lease value is een endpoint attribuut dat betekent dat het is opgeslagen ISE DB.

Alle endpointkenmerken die postuur-lease omvatten, worden over alle knooppunten in de ISE-implementatie gerepliceerd.

Wanneer PSN een nieuwe sessie krijgt voor de eindpuntpositie, kan de lease worden gebruikt om de sessie meteen als conform te markeren.

Om dit besluit te nemen, gebruikt PSN 3 waarden. Deze waarden zijn:

1. Het aantal dagen dat is gedefinieerd voor posterieverhuur in ISE-instellingen: Navigeren naar Beheer > Systeem > Houding > Algemene instellingen:

2. Waarde van het attribuut PostureExpiry is een eigenlijk eindpuntattribuut dat een Epoch timestamp bevat. De waarde van PostureExpiry is aanvankelijk bevolkt op de eerste succesvolle postuur poging voor eindpunt nadat de beheerder van ISE postuur huur toeliet.

Later deze waarde bijgewerkt op de volgende succesvolle postuur poging die gebeurt na afloop van de leaseovereenkomst.

            U ziet een PostureExpiry in Context Visibility > Endpoints terwijl een van de postured endpoints wordt geopend:

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

3. De systeemtijd van PSN op het moment dat nieuwe verificatie plaatsvindt

Wanneer de authentificatie voor een eindpunt met posteriehuur PSN raakt, gebruikt het PostureExpiry en systeemdatum om het aantal dagen te krijgen die van de laatste succesvolle posteringcontrole zijn verstreken.

Als de resultaatwaarde binnen een posture-leaseinterval valt dat in instellingen is gedefinieerd, krijgt de sessie een conforme status.

Als de resultaatwaarde hoger is dan de leasewaarde, krijgt de sessie een Onbekende status.

Hierdoor wordt de houding opnieuw uitgevoerd en kan de nieuwe PostureExpiry waarde worden opgeslagen.

In dit diagram wordt het proces weergegeven bij een failover:

1. De eerste verificatie gebeurt met PSN1.

2. Session ABC wordt in het sessiecache gemaakt.

3. De beoordeling van de houding gebeurt.

4. Sessiestatus verandert in conform

5. COA wordt geactiveerd door wijziging van de postuur status en leidt tot opnieuw authenticeren van het eindpunt om het volgende toegangsniveau toe te passen.

6. De waarde van PostureExpiry wordt opgeslagen in het eindpunt.

7. De endpointgegevens worden tijdens de implementatie gerepliceerd.

8. Volgende verificatie bereikt PSN2.

9. PSN2 controleert of het eindpunt zich in een geldige posterieuslease bevindt.

11. Session wordt als conform aan het sessiecache toegevoegd.

12. Vanwege de geldige lease wordt de sessie aangemaakt met status conform.

Implementatie van herverificatie 

Druk altijd op herverificatietimer van ISE met RADIUS-request, geselecteerd in Connectiviteit onderhouden tijdens herverificatie. Deze instelling zorgt ervoor dat NAD dezelfde sessie-ID bij herverificatie houdt.

.

Omgevingen met taakverdeling

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

Verschillende subnetten kunnen worden gebruikt voor wachtende en compatibele staten

Wanneer het netwerkontwerp de mogelijkheid biedt om verschillende subnetten te gebruiken die hangende en conforme staten zijn, garandeert deze benadering dat elke verandering in de status van de postuur resulteert in de standaardgateway.

Standaardevaluatie gebruikt in dezelfde interval als een herverificatieteller

Houdingsevaluatie kan worden ingeschakeld met een interval dat gelijk is aan de herverificatietimer. In een dergelijk geval, wanneer het originele PSN niet beschikbaar wordt, herstart PRA-storing het detectieproces.

Moderne aanpak - Positie staat delen

Als deel van een geïmplementeerde verbetering (beschreven in Cisco bug ID CSCvi35647 ) heeft patch 6 voor ISE 2.6 een nieuwe functie die de status van het delen van de sessiestatus van alle knooppunten in ISE-implementatie implementeert.

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

Deze nieuwe functie is gebaseerd op Light Session Directory (LSD) mechanisme dat is geïntroduceerd in ISE 2.6. In de nieuwere versies is deze functionaliteit hernoemd naar Light Data Distribution (LDD) Radius Session Directory.  Light Data Distribution is standaard ingeschakeld en maakt het delen van een beperkte sessiecontext tussen ISE-knooppunten mogelijk. Er is niet zoiets als volledige sessiecontextreplicatie tussen PSN's, slechts een beperkte hoeveelheid attributen gedeeld voor elke sessie.

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 sessieeigenaar moet bepalen.

Meestal is het zoeken van de eigenaar nodig wanneer de Cacao stroom begint. Met LDD kan elke PSN een eigenlijke eigenaar van de sessie vinden vanuit het lokale Radius Session Directory cache. 

Architectuur voor lichtgegevensdistributie

Deze functionaliteit bevat de volgende elementen:

• Radius Session Directory (RSD) cache

Deze cache bestaat op elk ISE-knooppunt en slaat alle actieve sessies op die in ISE-implementatie worden gepresenteerd. Elke sessie heeft een beperkte hoeveelheid attributen in de cache. 

Hier zijn voorbeelden van de kenmerken die in de Radius Session Directory zijn opgeslagen voor elke sessie:

• Sessie-ID
• Endpoint MAC
• BelStation-id
• Endpoint IP
• PSN IP - PSN waar verificatie heeft plaatsgevonden
• PSN-FQDN 
• NAS-IP-adres
• NAS-IPv6-adres
• Staat - geverifieerd, gestart, gestopt

• RabbitMQ uitwisseling

Er is een uitwisseling gevormd waarin Uitgever, verwante Wachtrij, en Consument op elke knoop in de plaatsing van ISE worden voorgesteld. Dit waarborgt dat de topologie met volledige mesh tussen alle ISE-knooppunten vormde.

• Uitgever

De Radius Session Directory staat hier voor een uitgever. Wanneer een nieuwe succesvolle verificatie wordt verwerkt door een PSN, wordt er een nieuwe sessie gemaakt in het PSN-sessiecache.

Voor deze sessie wordt een beperkte set kenmerken in de Radius Session Directory geplaatst.

• Consument - op alle andere knooppunten; Radius Session Directory vertegenwoordigt een consument.

De figuur legt uit hoe COA flow werkt met RSD cache:

1. De eerste verificatie gebeurt met PSN1.

2. Session ABC wordt in het sessiecache gemaakt.

3. De vereiste eigenschappen worden opgeslagen in RSD.

4. Sessie wordt gedeeld via RabbitMQ met alle andere ISE-knooppunten.

5. Session wordt op alle ISE-knooppunten in RSD-cache gemaakt.

6. Op PSN2 worden nieuwe profielgegevens aangeleverd.

7. Endpoint wordt opnieuw geprofileerd en (in het geval van een wijziging waarvoor Cacao-uitvoering vereist is PSN2) gaat met de volgende stap verder.

8. Een interne API-oproep wordt naar RSD-cache gestuurd om de OCR uit te voeren.

9. De gegevens van het RSD-cachegeheugen worden gebruikt om een Proxy-COA-bericht voor te bereiden. Het gaat van de ene ISE-knooppunt naar de andere en bevat alle details die de doelknooppunt kan gebruiken om een CAO-verzoek terug te sturen naar NAD. Het COA-bericht wordt eerst intern naar PRT Runtime (Actual AAA-server binnen ISE) verzonden.

10. PSN2 verstuurt een COA-bericht naar PSN1.

11. PSN1 stuurt een COA-bericht naar NAD.

Om de communicatie via LDD op de ISE op te lossen, schakelt u de component Light Session Director in DEBUG:

Hier is een voorbeeld van een debug bericht van lsd.log bestand voor het maken van sessies en publicatie op de 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-knooppunten ziet u hoe een sessie is geconsumeerd:

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

Positie Status Sharing via RSD

Positie status delen lost problemen op wanneer de worteloorzaak is of Stale/Phantom sessie of re-authenticatie op verschillende PSN die niet ontdekking opnieuw starten.

Zodra de sessie conform wordt, wordt deze informatie geplaatst in de sessie RSD, en later kan het worden gebruikt door elke PSN in de implementatie.

Er zijn nog enkele andere hoekcases die de beschreven functie niet kan oplossen. Bijvoorbeeld een scenario wanneer NAD opnieuw verificatie uitvoert op hetzelfde PSN maar met een andere sessie-ID.

Dergelijke scenario's kunnen worden behandeld met de beste praktijken die in dit document worden beschreven.

Dit cijfer toont de topologie aan die voor een test van het delen van de postuur wordt gebruikt:

Posture Status delen via RSD - Stale/Phantom Session

Om een verouderde sessie te creëren, moet de authenticatie eerst uitgevoerd worden op de skuchere-ise26-1. Dan, NAD moet worden aangepast om boekhouding naar skuchere-ise26-3 te verzenden.

Nadat een boekhoudbericht is doorgestuurd naar de verkeerde PSN, moet NAD (opnieuw) worden aangepast om de boekhouding terug te sturen naar skuchere-ise26-1.

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

1. Door skuchere-ise26-1 verwerkte berichten voor het opstarten van een accounting.

2. tussentijdse boekhoudkundige update voor dezelfde sessie verwerkt door skuchere-ise26-3.

3. De sessie eindigt later op skuchere-ise26-1.

Na enige tijd verbindt het eindpunt opnieuw met het netwerk, maar de omleiding werkt niet meer. In de guest.log van PSN - 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 stapelbare/spooksessie houdt voor het eindpunt, antwoordt het niet op de ISE postermodule en dit stelt ons in staat om het juiste antwoord te krijgen van de PSN waar de laatste authenticatie plaatsvond.

Als oplossing voor het probleem van de vervelende/fantoomsessie op het moment van de sessie-lookup, controleert PSN de aanwezigheid van een nieuwe sessie voor het eindpunt in de RSD.

Indien RSD een andere sessie-ID bevat dan wat PSN heeft in het lokale sessiecache, wordt ervan uitgegaan dat de sessie (gepresenteerd in het sessiecache) verouderd is.

Posture Status Sharing over RSD - failover tussen PSNs

Om dit scenario te reproduceren, wordt een korte herverificatietimer ingeschakeld in het autorisatieprofiel dat is toegewezen aan het compatibele eindpunt.

Later, NAD is opnieuw geconfigureerd om verificatie en accounting naar een andere PSN (skuchere-ise26-3) te sturen.

Na het verlopen van de verificatietimer wordt dezelfde sessie niet geverifieerd op de verschillende PSN.

De figuur toont een verificatierapport dat de failover voor dezelfde sessie laat zien van skuchere-ise26-1 tot skuchere-ise26-3:

1. Verificatie vindt plaats op skuchere-ise26-1, autorisatieprofiel met omleiding is toegewezen.

2. CVA na een geslaagde beoordeling van de houding.

3. Volgende verificatie wanneer een autorisatieprofiel voor de compatibele status is toegewezen.

4. Verificatie raakt verschillende PSN, maar krijgt nog steeds een autorisatieprofiel voor de compatibele staat.

De sessie heeft een compatibele status op de 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 is opgelost door toevoeging van extra logica in het postuur status selectieproces.

Dit cijfer laat zien wat er is veranderd (wijzigingen gemarkeerd in rood):