Fehlerbehebung bei ISE-Sitzungsmanagement und Status

Einleitung

In diesem Dokument wird das häufige Problem mit Identity Service Engine (ISE)-Statusservices beschrieben: "Das AnyConnect ISE-Statusmodul erfüllt ...".

Hintergrundinformationen

In diesem Dokument wird das häufige Problem mit Identity Service Engine (ISE)-Statusservices beschrieben: Das AnyConnect ISE-Statusmodul ist während der Wartezeit des Sitzungsstatus auf der ISE kompatibel.

Obwohl die Symptome immer die gleichen sind, gibt es mehrere Ursachen für dieses Problem.

Häufig ist die Behebung eines solchen Problems sehr zeitaufwendig, was schwerwiegende Auswirkungen hat.

In diesem Dokument wird Folgendes erläutert:

• Problempunkt aus Sicht der Endbenutzer und ISE-Administratoren.
• Häufige problematische Szenarien.
• Die Theorie hinter ISE, AnyConnect und Netzwerkoperationen, die das Problem auslösen.
• Algorithmen zur schnellen Problemerkennung.
• Klassische Lösungen für gängige Problemszenarien.
• Statusfreigabe über das Radius-Sitzungsverzeichnis.

Eine genauere Erläuterung der später beschriebenen Konzepte finden Sie unter:

Problem

Anwendererlebnis

Dieses Problem tritt normalerweise auf, wenn kein Netzwerkzugriff oder keine ständige Umleitung zum ISE-Client-Bereitstellungsportal im Browser erfolgt, während das AnyConnect ISE-Statusmodul gleichzeitig den Status als konform anzeigt.

Typische Endbenutzererfahrung:

ISE-Administrationserfahrung

Normalerweise führt der ISE-Administrator bei der ersten Triage dieses Problems eine Radius-Live-Protokolluntersuchung durch, um sicherzustellen, dass eine tatsächliche Authentifizierung bei der ISE vorliegt.

Das erste in diesem Stadium erkannte Symptom weist auf eine Diskrepanz in einem Status zwischen Endpunkt und ISE hin, da in den Live-Protokollen oder RADIUS-Authentifizierungsberichten für die letzte erfolgreiche Authentifizierung des Endpunkts der Status Ausstehender Status angezeigt wird.

Typische ISE-Administrationserfahrung:

• Letzte erfolgreiche Authentifizierung für Identität: alice.
• Der Status der Sitzung lautet "Ausstehend".
• Letzte Session-Veranstaltung für Identity: alice.
• Das Sitzungsereignis zeigt den Status als konform an.

Hinweis: c. und d. werden nicht immer in den Live-Protokollen angezeigt, wenn das beschriebene Problem auftritt. Ein Sitzungsereignis mit dem Status Compliant ist häufiger in Szenarien zu finden, die durch veraltete oder Phantom-Sitzungen verursacht werden (siehe weiter unten in diesem Dokument).

Häufige Problemszenarien

Dieses Problem tritt normalerweise in zwei problematischen Szenarien auf, von denen jedes mehrere Ursachen hat. Die Szenarien:

• Das AnyConnect ISE-Statusmodul wurde während des Statusvorgangs vom Policy Service Node (PSN) falsch informiert, wodurch der falsche Status angezeigt wurde. 

In diesem Fall handelt es sich normalerweise um eine veraltete oder Phantom-Sitzung im PSN-Sitzungscache.

• Die AnyConnect ISE zeigt den Status aus dem vorherigen Erkennungszyklus an, da die aktuelle Authentifizierung keinen Erkennungsvorgang ausgelöst hat.

Das ISE-Statusmodul in AnyConnect verfügt über eine begrenzte Anzahl von Ereignissen, die den Erkennungsprozess auslösen. Es ist möglich, dass während der Authentifizierung oder erneuten Authentifizierung keines dieser Ereignisse erkannt wurde.

Veraltete/Phantom-Sitzung

Um das Problem besser zu verstehen, untersuchen Sie die erforderliche ISE-Sitzungsverwaltungslogik und den AnyConnect-Erkennungsprozess.

ISE-Sitzungsmanagement-Logik

Bei der ISE-Bereitstellung sind zwei Personen für den Sitzungsmanagementprozess verantwortlich: PSN und Monitoring Node (MNT).

Um dieses Problem richtig zu beheben und zu identifizieren, ist es wichtig, die Theorie der Sitzungsverwaltung für beide Personen zu verstehen.

MNT- und Sitzungsmanagement

Wie in diesem Bild erläutert, erstellt der MNT-Knoten Jahreszeiten auf der Grundlage der übergebenen Syslog-Authentifizierungsmeldungen, die von PSNs stammen.

Der Sitzungsstatus kann später vom Syslog für die Kontoführung aktualisiert werden.

Das Entfernen von Sitzungen auf MNT geschieht in drei Szenarien:

1. Sitzungen ohne Abrechnungsstart wurden ca. 60 Minuten nach ihrer Erstellung entfernt: Es wird alle 5 Minuten ein Cron-Job ausgeführt, um den Sitzungsstatus zu überprüfen und zu bereinigen.

2. Die beendete Sitzung wurde ca. 15 Minuten nach der Verarbeitung des Abrechnungsstopps durch denselben Cron-Auftrag entfernt.

3. Derselbe Cron bei jeder Ausführung entfernt auch Sitzungen, die sich seit mehr als 5 Tagen (120 Stunden) im Status "Gestartet" befinden. Ein gestarteter Zustand bedeutet, dass der MNT-Knoten sowohl die Authentifizierung als auch die Kontoverwaltung verarbeitet hat, um Syslog für die Sitzung zu starten.

Beispiele für Syslog-Meldungen von PSN:

Diese Meldungen werden in prrt-server.log protokolliert, wenn die Komponente runtime-aaa in DEBUG aktiviert ist. Fett formatierte Teile können zum Erstellen von regulären Suchausdrücken verwendet werden.

Authentifizierung bestanden:

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

Anfang der Buchhaltung:

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

Aktualisierung der Zwischenabrechnung:

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

Abrechnungstopp:

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- und Sitzungsmanagement

Der PSN-Sitzungscache ist eine In-Memory-Datenbank, in der alle aktiven Sitzungen eines bestimmten PSN gespeichert werden. Der Sitzungscache ist immer lokal für den Knoten.

Es gibt keinen Mechanismus in der ISE, der eine Replikation des FULL-Sitzungszustands von einem Knoten auf einen anderen durchführen kann.

Für jede aktive Sitzungs-ID speichert PSN alle Attribute, die während der Authentifizierungs-/Autorisierungsphase erfasst wurden (z. B. interne/externe Benutzergruppen, NAD-Attribute (Network Access Device), Zertifikatattribute usw.). Diese Attribute werden von PSN verwendet, um verschiedene Richtlinientypen (wie Authentifizierung, Autorisierung, Clientbereitstellung und Status) auszuwählen.

