Problemen met ISE-sessiebeheer en houding oplossen

Inleiding

Dit document beschrijft het probleem van de Common Identity Service Engine (ISE)-houdingsservices: "AnyConnect ISE-houdingsmodule voldoet aan de vereisten..."

Achtergrondinformatie

In dit document wordt het probleem met de postuur van de Common Identity Service Engine (ISE) beschreven. De posture-module van AnyConnect ISE is compatibel terwijl de sessiestatus van ISE in behandeling is.

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

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

In dit document wordt uitgelegd:

• Probleemmanifestatie vanuit het perspectief van de eindgebruiker en de ISE-beheerder.
• Veelvoorkomende problematische scenario's.
• De theorie achter ISE, AnyConnect en netwerkbewerkingen die het probleem veroorzaken.
• Algoritmes voor snelle probleemidentificatie.
• Klassieke oplossingen voor veel voorkomende problematische scenario's.
• Het delen van de houdingsstatus over de Radius-sessiemap.

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

Probleem

Eindgebruikerservaring

Dit probleem manifesteert zich normaal gesproken in de afwezigheid van netwerktoegang of constante omleiding naar het ISE-portaal voor clientvoorziening in de browser, terwijl tegelijkertijd de AnyConnect ISE-houdingsmodule de houdingsstatus Compliant weergeeft.

Typische eindgebruikerservaring:

ISE-beheerderservaring

Normaal gesproken voert de ISE-beheerder in de eerste triage van dit probleem het Radius Live-logboekonderzoek uit om ervoor te zorgen dat er een daadwerkelijke verificatie is die de ISE raakt.

Het eerste symptoom dat in deze fase wordt ontdekt, duidt op een mismatch in een houdingsstatus tussen eindpunt en ISE, zoals in de live logs of Radius-verificatierapporten de laatste succesvolle verificatie voor het eindpunt toont de wachtende houdingsstatus.

Typische ISE-beheerderservaring:

• Laatste succesvolle authenticatie voor Identity: alice.
• De status van de sessie is in behandeling.
• Laatste sessie voor Identity: alice.
• De sessie-gebeurtenis geeft de status van de houding weer als Voldoet aan.

Opmerking: c. en d. worden niet altijd weergegeven in de live logs wanneer het beschreven probleem zich voordoet. Een sessie-evenement met een postuur-status van Compliant komt vaker voor bij scenario's die worden veroorzaakt door de verouderde of spookachtige sessies (later in dit document beschreven).

Veelvoorkomende problematische scenario's

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

• De AnyConnect ISE-posturemodule is tijdens het posturatieproces verkeerd geïnformeerd door de Policy Service Node (PSN), waardoor de verkeerde posturatiestatus werd weergegeven. 

In dit geval hebben we normaal gesproken te maken met een verouderde of fantoomsessie in de PSN-sessiecache.

• AnyConnect ISE toont de houdingsstatus van de vorige detectiecyclus omdat de huidige verificatie geen detectieproces heeft geactiveerd.

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

Stale/fantoomsessieprobleem

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

ISE-sessiebeheerlogica

Bij ISE-implementatie zijn er 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 in deze afbeelding wordt uitgelegd, maakt MNT-node seizoenen op basis van de doorgegeven verificatie Syslog-berichten die afkomstig zijn van PSN's.

De sessiestatus kan later worden bijgewerkt door de Syslog voor boekhouding.

Sessieverwijdering op MNT gebeurt in 3 scenario's:

1. Sessies zonder boekhoudkundige start worden ongeveer 60 minuten nadat ze zijn gemaakt verwijderd: er wordt elke 5 minuten een cron-taak uitgevoerd om de sessiestatus te controleren en op te schonen.

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

3. Dezelfde kroon op elke uitvoering verwijdert ook sessies die langer dan 5 dagen (120 uur) in de status 'Gestart' zijn geweest. Een starttoestand betekent dat de MNT-node zowel verificatie als boekhouding heeft verwerkt om Syslog voor de sessie te starten.

Voorbeelden van Syslog-berichten van PSN:

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

Geslaagde verificatie:

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

Boekhoudkundige start:

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

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 een specifieke PSN opslaat. De sessiecache is altijd lokaal in de node.

Er is geen mechanisme in ISE dat replicatie van de FULL-sessiestatus van de ene node naar de andere kan uitvoeren.

Voor elke actieve sessie-ID slaat PSN alle attributen op die zijn verzameld tijdens de authenticatie-/autorisatiefase (bijvoorbeeld Interne/Externe gebruikersgroepen, Network Access Device (NAD) attributen, certificaatattributen, enzovoort). Deze attributen worden door PSN gebruikt om verschillende beleidstypen te selecteren (zoals Authenticatie, Autorisatie, Client Provisioning en Posture).

