ISE-Sitzungsmanagement und -Status

Einführung

Dieses Dokument beschreibt das häufige ISE-Statusdienstproblem (Identity Service Engine) - das AnyConnect ISE-Statusmodul erfüllt die Richtlinien, während der Sitzungsstatus auf der ISE aussteht. Dieses Problem wird immer beliebter, und obwohl die Symptome immer gleich sind, kann es mehrere tatsächliche Ursachen für dieses Problem geben. Häufig ist die Fehlerbehebung bei einem solchen Problem extrem zeitaufwendig, was schwerwiegende Auswirkungen haben kann.

Hintergrundinformationen

In diesem Dokument wird erläutert:

• Problemmanifestation aus Endbenutzer- und ISE-Administratorperspektive.
• Häufige Problemszenarien.
• Die Theorie hinter ISE, AnyConnect und dem Netzwerkbetrieb, die das Problem auslösen kann.
• Algorithmen zur schnellen Problemerkennung.
• Klassische Lösungen für häufige Problemszenarien.
• Statusfreigabe über das Radius-Sitzungsverzeichnis.

Für ein besseres Verständnis der später beschriebenen Konzepte wird empfohlen:

Problem

Anwendererlebnis

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

Typische Endbenutzerumgebung:

ISE-Administratorerfahrung

In der Regel führt der ISE-Administrator während des ersten Triage dieses Problems eine Radius-Live-Protokollüberprüfung durch, um sicherzustellen, dass die ISE tatsächlich authentifiziert wird. Das erste Symptom, das während dieser Phase entdeckt wurde, weist darauf hin, dass der Status des Endpunkts und der ISE nicht übereinstimmt, da in den Live-Protokollen oder RADIUS-Authentifizierungsberichten die letzte erfolgreiche Authentifizierung für den Endpunkt den Status Ausstehend Status angezeigt wird.

Typische ISE-Administrationserfahrung:

• Letzte erfolgreiche Authentifizierung für Alice.
• Der Status der Sitzung ist ausstehend.
• Letzte Session-Veranstaltung für Alice.
• Das Sitzungsereignis zeigt den Status als konform an.

Hinweis: c) und d. werden nicht immer in den Live-Protokollen angezeigt, wenn Problemmanifeste beschrieben werden. Sitzungsereignisse mit Status-Status Entspricht sind häufiger für Szenarien, die durch veraltete oder Phantom-Sitzungen verursacht werden, die später in diesem Dokument beschrieben werden.

Häufige Problemszenarien

Dieses Problem manifestiert sich normalerweise in zwei problematischen Szenarien, die jeweils mehrere Ursachen haben können. Die Szenarien:

• Das AnyConnect ISE-Statusmodul wurde während des Statusprozesses vom Policy Service Node (PSN) falsch informiert, wodurch der falsche Status angezeigt wurde. In diesem Fall wird normalerweise eine veraltete oder Phantom-Sitzung im PSN-Sitzungscache behandelt.
• AnyConnect ISE zeigt den Status des vorherigen Erkennungszyklus an, da die aktuelle Authentifizierung keinen Erkennungsprozess auslöst.Das ISE-Statusmodul in AnyConnect verfügt über eine begrenzte Anzahl von Ereignissen, die den Erkennungsprozess auslösen. Es kann vorkommen, dass während der Authentifizierung oder erneuten Authentifizierung keines dieser Ereignisse erkannt wurde.

Problem mit veralteten/Phantom-Sitzungen

Um das Problem besser zu verstehen, benötigen Sie detaillierte Informationen zur ISE-Sitzungsverwaltungslogik und zum AnyConnect-Erkennungsprozess.

ISE-Sitzungsmanagement-Logik

Bei der ISE-Bereitstellung sind zwei Personen für den Sitzungsmanagement-Prozess verantwortlich: PSN und Monitoring Node (MNT). Um dieses Problem richtig zu beheben und zu identifizieren, ist es wichtig, die Theorie des Sitzungsmanagements auf beiden Personas zu verstehen.

MNT und Sitzungsmanagement

Wie in der Abbildung "MNT-Knoten" erläutert, werden Jahreszeiten basierend auf der bestanden Authentifizierung Syslog-Meldungen von PSNs erstellt. Spätere Sitzungsstatus können von Syslog zur Abrechnung aktualisiert werden.

Die Sitzungsentfernung auf MNT erfolgt in 3 Szenarien:

• Sitzungen ohne Accounting beginnen ca. 60 Minuten nach ihrer Erstellung entfernt. Alle 5 Minuten wird ein Cron-Auftrag ausgeführt, um den Sitzungsstatus zu überprüfen und die Reinigung durchzuführen.
• Die beendete Sitzung wurde ca. 15 Minuten entfernt, nachdem der Accounting-Stopp vom selben Cron-Auftrag verarbeitet wurde.
• Derselbe Cron für jede Ausführung entfernt auch Sitzungen, die sich mehr als 5 Tage (120 Stunden) im Status "Gestartet" befinden. Ein Startzustand bedeutet, dass der MNT-Knoten sowohl Authentifizierung als auch Accounting verarbeitet hat, um Syslog für die Sitzung zu starten.

Beispiele für Syslog-Meldungen von PSN. Diese Meldungen werden bei der in DEBUG aktivierten Laufzeitaa-Komponente "prt-server.log" angemeldet. Fettgedruckte Teile können zum Erstellen von regulären Ausdrücken verwendet werden.

Passed Authentication:

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

Buchhaltungsstart:

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

Aktualisierte 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

Buchhaltung Stopp:

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

Was ist der PSN-Sitzungscache?

Eine In-Memory-Datenbank, die alle aktiven Sitzungen eines bestimmten PSN speichert. Der Sitzungscache ist immer lokal für den Knoten, und es gibt keinen Mechanismus in der ISE, der die Replikation des VOLLSTÄNDIGEN Sitzungszustands von einem Knoten zu einem anderen durchführen kann.

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

Der Sitzungscache wurde vollständig entfernt, wenn Dienste auf dem Knoten oder Knoten selbst neu gestartet werden.