Der Sitzungscache wird vollständig entfernt, wenn der Knoten (oder die Dienste auf dem Knoten) neu gestartet werden.

Die aktuelle Sitzungsverarbeitungslogik erstellt in zwei Szenarien einen neuen Eintrag im Sitzungscache. Spätere Details bestehender Sitzungen können anhand von Accounting-Meldungen von NADs aktualisiert werden.

• Die Sitzung wurde auf dem PSN erfolgreich authentifiziert.
• PSN hat ein Accounting-Zwischenupdate für die Sitzung erhalten, das nicht im Sitzungscache vorhanden ist.

Wenn es um das Entfernen von Sitzungen geht, implementiert PSN diese Logik:

• Der Sitzungscacheeintrag wird unmittelbar nach der Verarbeitung der Accounting-Stopp-Nachricht entfernt.
• PSN beginnt, die zuletzt verwendeten Sitzungen zu entfernen, wenn ein Knoten die Grenze der aktiven Sitzungen erreicht.

Veraltete Sitzung auf PSN

In der ISE-Bereitstellung wurde der Accounting-Stopp für eine vorhandene Sitzung vom PSN verarbeitet, der die eigentliche Authentifizierung nicht durchgeführt hat:

Beispiel der veralteten Sitzung:

1. Die erfolgreiche Authentifizierung erfolgt auf PSN für die Sitzung ABC.

2. PSN erstellt einen Eintrag im Sitzungscache.

3. Statusüberprüfung wird durchgeführt.

4. Sitzung ist als konform markiert.

5. Eine Autorisierungsänderung (COA, Change of Authorization) (ausgelöst durch Statusänderungen) führt zur erneuten Authentifizierung des Endpunkts, sodass die nächste Zugriffsebene übernommen wird.

6. Der Abrechnungsstopp für die Sitzung ABC kommt zu PSN2.

Danach bleibt ABC auf dem PSN1 im veralteten Zustand, da auf diesem PSN keine Abrechnungs-Stopp-Nachricht verarbeitet wird, um ihn zu entfernen.

Die Sitzung wird für einen längeren Zeitraum entfernt, wenn bei der Bereitstellung nicht eine hohe Anzahl von Authentifizierungsversuchen auftreten.

Die veraltete Sitzung wird in folgenden Szenarien im PSN-Sitzungscache angezeigt:

• Der Abrechnungsstopp wurde aufgrund des Ablaufs des Stickiness-Timers auf dem Load Balancer falsch gesetzt.
• Die falsche Konfiguration auf dem NAD ist nicht dieselbe PSN, die für Authentifizierung und Abrechnung konfiguriert wurde.
• Temporäre Verbindungsprobleme auf dem Netzwerkpfad, die einen NAD-Failover auf das nächste PSN verursachen.

Beispiel für eine veraltete Sitzung in einer Load Balancer (LB)-Umgebung:

1. Die anfängliche Authentifizierung für die Session ABC wird von PSN 1 durchgeführt.

2. Mit dieser Authentifizierung wird ein Stickiness-Timer für den Load Balancer initiiert.

3. PSN 1 erstellt einen Eintrag für das Session-ABC im lokalen Cache.

4. Syslog-Meldung für übergebene Authentifizierung wird an MNT-Knoten übertragen.

5. Der Eintrag für Session ABC wird im MNT Session Verzeichnis mit dem Status Authenticated erstellt.

6. Abrechnungsstartmeldung für Session ABC landet auf PSN 1.

7. Der Eintrag im Sitzungscache für die Sitzung ABC wird mit den Informationen von Accounting-Start aktualisiert.

8. Die Syslog-Meldung für Accounting-Start wird an den MNT-Knoten übertragen.

9. Der Sitzungsstatus wird auf "Gestartet" aktualisiert.

10. Der Stickiness-Timer läuft auf dem Load Balancer ab.

11. Accounting-Stopp für Session ABC wird vom Load Balancer an PSN 2 weitergeleitet.

12. Die Syslog-Meldung für Accounting-Stopp wird von PSN 2 an MNT weitergeleitet.

13. Sitzung ABC ist als beendet auf MNT markiert.

Phantom-Sitzung auf dem PSN

Die Phantomsitzung ist ein Szenario, in dem das Accounting-Interim-Update auf das PSN kommt, das keine Authentifizierung für diese spezielle Sitzung durchgeführt hat. In diesem Szenario wird ein neuer Eintrag im PSN-Sitzungscache erstellt.

Wenn PSN für diese Sitzung keine Abrechnungs-Stoppmeldung erhält, wird der Eintrag nicht entfernt, es sei denn, PSN erreicht das Limit für aktive Sitzungen.

Beispiel einer Phantom-Sitzung:

1. Die gleichen Schritte wie im Beispiel für veraltete Sitzungen werden auf PSN1 für die Sitzung ABC ausgeführt.

2. Sitzung ABC hat den Status Compliant im PSN1-Sitzungscache.

3. Ein Accounting-Zwischenupdate für Session ABC trifft auf PSN2.

4. Ein Sitzungseintrag für die Sitzung ABC wird auf PSN2 erstellt. Da der Sitzungseintrag aus der Abrechnungsmeldung erstellt wird, verfügt er über eine begrenzte Anzahl von Attributen. Beispielsweise ist der Status für Sitzung ABC nicht verfügbar. Auch Funktionen wie Benutzergruppen und andere autorisierungsspezifische Attribute fehlen.

Die Phantom-Sitzung wird in folgenden Szenarien im PSN-Sitzungscache angezeigt:

• Kurzfristige Ausfälle bei der Netzwerkübertragung.
• Fehlverhalten des Netzwerkzugriffsgeräts
• Fehlerhaftes Verhalten oder falsche Konfiguration auf dem Load Balancer.

Das folgende Beispiel zeigt eine Phantom-Sitzung für das Szenario mit vorübergehenden Problemen auf dem Netzwerkpfad zu PSN1:

1. Die Erstauthentifizierung für die Session ABC wird vom PSN durchgeführt.

2. PSN1 erstellt einen Eintrag für das Session-ABC im lokalen Cache.

3. Die Syslog-Meldung für die übergebene Authentifizierung wird an den MNT-Knoten übertragen.

4. Ein Eintrag für Session ABC wird in TimesTen DB mit dem Status Authenticated erstellt.

5. Die Accounting-Startmeldung für Session ABC landet auf PSN 1.

6. Ein Session-Cache-Eintrag für Session ABC wird mit Informationen von Accounting-Start aktualisiert.

7. Die Syslog-Meldung für Accounting-Start wird an den MNT-Knoten übertragen.

8. Der Sitzungsstatus wird auf "Gestartet" aktualisiert.

9. Das Interim-Accounting Update für Session ABC wird an PSN2 weitergeleitet.