De sessiecache wordt volledig verwijderd wanneer de node (of services op de node) opnieuw wordt gestart.

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

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

Als het gaat om sessieverwijdering, implementeert PSN deze logica:

• De vermelding van de sessiecache wordt onmiddellijk verwijderd na het verwerken van het bericht voor het stoppen van de boekhouding.
• PSN begint met het verwijderen van de laatst gebruikte sessies wanneer een node de limiet van actieve sessies bereikt.

Verouderde sessie op PSN

In ISE-implementatie is de boekhoudstop voor een bestaande sessie verwerkt door de PSN die de daadwerkelijke verificatie niet heeft uitgevoerd:

Voorbeeld van de verouderde sessie:

1. Een PSN-sessie voor ABC wordt met succes geverifieerd.

2. PSN maakt een item aan in de sessiecache.

3. Houding beoordeling gebeurt.

4. De sessie is gemarkeerd als Conform.

5. Wijziging van de autorisatie (COA) (veroorzaakt door verandering van de houdingsstatus) leidt tot herverificatie van het eindpunt om het volgende toegangsniveau toe te passen.

6. Boekhoudstop voor sessie ABC komt naar PSN2.

Daarna komt ABC vast te zitten in de muffe toestand op de PSN1 omdat er geen boekhoudstopbericht op deze PSN is verwerkt om het te verwijderen.

De sessie wordt voor een lange tijd verwijderd als de implementatie niet wordt gekenmerkt door een groot aantal verificatiepogingen.

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

• De boekhoudstop kwam tot de verkeerde PSN als gevolg van plakkerigheid timer vervaldatum op de load balancer.
• De verkeerde configuratie op de NAD is niet dezelfde PSN die is geconfigureerd voor verificatie en boekhouding.
• Tijdelijke connectiviteitsproblemen op het netwerkpad die NAD-failover naar de volgende PSN veroorzaken.

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

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

2. Met deze verificatie wordt een kleverige timer op de taakverdeler gestart.

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

4. Syslog-bericht voor doorgegeven verificatie overgebracht naar MNT-node.

5. Entry voor sessie-ABC wordt gemaakt in de MNT-sessiemap met de status Authenticated.

6. Boekhoudkundig startbericht voor sessie ABC landt op PSN 1.

7. De sessiecache-invoer voor sessie-ABC wordt bijgewerkt met informatie van Accounting-Start.

8. Syslog-bericht voor Accounting-Start wordt overgebracht naar MNT-node.

9. De sessiestatus wordt bijgewerkt naar Gestart.

10. Stickiness timer vervalt op de load balancer.

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

12. Syslog-bericht voor Accounting-Stop wordt door PSN 2 doorgestuurd naar MNT.

13. Sessie-ABC wordt gemarkeerd als beëindigd op MNT.

Phantom Session op de PSN

De fantoomsessie is een scenario waarin tussentijdse boekhoudkundige update naar het PSN komt die geen verificatie voor deze specifieke sessie heeft uitgevoerd. In dit scenario wordt een nieuw item gemaakt in de PSN-sessiecache.

Als PSN geen bericht voor het stoppen van de boekhouding voor deze sessie ontvangt, wordt de vermelding niet verwijderd, tenzij PSN de limiet van actieve sessies bereikt.

Voorbeeld van de fantoomsessie:

1. Dezelfde stappen als beschreven in het verouderde sessievoorbeeld worden uitgevoerd op PSN1 voor de ABC-sessie.

2. Sessie-ABC heeft een status Compliant in de PSN1-sessiecache.

3. Een tussentijdse boekhoudkundige actualisering voor sessie ABC treft PSN2.

4. Er wordt een sessie-item voor sessie-ABC gemaakt op PSN2. Omdat de sessievermelding is gemaakt op basis van het boekhoudbericht, heeft deze een beperkt aantal kenmerken. De status van de houding is bijvoorbeeld niet beschikbaar voor sessie-ABC. Ook zaken als gebruikersgroepen en andere autorisatiespecifieke attributen ontbreken.

De fantoomsessie wordt in de PSN-sessiecache weergegeven in de volgende scenario's:

• Korte termijn uitval op het transitnetwerk.
• Verkeerd gedrag van netwerktoegangsapparaat.
• Verkeerd gedrag of verkeerde configuratie bij taakverdeling.

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

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

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

3. Het syslog-bericht voor doorgegeven verificatie wordt overgebracht naar de MNT-node.

4. Er wordt een item voor sessie ABC gemaakt in TimesTen DB met de status Geverifieerd.

5. Het boekhoudingsstartbericht voor sessie ABC wordt op PSN 1 geplaatst.

6. Een sessiecache-item 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 status van de sessie wordt bijgewerkt naar Gestart.