Durch die aktuelle Sitzungsverarbeitungslogik wird in zwei Szenarien ein neuer Eintrag im Sitzungscache erstellt. Spätere Details der vorhandenen Sitzungen können aus den von NADs stammenden Accounting-Meldungen aktualisiert werden:

• Die Sitzung wurde im PSN erfolgreich authentifiziert.
• PSN hat eine Zwischenaktualisierung für die Sitzung erhalten, die nicht im Sitzungscache vorhanden ist.

Beim Entfernen von Sitzungen implementiert PSN folgende Logik:

• Der Sitzungscacheneintrag wurde unmittelbar nach Verarbeitung der Stopp-Nachricht für die Abrechnung entfernt.
• PSN entfernt die zuletzt verwendeten Sitzungen, 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 nicht die eigentliche Authentifizierung durchgeführt hat:

Beispiel für eine veraltete Sitzung:

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

2. PSN erstellt einen Eintrag im Sitzungscache.

3. Statusüberprüfung erfolgt.

4. Sitzung als konform markiert.

5. Durch Statusänderungen ausgelöste Änderungen der Autorisierung (COA) führen zur erneuten Authentifizierung des Endpunkts, um die nächste Zugriffsebene anzuwenden.

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

Nach Schritt 6 wird ABC auf dem PSN1 im veralteten Zustand festgehalten, da auf diesem PSN keine Abrechnungsstopmeldung zum Entfernen des Geräts verarbeitet wird. Wenn bei der Bereitstellung nicht viele Authentifizierungsversuche vorliegen, kann die Sitzung für lange Zeit nicht entfernt werden.

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

• Der Abrechnungsstopp kam aufgrund des Ablaufs des Stickiness-Timers am Load Balancer zum falschen PSN.
• Die falsche Konfiguration auf der NAD ist nicht dasselbe PSN, das für Authentifizierung und Abrechnung konfiguriert wurde.
• Temporäre Verbindungsprobleme im Netzwerkpfad, die zu einem NAD-Failover zum nächsten PSN führen.

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

1. Erstauthentifizierung für den Session-ABC durch PSN 1.

2. Diese Authentifizierung initiiert einen Stickiness-Timer auf dem Load Balancer.

3. PSN 1 erstellt einen Eintrag für die Sitzung-ABC im lokalen Cache.

4. Syslog-Meldung für die übergebene Authentifizierung, die an den MNT-Knoten übertragen wurde.

5. Eintrag für ABC der Sitzung, der im MNT-Sitzungsverzeichnis mit dem Status Authenticated erstellt wurde.

6. Die Startnachricht für die Accounting-Funktion für die Sitzung ABC landet auf PSN 1.

7. Sitzungscache-Eintrag für Sitzung ABC aktualisiert mit Informationen aus Accounting-Start.

8. Syslog-Meldung für Accounting-Start auf MNT-Knoten übertragen.

9. Sitzungsstatus aktualisiert auf "Gestartet".

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

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

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

13. Sitzung ABC als auf MNT beendet markiert.

Phantom-Sitzung auf dem PSN

Die Phantom-Sitzung ist ein Szenario, in dem Zwischenaktualisierungen der Buchhaltung zum PSN kommen, die keine Authentifizierung für diese bestimmte Sitzung durchgeführt haben. In diesem Szenario wird ein neuer Eintrag im PSN-Sitzungscache erstellt, und wenn PSN keine Abrechnungsstopmeldung für diese Sitzung erhält, wird der Eintrag erst entfernt, wenn PSN die Grenze für aktive Sitzungen erreicht.

Beispiel einer Phantom-Sitzung:

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

2. Der Session-ABC ist im PSN1-Sitzungscache dem Status entsprechend.

3. Accounting Interim Update für Session ABC Hits PSN2.

4. Sitzungseintrag für auf PSN2 erstellte Sitzung-ABC. Da der Sitzungseintrag aus der Abrechnungsmeldung erstellt wurde, verfügt er über eine begrenzte Anzahl von Attributen. Beispielsweise ist für den Sitzungs-ABC kein Status verfügbar. Auch Elemente wie Benutzergruppen und andere autorisierungsspezifische Attribute fehlen.

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

• Kurzfristige Ausfälle beim Netzwerktransport.
• Fehlverhalten des Netzwerkzugriffsgeräts.
• Fehlverhalten oder falsche Konfiguration auf Load Balancer.

Beispiel einer Phantom-Sitzung für das Szenario mit temporären Problemen im Netzwerkpfad zu PSN1:

1. Erstauthentifizierung für den Session-ABC durch PSN.

2. PSN1 erstellt einen Eintrag für die Sitzung-ABC im lokalen Cache.

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

4. Eintrag für Sitzung ABC erstellt in TimesTen DB mit dem Status Authenticated.

5. Die Startnachricht für die Accounting-Funktion für die Sitzung ABC landet auf PSN 1.

6. Sitzungscache-Eintrag für Sitzung ABC aktualisiert mit Informationen aus Accounting-Start.

7. Syslog-Meldung für Accounting-Start auf MNT-Knoten übertragen.

8. Sitzungsstatus aktualisiert auf "Gestartet".

9. Interim-Accounting-Update für die Sitzung ABC an PSN2 weitergeleitet.

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

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

12. Eintrag für Sitzung-ABC aus dem Sitzungscache auf PSN1 entfernt.

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

14. Sitzung ABC als auf MNT beendet markiert.

Das Szenario der Phantom-Sitzung, die für die VPN-Verbindung mit langer Lebensdauer erstellt wird:

1. Erstauthentifizierung auf PSN1.

2. Im Sitzungscache erstellte Sitzung-ABC.

3. Die Abrechnung startet die vom PSN verarbeitete Nachricht.

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

5. Zwischenabrechnungs-Update mit IP-Adressinformationen landet auf PSN.

6. Dem Sitzungscache hinzugefügte IP-Adressinformationen.

7. Statusüberprüfung mit PSN1.