10. PSN2 erstellt einen Eintrag für die Session ABC im lokalen Cache.

11. Der Accounting-Stopp für Session ABC wird an PSN1 weitergeleitet.

12. Der Eintrag für Session-ABC wird aus dem Session-Cache auf PSN1 entfernt.

13. Eine Syslog-Meldung für Accounting-Stopp wird von PSN 1 an MNT weitergeleitet.

14. Die Sitzung ABC ist als beendet auf MNT markiert.

In dieser Abbildung wird ein Szenario der Phantom-Sitzung dargestellt, die für die langlebige VPN-Verbindung erstellt wurde:

1. Anfängliche Authentifizierung auf PSN1.

2. Session-ABC wird im Session-Cache erstellt.

3. Die Abrechnung startet die vom PSN verarbeitete Nachricht.

4. Die neue IP-Adresse wird dem Virtual Private Network (VPN)-Adapter zugewiesen.

5. Ein vorläufiges Accounting-Update mit IP-Adressinformationen landet auf PSN.

6. Die IP-Adressinformationen werden dem Sitzungscache hinzugefügt.

7. Statusüberprüfung erfolgt mit PSN1.

8. Der Status wird in der Sitzung aktualisiert.

9. Ein COA-Push wird von der ISE ausgeführt; dies löst eine neu zuzuweisende Zugriffsebene aus.

10. Aufgrund eines Ausfalls auf dem Netzwerkpfad ist PSN1 nicht zugänglich.

11. Nach Ablauf eines vorläufigen Aktualisierungsintervalls erkennt ASA/FTD, dass auf PSN1 nicht zugegriffen werden kann. 

12. Die Aktualisierung der Zwischenbuchhaltung erfolgt auf PSN2.

13. Die Phantom-Sitzung wird im PSN2-Sitzungscache erstellt.

Wird PSN1 später erreichbar (14), werden dort alle nachfolgenden Abrechnungsmeldungen weitergeleitet (15,16) und die Session ABC für eine undefinierte Zeit im PSN2 Session Cache belassen.

Wie veraltete Sitzungen und Phantom-Sitzungen den Statusprozess durchbrechen

Um zu verstehen, wie die veraltete Sitzung und die Phantom-Sitzung den Status unterbrechen, können Sie den Erkennungsprozess des AnyConnect ISE-Statusmoduls überprüfen:

Erkennung in Phase 1:

Während dieser Phase führt das ISE-Statusmodul vier gleichzeitige Probleme aus, um das PSN zu finden, das eine Authentifizierung für den Endpunkt durchgeführt hat.

Zunächst werden 3 Sonden auf der Abbildung umleitungsbasiert (Standard-GW-IP. Discovery-Host-IP (sofern definiert) und enroll.cisco.com IP); Diese Tests verweisen den Agenten immer auf das richtige PSN, da die umgeleitete URL aus dem NAD selbst stammt.

Der Prüfpunkt Nummer 4 wird an alle primären Server in der Datei ConnectionData.xml gesendet. Diese Datei wird nach dem ersten erfolgreichen Statusversuch erstellt. Der Dateiinhalt kann zu einem späteren Zeitpunkt aktualisiert werden, falls der Client zwischen PSNs migriert.

Auf Windows-Systemen lautet der Dateispeicherort C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Da alle Prüfpunkte der Stufe 1 gleichzeitig ausgeführt werden, wird das Ergebnis von Prüfpunkt 4 nur verwendet, wenn alle anderen drei Prüfpunkte fehlschlugen oder wenn das ISE-Statusmodul nicht in der Lage war, innerhalb von 5 Sekunden eine korrekte Kommunikation mit dem in der Umleitungs-URL zurückgegebenen PSN herzustellen.

Wenn Probe 4 auf das PSN trifft, enthält es eine Liste der aktiven IP- und MAC-Adressen, die auf dem Endpunkt erkannt werden. PSN verwendet diese Daten, um eine Sitzung für diesen Endpunkt im lokalen Cache zu suchen.

Wenn PSN eine veraltete oder Phantom-Sitzung für einen Endpunkt hat, kann dies zu einem falschen Statusstatus führen, der später auf der Clientseite angezeigt wird.

Wenn ein Agent mehrere Antworten für Probe 4 erhält (ConnectionData.xml kann mehr als ein primäres PSN enthalten), wird immer die schnellste Antwort verwendet.

Erkennung in Phase 2:

Alle Erkennungssonden der Stufe 2 sind nicht umleitbar, d. h. jeder Test löst eine Sitzungssuche für das Ziel-PSN aus.

Wenn der PSN die Sitzung nicht im lokalen Sitzungscache findet, muss er eine MNT-Suche (nur auf Basis der MAC-Adresse) durchführen, um einen Sitzungsbesitzer zu finden und den Besitzernamen an den Agenten zurückzugeben.

Da alle Tests eine Sitzungssuche auslösen, kann die Erkennung in Stufe 2 durch veraltete oder Phantom-Sitzungen noch stärker von Problemen betroffen sein.

Wenn PSN Phase 2 erreicht, erstellt die im Sitzungscache vorhandene Erkennungssonde einen veralteten oder Phantom-Eintrag für denselben Endpunkt. Dies führt dazu, dass der Endbenutzer den falschen Status erhält.

Das Beispiel zeigt den Status, wenn PSN eine veraltete Sitzung oder eine Phantom-Sitzung hält:

Hinweis: Dieses Problem kann nur auftreten, wenn alle umleitungsbasierten Erkennungsüberprüfungen fehlschlagen oder wenn ein Status ohne Umleitung implementiert ist.

1. Alle vom ISE-Statusmodul herausgegebenen Sitzungssonden finden.

2. PSN führt eine Sitzungssuche im Sitzungscache durch. Wenn die Sitzung gefunden werden soll, tritt ein veraltetes oder Phantom-Sitzungsproblem auf.

3. PSN führt die Richtlinienauswahl für die Clientbereitstellung aus. In Fällen, in denen eine Phantom-Sitzung ohne Authentifizierungs-/Autorisierungsattribute und alle vom Kunden konfigurierten Richtlinien sehr spezifisch sind (z. B. werden Richtlinien für bestimmte Active Directory-Gruppen erstellt), kann PSN keine richtige Client-Bereitstellungsrichtlinie zuweisen. Dies kann sich in der Fehlermeldung "Bypassing AnyConnect scan your network is configured to use Cisco NAC Agent" (Scannen mit AnyConnect umgehen ist für die Verwendung von Cisco NAC Agent konfiguriert) zeigen.