9. De tussentijdse actualisering van de boekhouding voor sessie ABC wordt doorgestuurd naar PSN2.

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

11. De boekhoudsessie voor ABC 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 PSN 1 doorgestuurd naar MNT.

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

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

1. Eerste verificatie op PSN1.

2. Sessie-ABC wordt gemaakt in de sessiecache.

3. Met boekhouden wordt het bericht gestart dat door het PSN wordt verwerkt.

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

5. Een tussentijdse actualisering van de boekhouding met informatie over het IP-adres komt op PSN terecht.

6. IP-adresgegevens worden toegevoegd aan de sessiecache.

7. Houding beoordeling gebeurt met PSN1.

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

9. Een COA-push wordt uitgevoerd door ISE; hierdoor wordt een nieuw toegangsniveau toegewezen.

10. Er is een storing op het netwerkpad waardoor PSN1 niet toegankelijk is.

11. Na het verstrijken van een tussentijds actualiseringsinterval constateert ASA/FTD dat PSN1 ontoegankelijk is. 

12. De tussentijdse actualisering van de boekhouding heeft betrekking op PSN2.

13. De fantoomsessie wordt gemaakt in de PSN2-sessiecache.

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

Hoe muffe sessie en fantoomsessie het houdingsproces doorbreken

Als u wilt begrijpen hoe de verouderde sessie en de fantoomsessie de houding doorbreken, kunt u het proces voor het opsporen van de AnyConnect ISE-houdingsmodule bekijken:

Fase 1 Ontdekking:

Tijdens deze fase voert de ISE-houdingsmodule 4 gelijktijdige sondes uit om de PSN te vinden die een verificatie voor het eindpunt heeft uitgevoerd.

Ten eerste zijn 3 sondes op de figuur omleidingsgebaseerd (standaard GW IP). Discovery host IP (indien gedefinieerd) en enroll.cisco.com IP); Deze probes wijzen de agent altijd naar de juiste PSN als omgeleide URL wordt genomen van de NAD zelf.

Probe nummer 4 wordt verzonden naar alle primaire servers die worden weergegeven in het bestand ConnectionData.xml. Dit bestand wordt aangemaakt na de eerste succesvolle posturepoging. 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\.

Omdat alle fase 1-sondes gelijktijdig worden uitgevoerd, wordt het resultaat van sonde 4 alleen gebruikt als alle andere 3-sondes zijn mislukt of als de ISE-houdingsmodule niet in staat was om binnen 5 seconden een goede communicatie tot stand te brengen met de PSN die in redirect-URL is geretourneerd.

Wanneer probe 4 op de PSN terechtkomt, 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 muffe of fantoomsessie heeft voor een eindpunt, kan dit resulteren in een verkeerde houdingsstatus die later aan de clientzijde wordt weergegeven.

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

Fase 2 Detectie:

Alle fase 2-detectiesondes zijn omleidingsloos, wat betekent dat elke sonde een sessie-opzoeking op de PSN-bestemming activeert.

Als de PSN de sessie niet kan vinden in de lokale sessiecache, moet deze een MNT-zoekopdracht uitvoeren (alleen op basis van het MAC-adres) om de 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 ontdekking van fase 2 nog meer worden beïnvloed door problemen als gevolg van verouderde of fantoomsessies.

Als PSN fase 2 bereikt, maakt de detectieprobe die in de sessiecache bestaat een stabiel of fantoomitem voor hetzelfde eindpunt. Het resultaat is dat de verkeerde houding wordt teruggegeven aan de eindgebruiker.

Het voorbeeld laat zien hoe houding gebeurt wanneer PSN een muffe sessie of fantoomsessie houdt:

Opmerking: dit probleem kan zich alleen voordoen wanneer alle detectieprobes op basis van omleiding falen of wanneer een niet-omleidingshouding wordt geïmplementeerd.

1. Alle sondes van Zoek mijn sessie die zijn uitgegeven door de ISE-module voor houding.

2. PSN voert het opzoeken van sessies uit in de sessiecache. Als de sessie wordt gevonden, treedt er een verouderd of fantoomsessieprobleem op.

3. PSN voert de beleidsselectie voor clientprovisioning uit. In het geval dat een fantoomsessie met een gebrek aan verificatie-/autorisatiekenmerken en alle beleidsregels die door de klant zijn geconfigureerd, zeer specifiek zijn (er worden bijvoorbeeld beleidsregels gemaakt voor specifieke Active Directory-groepen), kan PSN geen beleid voor de juiste clientvoorziening toewijzen. Dit kan zich uiten in de foutmelding: "AnyConnect-scan omzeilen terwijl uw netwerk niet is geconfigureerd voor het gebruik van Cisco NAC Agent".