8. Status in der Sitzung aktualisiert.

9. Der von der ISE ausgeführte COA-Push löst die Zuweisung einer neuen Zugriffsebene aus.

10. Ausfall des Netzwerkpfads, wodurch der Zugriff auf PSN1 nicht möglich ist.

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

12. Die Aktualisierung der vorläufigen Buchhaltung kommt zu PSN2.

13. Die Phantom-Sitzung, die im PSN2-Sitzungscache erstellt wurde.

Wenn später auf PSN1 zugegriffen werden kann (14), werden alle nachfolgenden Accounting-Nachrichten (15,16) dorthin weitergeleitet. Dadurch bleibt ABC der Sitzung für eine undefinierte Zeit im PSN2-Sitzungscache.

Wie kann eine veraltete Sitzung und Phantom-Sitzung den Statusprozess unterbrechen?

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

Phase 1 Erkennung:

In dieser Phase führt das ISE-Statusmodul 4 Probleme gleichzeitig aus, um das PSN zu finden, das eine Authentifizierung für den Endpunkt durchgeführt hat.

Zunächst werden drei Probes der Zahl umgeleitet (Standard-GW-IP). Discovery Host IP (falls definiert) und enroll.cisco.com IP) - Diese Tests sollten den Agenten immer auf das rechte PSN verweisen, da die Weiterleitungs-URL vom NAD selbst übernommen wird.

Die Testnummer 4 wird an alle primären Server gesendet, die in der ConnectionData.xml-Datei dargestellt sind. Diese Datei, die nach dem ersten erfolgreichen Statusversuch erstellt wurde, und spätere Dateiinhalte können aktualisiert werden, wenn der Client zwischen PSNs migriert. Auf Windows-Systemen lautet der Speicherort der Datei: C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Da alle Tests der Stufe 1 gleichzeitig ausgeführt werden, wird das Ergebnis der Probe 4 nur verwendet, wenn alle anderen 3 Tests fehlschlagen oder das ISE-Statusmodul nicht in der Lage war, eine ordnungsgemäße Kommunikation mit dem in der Umleitungs-URL zurückgegebenen PSN innerhalb von 5 Sekunden herzustellen.

Wenn die Probe 4 auf das PSN übertragen wird, enthält sie eine Liste der aktiven IP- und MAC-Adressen, die auf dem Endpunkt erkannt wurden. PSN verwendet diese Daten, um eine Sitzung für diesen Endpunkt im lokalen Cache zu suchen. Wenn PSN über eine veraltete oder Phantom-Sitzung für Endpunkte verfügt, kann dies zu einem falschen Status führen, der später auf Client-Seite angezeigt wird.

Wenn ein Agent mehrere Antworten für Frage 4 erhält (ConnectionData.xml kann mehrere primäre PSNs enthalten), wird immer die schnellste Antwort verwendet.

Phase 2: Erkennung:

Alle Erkundungstests der Stufe 2 sind umleitungslos, d. h., jede Anfrage löst eine Sitzungssuche auf dem Ziel-PSN aus. Wenn das PSN die Sitzung im Cache für lokale Sitzungen nicht finden kann, muss es eine MNT-Suche (nur MAC-Adresse) durchführen, um einen Sitzungseigentümer zu finden und den Eigentümernamen an den Agenten zurückzugeben.

Da alle Sonden die Suche nach Sitzungen auslösen, kann die Erkennung in Phase 2 noch stärker von Problemen durch veraltete oder Phantom-Sitzungen betroffen sein.

Wenn PSN auf Stufe 2 geht, erstellt die im Sitzungscache vorhandene Erkennungsprobe einen veralteten oder Phantom-Eintrag für denselben Endpunkt. Daraus ergibt sich der falsche Status, der an den Endbenutzer zurückgegeben wird.

Das Beispiel zeigt, wie der Status auftritt, wenn PSN eine veraltete Sitzung oder eine Phantom-Sitzung abhält:

Hinweis: Es ist wichtig, sich daran zu erinnern, dass dieses Problem nur auftreten kann, wenn alle auf der Umleitung basierenden Discovery-Tests fehlschlagen oder wenn der Status "Nicht umleiten" implementiert ist.

1. Alle vom ISE-Statusmodul bereitgestellten Sitzungssonden suchen

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

3. PSN führt die Richtlinienauswahl für die Client-Bereitstellung aus. Bei einer Phantom-Sitzung ohne Authentifizierungs-/Autorisierungsattribute sind alle vom Kunden konfigurierten Richtlinien sehr spezifisch (Richtlinien werden z. B. für bestimmte Active Directory-Gruppen erstellt), kann PSN möglicherweise keine geeignete Client-Bereitstellungsrichtlinie zuweisen. Dies kann in der Fehlermeldung "Bypasing AnyConnect scan your network is configured to use Cisco NAC Agent" (AnyConnect-Prüfung umgehen, das Netzwerk ist für die Verwendung von Cisco NAC Agent konfiguriert) manifestiert werden.

• Wenn die Client-Bereitstellungsrichtlinien allgemein sind (die in der Phantom-Sitzung verfügbaren Attribute reichen aus, um die Richtlinie mit der AnyConnect-Konfiguration abzustimmen), antwortet PSN mit den Details, die für die Fortsetzung des Bewertungsprozesses erforderlich sind.
• Auch in diesem Schritt, wenn wir mit veralteten Sitzungen behandeln können, antwortet PSN sofort mit Status Compliance und alle nächsten Schritte werden nicht ausgeführt. PSN sendet kein COA, da es der Ansicht ist, dass die Sitzung bereits konform ist. In RADIUS Live-Protokollen wird kein Sitzungsereignis mit dem Compliance-Status angezeigt.

4. Für das Phantom-Sitzungsszenario wird das ISE-Statusmodul mit der Anforderung des anfänglichen Status fortgesetzt. Diese Anforderung enthält Informationen zu allen Sicherheits- und Patch-Management-Produkten, die auf dem Endgerät erkannt wurden.