• In Fällen, in denen Richtlinien für die Client-Bereitstellung allgemein gehalten werden (die in der Phantom-Sitzung verfügbaren Attribute reichen aus, um die Richtlinie mit der AnyConnect-Konfiguration abzustimmen), antwortet PSN mit den für die Fortsetzung des Bewertungsprozesses erforderlichen Details.
• In diesem Schritt, wenn wir mit veralteten Sitzungen umgehen können, antwortet PSN sofort mit dem Status "Konformität" und alle nächsten Schritte werden nicht ausgeführt. PSN sendet kein COA, da es der Meinung ist, dass die Sitzung bereits konform ist. In Radius Live-Protokollen wird kein Sitzungsereignis mit dem Status Compliant angezeigt.

4. Im Szenario mit einer Phantom-Sitzung wird das ISE-Statusmodul mit der ursprünglichen Statusanforderung fortgesetzt. Diese Anfrage enthält Informationen zu allen Sicherheits- und Patch-Verwaltungsprodukten, die auf dem Endpunkt erkannt wurden.

5. PSN verwendet Informationen aus den Anforderungs- und Sitzungsattributen, um die richtige Statusrichtlinie abzugleichen. Da es der Phantom-Sitzung derzeit an Attributen fehlt, gibt es keine übereinstimmende Richtlinie. In diesem Fall antwortet PSN auf den Endpunkt, dass er die Vorgaben erfüllt. Dies ist ein Standard-ISE-Verhalten, wenn die Statusrichtlinie nicht übereinstimmt. 

Hinweis: Wenn es eine allgemeine Richtlinie gibt, die aus Attributen von Phantom-Sitzungen ausgewählt werden kann, fahren wir mit Schritt 6 fort.

6. PSN gibt die ausgewählten Statusrichtlinien an den Agenten zurück.

Hinweis: Wenn keine Richtlinie ausgewählt werden kann, gibt PSN den Status "Konformität" zurück.

7. Der Agent gibt den Status für jede Richtlinie/Anforderung entweder als "bestanden" oder "fehlgeschlagen" zurück.

8. Berichtsauswertung erfolgt über ISE und Sitzungsstatusänderungen sind konform.

Hinweis: Bei Statusproblemen, die durch die Phantom-Sitzung verursacht werden, bemerkt der ISE-Administrator möglicherweise einige fehlgeschlagene Status-COAs. In solchen Fällen werden COA-Anforderungen von den falschen PSNs und für falsche Sitzungs-IDs ausgeführt.

Der Erkennungsprozess wird bei einem neuen Authentifizierungsversuch nicht gestartet.

Das ISE-Statusmodul überwacht eine begrenzte Anzahl von Ereignissen am Endpunkt, um einen Erkennungsprozess auszulösen.

Ereignisse, die eine Erkennung auslösen:

• Erstinstallation des ISE-Statusmoduls.
• Benutzeranmeldung.
• Energieereignisse.
• Änderung des Schnittstellenstatus.
• Das Betriebssystem wird nach dem Energiesparmodus fortgesetzt.
• Ändern des Standard-Gateways (DG).
• Statusüberprüfung (PRA) fehlgeschlagen, siehe Cisco Bug-ID CSCvo69557

Die neue 802.1x-Authentifizierung, die PC-Freigabe und die Änderung der IP-Adresse werden vom ISE-Statusmodul nicht erkannt.

Das ISE-Statusmodul kann in den folgenden Szenarien keinen neuen Authentifizierungs- oder Neuauthentifizierungsversuch erkennen:

• Die Neuauthentifizierung trifft auf unterschiedliche PSN zu (entweder aufgrund von LB-Entscheidungen oder Problemen mit dem ursprünglichen PSN).
• NAD generiert bei der Neuauthentifizierung eine neue Sitzungs-ID.

Neuauthentifizierung auf anderem PSN

Dieses Diagramm zeigt ein Beispiel für eine erneute Authentifizierung auf verschiedenen PSNs, die durch den Ausfall des ursprünglichen PSNs verursacht wurde. Ein Szenario mit einem Load Balancer sieht sehr ähnlich aus.

Im Fall eines Load Balancers wird die erneute Authentifizierung an die verschiedenen PSNs weitergeleitet, da ein Stickiness-Timer abläuft.

1. Anfängliche Authentifizierung auf PSN1

2. Session ABC wird im PSN1 Session Cache erstellt.

3. Statusüberprüfung wird mit PSN1 durchgeführt.

4. Der Status der ABS-Status für die Sitzung wird in "Konformität" geändert.

5. COA wird durch Statusänderungen ausgelöst und führt zur erneuten Authentifizierung des Endpunkts, um die nächste Zugriffsebene anzuwenden.

6. PSN1 ist nicht mehr verfügbar.

7. Neuauthentifizierung für Sitzung ABC trifft PSN2.

8. Da es sich um eine neue Sitzung für PSN2 handelt, wird der Status der Sitzung zu Ausstehend.

Der anfängliche Status wird der Sitzung von PSN zugewiesen:

Hinweis: State-Machine beschreibt nur eine erste Auswahl des Statusstatus. Jede Sitzung, die anfänglich als "Unbekannt" markiert ist, kann später auf Grundlage der vom ISE-Statusmodul erhaltenen Berichtsbewertung als "konform" oder "nicht konform" eingestuft werden.

NAD generiert neue Sitzungs-ID bei der Neuauthentifizierung

Dies könnte in den beiden gängigsten Szenarien geschehen:

• Die erneute Authentifizierung ist auf der ISE-Seite falsch konfiguriert. Die Lösung dieses Problems wird weiter unten in diesem Dokument behandelt.
• Fehlverhalten auf NAD-Seite; normalerweise behält NAD während des erneuten Authentifizierungsversuchs die gleiche Sitzungs-ID bei. Hierbei handelt es sich um ein potenziell fehlerhaftes Verhalten, das im NAD selbst untersucht werden muss.

Die neue Sitzungs-ID kann auch in anderen Szenarien generiert werden. In einigen Fällen kann beispielsweise Wireless-Roaming eine Ursache dafür sein.

Die Hauptsache hierbei ist, dass ISE PSN eine neue Sitzung immer in den Status "Ausstehend" versetzt, sofern der Status-Lease nicht konfiguriert ist. Der Leasingvertrag für Status wird weiter unten in diesem Dokument erläutert.

Schnelle Identifizierung, wann das Problem durch die veraltete/Phantom-Sitzung verursacht wurde

Ob AnyConnect im Umleitungsstatus Compliance zeigt, wird durch die veraltete/Phantom-Sitzung ermittelt. Wir müssen Zugriff auf den Endpunkt erhalten, während dieser sich im problematischen Zustand befindet.

1.  Details der Systemsuche überprüfen:
   
   

     1. Klicken Sie auf das Zahnrad-Symbol in der AnyConnect-Benutzeroberfläche

   

         2. Navigieren Sie im neuen Fenster zu System Scan > Statistics.

   

           Beachten Sie dabei zwei Aspekte:

   •   Latest Scan Start Time (Neueste Scan-Startzeit): Der Zeitstempel hier muss nahe der Zeit liegen, zu der das Problem erkannt wurde.
   •   Policy Server: In diesem Feld wurde der Name des Policy Servers angegeben, der eine Statusüberprüfung für den Endpunkt durchgeführt hat. Der FQDN von hier muss mit dem FQDN von Redirect-URL (für Redirect Base Posture) oder mit dem PSN-Namen vom letzten Authentifizierungsversuch (für Redirect-less Posture) verglichen werden.
