De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft het probleem met de gemeenschappelijke posterijen van Identity Service Engine (ISE): "AnyConnect ISE-postermodule toont compatibele..."
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, kunnen er meerdere grondoorzaken van dit probleem zijn.
Vaak wordt het oplossen van problemen bij een dergelijk probleem extreem tijdrovend, wat ernstige gevolgen heeft.
Dit document verklaart:
Voor een betere uitleg van de later beschreven concepten raadpleegt u:
Deze kwestie komt normaal gesproken tot uiting in het ontbreken van netwerktoegang of constante omleidingen naar het ISE-client provisioningportal in de browser, terwijl tegelijkertijd AnyConect ISE-postermodule posterstatus als conform toont.
Typische eindgebruikerservaring:
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:
Opmerking: c. en d. worden niet altijd in de bewegende logbestanden getoond wanneer de beschreven kwestie zich manifesteert. Session event met postuur status Compliant is gebruikelijker voor scenario's die worden veroorzaakt door de verouderde of spooksessies die later in dit document worden beschreven.
Deze kwestie manifesteert zich normaal in twee problematische scenario's en elk van hen heeft meerdere grondoorzaken. De scenario's:
Om het probleem beter te begrijpen, moet u de ISE-sessiebeheerlogica en het AnyConnect-detectieproces onderzoeken.
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.
Zoals uitgelegd in deze afbeelding, MNT-knooppunt maakt seizoenen op basis van de doorgegeven authenticatie Syslog-berichten die afkomstig zijn van PSN's.
De latere sessiestatus kan door de Syslog worden bijgewerkt voor de boekhouding.
Session verwijdering op MNT gebeurt in 3 scenario's:
Voorbeelden van Syslog-berichten van PSN. Die berichten worden ingelogd op poortserver.log wanneer 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
Wat is het PSN-sessiecache?
Een in-memory database die alle actieve sessies van specifieke PSN opslaat. Session cache is altijd lokaal voor de node en er is geen mechanisme in ISE dat replicatie van de volledige sessiestatus van de ene knooppunt naar de andere kan uitvoeren.
Voor elke actieve sessie-ID slaat PSN alle attributen op die tijdens de verificatie-/autorisatiefase zijn verzameld, zoals interne/externe gebruikersgroepen, NAD-kenmerken (Network Access Device), certificaatkenmerken, enzovoort. Deze kenmerken worden door PSN gebruikt om verschillende beleidstypen te selecteren, zoals Verificatie, autorisatie, clientprovisioning, houding.
Session cache volledig verwijderd wanneer services op het knooppunt of knooppunt zelf opnieuw worden gestart.
De huidige logica van de zittingsverwerking leidt tot een nieuwe ingang in het zittingsgeheim in twee scenario's, kunnen de recentere details van bestaande zittingen van boekhoudingsberichten worden bijgewerkt die uit NADs komen:
Als het gaat om sessieverwijdering, implementeert PSN deze logica:
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 gemarkeerd als conform.
5. Een wijziging van de autorisatie (COA) die wordt veroorzaakt door een wijziging van de 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.
Na stap 6 sessie, wordt ABC vastgezet in de verbale status op de PSN1 omdat er geen accounting stop bericht 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:
Voorbeeld van een verouderde sessie in een taakverdeling (LB)-omgeving:
1. Eerste verificatie voor de sessie ABC 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. Inschrijving voor sessie ABC gemaakt in MNT sessiemap met de status Geverifieerd.
6. Boekhoudkundige start-bericht voor sessie ABC landt op PSN 1.
7. Session cache-ingang voor sessie ABC bijgewerkt met informatie van Accounting-Start.
8. Syslog-bericht voor accounting-start overgebracht naar MNT-knooppunt.
9. Sessiestatus bijgewerkt naar Starten.
10. De kleverheidstimer verloopt op de taakverdeling.
11. Accounting-Stop voor sessie ABC door de taakverdeler doorgestuurd naar PSN 2.
12. Syslog-bericht voor accounting-stop doorgestuurd door PSN 2 naar MNT.
13. Sessie ABC gemarkeerd als beëindigd op MNT.
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 gecreëerd in het PSN-sessiecache en als PSN geen accountingstop-bericht krijgt voor deze sessie, wordt de ingang 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. tussentijdse update van de accounting voor sessie ABC hits PSN2.
4. Session entry voor sessie ABC gemaakt op PSN2. Sinds de sessie die is gemaakt op basis van het rekeningbericht, 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:
Voorbeeld van een spooksessie voor het scenario met tijdelijke problemen op het netwerkpad naar PSN1:
1. Eerste verificatie voor de sessie ABC uitgevoerd door PSN.
2. PSN1 maakt een ingang voor de sessie ABC in de lokale cache.
3. Syslog-bericht voor doorgegeven verificatie naar MNT-knooppunt.
4. Inschrijving voor sessie ABC gemaakt in TimesTen DB met de staat Geverifieerd.
5. Boekhoudkundige start-bericht voor sessie ABC landt op PSN 1.
6. Session cache-ingang voor sessie ABC bijgewerkt met informatie van Accounting-Start.
7. Syslog-bericht voor accounting-start overgebracht naar MNT-knooppunt.
8. Sessiestatus bijgewerkt naar Starten.
9. Tussentijdse bijwerking van de boekhouding voor de sessie die ABC naar PSN2 doorstuurde.
10. PSN2 maakt een ingang voor de sessie ABC in de lokale cache.
11. Accounting-Stop voor sessie die ABC doorstuurt naar PSN1.
12. Inschrijving voor sessie ABC verwijderd uit de sessiecache op PSN1.
13. Syslog-bericht voor accounting-stop doorgestuurd door PSN 1 naar MNT.
14. Sessie ABC gemarkeerd als beëindigd op MNT.
Het scenario van de fantoomsessie zoals deze is gemaakt voor de langdurige VPN-verbinding:
1. Eerste verificatie op PSN1.
2. Session ABC gemaakt in het sessiecache.
3. Boekhouding start het bericht dat door het PSN wordt verwerkt.
4. Het nieuwe IP-adres dat is toegewezen aan de VPN-adapter (Virtual Private Network).
5. Tussentijdse boekhoudkundige update met IP-adresinfo landt op PSN.
6. IP-adresinformatie toegevoegd aan het sessiecache.
7. Bij PSN1 wordt de houding beoordeeld.
8. Status bijgewerkt in de sessie.
9. Een door ISE uitgevoerde CCA-push zorgt ervoor dat een nieuw toegangsniveau wordt toegewezen.
10. Uitval op het netwerkpad waardoor PSN1 niet toegankelijk is.
11. Na het verstrijken van het tussentijdse updateinterval detecteert ASA/FTD dat PSN1 ontoegankelijk is.
12. Tussentijdse boekhoudkundige bijwerking heeft betrekking op PSN2.
13. De spooksessie die in het PSN2-sessiecache is gemaakt.
Als later PSN1 toegankelijk wordt (14) worden alle volgende boekhoudberichten doorgestuurd (15,16) en blijft ABC voor een onbepaalde tijd in het PSN2-sessiecache.
Om te begrijpen hoe de verouderde sessie en de spooksessie de houding verbreken, kunt u het AnyConnect ISE-proces voor het detecteren van de poortmodule 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.
Eerst worden 3 sondes in de figuur omgeleid op basis van (standaard GW IP. IP van de ontdekkingsgastheer (indien bepaald) en enroll.cisco.com IP) - Die sondes richten altijd de agent aan het recht PSN aangezien de omleiding 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 dat is gemaakt na de eerste succesvolle poging tot postuur en latere bestandsinhoud kan worden bijgewerkt als client migreert tussen PSN's. 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 resultaat van sonde 4 gebruikt slechts als alle andere 3 sondes ontbraken of de module van de post van ISE niet in staat was om juiste communicatie met PSN te vestigen die in redirect URL binnen 5 seconden is teruggekeerd.
Wanneer sonde 4 landt op de PSN bevat het een lijst van actieve IP en 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 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 PSN de sessie niet kan vinden in het lokale sessiecache, moet het MNT lookup uitvoeren (alleen op MAC-adres gebaseerd) 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: het is belangrijk om te onthouden dat deze kwestie alleen kan manifesteren wanneer alle op redirect-gebaseerde ontdekkingssondes falen of wanneer niet-redirect houding 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 selectie van clientprovisioningbeleid uit. Bij een spooksessie met een gebrek aan authenticatie-/autorisatiekenmerken en alle beleid dat door de klant is geconfigureerd, zijn zeer specifiek (beleid wordt bijvoorbeeld gemaakt voor specifieke Active Directory-groepen) is PSN niet in staat om een juiste client provisioningbeleid toe te wijzen. Dit kan zich manifesteren in de foutmelding: "Bypassing AnyConnect scan uw netwerk is geconfigureerd om Cisco NAC Agent te gebruiken".
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 zo'n geval, PSN antwoordt op het eindpunt dat het volgzaam is aangezien dit een standaard ISE gedrag in het geval van niet postuur beleidsmatch is.
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 de status voor elk beleid/elk vereiste zoals 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, de ISE-beheerder mogelijk een aantal mislukte postuur-CoA’s opmerken, zoals in dat geval COA-verzoeken worden uitgevoerd vanuit de verkeerde PSN’s en voor verkeerde sessie-ID’s.
ISE postermodule ontworpen om een beperkte hoeveelheid gebeurtenissen op het eindpunt te monitoren om een detectieproces te starten. Lijst van gebeurtenissen die aanleiding geven tot de ontdekking:
Nieuwe dot1x-verificatie, pc-ontgrendeling, wijziging van IP-adres worden niet gedetecteerd door de ISE-poortmodule.
De ISE-postermodule kan in deze scenario's geen nieuwe verificatie- of herverificatiepoging detecteren:
Voorbeeld van herverificatie op verschillende PSN veroorzaakt door de stroomonderbreking van het oorspronkelijke PSN. Het scenario met lastverdeler lijkt erg op elkaar. In het geval van SLB moet opnieuw worden geauthenticeerd op de verschillende PSN als gevolg van het verlopen van de stickiness timer.
1. Eerste verificatie op PSN1.
2. Session ABC gemaakt in het PSN1-sessiecache.
3. Met PSN1 uitgevoerde beoordeling van de houding.
4. De ABS van de zitting positiestatus beweegt zich aan Volgzaam.
5. Een COA dat wordt geactiveerd door een wijziging van de status leidt tot een nieuwe authenticatie 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 is voor de PSN2-status van de sessie wordt Hangende.
Eerste postuur status toegewezen door PSN aan de sessie:
Opmerking: State-machine beschrijft alleen een eerste selectie van de postuur status. Elke sessie die aanvankelijk als Onbekend werd gemarkeerd, kan later conform of niet-conform worden op basis van de evaluatie van het rapport die van de ISE-postermodule is ontvangen.
Dit zou kunnen gebeuren in de twee meest voorkomende scenario's:
De nieuwe sessie-ID kan worden gegenereerd in een aantal andere hoekscenario's. In sommige gevallen kan draadloos roaming er bijvoorbeeld de oorzaak van 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.
Om te bepalen of AnyConnect naleving laat zien terwijl het in de omleidingsstaat wordt veroorzaakt door de verouderde/spookzitting, moeten wij toegang tot het eindpunt krijgen terwijl het in de problematische staat is.
1. Druk op het tandwielpictogram in AnyConnect UI
2. Navigeer in het nieuwe venster naar het tabblad Scannen en het tabblad Statistieken
Let hier op twee elementen:
In het gegeven voorbeeld is er een wanverhouding tussen de naam die erop wijst dat PSN met naam ciscolive-ise2 een stapelbare of spooksessie voor dit eindpunt houdt.
In de demo zijn de stappen opgenomen die nodig zijn voor de identificatie van het probleem:
Het vorige voorbeeld is om de kwestie van een vervelende of spookzitting van het probleem van het ontdekkingsproces te onderscheiden 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.
Terwijl in sommige scenario's vervelende en spooksessies niet kunnen worden vermeden. We moeten ervoor zorgen dat er geen verouderde / spooksessies worden gecreëerd in de omgeving als gevolg van een aantal van de best practices die niet worden geïmplementeerd.
Analyseer een DART-bundel die is genomen van het eindpunt dat het probleem reproduceert.
Om dit te bereiken, moet het DART bundelhulpprogramma beginnen als beheerder en logopmaak uitvoeren.
Nadat de DART-bundel is verzameld, moeten we deze verwijderen en ons richten op het bestand AnyConnect_ISEPosture.txt dat zich bevindt 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. Een paar lijnen na de ontdekking herstart je ziet een lijn die bevat - Probing geen MNT-podiumdoelen. Dit is een indicator van stadium 1 ontdekkingsbegin:
Het is aan te raden om alle omleiding gebaseerde sondes met dezelfde kleur te markeren, terwijl eerder verbonden PSN’s genomen van ConnectionData.xml (Auth-Status targets) moeten worden gemarkeerd in verschillende kleuren omdat PSN FQDN’s meestal erg vergelijkbaar zijn en het is moeilijk om het verschil te herkennen.
3.Lees de logbestanden om een resultaat te zien voor elke sonde. Zoals al is gezegd in het geval van de kwestie veroorzaakt door vervelende/spooksessie, moeten alle omgeleide sondes falen. 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. Een paar 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 erachter te komen hoe deze sessie vervelend/fantoomloos wordt:
In de guest.log met clientwebapp component ingeschakeld in DEBUG, de PSN die antwoordt met de Stale/Phantom sessie kan worden gezien.
PSN krijgt een verzoek van de ISE postuur agent. U kunt zien dat dit een verzoek is van AnyConnect vanwege de waarde voor 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 voorbeeld heeft elke array slechts één waarde. Eveneens laat het logboek zien dat sessie-ID van het verzoek ongeldig is, wat aangeeft dat dit een verzoek van de non-redirect gebaseerde sonde is.
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
Nadat u het ID van de vervelende/spooksessie kent, kunt u het Radius-accountingrapport onderzoeken om een beter begrip te krijgen van wat deze sessie heeft veroorzaakt tot vervelend/spookbeeld:
Voorbeeld van een rapport dat laat zien hoe oud de sessie is op ciscolive-ise2:
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:
De benadering hier is zeer gelijkaardig aan de Geavanceerde sectie van de Oplossing van het Probleemverhaal/van de Spookzitting. Het belangrijkste element van probleemoplossing is het DART bundelonderzoek. Binnen de DART bundel, kunt u zoeken naar ontdekkings herstart zoals het voor het vorige probleem is getoond en bevestigen dat er geen ontdekking herstart was op het moment dat het probleem werd gemeld.
Aan de kant van ISE, focus op Radius Live Logs/Radius authenticatie rapport om te bevestigen dat er was failover tussen PSNs of nieuwe sessie-ID is gegenereerd door NAD.
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.
Voer waar mogelijk altijd een omleidingsgerichte houding uit
Een tegenargument tegen deze aanbeveling is een slechte gebruikerservaring als pop-ups in het besturingssysteem of browsers worden gezien die wijzen op omleiding terwijl AnyConnect ISE-postermodule 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.
In het voorbeeld wordt ACL getoond die is ontworpen om alleen HTTP-verzoeken naar Discovery Host (10.1.1.1 in dit voorbeeld) en enroll.cisco.com (172.16.1.80) om te leiden:
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 moet u meerdere beleidsregels voor PosturePending autorisatie implementeren (éé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 in behandeling bij 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 geblokkeerd door het NAD zoals door een eerder toegewezen ACL.
5. Sonde naar PSN1 toegestaan door ACL toegewezen aan NAD.
Best practices voor taakverdeling
Posture over VPN use-case
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
Posture lease inschakelen
Dit is een functie op ISE die eindpunt markeert als een conforme 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 voor de endpointpostuur krijgt, kan deze worden gebruikt om de sessie meteen als conform te markeren.
Om dit besluit te nemen gebruikt PSN 3 waarden. Deze waarden zijn:
U kunt een PostureExpiry in Context Visibility > Endpoints zien terwijl één van de gepostuleerde eindpunten wordt geopend:
Deze waarde kan in de door de mens leesbare tijdstempel worden omgezet, bijvoorbeeld hier - https://www.epochconverter.com/
Wanneer de authenticatie voor een eindpunt met postuur leasehits PSN gebruikt het PostureExpiry en systeemdatum om een aantal dagen te krijgen die van de laatste succesvolle postuur controle overgingen. 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 een nieuwe PostureExpiry waarde worden opgeslagen.
Het getal verklaart het proces bij failover:
1. De eerste verificatie gebeurt met PSN1.
2. Session ABC gemaakt in het sessiecache.
3. De beoordeling van de houding gebeurt.
4. Sessiestatus verandert in conform
5. Een COA dat wordt geactiveerd door een wijziging van de status leidt tot een nieuwe authenticatie van het eindpunt om het volgende toegangsniveau toe te passen.
6. PostureExpiry-waarde opgeslagen in het eindpunt.
7. Endpoint data gerepliceerd over de implementatie.
8. Volgende verificatie bereikt PSN2.
9. PSN2 controleert of het eindpunt zich in een geldige posterieuslease bevindt.
11. Sessie toegevoegd aan het sessiecache als conform.
12. Vanwege de geldige lease, de sessie gecreëerd met status conform.
Implementatie van herverificatie
Druk altijd op herverificatietimer van ISE met RADIUS-Aanvraag geselecteerd in Connectiviteit behouden tijdens herverificatie. Deze instelling zorgt ervoor dat NAD dezelfde sessie-ID bij herverificatie houdt.
.
Omgevingen met taakverdeling
Dezelfde set best practices kan worden geïmplementeerd die in de sectie Stale/Phantom Session werden uitgelegd.
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 houding 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 wordt het detectieproces opnieuw gestart wanneer de oorspronkelijke PSN niet beschikbaar is voor PRA-storing.
Als deel van een geïmplementeerde verbetering die in Cisco bug-id CSCvi35647patch 6 voor ISE 2.6 is beschreven, is er een nieuwe functie die de status van het delen van de sessiestatus op 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.
Het belangrijkste idee achter Light Session Directory is om de noodzaak te verwijderen om dure API-oproepen naar MNT uit te voeren wanneer een van de knooppunten in de implementatie moet uitzoeken wie de huidige sessieeigenaar is. Meestal eigenaar zoeken is nodig wanneer Cacao stroom start. Met LDD kan elke PSN een eigenlijke eigenaar van de sessie vinden vanuit het lokale Radius Session Directory cache.
Deze functionaliteit bevat de volgende elementen:
Opmerking: algemene RabbitMQ-terminologie en -architectuur vallen buiten het bereik van dit document.
De figuur legt uit hoe COA flow werkt met RSD cache:
1. De eerste verificatie gebeurt met PSN1.
2. Session ABC gemaakt in het sessiecache.
3. De vereiste eigenschappen worden opgeslagen in RSD.
4. Sessie gedeeld via RabbitMQ met alle andere ISE-knooppunten.
5. Session wordt gemaakt in RSD cache op alle ISE-knooppunten.
6. Op PSN2 worden nieuwe profielgegevens aangeleverd.
7. Endpoint wordt opnieuw geprofileerd en in het geval van de verandering die vereist dat COA uitvoering PSN2 gaat met de volgende stap.
8. Een interne API-oproep die wordt ingediend bij het RSD-cachegeheugen om de OCR uit te voeren.
9. Gegevens van het RSD-cachegeheugen dat wordt gebruikt om een Proxy-COA-bericht voor te bereiden (een COA die van de ene ISE-knooppunt naar de andere gaat, bevat alle details die de bestemmingsknooppunt kan gebruiken om een CAO-verzoek terug te sturen naar NAD). COA-bericht eerst intern overgedragen naar PRTR Runtime (Actual AAA-server binnen ISE).
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, kunt u de Light Session Director-component inschakelen voor DEBUG:
Een voorbeeld van debug-bericht uit lsd.log-bestand voor het maken en publiceren van sessies 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]
Posture status delen tussen de knooppunten lost het probleem op dat het symptoom heeft zoals 'AnyConnect ISE postuur module toont compatibele terwijl de sessiestatus op ISE hangende is' wanneer de worteloorzaak is of Stale/Phantom sessie of Re-authenticatie op verschillende PSN met een originele sessie-ID 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.
Het cijfer toont de topologie aan die voor een test van het delen van de postuur wordt gebruikt:
Om een verouderde sessie authenticatie te maken is eerst uitgevoerd op de skuchere-ise26-1 en later en is opnieuw geconfigureerd om accounting naar skuchere-ise26-3 te sturen. Nadat een boekhoudbericht is doorgestuurd naar de verkeerde PSN en opnieuw is ingesteld 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/spooksessie nu op het moment van de sessieraadpleging controleert PSN de aanwezigheid van een nieuwe sessie voor het eindpunt in de RSD. Als RSD sessie-ID anders bevat dan wat PSN in het lokale sessiecache heeft, wordt ervan uitgegaan dat de sessie die in het sessiecache wordt gepresenteerd, verouderd is.
Om dit scenario te reproduceren is een korte herverificatietimer ingeschakeld in het autorisatieprofiel dat is toegewezen aan het eindpunt in de compatibele staat. Later werd NAD hergeconfigureerd om authenticatie en accounting naar een andere PSN (skuchere-ise26-3) te sturen. Na het verlopen van de verificatietimer is dezelfde sessie niet geverifieerd op de verschillende PSN.
De figuur toont een authenticatierapport dat de failover voor de sinaasappe toont 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 krijgt 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 extra logica toe te voegen aan het proces voor de selectie van de postuur. Het getal toont aan wat er is veranderd (wijzigingen gemarkeerd in rood):
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
31-May-2023 |
Hercertificering |
1.0 |
22-Apr-2020 |
Eerste vrijgave |