5. PSN verwendet Informationen aus den Anforderungs- und Sitzungsattributen, um die richtige Statusrichtlinie zu erfüllen. Da die Phantom-Sitzung zu diesem Zeitpunkt über keine Attribute verfügt, können wir möglicherweise keine übereinstimmenden Richtlinien verwenden. In einem solchen Fall antwortet PSN dem Endpunkt, dass es konform ist, da es sich um ein Standard-ISE-Verhalten handelt, wenn die Statusrichtlinien nicht übereinstimmen. 

Hinweis: Wenn eine generische Richtlinie aus Phantom-Sitzungsattributen ausgewählt werden kann, fahren Sie mit Schritt 6 fort.

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

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

7. Der Agent gibt die Status für jede Richtlinie/Anforderung als übergeben oder fehlgeschlagen zurück.

8. Die Berichtsauswertung erfolgt auf der ISE und Änderungen des Sitzungsstatus auf Konformität.

Hinweis: Bei Statusproblemen, die durch die Phantom-Sitzung verursacht wurden, kann der ISE-Administrator einige fehlgeschlagene StatusCOAs feststellen, da COA-Anfragen in diesem Fall von falschen PSNs und falschen Sitzungs-IDs ausgeführt werden.

Der Erkennungsprozess startet bei einem neuen Authentifizierungsversuch nicht.

ISE-Statusmodul zur Überwachung einer begrenzten Anzahl von Ereignissen am Endpunkt, um einen Erkennungsprozess auszulösen. Liste der Ereignisse, die die Erkennung auslösen:

• Erstinstallation des ISE-Statusmoduls.
• Benutzeranmeldung.
• Power-Events
• Änderung des Schnittstellenstatus.
• Das Betriebssystem wird nach dem Schlaf wieder aufgenommen.
• Änderung des Standard-Gateways (DG).
• Fehler bei der Statusneubewertung (PRA), siehe Cisco Bug-ID CSCvo69557

Neue 802.1x-Authentifizierung, PC-Entsperrung und IP-Adressänderung werden vom ISE-Statusmodul nicht erkannt.

Das ISE-Statusmodul kann in folgenden Szenarien keinen neuen Authentifizierungs- oder Re-Authentifizierungsversuch erkennen:

• Die erneute Authentifizierung trifft auf verschiedene PSNs (entweder aufgrund von LB-Entscheidungen oder Problemen mit dem ursprünglichen PSN).
• NAD generiert bei der erneuten Authentifizierung eine neue Session-ID.

Reauthentifizierung auf einem anderen PSN

Beispiel für eine erneute Authentifizierung auf verschiedenen PSNs, die durch den Ausfall des ursprünglichen PSN verursacht wurde. Das Szenario mit Load Balancer sieht sehr ähnlich aus. Bei LB wird die erneute Authentifizierung nach Ablauf des Stickiness-Timers an die verschiedenen PSNs weitergeleitet.

1. Erstauthentifizierung auf PSN1.

2. Im PSN1-Sitzungscache erstellte Sitzung-ABC.

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

4. Status des Sitzungs-ABS wechselt zu Compliance.

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

6. PSN1 ist nicht verfügbar.

7. Erneute Authentifizierung für Sitzungen ABC trifft PSN2.

8. Da es sich um eine neue Sitzung für den PSN2-Statusstatus der Sitzung handelt, wird diese als ausstehend angezeigt.

Anfänglicher Status, der der Sitzung vom PSN zugewiesen wurde:

Hinweis: State-Machine beschreibt nur eine erste Auswahl des Status-Status. Jede Sitzung, die ursprünglich als "Unbekannt" markiert wurde, kann zu einem späteren Zeitpunkt aufgrund der vom ISE-Statusmodul erhaltenen Berichtsauswertung zur Konformität oder zur Nicht-Konformität werden.

NAD generiert neue Sitzungs-ID bei Reauthentifizierung.

Dies kann in den beiden häufigsten Szenarien auftreten:

• Die erneute Authentifizierung auf ISE-Seite ist falsch konfiguriert. Die Lösung dieses Problems wird später in diesem Dokument behandelt.
• Falsches Verhalten von der NAD-Seite - normalerweise sollte NAD während des erneuten Authentifizierungsversuchs dieselbe Sitzungs-ID beibehalten. Falls Sie festgestellt haben, dass NAD eine Session-ID bei der erneuten Authentifizierung ändert, ist dies ein potenziell fehlerhaftes Verhalten, das im NAD selbst untersucht werden muss.

Die neue Sitzungs-ID kann in einigen anderen Szenarien in der Ecke generiert werden. In einigen Fällen kann beispielsweise das Wireless-Roaming eine Ursache dafür sein. Das Wichtigste dabei ist, dass ISE PSN immer eine neue Sitzung in den Status Pending-Status setzt, es sei denn, der Status-Lease ist konfiguriert. Der Status-Lease wird später in diesem Dokument beschrieben.

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

Um festzustellen, ob AnyConnect die Compliance anzeigt, während der Umleitungsstatus durch die veraltete/Phantom-Sitzung verursacht wird, müssen wir auf den Endpunkt zugreifen, während er sich im problematischen Zustand befindet.

1.  Details zur Systemprüfung:
   
   

     1. Drücken Sie auf das Zahnrad-Symbol in der AnyConnect-Benutzeroberfläche.

   

         2. Navigieren Sie im neuen Fenster zur Registerkarte Systemprüfung und zu den Unterregisterkarten Statistik.

   

           Beachten Sie dabei zwei Aspekte:

   •   Letzte Scan-Startzeit: Der Zeitstempel sollte hier die Zeit schließen, zu der das Problem erkannt wurde.
   •   Policy Server: Dieser Parameter gibt den Namen des Richtlinienservers an, 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 den Status der Redirect Base) oder mit dem PSN-Namen aus dem letzten Authentifizierungsversuch (für Status ohne Umleitung) verglichen werden.
2. Vergleichen Sie den Policy Server FQDN von der Systemscannstatistik mit dem Knotennamen, der die Authentifizierung für den Endpunkt durchgeführt hat:

Im vorliegenden Beispiel besteht eine Diskrepanz zwischen dem Namen, der angibt, dass PSN mit dem Namen ciscolive-ise2 eine veraltete oder Phantom-Sitzung für diesen Endpunkt enthält.

Die Demo zeigt die Aufzeichnung der Schritte, die für die Problemermittlung erforderlich sind:

Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen

Im vorherigen Beispiel wird das Problem einer veralteten oder Phantom-Sitzung vom Problem des Erkennungsvorgangs unterschieden, das nicht gestartet wurde. Gleichzeitig müssen wir möglicherweise die eigentliche Sitzung identifizieren, die das Problem ausgelöst hat, um besser zu verstehen, wie es zu einem Problem mit einer veralteten oder Phantom-Sitzung wird.

In manchen Fällen können veraltete und Phantom-Sitzungen nicht vermieden werden. Wir müssen sicherstellen, dass in der Umgebung keine veralteten/Phantom-Sitzungen erstellt werden, da einige der Best Practices nicht implementiert werden.

DART-Paketsammlung

Analysieren Sie ein DART-Paket, das vom Endgerät übernommen wurde und das Problem reproduzierte.

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

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

1. Navigieren Sie unter Windows Zu Start und beginnen Sie mit der Eingabe von DART. Klicken Sie dann mit der rechten Maustaste, und wählen Sie - Als Administrator ausführen aus.
   
   
2. Drücken Sie im ersten Bildschirm des Assistenten die Taste Weiter.
   
   
3. Drücken Sie im nächsten Assistenten-Bildschirm die Taste Alle Protokolle löschen.
   
   
   
   
4. Nachdem Sie das Problem DART von hier reproduziert haben, folgen Sie dem Assistenten, und drücken Sie Weiter.

DART-Paketanalyse

Nachdem das DART-Paket gesammelt wurde, müssen wir es aufheben und uns auf die Datei AnyConnect_ISEPosture.txt im Ordner Cisco AnyConnect ISE Posture Module konzentrieren. Diese Datei enthält alle Discovery-bezogenen Ereignisse.

1. Starten Sie die Fehlerbehebung, indem Sie alle Momente des Erkennungsneustarts identifizieren. Zu durchsuchende Schlüsselwörter sind Neustarten der Erkennung oder HTTP-Erkennung. Navigieren Sie hier zur Zeile mit Discovery Restart (Neustart der Erkennung), die im Problemfall aufgetreten ist:

2. Einige Zeilen nach dem Neustart der Erkennung sollten Sie eine Zeile sehen, die enthält - Probing no MNT Stage Targets. Dies ist ein Indikator für den Start der Erkennung in Phase 1:

Es wird empfohlen, alle umleitungsbasierten Tests mit derselben Farbe zu markieren, während zuvor verbundene PSNs aus ConnectionData.xml (Auth-Status-Ziele) in verschiedenen Farben hervorgehoben werden müssen, da die PSN-FQDNs normalerweise sehr ähnlich sind. Der Unterschied lässt sich nur schwer erkennen.

3.Folgen Sie den Protokolldateien, um ein Ergebnis für jede einzelne Abfrage zu sehen. Wie bereits erwähnt, müssen alle auf der Umleitung basierenden Tests fehlschlagen, wenn das Problem durch eine veraltete/Phantom-Sitzung verursacht wurde. Im Folgenden sehen Sie ein Beispiel für die fehlgeschlagene Überprüfung:

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

5. Einige Zeilen später sollte eine Zeile mit dem Schlüsselwort MSG_NS_SWISS_NEW_SESSION vorhanden sein. Diese Zeile enthält eine tatsächliche Session-ID, die von PSN als Ergebnis der Sitzungssuche ausgewählt wurde. Verwenden Sie diese Sitzungs-ID, um weitere Untersuchungen zur ISE durchzuführen, um herauszufinden, wie diese Sitzung veraltet/Phantom-groß wird:

Untersuchung auf ISE-Protokolle

 In der guest.log-Datei, in der die clientwebapp-Komponente in DEBUG aktiviert ist, ist das PSN zu sehen, das mit der Stale/Phantom-Sitzung antwortet.

PSN erhält eine Anfrage vom ISE-Status-Agenten. Sie können sehen, dass es sich um eine Anfrage von AnyConnect handelt, da der Benutzer-Agent-Wert folgende Werte aufweist:

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 mit IP-Adressen und MAC-Adressen. In diesem Beispiel enthält jedes Array nur einen Wert. Außerdem zeigt das Protokoll, dass die Sitzungs-ID aus der Anfrage NULL ist, was darauf hinweist, dass es sich um eine Anforderung der nicht umgeleiteten Anfrage handelt.

Später sehen Sie, wie Werte aus Arrays zum Suchen einer Sitzungs-ID verwendet werden:

cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being 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 Schlüsselwörtern Gesendete HTTP-Antwort können Sie Inhalte aus der tatsächlichen 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 von ISE-Berichten

Nachdem Sie die ID der veralteten/Phantom-Sitzung kennen, können Sie den Radius-Accounting-Bericht untersuchen, um sich ein besseres Verständnis darüber zu verschaffen, was dazu geführt hat, dass diese Sitzung veraltet/phantom wurde:

• Navigieren Sie zu Operations > Reports > Endpoints and Users > Radius Accounting Report, und führen Sie diesen Bericht 7 Tage lang aus. Benutzer und Endpunkt-ID als Filterschlüssel.

Beispiel für einen Bericht, der zeigt, wie veraltete Sitzungen auf ciscolive-ise2 zurückbleiben:

1. Der Beginn der Schulung erfolgte im PSN ciscolive-ise2.
2. Die vorläufige Aktualisierung für die Sitzung wurde auf demselben PSN verarbeitet.
3. Die Nachricht zur Unterbrechung der Rechnungslegung für eine problematische Sitzung wurde an ein anderes PSN gesendet (ciscolive-ise1).