2. Vergleichen Sie den FQDN des Policy Servers aus der Systemscanstatistik mit dem Knotennamen, der die Authentifizierung für den Endpunkt durchgeführt hat:

Die Demo zeigt die Aufzeichnung der Schritte zur Problemermittlung:

Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen

Das vorherige Beispiel dient dazu, das Problem einer veralteten oder Phantom-Sitzung vom Problem des Erkennungsvorgangs zu unterscheiden, das nicht gestartet wurde.

Gleichzeitig müssen wir die eigentliche Sitzung identifizieren, die das Problem ausgelöst hat, um besser verstehen zu können, wie es zu einem veralteten oder Phantom-Sitzungsproblem wird.

Auch wenn in einigen Szenarien veraltete und Phantom-Sitzungen nicht vermieden werden können, müssen wir sicherstellen, dass Best Practices implementiert werden, damit keine veralteten oder Phantom-Sitzungen in der Umgebung erstellt werden.

DART-Paketerfassung

Analyse eines DART-Pakets vom Endgerät, das das Problem reproduziert

• Führen Sie nur wichtige Protokolle im DART. Es wird empfohlen, die Protokolle zu löschen, bevor das Problem reproduziert wird. 

Um dies zu erreichen, muss das DART-Paketdienstprogramm als Administrator starten und die Protokollbereinigung durchführen. 

1. Navigieren Sie unter Windows zu Start, und beginnen Sie mit der Eingabe von DART, klicken Sie mit der rechten Maustaste, und wählen Sie - Als Administrator ausführen.
   
   
2. Klicken Sie im ersten Bildschirm des Assistenten auf Weiter.
   
   
3. Klicken Sie im nächsten Assistenten auf Alle Protokolle löschen.
   
   

4. Nachdem das Problem reproduziert wurde, kann DART von hier erfasst werden. Klicken Sie auf Weiter.

DART-Paketanalyse

Nachdem das DART-Paket gesammelt wurde, heben Sie die Archivierung auf, und konzentrieren Sie sich auf die Datei AnyConnect_ISEPosture.txt im Ordner Cisco AnyConnect ISE Posture Module. Diese Datei enthält alle erkennungsbezogenen Ereignisse.

1. Starten Sie die Fehlerbehebung, und identifizieren Sie alle Momente des Neustarts der Erkennung. Die zu suchenden Schlüsselwörter sind "Neustarten der Erkennung" oder "HTTP-Erkennung". Navigieren Sie hier zu der Zeile mit dem Neustart der Erkennung, der im problematischen Moment stattfand:

2. Mehrere Zeilen nach dem Neustart der Erkennung gibt es eine Zeile, die - Probing no MNT stage targets enthält. Dies ist ein Indikator für den Erkennungsstart in Phase 1:

Es wird empfohlen, alle umleitungsbasierten Tests mit derselben Farbe und zuvor verbundenen PSNs aus ConnectionData.xml (Auth-Status-Ziele) in einer anderen Farbe hervorzuheben.

Normalerweise sind die PSN-FQDNs sehr ähnlich, und der Unterschied ist schwer zu erkennen.

3.Lesen Sie die Log-Dateien, um ein Ergebnis für jede einzelne Probe zu sehen. Dies ist ein Beispiel dafür, wie die fehlgeschlagene Überprüfung aussieht:

4. Irgendwo in der Datei nach dem Neustart der Erkennung für Stufe 1 oder Stufe 2 wird eine erfolgreiche Antwort von einem oder mehreren PSNs angezeigt:

5. Mehrere Zeilen später gibt es eine Zeile mit dem Schlüsselwort MSG_NS_SWISS_NEW_SESSION.

Diese Zeile enthält eine tatsächliche Sitzungs-ID, die von PSN als Ergebnis der Sitzungssuche ausgewählt wurde.

Verwenden Sie diese Sitzungs-ID für weitere Untersuchungen der ISE, um festzustellen, wie diese Sitzung veraltet/Phantom wird:

Untersuchung zu ISE-Protokollen

 In der Datei guest.log kann bei Aktivierung der Komponente clientwebapp in DEBUG der PSN angezeigt werden, der mit der Stale/Phantom-Sitzung antwortet.

PSN erhält eine Anfrage vom ISE-Statusagenten. Dies ist eine Anforderung von AnyConnect aufgrund des User-Agent-Werts:

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

Die Anforderung enthält Arrays aus IP- und MAC-Adressen. In diesem Beispiel enthält jedes Array nur einen Wert.

Das Protokoll zeigt an, dass die Sitzungs-ID der Anforderung NULL ist. Dies bedeutet, dass es sich um eine Anforderung des nicht umleitungsbasierten Tests handelt.

Später können Sie sehen, wie Werte aus Arrays zum Auffinden einer Sitzungs-ID verwendet werden:

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

Nach der Zeile mit den Schlüsselwörtern "Sent http response" können Sie den Inhalt der eigentlichen Antwort sehen:

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

Untersuchung zu ISE-Berichten

Nachdem Sie die ID der veralteten/Phantom-Sitzung kennen, können Sie den Radius-Accounting-Bericht untersuchen, um ein besseres Verständnis darüber zu erhalten, was diese Sitzung veraltet/Phantom wurde:

• Navigieren Sie zu Operations > Reports > Endpoints and Users > Radius Accounting (Vorgänge > Berichte > Endpunkte und Benutzer > Radius-Buchhaltung), und führen Sie diesen Bericht 7 Tage lang aus. Verwenden Sie eine Endpunkt-ID als Filterschlüssel.

Im Folgenden finden Sie ein Beispiel für einen Bericht, der aufzeigt, wie veraltete Sitzungen auf ciscolive-ise2 überlebt haben:

1. Der Accounting-Start für die Sitzung erfolgte über das PSN ciscolive-ise2.
2. Die Zwischenaktualisierung für die Sitzung wurde auf demselben PSN verarbeitet.
3. Eine Accounting-Stopp-Nachricht für die problematische Sitzungs-ID wurde an ein anderes PSN gesendet (ciscolive-ise1).

Eine schnelle Methode zur Identifizierung, wann das Problem durch das Fehlen eines Discovery-Neustarts verursacht wurde

Hier gilt dieselbe Logik wie für die vorherige Ausgabe. Der einzige Unterschied besteht darin, dass Sie sich auf die letzte Startzeit des Scans konzentrieren müssen. Bei dieser Art von Problem liegt der Zeitstempel des letzten Scans irgendwo in der Vergangenheit.