• In gevallen waarin het beleid voor clientprovisioning generiek is (kenmerken die beschikbaar zijn in de fantoomsessie zijn voldoende om het beleid te matchen met de AnyConnect-configuratie), antwoordt PSN met details die nodig zijn voor de voortzetting van het evaluatieproces.
• In deze stap, wanneer we kunnen omgaan met muffe sessies, reageert PSN meteen met een postuur status van Compliant en worden alle volgende stappen niet uitgevoerd. PSN stuurt COA niet omdat het van mening is dat de sessie al voldoet. In Radius Live-logs wordt geen sessie-evenement weergegeven met de status Compliant.

4. Voor het scenario van de fantoomsessie gaat de ISE-houdingsmodule verder met het eerste houdingsverzoek. Dit verzoek bevat informatie over alle beveiligings- en patchbeheerproducten die op het eindpunt zijn gedetecteerd.

5. PSN gebruikt informatie uit de aanvraag- en sessiekenmerken om overeen te komen met het juiste houdingsbeleid. Omdat de fantoomsessie op dit moment een gebrek aan attributen heeft, hebben we geen beleid om overeen te komen. In een dergelijk geval reageert PSN op het eindpunt dat het voldoet. Dit is een standaard ISE-gedrag in het geval van een niet-overeenkomende houding. 

Opmerking: Wanneer er een algemeen beleid is dat kan worden geselecteerd uit fantoomsessiekenmerken, gaan we verder met stap 6.

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

Opmerking: als er geen beleid kan worden geselecteerd, retourneert PSN de status Compliant.

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

8. Evaluatie van het rapport gebeurt op ISE en wijzigingen in de sessiestatus van Compliant.

Opmerking: In het geval van houdingsproblemen veroorzaakt door de fantoomsessie, merkt de ISE-beheerder mogelijk een aantal mislukte houding-COA's op. In dergelijke gevallen worden COA-verzoeken uitgevoerd vanaf de verkeerde PSN's en voor verkeerde sessie-ID's.

Detectieproces start niet bij een nieuwe verificatiepoging

De ISE-posture-module is ontworpen om een beperkt aantal gebeurtenissen op het eindpunt te bewaken om een detectieproces te activeren.

Gebeurtenissen die ontdekking veroorzaken:

• Initiële installatie van de ISE-houdingsmodule.
• Aanmelden bij gebruiker.
• Machtsgebeurtenissen.
• Statuswijziging van de interface.
• OS hervatten na de slaap.
• Standaardgateway (DG) wijzigen.
• Posture Reassessment (PRA)-fout, zie Cisco-bug-ID CSCvo69557

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

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

• Herverificatie raakt verschillende PSN (als gevolg van LB-beslissingen of problemen met het oorspronkelijke PSN).
• NAD genereert nieuwe sessie-id bij herverificatie.

Reauthenticatie op verschillende PSN

Dit diagram toont een voorbeeld van re-authenticatie op verschillende PSN veroorzaakt door de uitval van de originele PSN. Een scenario met een load balancer lijkt erg op elkaar.

In het geval van een load balancer wordt de herauthenticatie naar de verschillende PSN gestuurd als gevolg van een stickiness timer expiration.

1. Eerste verificatie op PSN1

2. Sessie-ABC wordt gemaakt in de PSN1-sessiecache.

3. Houdingbeoordeling wordt uitgevoerd met PSN1.

4. De status van de sessie-ABS-houding wordt verplaatst naar Compliant.

5. COA wordt geactiveerd door een verandering in de houdingsstatus en leidt tot herverificatie van het eindpunt om het volgende toegangsniveau toe te passen.

6. PSN1 is niet meer beschikbaar.

7. Herverificatie voor sessie-ABC bereikt PSN2.

8. Omdat het een nieuwe sessie voor PSN2 is, wordt de status van de sessie in behandeling.

De eerste houdingsstatus wordt door PSN toegewezen aan de sessie:

Opmerking: State-machine beschrijft alleen een eerste selectie van de houding status. Elke sessie die in eerste instantie als onbekend is gemarkeerd, kan later conform of niet-conform 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 onjuist geconfigureerd aan de ISE-zijde. De oplossing voor dit probleem wordt verderop in dit document behandeld.
• Wangedrag van NAD-zijde; normaal houdt NAD dezelfde sessie-ID bij tijdens de herauthenticatiepoging. Dit is een potentieel buggy gedrag dat moet worden onderzocht op de NAD zelf.

De nieuwe sessie-ID kan worden gegenereerd in andere scenario's in de hoek. In sommige gevallen kan bijvoorbeeld draadloos zwerven een oorzaak zijn.