Eine schnelle Methode, um festzustellen, wann das Problem durch das Nichtvorhandensein von Discovery Restart verursacht wurde.

Hier gilt die gleiche Logik wie bei der vorherigen Ausgabe. Der einzige Unterschied besteht darin, dass Sie sich auf die neueste Scan-Startzeit konzentrieren müssen. Bei dieser Art von Problem befindet sich der Zeitstempel der letzten Prüfung an einer Stelle in der Vergangenheit.

Wenn der Endbenutzer ein Problem feststellt, wird normalerweise eine Prüfung durchgeführt, die vor einiger Zeit stattfand. In den ISE Radius Live-Protokollen werden die letzten Authentifizierungsversuche des problematischen Endpunkts angezeigt.

Die nachfolgende Demo zeigt die Aufzeichnung der zur Problemermittlung erforderlichen Schritte:

Erweiterte Fehlerbehebung fehlender Neustart der Erkennung

Der Ansatz ist hier sehr ähnlich dem Abschnitt "Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen". Das Hauptelement zur Fehlerbehebung ist die Untersuchung des DART-Pakets. Innerhalb des DART-Pakets können Sie nach Erkennungsneustarts suchen, wie sie für das vorherige Problem gezeigt wurden, und bestätigen, dass zum Zeitpunkt der Problemmeldung kein Neustart der Erkennung aufgetreten ist.

Auf der ISE-Seite sollten Sie sich auf RADIUS Live Logs/Radius-Authentifizierungsberichte konzentrieren, um zu überprüfen, ob ein Failover zwischen PSNs vorliegt oder ob die neue Session-ID von NAD generiert wurde.

Lösung

Klassischer Ansatz - Vermeidung von Problemen

Bisher gab es keine Funktion für die ISE, die die in diesem Dokument beschriebenen Probleme lösen konnte. Daher war die einzige Möglichkeit, sich auf die Best Practices zu verlassen, die im Netzwerk und auf der ISE-Seite implementiert wurden, um Risiken zu minimieren.

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

Implementieren Sie immer, wenn möglich, einen umleitungsbasierten Status.

Ein häufiges Gegenargument für diese Empfehlung ist eine schlechte Benutzererfahrung, da Benutzer im Betriebssystem oder in Browsern Popups sehen, die auf Umleitung hinweisen, während das AnyConnect ISE-Statusmodul im Hintergrund einen Bewertungsprozess durchführt.

Um dies zu erreichen, ist es möglich, NUR ISE-Statusmodul-Erkennungssonden umzuleiten und gleichzeitig den gesamten anderen Datenverkehr selektiv zuzulassen.

Beispiel: Umleitung der ACL, die entwickelt wurde, um nur HTTP-Anfragen an Discovery Host (in diesem Beispiel 1.1.1) umzuleiten, und enroll.cisco.com (72.163.1.80):

ip access-list extended REDIRECT-DH-ENROLL

 permit tcp any host 1.1.1.1 eq www

 permit tcp any host 72.163.1.80

 deny   ip any any

Um ein akzeptables Sicherheitsniveau zu gewährleisten, kann diese Umleitungs-ACL mit der von der ISE zugewiesenen DACL kombiniert werden.

Der ausstehende Status gestattet nur Verbindungen mit PSN, bei denen der Endpunkt authentifiziert wurde.

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

Als Lösung müssen Sie mehrere StatusPending-Autorisierungsrichtlinien implementieren (eine pro PSN). Jede Richtlinie muss als eine der Bedingungen den Namen des PSN enthalten, bei dem die Authentifizierung stattfand. Im Autorisierungsprofil, das jeder Richtlinie zugewiesen wurde, sollte der Zugriff auf alle PSNs blockiert werden, mit Ausnahme des Knotens, in dem die Authentifizierung erfolgt ist.

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

1. Status Ausstehende Richtlinie für PSN1.

2. In der Richtlinie verwendeter PSN1-Name.

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

4. Status Ausstehende Richtlinie für PSN2.

5. Als Bedingung in der Richtlinie verwendeter PSN2-Name.

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

7. Autorisierungsrichtlinie für "Compliance"

Die Abbildung zeigt die Funktionsweise dieses Ansatzes:

1. Die Authentifizierung trifft PSN1.

2. Aufgrund konfigurierter Autorisierungsrichtlinien weist PSN1 Autorisierungsprofile zu, die den Zugriff auf alle anderen Knoten außer PSN1 blockieren.

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

4. Anfrage an PSN2, blockiert durch die NAD, wie durch eine zuvor zugewiesene ACL.

5. Anfrage an PSN1 erlaubt durch die auf NAD zugewiesene ACL.

Best Practices für Load Balancer

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

Status gegenüber VPN-Anwendungsfall 

• Stellt sicher, dass das Aktualisierungsintervall für die Zwischenabrechnung größer oder gleich dem Timeout für die VPN-Sitzung ist. Dadurch wird vermieden, dass bei langlebigen VPN-Sitzungen zwischen den PSNs Flapping-Vorgänge durchgeführt werden. 

Das nachfolgende Beispiel zeigt das für 20 Stunden konfigurierte Intervall für Zwischenabrechnungen. Dies verhindert jedoch nicht das erste Zwischenupdate, das die dem Endpunkt zugewiesene IP-Adresse enthält.

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 zu minimieren, die sich aus dem fehlenden Neustart der ISE-Statusmodul-Erkennung ergeben.

Status-Leasing aktivieren 

Diese Funktion auf der ISE markiert den Endpunkt für einen bestimmten Zeitraum (1-365 Tage) als konform. Der Status-Lease-Wert ist ein Endgeräteattribut, das bedeutet, dass er von der ISE DB gespeichert wird. Alle Endgeräteattribute, einschließlich Statusleasing, werden über alle Knoten in der ISE-Bereitstellung repliziert.

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

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

• Die Anzahl der Tage, die in den ISE-Einstellungen für das Statusleasing definiert werden, indem Sie zu Administration > System > Posture > General Settings (Verwaltung > System > Status > Allgemeine Einstellungen) navigieren:

• Value of PostureExpiry-Attribut: Dies ist ein tatsächliches Endpunktattribut mit einem Epoch-Timestamp. Der StatusExpiry-Wert wird anfänglich nach dem ersten erfolgreichen Statusversuch für Endpunkte eingefügt, nachdem der ISE-Administrator den Status geleast hat. Dieser Wert wird später beim nächsten erfolgreichen Statusversuch aktualisiert, der nach Ablauf des Leasingvertrags erfolgt.

            Sie können ein PostureExpiry-Fenster unter Context Visibility > Endpoints sehen, während Sie einen der aufgeführten Endpunkte öffnen:

           Dieser Wert kann beispielsweise hier in einen für Benutzer lesbaren Zeitstempel umgewandelt werden - https://www.epochconverter.com/

• PSN-Systemzeit zum Zeitpunkt der neuen Authentifizierung

Wenn die Authentifizierung für einen Endpunkt mit Statusüberprüfung auf PSN trifft, verwendet sie PostureExpiry und das Systemdatum, um eine Reihe von Tagen ab der letzten erfolgreichen Statusüberprüfung zu erhalten. Wenn sich der resultierende Wert in einem in den Einstellungen definierten Statusleaseintervall befindet, erhält die Sitzung einen Compliance-Status. Wenn der resultierende Wert den Leasingwert übersteigt, erhält die Sitzung den Status Unbekannt. Dadurch wird der Status erneut ausgeführt, und der neue PostureExpiry-Wert kann gespeichert werden.

In der Abbildung wird der Failover-Vorgang erläutert:

1. Die anfängliche Authentifizierung erfolgt mit PSN1.

2. Im Sitzungscache erstellte Sitzung-ABC.

3. Statusüberprüfung erfolgt.

4. Sitzungsstatus ändert sich in Konformität

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

6. PostureExpiry-Wert wurde im Endpunkt gespeichert.

7. Endpunktdaten werden in der gesamten Bereitstellung repliziert.

8. Die nächste Authentifizierung trifft PSN2.

9. PSN2 überprüft, ob sich der Endpunkt in einem gültigen Statusleasing befindet.

11. Sitzung, die dem Sitzungscache als konform hinzugefügt wurde.

12. Aufgrund des gültigen Leasingvertrags wurde die Sitzung mit dem Status Compliance erstellt.

Implementierung der erneuten Authentifizierung

Push-Re-Authentication-Timer immer von der ISE, wobei RADIUS-Request in Maintain Connectivity during Reauthentication ausgewählt wurde. Mit dieser Einstellung wird sichergestellt, dass die NAD bei der erneuten Authentifizierung dieselbe Sitzungs-ID behält.

.

Umgebungen mit Load Balancern

Es können die gleichen Best Practices implementiert werden, die im Abschnitt zu veralteten/Phantom-Sitzungen erläutert wurden.

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

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

Statusüberprüfung wird im gleichen Intervall wie ein Timer für die erneute Authentifizierung verwendet.

Statusüberprüfung kann aktiviert werden, wobei das Intervall dem Wiederholungs-Timer entspricht. Wenn in einem solchen Fall das ursprüngliche PSN nicht verfügbar ist, startet der PRA-Fehler den Erkennungsvorgang neu.

Moderner Ansatz - Statusfreigabe

Im Rahmen der Implementierung einer Erweiterung wurde im CSCvi35647Patch 6 für ISE 2.6 beschrieben und eine neue Funktion implementiert, die die Freigabe des Sitzungsstatusstatus für alle Knoten in der ISE-Bereitstellung implementiert. Diese Erweiterung wird auch in zukünftige Versionen integriert: 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 neueren Versionen wurde diese Funktion in Light Data Distribution (LDD) Radius Session Directory umbenannt.  Light Data Distribution (Light-Datenverteilung) ist standardmäßig aktiviert und ermöglicht die Freigabe eines eingeschränkten Sitzungskontexts zwischen ISE-Knoten. Es gibt keine Funktionen wie die vollständige Sitzungskontextreplikation zwischen PSNs, sondern nur eine begrenzte Anzahl von Attributen, die für jede Sitzung gemeinsam genutzt werden.

Die Hauptidee hinter dem Light Session Directory besteht darin, die Notwendigkeit der Ausführung ressourcenintensiver API-Aufrufe an MNT zu entfernen, wenn einer der Knoten in der Bereitstellung herausfinden muss, wer der aktuelle Sitzungseigentümer ist. Beim Start des COA-Flusses ist meist eine Suche nach dem Besitzer erforderlich. Mit LDD kann jedes PSN vom lokalen RADIUS Session Directory-Cache einen tatsächlichen Besitzer der Sitzung finden. 

Architektur für die Datenverteilung bei Licht

Diese Funktion enthält die folgenden Elemente:

• Radius Session Directory (RSD)-Cache: Dieser Cache ist auf jedem ISE-Knoten vorhanden und speichert alle aktiven Sitzungen in der ISE-Bereitstellung. Jede Sitzung verfügt über eine begrenzte Anzahl von Attributen im Cache. Beispiele für die Attribute, die für jede Sitzung im Radius-Sitzungsverzeichnis gespeichert sind:
  
  
  • Sitzungs-ID.
  • Endpunkt-MAC.
  • CallingStationID.
  • Endpunkt-IP
  • PSN IP - PSN, bei dem die Authentifizierung erfolgt ist.
  • PSN FQDN - identisch mit oben.
  • NAS-IP-Adresse
  • NAS-IPv6-Adresse.
  • Status - Authentifizierung, Gestartet, Beendet.

• RabbitMQ-Austausch - Es entsteht ein Austausch, in dem Publisher, die entsprechende Warteschlange und der Consumer auf jedem Knoten in der ISE-Bereitstellung angezeigt werden. Dadurch wird sichergestellt, dass die vollständig vermaschte Topologie zwischen allen ISE-Knoten gebildet wird.