Wenn der Endbenutzer ein Problem erkennt, wird normalerweise ein Scan angezeigt, der vor einiger Zeit durchgeführt wurde. Während der ISE Radius Live-Protokolle werden die letzten Authentifizierungsversuche vom problematischen Endpunkt festgestellt.

Die Demo zeigt die Aufzeichnung der Schritte zur Problemermittlung:

Erweiterte Fehlerbehebung Fehlende Erkennung Neustart

Der Ansatz hier ähnelt dem Abschnitt Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen. Das wichtigste Element der Fehlerbehebung ist die Untersuchung des DART-Pakets.

Innerhalb des DART-Pakets können Sie nach Neustarts der Erkennung suchen (wie für das vorherige Problem dargestellt) und bestätigen, dass zum Zeitpunkt der Problemmeldung kein Neustart der Erkennung stattgefunden hat.

Konzentrieren Sie sich auf der ISE-Seite auf den Authentifizierungsbericht Radius Live Logs/Radius, um sicherzustellen, dass zwischen den PSNs ein Failover stattgefunden hat, oder dass von NAD eine neue Sitzungs-ID generiert wurde.

Lösung

Klassischer Ansatz - Vermeidung von Problemen

In der Vergangenheit gab es keine Funktion für die ISE, die die in diesem Dokument beschriebenen Probleme lösen konnte. Die einzige Möglichkeit bestand daher darin, sich auf die Best Practices zu verlassen, die auf dem Netzwerk und der ISE-Seite implementiert werden, um Risiken zu minimieren.

Best Practices zur Minimierung veralteter oder Phantom-Sitzungen bei der ISE-Bereitstellung

Implementieren Sie, wenn möglich, stets einen auf Umleitung basierenden Status.

Ein häufiges Gegenargument zu dieser Empfehlung ist ein schlechtes Anwendererlebnis. Es werden Popup-Fenster im Betriebssystem oder im Browser angezeigt. Dies zeigt eine Umleitung an, während das AnyConnect ISE-Statusmodul im Hintergrund einen Bewertungsprozess durchführt.

Als Lösung hierfür ist es möglich, NUR ISE Posture-Modul-Erkennungssonden umzuleiten und selektiv den gesamten anderen Datenverkehr zuzulassen.

Dieses Beispiel zeigt eine Umleitungszugriffskontrollliste, die nur zum Umleiten von HTTP-Anforderungen an den Discovery Host (in diesem Beispiel 10.1.1.1) und an enroll.cisco.com (172.16.1.80) entwickelt wurde:

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

Um ein akzeptables Maß an Sicherheit zu gewährleisten, kann eine solche Umleitungs-ACL mit einer von der ISE zugewiesenen DACL kombiniert werden.

Ausstehend - Ermöglicht Verbindungen nur mit PSN, wenn das Endgerät authentifiziert wurde

Dieser Ansatz eignet sich für Umgebungen, in denen die URL-Umleitung nicht unterstützt wird (z. B. Implementierungen mit NADs von Drittanbietern).

Implementieren Sie als Lösung mehrere PosturePending-Autorisierungsrichtlinien (eine pro PSN). Jede Richtlinie muss als eine der Bedingungen den Namen des PSN enthalten, bei dem die Authentifizierung erfolgt ist.

Im Autorisierungsprofil, das jeder Richtlinie zugewiesen ist, muss der Zugriff auf alle PSNs mit Ausnahme des Knotens blockiert werden, an dem die Authentifizierung erfolgt ist.

Erstellen von Autorisierungsrichtlinien für die Bereitstellung von 2 Knoten:

 

1. Ausstehende Statusrichtlinie für PSN1

2. Der PSN1-Name, der als Bedingung in der Richtlinie verwendet wird.

3. Autorisierungsprofil mit ACL, das den Zugriff auf alle PSNs außer PSN1 blockiert.

4. Ausstehende Statusrichtlinie für PSN2.

5. Der als Bedingung in der Richtlinie verwendete PSN2-Name.

6. Autorisierungsprofil mit ACL, das den Zugriff auf alle PSNs außer PSN2 blockiert.

7. Autorisierungsrichtlinie für Status "konform".

Die Abbildung erklärt, wie dieser Ansatz funktioniert:

1. Authentifizierungstreffer PSN1.

2. Aufgrund konfigurierter Autorisierungsrichtlinien weist PSN1 ein Autorisierungsprofil zu, das den Zugriff auf alle anderen Knoten mit Ausnahme von PSN1 blockiert.

3. Das AnyConnect ISE-Statusmodul startet den Erkennungsprozess neu.

4. Die Sonde für PSN2 wird vom NAD blockiert, da sie von einer zuvor zugewiesenen ACL blockiert wird.

5. Der Test für PSN1 ist durch die auf NAD zugewiesene ACL zulässig.

Load Balancer - Best Practices

• Aktivieren Sie Stickiness auf dem Load Balancer für Authentifizierung und Abrechnung, wobei Calling-Station-ID als Stickiness-Schlüssel verwendet wird. Weitere Informationen zu LB Best Practices für ISE finden Sie hier.
• Verwenden Sie einen Verklebungszeitgeber, der länger als ein durchschnittlicher Arbeitstag ist, um den Moment abzudecken, in dem der PC in den Schlaf geht (z. B. 10 statt 8 Stunden).
• Falls eine erneute Authentifizierung implementiert ist, verwenden Sie einen etwas niedrigeren Timer für die erneute Authentifizierung als den Stickiness-Timer (z. B. 8 Stunden, wenn Stickiness für 10 Stunden konfiguriert ist). Dadurch wird sichergestellt, dass das Stickiness-Intervall durch eine erneute Authentifizierung verlängert wird.

Statusüberprüfung beim VPN-Anwendungsfall 

• Stellen Sie sicher, dass das Aktualisierungsintervall accounting-interim größer oder gleich vpn-session-timeout ist. Dadurch wird das Flapping bei der Abrechnung zwischen den PSNs während langer VPN-Sitzungen minimiert. 

Dieses Beispiel zeigt das Interim Accounting-Aktualisierungsintervall, das für 20 Stunden konfiguriert wurde. Das anfängliche Zwischenupdate, das die dem Endpunkt zugewiesene IP-Adresse enthält, wird dadurch nicht verhindert.

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 können implementiert werden, um die Auswirkungen eines fehlenden ISE-Statusmodul-Erkennungsneustarts zu minimieren

Statusleasing aktivieren 

Dies ist eine Funktion auf der ISE, die ein Endgerät für einen definierten Zeitraum (1-365 Tage) als konform markiert. Der Status-Leasingwert ist ein Endgeräteattribut, d. h., er wird in der ISE DB gespeichert.

Alle Endpunkteigenschaften, die Statusleasing umfassen, werden über alle Knoten in der ISE-Bereitstellung repliziert.