Het belangrijkste hier is, ISE PSN plaatst altijd een nieuwe sessie in houding In afwachting van de staat, tenzij de houding lease is geconfigureerd. De houdingshoeveelheid wordt later in dit document uitgelegd.

Snelle manier om te identificeren wanneer het probleem werd veroorzaakt door de verouderde / fantoomsessie

Als u wilt bepalen of AnyConnect voldoet aan de voorwaarden terwijl het systeem zich in de omleidingsstatus bevindt, wordt dit veroorzaakt door de verouderde/spooksessie. We moeten toegang krijgen tot het eindpunt terwijl het zich in de problematische staat bevindt.

1.  Systeemscandetails onderzoeken:
   
   

     1. Klik op het tandwielpictogram in AnyConnect UI

   

         2. Navigeer in het nieuwe venster naar Systeemscan > Statistieken

   

           Besteed hier aandacht aan twee elementen:

   •   Laatste scanstarttijd - de tijdstempel hier moet dicht bij het moment zijn waarop het probleem werd ontdekt.
   •   Beleidsserver - dit bestand gaf de naam aan van de beleidsserver die een houdingsbeoordeling voor het eindpunt heeft uitgevoerd. De FQDN van hier moet worden vergeleken met FQDN van Redirect-URL (voor redirect-basishouding) of met de PSN-naam die is overgenomen van de laatste authenticatiepoging (voor redirect-less houding).
2. Vergelijk Policy Server FQDN van System Scan Statistics met de nodenaam die de verificatie voor het eindpunt heeft uitgevoerd:

De demo toont de opname van de stappen die nodig zijn voor de identificatie van problemen:

Geavanceerde probleemoplossing van een verouderde/fantoomsessie

Het vorige voorbeeld dient om het probleem van een verouderde of fantoomsessie te onderscheiden van het probleem van het ontdekkingsproces dat niet is gestart.

Tegelijkertijd moeten we de eigenlijke sessie identificeren die het probleem heeft veroorzaakt om beter te begrijpen hoe het precies een muf of spooksessieprobleem wordt.

Hoewel in sommige scenario's muffe en spookachtige sessies niet kunnen worden vermeden, moeten we ervoor zorgen dat best practices worden geïmplementeerd, zodat er geen muffe / spooksessies in de omgeving worden gemaakt.

DART-bundelcollectie

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

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

Om dit te bereiken, moet het DART-bundelhulpprogramma starten als beheerder en logopschoning uitvoeren. 

1. Navigeer in Windows naar Start en begin met het typen van DART, klik met de rechtermuisknop en kies - Uitvoeren als beheerder
   
   
2. Klik in het eerste wizardscherm op Volgende.
   
   
3. Klik in het volgende wizardscherm op Alle logboeken wissen.
   
   

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

DART-bundelanalyse

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

1. Start de probleemoplossing en identificeer alle momenten waarop de ontdekking opnieuw wordt gestart. Trefwoorden om te zoeken zijn Opnieuw starten van Discovery of HTTP Discovery. Navigeer hier naar de regel met de herstart van de ontdekking die op het problematische moment plaatsvond:

2. Meerdere regels na herstart van de ontdekking, is er een regel die bevat - Probing geen MNT-stadiumdoelen. Dit is een indicator voor het begin van de fase 1-ontdekking:

Het wordt aanbevolen om alle redirect-gebaseerde probes met dezelfde kleur en eerder verbonden PSN's afkomstig van ConnectionData.xml (Auth-Status targets) in een andere kleur te markeren.

Normaal gesproken lijken PSN FQDN's erg op elkaar en is het moeilijk om het verschil te zien.

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

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

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

Deze regel bevat een werkelijke sessie-ID die door PSN is geselecteerd als gevolg van het opzoeken van de sessie.

Gebruik deze sessie-ID voor verder onderzoek op ISE om te bepalen hoe deze sessie muf/fantoom wordt:

Onderzoek naar ISE-logs

 In het guest.log met de clientwebapp component ingeschakeld in DEBUG, is de PSN te zien die antwoordt met de Stale/Phantom sessie.

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

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

Het logboek laat zien dat de sessie-ID van het verzoek null is, wat aangeeft dat dit een verzoek is van de niet-redirect-gebaseerde sonde.

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

Na de regel met trefwoorden Verzonden http-reactie, kunt u inhoud van het eigenlijke antwoord zien:

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

Nadat u de ID van de verouderde / fantoomsessie kent, kunt u het Radius Accounting-rapport onderzoeken om een beter inzicht te krijgen in wat ervoor zorgde dat deze sessie muf / fantoom werd:

• Navigeer naar Bewerkingen > Rapporten > Eindpunten en Gebruikers > Radius Accounting-rapport en voer dit rapport gedurende 7 dagen uit. Gebruik een eindpunt-ID als filtersleutel.