• Publisher - Das Radius Session Directory stellt hier einen Publisher dar. Wenn eine neue erfolgreiche Authentifizierung, die von PSN verarbeitet wird, im PSN-Sitzungscache erstellt wird. Für diese Sitzung wird eine begrenzte Anzahl von Attributen im Radius-Sitzungsverzeichnis platziert.

• Consumer - Auf allen anderen Knoten stellt Radius Session Directory einen Consumer dar.

Hinweis: Allgemeine RabbitMQ-Terminologie und -Architektur sind nicht Bestandteil dieses Dokuments. 

In der Abbildung wird erklärt, wie COA-Fluss mit RSD-Cache funktioniert:

1. Die anfängliche Authentifizierung erfolgt mit PSN1.

2. Im Sitzungscache erstellte Sitzung-ABC.

3. Erforderliche Attribute werden im RSD gespeichert.

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

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

6. Auf PSN2 werden neue Profilerstellungsdaten eingegeben.

7. Endpunkt wird neu profitiert, und im Falle einer Änderung, die die COA-Ausführung erfordert, geht PSN2 mit dem nächsten Schritt weiter.

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

9. Daten aus dem RSD-Cache, die zur Vorbereitung einer Proxy-COA-Nachricht verwendet werden (ein COA, der von einem ISE-Knoten zu einem anderen wechselt, enthält alle Details, mit denen der Zielknoten eine CAO-Anforderung an NAD zurücksenden kann). Die COA-Nachricht wurde zuerst intern an die PRRT Runtime übertragen (tatsächlicher AAA-Server innerhalb der ISE).

10. PSN2 sendet eine COA-Nachricht an PSN1.

11. PSN1 sendet eine COA-Nachricht an NAD.

Zur Fehlerbehebung bei der Kommunikation über LDD auf der ISE können Sie die Light Session Director-Komponente in DEBUG aktivieren:

 Beispiel einer Debugmeldung aus der Datei lsd.log zur Erstellung und Veröffentlichung von Sitzungen 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 sollten Sie sehen, 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 zwischen den Knoten löst das Problem mit dem Symptom "AnyConnect ISE-Statusmodul zeigt Konformität, während der Sitzungsstatus auf ISE aussteht", wenn die zugrunde liegende Ursache entweder eine Stale/Phantom-Sitzung oder eine Re-Authentifizierung auf verschiedenen PSN ist, wobei die ursprüngliche Sitzungs-ID keinen Neustart der Erkennung auslöste. Sobald die Sitzung konform wird, werden diese Informationen in den RSD der Sitzung aufgenommen und können später von jedem PSN in der Bereitstellung verwendet werden.

Es gibt noch einige andere Fälle, die mit der beschriebenen Funktion nicht gelöst werden können. Beispiel: Ein Szenario, in dem NAD eine erneute Authentifizierung auf demselben PSN, jedoch mit einer anderen Session-ID ausführt. Solche Szenarien können durch die Implementierung der in diesem Dokument beschriebenen Best Practices bewältigt werden.

Die Abbildung zeigt die Topologie für das Testen der Statusfreigabe:

Statusfreigabe über RSD - Stable/Phantom-Sitzung

Um eine veraltete Sitzung zu erstellen, wurde zunächst die Authentifizierung auf der skuchere-ise26-1 und höher durchgeführt. NAD wurde so umkonfiguriert, dass sie Accounting an skuchere-ise26-3 sendet. Nachdem eine Buchhaltungsmeldung an das falsche PSN weitergeleitet wurde, wurde die NAD erneut so konfiguriert, dass sie die Rechnungslegung an skuchere-ise26-1 zurücksendet.

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

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

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

3. Die Sitzung wird zu einem späteren Zeitpunkt auf skuchere-ise26-1 abgeschlossen.

Nach einiger Zeit stellt das Endgerät wieder eine Verbindung zum Netzwerk her, aber die Umleitung funktioniert nicht mehr. Im guest.log von PSN - skuchere-ise26-3 werden folgende Protokollmeldungen angezeigt, 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 das PSN erkennt, dass es eine veraltete/Phantom-Sitzung für den Endpunkt abhält, antwortet es nicht auf das ISE-Statusmodul. Dies ermöglicht es uns, die richtige Antwort vom PSN zu erhalten, wo die neueste Authentifizierung erfolgt ist.

Als Lösung für das Problem einer veralteten/Phantom-Sitzung prüft PSN jetzt zum Zeitpunkt der Sitzungssuche das Vorhandensein einer neuen Sitzung für den Endpunkt im RSD. Wenn der RSD eine Session-ID enthält, die sich von der im lokalen Sitzungscache vorhandenen Session-ID unterscheidet, wird davon ausgegangen, dass die im Sitzungscache vorgestellte Sitzung veraltet ist.

Statusfreigabe über RSD - Failover zwischen PSNs

Um dieses Szenario zu reproduzieren, wurde ein kurzer Wiederauthentifizierungs-Timer im Autorisierungsprofil aktiviert, das dem Endpunkt im konformen Zustand zugewiesen wurde. Später wurde NAD so umkonfiguriert, dass Authentifizierung und Abrechnung an ein anderes PSN gesendet werden (skuchere-ise26-3). Nach Ablauf des Timers für die erneute Authentifizierung wurde dieselbe Sitzung auf den verschiedenen PSN nicht authentifiziert.

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

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

2. COA nach erfolgreicher Statusüberprüfung.

3. Nächste Authentifizierung, wenn das Autorisierungsprofil für den konformen Zustand zugewiesen wird.

4. Die Authentifizierung trifft auf verschiedene PSNs, aber sie erhält immer noch ein Autorisierungsprofil für den konformen Status.

Die Sitzung erhält nach dem Failover in ise-psc.log mit epm-pip- und nsf-session-Komponenten, die in DEBUG aktiviert sind, den Status des neuen PSN:

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 wurde gelöst, indem dem Status-Auswahlprozess zusätzliche Logik hinzugefügt wurde. Die Abbildung zeigt, was geändert wurde (Änderungen sind rot markiert):