Wenn PSN eine neue Sitzung für den Endpunktstatus erhält, kann diese sofort als konform markiert werden.

Für diese Entscheidung verwendet PSN drei Werte. Diese Werte sind:

1. Anzahl der Tage, die in den ISE-Einstellungen für den Status-Leasing definiert wurden: Navigieren Sie zu Administration > System > Posture > General Settings:

2. Das PostureExpiry-Attribut ist ein tatsächliches Endpunktattribut, das einen Epoch-Zeitstempel enthält. PostureExpiry-Wert wird anfänglich beim ersten erfolgreichen Statusversuch für Endpunkt aufgefüllt, nachdem der ISE-Administrator das Statusleasing aktiviert hat.

Später wurde dieser Wert beim nächsten erfolgreichen Statusversuch aktualisiert, der nach Ablauf des Leasingvertrags stattfindet.

            Sie können ein PostureExpiry-Ereignis in Context Visibility > Endpoints (Kontextsichtbarkeit > Endpunkte) sehen, während einer der bereitgestellten Endpunkte geöffnet wird:

           Dieser Wert kann z. B. hier in den menschenlesbaren Zeitstempel konvertiert werden - https://www.epochconverter.com/

3. PSN-Systemzeit zum Zeitpunkt der neuen Authentifizierung

Wenn die Authentifizierung für einen Endpunkt mit Posture Lease auf PSN trifft, werden PostureExpiry und das Systemdatum verwendet, um die Anzahl der Tage abzurufen, die seit der letzten erfolgreichen Posture Check vergangen sind.

Wenn der Ergebniswert innerhalb eines in den Einstellungen definierten Leaseintervalls liegt, erhält die Sitzung den Status Compliance.

Wenn der Ergebniswert höher als der Lease-Wert ist, erhält die Sitzung den Status Unbekannt.

Dadurch wird der Status erneut ausgeführt, und der neue PostureExpiry-Wert kann gespeichert werden.

In diesem Diagramm wird der Vorgang bei einem Failover dargestellt:

1. Die Erstauthentifizierung erfolgt mit PSN1.

2. Session-ABC wird im Session-Cache erstellt.

3. Statusüberprüfung wird durchgeführt.

4. Änderungen des Sitzungsstatus in "Konformität"

5. COA wird durch Statusänderungen ausgelöst und führt zur erneuten Authentifizierung des Endpunkts, um die nächste Zugriffsebene anzuwenden.

6. PostureExpiry-Wert wird im Endpunkt gespeichert.

7. Endpunktdaten werden in der gesamten Bereitstellung repliziert.

8. Nächste Authentisierung trifft auf PSN2.

9. PSN2 überprüft, ob sich der Endpunkt innerhalb eines gültigen Leasingvertrags mit Status befindet.

11. Sitzung wird dem Sitzungscache als konform hinzugefügt.

12. Aufgrund des gültigen Leasingvertrags wird die Sitzung mit dem Status "Konformität" erstellt.

Implementierung der erneuten Authentifizierung 

Push-Timer für die Neuauthentifizierung immer von der ISE mit RADIUS-Request, ausgewählt unter Verbindung bei Neuauthentifizierung aufrechterhalten. Mit dieser Einstellung wird sichergestellt, dass NAD bei der erneuten Authentifizierung dieselbe Sitzungs-ID beibehält.

.

Umgebungen mit Load Balancern

Es können dieselben Best Practices (wie im Abschnitt veraltete/Phantom-Sitzungen erläutert) implementiert werden.

Verschiedene Subnetze können für ausstehende und konforme Zustände verwendet werden

Wenn das Netzwerkdesign die Möglichkeit bietet, verschiedene Subnetze mit dem Status Ausstehend und Konformität zu verwenden, garantiert dieser Ansatz, dass jede Statusänderung zu einer Änderung des Standard-Gateways führt.

Statusüberprüfung Im gleichen Intervall wie bei einem Timer zur erneuten Authentifizierung verwendet

Die Statusüberprüfung kann aktiviert werden, wobei das Intervall dem Neuauthentifizierungs-Timer entspricht. Wenn das ursprüngliche PSN nicht mehr verfügbar ist, startet der PRA-Fehler den Erkennungsprozess neu.

Moderner Ansatz - Statusfreigabe

Als Teil einer implementierten Erweiterung (beschrieben in Cisco Bug-ID CSCvi35647 ) verfügt Patch 6 für ISE 2.6 über eine neue Funktion, die die Freigabe des Sitzungsstatus für alle Knoten in der ISE-Bereitstellung implementiert.

Diese Erweiterung ist Bestandteil zukünftiger Versionen: ISE 2.7 Patches 2 und ISE 3.0.

Diese neue Funktion basiert auf dem LSD-Mechanismus (Light Session Directory), der in ISE 2.6 eingeführt wurde. In den neueren Versionen wurde diese Funktion in LDD (Light Data Distribution) Radius Session Directory umbenannt.  Light Data Distribution ist standardmäßig aktiviert und ermöglicht die gemeinsame Nutzung eines begrenzten Sitzungskontexts zwischen ISE-Knoten. Es gibt keine vollständige Replikation des Sitzungskontexts zwischen PSNs, sondern nur eine begrenzte Anzahl von für jede Sitzung freigegebenen Attributen.

Light Session Directory macht kostspielige API-Aufrufe an MNT überflüssig, wenn einer der Knoten in der Bereitstellung den aktuellen Sitzungsbesitzer bestimmen muss.

Meist ist eine Owner-Suche erforderlich, wenn der COA-Fluss beginnt. Mit LDD kann jeder PSN einen tatsächlichen Besitzer der Sitzung aus dem lokalen Radius Session Directory-Cache finden. 

Architektur für die leichte Datenverteilung

Diese Funktion umfasst folgende Elemente:

• Radius Session Directory (RSD)-Cache

Dieser Cache ist auf allen ISE-Knoten vorhanden und speichert alle aktiven Sitzungen in der ISE-Bereitstellung. Jede Sitzung hat eine begrenzte Anzahl von Attributen im Cache. 

Nachfolgend finden Sie Beispiele für die Attribute, die für jede Sitzung im Radius-Sitzungsverzeichnis gespeichert sind:

• Sitzungs-ID
• Endpunkt-MAC
• AnrufstationID
• Endpunkt-IP
• PSN-IP - PSN, bei dem die Authentifizierung erfolgt ist
• PSN-FQDN 
• NAS-IP-Adresse
• NAS-IPv6-Adresse
• Status - Authentifiziert, gestartet, gestoppt

• RabbitMQ-Austausch

Es wird eine Börse gebildet, in der Publisher, zugehörige Queue und Consumer auf jedem Knoten in der ISE-Bereitstellung dargestellt werden. Dadurch wird sichergestellt, dass sich die vollständig vermaschte Topologie zwischen allen ISE-Knoten bildet.