Hier is een voorbeeld van een rapport dat laat zien hoe muffe sessie is overgebleven op ciscolive-ise2:

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

Een snelle manier om te identificeren wanneer het probleem werd veroorzaakt door de afwezigheid van Discovery Restart

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

Wanneer de eindgebruiker een probleem ontdekt, wordt normaal gesproken een scan gezien die enige tijd geleden heeft plaatsgevonden. Terwijl in de ISE Radius Live-logs, recente authenticatie pogingen van het problematische eindpunt worden gezien.

De demo toont de opname van de stappen die nodig zijn voor de identificatie van problemen:

Geavanceerde probleemoplossing De afwezigheid van Discovery Restart

De aanpak hier is zeer vergelijkbaar met Advanced Troubleshoot Stale / Phantom Session sectie. Het belangrijkste probleemoplossingselement is het DART-bundelonderzoek.

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

Aan de ISE-zijde kunt u zich concentreren op het verificatierapport Radius Live Logs/Radius om te bevestigen dat er sprake was van failover tussen PSN's of dat er een nieuwe sessie-ID is gegenereerd door NAD.

Oplossing

Klassieke benadering - Vermijden van problemen

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

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

Implementeer altijd een op omleiding gebaseerde houding wanneer mogelijk

Een veel voorkomend tegenargument voor deze aanbeveling is een slechte gebruikerservaring; pop-ups in het besturingssysteem of browsers worden gezien. Dit duidt op een omleiding terwijl de AnyConnect ISE-houdingsmodule op de achtergrond een beoordelingsproces uitvoert.

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

In dit voorbeeld ziet u ACL omleiden 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 aanvaardbaar beveiligingsniveau te behouden, kan een dergelijke omleiding ACL worden gecombineerd met DACL toegewezen van ISE.

In behandeling zijnde status staat alleen verbindingen toe met PSN waar Eindpunt is geverifieerd

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

Implementeer als oplossing meerdere PosturePending-autorisatiebeleid (één per PSN). Elk beleid moet als een van de voorwaarden de naam bevatten van de PSN waar de authenticatie plaatsvond.

In het machtigingsprofiel dat aan elk beleid is toegewezen, moet de toegang tot alle PSN's worden geblokkeerd, behalve het knooppunt waar de verificatie heeft plaatsgevonden.

Machtigingsbeleid maken voor implementatie van twee knooppunten:

1. Houding in afwachting van beleid voor PSN1

2. PSN1-naam gebruikt als voorwaarde in het beleid.

3. Autorisatieprofiel met ACL dat de toegang tot alle PSN's behalve PSN1 blokkeert.

4. Posture Pending policy voor PSN2.

5. PSN2 naam gebruikt als voorwaarde in het beleid.

6. Autorisatieprofiel met ACL dat de toegang tot alle PSN's behalve PSN2 blokkeert.

7. Houding "conform" toelatingsbeleid.

In de figuur wordt uitgelegd hoe deze aanpak werkt:

1. Verificatie bereikt PSN1.

2. Als gevolg van het geconfigureerde autorisatiebeleid wijst PSN1 een autorisatieprofiel toe dat de toegang tot alle andere knooppunten behalve PSN1 blokkeert.

3. De AnyConnect ISE-posturemodule start het detectieproces opnieuw.

4. De sonde naar PSN2 wordt geblokkeerd door de NAD zoals door een eerder toegewezen ACL.

5. Een sonde naar PSN1 is toegestaan door ACL toegewezen aan NAD.

Best practices voor taakverdeling

• Schakel plakkerigheid in op de taakverdeler voor verificatie en boekhouding met Calling-Station-ID als kleverige sleutel. Meer informatie over de beste praktijken van LB voor ISE is hier beschikbaar.
• Gebruik plakkerige timer langer dan een gemiddelde werkdag om het moment te dekken waarop de pc in slaap valt (bijvoorbeeld 10 uur in plaats van 8 uur).
• Als herverificatie is geïmplementeerd, gebruikt u een herverificatietimer die iets lager is dan een kleverige timer (bijvoorbeeld 8 uur als kleverigheid gedurende 10 uur is geconfigureerd). Dit zorgt ervoor dat de kleverigheid interval wordt verlengd door re-authenticatie.

Houding over VPN-use-case 

• Zorg ervoor dat het interval voor de tussentijdse update van de boekhouding hoger is of gelijk is aan de time-out van VPN-sessies. Dit minimaliseert boekhoudkundig flapperen tussen PSN's tijdens lange VPN-sessies. 

In dit voorbeeld wordt het interval voor tussentijdse boekhoudkundige updates weergegeven dat gedurende 20 uur is geconfigureerd. Dit belet niet dat de eerste tussentijdse update het IP-adres bevat 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

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

Houdinglease inschakelen 

Dit is een kenmerk op ISE dat aangeeft dat het eindpunt voldoet voor een bepaalde periode (1-365 dagen). De waarde van de houdingslease is een eindpunt attribuut, wat betekent dat het is opgeslagen ISE DB.

Alle eindpuntattributen die houdingslease bevatten, worden gerepliceerd in alle knooppunten in ISE-implementatie.

Wanneer PSN een nieuwe sessie voor de eindpunthouding krijgt, kunt u de sessie meteen markeren als Compliant.

Om deze beslissing te nemen, gebruikt PSN 3 waarden. Deze waarden zijn:

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

2. Waarde van PostureExpiry attribuut is een feitelijk eindpunt attribuut dat een Epoch timestamp bevat. De waarde voor PostureExpiry wordt in eerste instantie ingevuld bij de eerste succesvolle poging tot postuur voor eindpunt nadat de ISE-beheerder de postuur-lease heeft ingeschakeld.

Later werd deze waarde bijgewerkt bij de volgende succesvolle poging tot houding die plaatsvindt na het verstrijken van de lease.

            U kunt een HoudingVervaldatum zien in Contextzichtbaarheid > Eindpunten terwijl een van de gepositioneerde eindpunten wordt geopend:

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

3. PSN-systeemtijd op het moment dat nieuwe verificatie plaatsvindt

Wanneer de verificatie voor een eindpunt met houdingslease PSN bereikt, gebruikt het PostureExpiry en de systeemdatum om het aantal dagen te krijgen dat is verstreken sinds de laatste succesvolle houdingscontrole.

Als de resultaatwaarde binnen een in instellingen gedefinieerde houdingslease-interval ligt, krijgt de sessie de status Compliant.

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

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

Dit diagram geeft het proces weer wanneer failover plaatsvindt:

1. De eerste verificatie vindt plaats met PSN1.

2. Sessie-ABC wordt gemaakt in de sessiecache.

3. Houding beoordeling gebeurt.

4. Wijzigingen in sessiestatus in Compliant

5. COA wordt geactiveerd door een verandering in de houdingsstatus en leidt tot herverificatie van het eindpunt om het volgende toegangsniveau toe te passen.

6. HoudingVervalwaarde wordt opgeslagen in het eindpunt.

7. Eindpuntgegevens worden gerepliceerd tijdens de implementatie.

8. De volgende verificatie bereikt PSN2.

9. PSN2 controleert of het eindpunt binnen een geldige houdingslease valt.

11. De sessie wordt als Compliant aan de cache toegevoegd.

12. Vanwege de geldige lease wordt de sessie aangemaakt met de status Houding Conform.

Implementatie van herverificatie 

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

.

Omgevingen met loadbalancers

Dezelfde set van best practices (uitgelegd in de sectie stale/fantoomsessie) kan worden geïmplementeerd.

Verschillende subnetten kunnen worden gebruikt voor wachtende en de nalevende staten

Wanneer het netwerkontwerp de mogelijkheid biedt om verschillende subnetten te gebruiken die in behandeling zijn en voldoen aan de vereisten, garandeert deze aanpak dat elke verandering in de status van de houding resulteert in de standaardgateway-wijziging.

Houdingsevaluatie in hetzelfde interval als een herverificatietimer

Houdingbeoordeling kan worden ingeschakeld met een interval dat gelijk is aan de timer voor herverificatie. In een dergelijk geval, wanneer de originele PSN niet beschikbaar is, start PRA-fout het detectieproces opnieuw op.

Moderne aanpak - Posture State Sharing

Als onderdeel van een geïmplementeerde verbetering (beschreven in Cisco bug ID CSCvi35647 ) heeft patch 6 voor ISE 2.6 een nieuwe functie waarmee de status van de sessiehouding wordt gedeeld tussen alle knooppunten in ISE-implementatie.

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

Deze nieuwe functie is gebaseerd op het LSD-mechanisme (Light Session Directory) dat is geïntroduceerd in ISE 2.6. In de nieuwere versies is 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 bestaat niet zoiets als volledige sessie context replicatie tussen PSN's, slechts een beperkt aantal attributen gedeeld voor elke sessie.

Light Session Directory verwijdert de noodzaak om resource dure API-aanroepen naar MNT uit te voeren wanneer een van de knooppunten in de implementatie de huidige sessieeigenaar moet bepalen.

Meestal is het opzoeken van de eigenaar nodig wanneer de COA-stroom begint. Met LDD kan elke PSN een werkelijke eigenaar van de sessie vinden in de lokale Radius Session Directory-cache. 

architectuur voor de distributie van lichte gegevens

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 in ISE-implementatie worden gepresenteerd. Elke sessie heeft een beperkt aantal attributen in de cache. 

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