• Herausgeber

Das Radius-Sitzungsverzeichnis stellt hier einen Publisher dar. Wenn eine neue erfolgreiche Authentifizierung von einem PSN verarbeitet wird, wird eine neue Sitzung im PSN-Sitzungscache erstellt.

Für diese Sitzung wird ein begrenzter Satz von Attributen in das Radius-Sitzungsverzeichnis eingefügt.

• Consumer - auf allen anderen Knoten. Radius-Sitzungsverzeichnis stellt einen Consumer dar.

Die Abbildung erklärt, wie der COA-Fluss mit dem RSD-Cache funktioniert:

1. Die Erstauthentifizierung erfolgt mit PSN1.

2. Session-ABC wird im Session-Cache erstellt.

3. Erforderliche Attribute werden in RSD gespeichert.

4. Die Sitzung wird über RabbitMQ mit allen anderen ISE-Knoten geteilt.

5. Die Sitzung wird im RSD-Cache auf allen ISE-Knoten erstellt.

6. Neue Profildaten kommen auf PSN2 an.

7. Endpunkt wird reprofiliert und (im Fall einer Änderung, die COA-Ausführung erfordert PSN2) geht mit dem nächsten Schritt.

8. Ein interner API-Aufruf wird an den RSD-Cache übermittelt, um COA auszuführen.

9. Daten aus dem RSD-Cache werden zur Vorbereitung einer Proxy-COA-Nachricht verwendet. Er wechselt von einem ISE-Knoten zu einem anderen und enthält alle Details, die der Zielknoten verwenden kann, um eine CAO-Anforderung an NAD zurückzugeben. Die COA-Nachricht wird zunächst intern an PRRT Runtime (tatsächlicher AAA-Server innerhalb der ISE) übertragen.

10. PSN2 sendet eine COA-Nachricht an PSN1.

11. PSN1 sendet eine COA-Nachricht an NAD.

Aktivieren Sie die Light Session Director-Komponente in DEBUG, um Probleme bei der Kommunikation über LDD auf der ISE zu beheben:

Hier ist ein Beispiel für eine Debug-Meldung aus der Datei lsd.log zur Sitzungserstellung und Veröffentlichung auf dem ursprünglichen 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

Auf allen anderen ISE-Knoten wird angezeigt, wie eine Sitzung genutzt wurde:

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

Statusfreigabe über RSD

Die Statusfreigabe löst Probleme, wenn die Ursache entweder "Stale/Phantom Session" oder "Re-authentication" auf verschiedenen PSNs ist, die keinen Neustart der Erkennung ausgelöst haben.

Sobald die Sitzung "Compliant" wird, werden diese Informationen in die RSD-Sitzung eingefügt, die später von jedem PSN in der Bereitstellung verwendet werden kann.

Es gibt noch einige andere Eckfälle, die die beschriebene Funktion nicht lösen kann. Beispiel: NAD führt eine erneute Authentifizierung auf demselben PSN mit einer anderen Sitzungs-ID durch.

Solche Szenarien können mit den in diesem Dokument beschriebenen Best Practices behandelt werden.

Diese Abbildung zeigt die Topologie, die für einen Test der Statusfreigabe verwendet wird:

Statusfreigabe über RSD - veraltete/Phantom-Sitzung

Um eine veraltete Sitzung zu erstellen, muss die Authentifizierung zunächst auf dem skuchere-ise26-1 ausgeführt werden. Anschließend muss NAD neu konfiguriert werden, um die Abrechnung an skuchere-ise26-3 zu senden.

Nachdem eine Accounting-Nachricht an das falsche PSN weitergeleitet wurde, muss NAD (erneut) neu konfiguriert werden, um das Accounting zurück an skuchere-ise26-1 zu senden.

Die Abbildung zeigt einen Abrechnungsbericht, der das Vorhandensein der Phantom-Sitzung auf skuchere-ise26-3 belegt:

1. Accounting-Start Nachrichten verarbeitet von skuchere-ise26-1.

2. Interim Accounting-Update für dieselbe Session, die von skuchere-ise26-3 verarbeitet wird.

3. Die Sitzung endet später auf skuchere-ise26-1.

Nach einiger Zeit stellt der Endpunkt wieder eine Verbindung mit dem Netzwerk her, aber die Umleitung funktioniert nicht mehr. Im guest.log von PSN - skuchere-ise26-3 können Sie diese Protokollmeldungen sehen, wenn die Client-webapp-Komponente in DEBUG aktiviert ist:

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

Wenn PSN feststellt, dass eine veraltete/Phantom-Sitzung für den Endpunkt vorhanden ist, antwortet es nicht auf das ISE-Statusmodul. Dies ermöglicht es uns, die richtige Antwort vom PSN zu erhalten, wenn die letzte Authentifizierung erfolgt ist.

Als Lösung für veraltete/Phantom-Sitzungsprobleme bei der Suche nach einer Sitzung überprüft PSN, ob eine neue Sitzung für den Endpunkt im RSD vorhanden ist.

Wenn der RSD eine andere Sitzungs-ID enthält als PSN im lokalen Sitzungscache, wird davon ausgegangen, dass die Sitzung (im Sitzungscache dargestellt) veraltet ist.

Statusfreigabe über RSD - Failover zwischen PSNs

Zur Reproduktion dieses Szenarios wird in dem Autorisierungsprofil, das dem kompatiblen Statusendpunkt zugewiesen ist, ein kurzer Neuauthentifizierungs-Timer aktiviert.

Später wird NAD neu konfiguriert, um die Authentifizierung und Abrechnung an ein anderes PSN (skuchere-ise26-3) zu senden.

Nach Ablauf des Zeitgebers für die Neuauthentifizierung wird dieselbe Sitzung auf dem anderen PSN nicht authentifiziert.

Die Abbildung zeigt einen Authentifizierungsbericht, der Failover für dieselbe Sitzung von skuchere-ise26-1 zu skuchere-ise26-3 anzeigt:

1. Authentifizierung erfolgt auf skuchere-ise26-1, Autorisierungsprofil mit Umleitung wird zugewiesen.

2. COA nach erfolgreicher Haltungsbeurteilung.

3. Die nächste Authentifizierung bei der Zuweisung eines Autorisierungsprofils für den kompatiblen Status.

4. Die Authentifizierung trifft auf verschiedene PSN zu, erhält aber weiterhin ein Autorisierungsprofil für den kompatiblen Zustand.

Die Sitzung hat auf dem neuen PSN nach einem Failover in ise-psc.log den Compliance-Status, wenn die epm-pip- und nsf-session-Komponenten in DEBUG aktiviert sind:

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

Das ursprüngliche Problem wird durch die Hinzufügung von zusätzlicher Logik in den Statusauswahlprozess gelöst.

Diese Abbildung zeigt, was geändert wurde (Änderungen rot hervorgehoben):