• Sessie-ID
• Eindpunt MAC
• CallingStationID
• Eindpunt-IP
• PSN IP - PSN waar authenticatie plaatsvond
• PSN FQDN 
• NAS-IP-adres
• NAS-IPv6-adres
• Status - geverifieerd, gestart, gestopt

• RabbitMQ-uitwisseling

Er is een uitwisseling gevormd waarin Publisher, gerelateerde Queue en Consumer worden gepresenteerd op elk knooppunt in de ISE-implementatie. Dit zorgt ervoor dat de full-mesh topologie gevormd tussen alle ISE knooppunten.

• uitgever

De Radius Session Directory vertegenwoordigt hier 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 attributen in de Radius Session Directory geplaatst.

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

Opmerking: Algemene RabbitMQ terminologie en architectuur valt buiten dit document.

In de figuur wordt uitgelegd hoe COA flow werkt met RSD cache:

1. De eerste verificatie vindt plaats met PSN1.

2. Sessie-ABC wordt gemaakt in de sessiecache.

3. Vereiste attributen worden opgeslagen in RSD.

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

5. De sessie wordt gemaakt in RSD-cache op alle ISE-nodes.

6. Er komen nieuwe profielgegevens op PSN2.

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

8. Er wordt een interne API-aanroep ingediend bij de RSD-cache om COA uit te voeren.

9. Gegevens uit de RSD-cache worden gebruikt om een proxy-COA-bericht voor te bereiden. Het gaat van het ene ISE-knooppunt naar het andere en bevat alle details die het bestemmingsknooppunt kan gebruiken om een CAO-verzoek terug te sturen naar NAD. Het COA-bericht wordt eerst intern overgedragen naar PRRT Runtime (Actual AAA server inside of ISE).

10. PSN2 stuurt een COA-bericht naar PSN1.

11. PSN1 stuurt een COA-bericht naar NAD.

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

Hier is een voorbeeld van een foutopsporingsbericht van het bestand lsd.log voor het maken en publiceren van sessies op de originele 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 houdingsstatus lost problemen op wanneer de hoofdoorzaak een verouderde/fantoomsessie is of een herverificatie op een andere PSN die geen herstart van de detectie heeft veroorzaakt.

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

Er zijn nog enkele andere hoekgevallen die de beschreven functie niet kan oplossen. Bijvoorbeeld een scenario waarin NAD herverificatie uitvoert op dezelfde PSN, maar met een andere sessie-ID.

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

Houding Status Delen Over RSD - Stale/Phantom Sessie

Om een stabiele sessie te maken, moet de authenticatie eerst worden uitgevoerd op de skuchere-ise26-1. Vervolgens moet NAD opnieuw worden geconfigureerd om de boekhouding naar skuchere-ise26-3 te sturen.

Nadat een boekhoudbericht is doorgestuurd naar de verkeerde PSN, moet NAD (opnieuw) worden geconfigureerd 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. Boekhouding-Start berichten verwerkt door skuchere-ise26-1.

2. Tussentijdse boekhoudkundige bijwerking voor dezelfde sessie verwerkt door skuchere-ise26-3.

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

Na enige tijd maakt het eindpunt weer verbinding met het netwerk, maar de omleiding werkt niet meer. In het guest.log van PSN - skuchere-ise26-3 kunt u deze logboekberichten zien met de component client-webapp 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 muffe / fantoomsessie voor het eindpunt heeft, reageert het niet op de ISE-houdingsmodule en dit stelt ons in staat om het juiste antwoord te krijgen van de PSN waar de nieuwste verificatie plaatsvond.

Als oplossing voor het probleem van de verouderde/spooksessie op het moment van het opzoeken van de sessie, controleert PSN de aanwezigheid van elke nieuwe sessie voor het eindpunt in de RSD.

Als RSD een andere sessie-ID bevat dan wat PSN in de lokale sessiecache heeft, wordt ervan uitgegaan dat de sessie (die in de sessiecache wordt weergegeven) stabiel 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 compatibele status.

Later wordt NAD opnieuw geconfigureerd om verificatie en boekhouding naar een andere PSN te verzenden (skuchere-ise26-3).

Na het verlopen van de timer voor herverificatie wordt dezelfde sessie niet-geverifieerd op de verschillende PSN.

De figuur toont een verificatierapport dat failover toont voor dezelfde sessie van skuchere-ise26-1 naar skuchere-ise26-3:

1. Authenticatie gebeurt op skuchere-ise26-1, autorisatieprofiel met omleiding wordt toegewezen.

2. COA na succesvolle beoordeling van de houding.

3. Volgende verificatie wanneer autorisatieprofiel voor de compatibele status wordt toegewezen.

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

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

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