Fehlerbehebung bei ISE-Sitzungsmanagement und Status

Download-Optionen

  • PDF     (2.1 MB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
Aktualisiert:25. August 2026
Dokument-ID:215419

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Vorschau
Einleitung
Hintergrundinformationen
Problem
Anwendererlebnis
ISE-Administrationserfahrung
Häufige Problemszenarien
Veraltete/Phantom-Sitzung
ISE-Sitzungsmanagement-Logik
MNT- und Sitzungsmanagement
PSN- und Sitzungsmanagement
Veraltete Sitzung auf PSN
Phantom-Sitzung auf dem PSN
Wie veraltete Sitzungen und Phantom-Sitzungen den Statusprozess durchbrechen
Der Erkennungsprozess wird bei einem neuen Authentifizierungsversuch nicht gestartet.
Neuauthentifizierung auf anderem PSN
NAD generiert neue Sitzungs-ID bei der Neuauthentifizierung
Schnelle Identifizierung der Ursache eines Problems durch eine veraltete/Phantom-Sitzung
Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen
DART-Paketerfassung
DART-Paketanalyse
Untersuchung zu ISE-Protokollen
Untersuchung zu ISE-Berichten
Ermitteln, wann ein Problem durch das Fehlen eines Discovery-Neustarts verursacht wurde
Erweiterte Fehlerbehebung Fehlende Erkennung Neustart
Lösung
Klassischer Ansatz - Vermeidung von Problemen
Best Practices zur Minimierung veralteter oder Phantom-Sitzungen bei der ISE-Bereitstellung
Statusüberprüfung beim VPN-Anwendungsfall
Best Practices können implementiert werden, um die Auswirkungen eines fehlenden ISE-Statusmodul-Erkennungsneustarts zu minimieren
Reauthentifizierungs-Implementierung
Umgebungen mit Load Balancern
Moderner Ansatz - Statusfreigabe
Architektur für die leichte Datenverteilung
Statusfreigabe über RSD
Statusfreigabe über RSD - veraltete/Phantom-Sitzung
Statusfreigabe über RSD - Failover zwischen PSNs

Einleitung

In diesem Dokument wird das häufige Problem mit Identity Service Engine (ISE)-Statusservices beschrieben, z. B. "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 konform, während der Sitzungsstatus auf der ISE aussteht."

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:

  • Häufige problematische Szenarien.
  • Algorithmen zur schnellen Problemerkennung.
  • Klassische Lösungen für gängige Problemszenarien.
  • Statusfreigabe über das Radius-Sitzungsverzeichnis.
  • Problempunkt aus Sicht des Endbenutzers und ISE-Administrators.
  • Die Theorie hinter ISE, AnyConnect und dem Netzwerkbetrieb, die das Problem auslöst.

Eine genauere Erläuterung der später beschriebenen Konzepte finden Sie unter ISE Posture Style Comparison for Pre and Post 2.2.

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 den Status als konform anzeigt.

Typische Endbenutzererfahrung:

Client Provisioning Portal

ISE-Administrationserfahrung

Beim erstmaligen Auslösen dieses Problems beginnt ein ISE-Administrator mit einer Untersuchung der Radius Live-Protokolle, um sicherzustellen, dass eine Authentifizierung die ISE erreicht. Das erste in diesem Stadium entdeckte Symptom weist auf eine Diskrepanz in einem Statusstatus zwischen dem Endpunkt und der ISE in den Live-Protokollen hin. Alternativ zeigt die Radius-Authentifizierung, die die letzte erfolgreiche Authentifizierung für den Endpunkt meldet, den Status Ausstehender Status an.

Typische ISE-Administratorerfahrung:

Client Provisioning Portal 2

  • Letzte erfolgreiche Authentifizierung für Identität: Alice.
  • Der Status der Sitzung lautet "Ausstehend".
  • Letztes Sitzungsereignis für Identität: Alice.
  • Das Sitzungsereignis zeigt den Status als konform an.

Anmerkung: Im Beispiel werden C und D nicht immer in den Live-Protokollen angezeigt, wenn das beschriebene Problem auftritt. Ein Sitzungsereignis mit dem Status "Compliant" tritt häufiger in Szenarien auf, die durch veraltete oder Phantom-Sitzungen verursacht werden (siehe Beschreibung 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 arbeitet das TAC normalerweise mit einer veralteten 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

In der ISE-Bereitstellung sind zwei Personen für den Sitzungsmanagementprozess verantwortlich: PSN und Monitoring Node (MNT). Um das Problem richtig zu beheben und zu identifizieren, ist es wichtig, die Theorie des Sitzungsmanagements für beide Personen zu verstehen.

MNT- und Sitzungsmanagement

Client Provisioning Portal 3

Wie in dieser Abbildung 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 säubern.

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 Sitzungen mit dem Status "Gestartet" für mehr als 5 Tage (120 Stunden). Ein Start-Status bedeutet, dass der MNT-Knoten sowohl die Authentifizierung als auch die Abrechnung verarbeitet hat, um die Syslog-Sitzung zu starten.

note-icon

Anmerkung: Hierbei handelt es sich um die normalen MnT-Cleanup-Timer, bei denen die Löschzeit der Wanduhr nicht garantiert ist. Die Entfernung kann sich verzögern, wenn:

  • SessionPurgeJob wird nicht erfolgreich ausgeführt.
  • MnT steht unter Ressourcen- oder Datenbankdruck.
  • Der Accounting-Stopp kann nicht mit der bestehenden Session korreliert werden.

Beispiele für Syslog-Meldungen von PSN:

Meldungen werden in der Komponente prrt-server.log protokolliert, wenn die Komponente runtime-aaa in DEBUG aktiviert ist. Fett formatierte Teile können verwendet werden, um reguläre Suchausdrücke zu erstellen.

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

Buchhaltungsanfang:

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

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

Buchhaltungsanschlag:

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 die Replikation von VOLLSTÄNDIGEN Sitzungszuständen 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.

Client Provisioning Portal 4

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

  • Die Sitzung wurde auf dem PSN erfolgreich authentifiziert.
  • PSN verfügt über ein Accounting-Interim-Update für die Sitzung, das nicht im Sitzungscache vorhanden ist. Beim Entfernen von Sitzungen 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:

Client Provisioning Portal 5

  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. Die Sitzung ist als konform markiert.
  5. Die Autorisierungsänderung (COA, Change of Authorization) wird durch die Statusänderung ausgelöst, die zur erneuten Authentifizierung des Endpunkts für die Anwendung der nächsten Zugriffsebene führt.
  6. Die Abrechnung für die Sitzung ABC-PSN2 wird beendet.

Danach bleibt ABC auf PSN1 in einem veralteten Zustand, da auf diesem PSN keine Abrechnungs-Stopp-Nachricht verarbeitet wird, um es zu entfernen. Die Sitzung wird entfernt, wenn bei der Bereitstellung nicht viele Authentifizierungsversuche auftreten.

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

  • Der Accounting-Stopp wurde aufgrund des Ablaufs des Stickiness-Timers auf dem Load Balancer an die falsche PSN gesendet.
  • Die falsche Konfiguration auf dem NAD ist nicht dieselbe PSN, die für Authentifizierung und Abrechnung konfiguriert wurde.
  • Temporäre Verbindungsprobleme im Netzwerkpfad führten zu einem NAD-Failover auf das nächste PSN.

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

Client Provisioning Portal 6

  1. Die anfängliche Authentifizierung für die Sitzung ABC wird von PSN1 durchgeführt. Diese Authentifizierung initiiert einen Stickiness-Timer auf dem Load Balancer.
  2. PSN1 erstellt einen Eintrag für Session ABC im lokalen Cache.
  3. Die Syslog-Meldung für die übergebene Authentifizierung wird an den MNT-Knoten übertragen.
  4. Der Eintrag für Session ABC wird im Sitzungsverzeichnis MNT mit dem Status Authenticated erstellt.
  5. Die Accounting-Startmeldung für Session ABC landet auf PSN1.
  6. Der Session-Cache-Eintrag für Session ABC wird mit Informationen aus 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. Der Stickiness-Timer läuft auf dem Load Balancer ab.
  10. Accounting-Stopp für Session ABC wird vom Load Balancer an PSN2 weitergeleitet.
  11. Die Syslog-Meldung für Accounting-Stopp wird von PSN2 an MNT weitergeleitet.
  12. Sitzung ABC ist als beendet auf MNT markiert.

Phantom-Sitzung auf dem PSN

Bei der Phantom-Sitzung handelt es sich um ein Szenario, in dem das Accounting-Interim-Update auf das PSN angewendet wird und keine Authentifizierung für diese Sitzung durchgeführt wurde. 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:

Client Provisioning Portal 7

  1. Die gleichen Schritte, die im Beispiel für eine veraltete Sitzung beschrieben werden, werden auf PSN1 für die ABC-Sitzung ausgeführt.
  2. Sitzung ABC hat den Status Konformität im PSN1-Sitzungscache.
  3. Ein Accounting-Zwischenupdate für Session ABC trifft auf PSN2.
  4. Ein Sitzungseintrag für ABC wird auf PSN2 erstellt. Da der Sitzungseintrag aus der Abrechnungsmeldung erstellt wird, weist er eine begrenzte Anzahl von Attributen auf. Der Status ist beispielsweise für die Sitzung ABC nicht verfügbar, und es fehlen auch Benutzergruppen oder andere autorisierungsspezifische Attribute.

Die Phantom-Sitzung wird in den 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.

Der nächste Screenshot zeigt ein Beispiel für eine Phantom-Sitzung, bei der temporäre Probleme mit dem Netzwerkpfad zu PSN1 auftreten:

Client Provisioning Portal 8

  1. Die Erstauthentifizierung für die Sitzung ABC wird von PSN durchgeführt.
  2. PSN1 erstellt einen Eintrag für 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 "Started" 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 PSN1 an MNT weitergeleitet.
  14. 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:

Client Provisioning Portal 9

  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 den IP-Adressinformationen landet auf dem PSN.
  6. Die IP-Adressinformationen werden dem Sitzungscache hinzugefügt.
  7. Die 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 neue Zugriffsebene aus, die zugewiesen wird.
  10. Bei einem Ausfall auf dem Netzwerkpfad ist der Zugriff auf PSN1 nicht möglich.
  11. Nach Ablauf des Intervalls für die Zwischenaktualisierung erkennt ASA/FTD, dass auf PSN1 nicht zugegriffen werden kann.
  12. Die Zwischenbuchung wird auf PSN2 aktualisiert.
  13. Die Phantom-Sitzung wird im PSN2-Sitzungscache erstellt.

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

Wie veraltete Sitzungen und Phantom-Sitzungen den Statusprozess durchbrechen

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

Client Provisioning Portal 10

Erkennung in Phase 1:

Während dieser Phase führt das ISE-Statusmodul vier gleichzeitige Tests durch, um das PSN zu finden, das den Endpunkt authentifiziert.

Erstens sind drei Tests auf der Abbildung umleitungsbasiert (Standard-GW-IP, Discovery-Host-IP (falls 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.

Prüfpunkt 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 später aktualisiert werden, wenn 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, werden die Ergebnisse von Prüfpunkt 4 nur verwendet, wenn alle anderen drei Prüfpunkte fehlschlagen oder wenn das ISE-Statusmodul nicht innerhalb von 5 Sekunden eine ordnungsgemäße Kommunikation mit dem in der Umleitungs-URL zurückgegebenen PSN herstellen kann.

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 Prüfpunkt vier 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 erheblich beeinträchtigt werden.

Wenn PSN zu Phase 2 verschoben wird, erstellt der im Sitzungscache befindliche Erkennungstest einen veralteten oder Phantom-Eintrag für denselben Endpunkt. Dies führt dazu, dass der Endbenutzer den falschen Status erhält.

Dieses Beispiel zeigt, wie ein Status angezeigt wird, wenn PSN eine veraltete Sitzung oder eine Phantom-Sitzung hält:

Client Provisioning Portal 11

Anmerkung: Dieses Problem kann sich nur manifestieren, wenn alle umleitungsbasierten Erkennungstests 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. Wenn eine Phantom-Sitzung keine Authentifizierungs-/Autorisierungsattribute aufweist und alle von Ihnen konfigurierten Richtlinien spezifisch sind (z. B. werden Richtlinien für bestimmte Active Directory-Gruppen erstellt), kann PSN keine richtige Richtlinie für die Client-Bereitstellung zuweisen. Dies kann sich in der folgenden Fehlermeldung manifestieren: "AnyConnect umgehen Scannen Sie Ihr Netzwerk ist nicht für die Verwendung von Cisco NAC Agent konfiguriert".
    • 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 einer AnyConnect-Konfiguration abzugleichen), antwortet PSN mit den für die Fortsetzung des Bewertungsprozesses erforderlichen Details.
    • In diesem Schritt antwortet PSN beim Arbeiten mit veralteten Sitzungen sofort mit dem Status "Konformität" und alle nächsten Schritte sind nicht abgeschlossen. PSN sendet kein COA, da die Sitzung nach seiner Ansicht 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 Endgerät erkannt wurden.

5. PSN verwendet Informationen aus den Anforderungs- und Sitzungsattributen, um die richtige Statusrichtlinie abzugleichen. Der Phantom-Sitzung fehlen derzeit Attribute, und es gibt keine Richtlinie, die übereinstimmen muss. In diesem Fall antwortet PSN dem Endpunkt, dass er die Vorgaben erfüllt. Dies ist das Standard-ISE-Verhalten, wenn die Statusrichtlinie nicht übereinstimmt. 

Anmerkung: Wenn es eine allgemeine Richtlinie gibt, die aus den Attributen der Phantom-Sitzung ausgewählt werden kann, können Sie mit Schritt 6 fortfahren.

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

Anmerkung: Wenn keine Richtlinie ausgewählt werden kann, kehrt PSN mit dem Status Compliant zurück.

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

8. Die Berichtsauswertung erfolgt für die ISE, und der Sitzungsstatus ändert sich in "Konformität".

Anmerkung: Wenn Statusprobleme durch die Phantom-Sitzung verursacht werden, kann der ISE-Administrator einige fehlgeschlagene Status-COAs feststellen. In diesem Fall werden die COA-Anforderungen von den falschen PSNs und für die falschen 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 CSCvo6957. Neue 802.1x-Authentifizierung, PC-Entsperrung und IP-Adressänderung werden vom ISE-Statusmodul nicht erkannt.

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

  • Die erneute Authentifizierung trifft auf ein anderes PSN zu (entweder aufgrund von LB-Entscheidungen oder aufgrund von 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 Neuauthentifizierung auf einem anderen PSN, die durch den Ausfall des ursprünglichen PSN verursacht wurde. Ein Szenario mit einem Load Balancer sieht ähnlich aus. Im Fall eines Load Balancers wird die Neuauthentifizierung an die verschiedenen PSN weitergeleitet, nachdem ein Stickiness-Timer abgelaufen ist.

Client Provisioning Portal 11

  1. Anfängliche Authentifizierung auf PSN1.
  2. Session-ABC wird im PSN1-Session-Cache erstellt.
  3. Die Statusüberprüfung wird mit PSN1 durchgeführt.
  4. Der Status des ABC-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, sodass die nächste Zugriffsebene übernommen wird.
  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, ändert sich der Status der Sitzung in Ausstehend.

Der ursprüngliche Status wird der Sitzung von PSN zugewiesen:

Client Provisioning Portal 12

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

NAD generiert neue Sitzungs-ID bei der Neuauthentifizierung

Dies kann in den beiden gängigsten Szenarien geschehen:

  • Die Neuauthentifizierung ist auf ISE-Seite falsch konfiguriert (die Lösung dieses Problems wird später in diesem Dokument behandelt).
  • Fehlverhalten von NAD-Seite; Normalerweise behält NAD während des erneuten Authentifizierungsversuchs dieselbe Sitzungs-ID bei. Dies ist ein potenziell fehlerhaftes Verhalten, das auf NAD untersucht werden muss.
    • Die neue Sitzungs-ID kann in einigen anderen Szenarien generiert werden. In einigen Fällen kann beispielsweise Wireless-Roaming eine Ursache sein.
    • ISE PSN setzt eine neue Sitzung immer in den Status Ausstehend, sofern der Status-Lease nicht konfiguriert ist. Der Leasingvertrag für Status wird weiter unten in diesem Dokument erläutert.

Schnelle Identifizierung der Ursache eines Problems durch eine veraltete/Phantom-Sitzung

Identifiziert, ob AnyConnect Compliance zeigt, während der Umleitungsstatus durch die veraltete/Phantom-Sitzung verursacht wird. Sie müssen Zugriff auf den Endpunkt erhalten, während dieser sich im problematischen Zustand befindet.

Details der Systemsuche überprüfen

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

Client Provisioning Portal 13

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

Client Provisioning Portal 14

Beachten Sie im nächsten Schritt zwei wichtige Elemente:

  • Neueste Suchstartzeit: Der Zeitstempel muss zum Zeitpunkt der Problemerkennung geschlossen sein.
  • Policy Server: Dieses Feld gibt den Namen des Policy Servers an, der eine Statusüberprüfung für den Endpunkt durchführt. Der FQDN muss mit dem FQDN der Redirect-URL (für den Status "Redirect Base") oder mit dem PSN-Namen des letzten Authentifizierungsversuchs (für den Status "Redirect-less") verglichen werden.
  1. Vergleichen Sie den FQDN des Policy Servers aus der Systemscanstatistik mit dem Knotennamen, der die Authentifizierung für den Endpunkt durchgeführt hat:

Client Provisioning Portal 15

Die Demo zeigt die Aufzeichnung der Schritte, die zur 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, der nicht gestartet wurde. Gleichzeitig müssen Sie die eigentliche Sitzung identifizieren, die das Problem ausgelöst hat, um zu verstehen, 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 Sie sicherstellen, dass Best Practices implementiert werden, um zu verhindern, dass veraltete oder Phantom-Sitzungen in einer Umgebung erstellt werden.

DART-Paketerfassung

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

  1. Behalten Sie nur wichtige Protokolle in DART bei, und es wird empfohlen, Protokolle zu löschen, bevor das Problem reproduziert wird.
  2. Um dies zu erreichen, muss das DART-Paketdienstprogramm als Administrator starten und die Protokollbereinigung durchführen.
  3. Navigieren Sie unter Windows zu Start, geben Sie DART ein, klicken Sie mit der rechten Maustaste, und wählen Sie - Als Administrator ausführen.


Client Provisioning Portal 16

4. Klicken Sie im ersten Bildschirm des Assistenten auf Weiter.

Client Provisioning Portal 17

5. Klicken Sie im nächsten Assistenten auf Alle Protokolle löschen.

Client Provisioning Portal 18

6. Nachdem das Problem reproduziert wurde, kann DART von hier gesammelt 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.

Client Provisioning Portal 19

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 zu der Zeile mit dem Neustart der Erkennung, der im problematischen Moment stattgefunden hat:

CLI Output

2. Mehrere Zeilen nach dem Neustart der Erkennung gibt es eine Zeile, die Folgendes enthält: "Probing no MNT stage targets" (dies ist ein Indikator für den Erkennungsstart für Stufe 1):

CLI Output 2

3. 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 ähnlich und können den Unterschied schwer erkennen.

4. Lesen Sie die Protokolldateien, um die Ergebnisse der einzelnen Tests anzuzeigen (dies ist ein Beispiel dafür, wie ein fehlgeschlagener Test aussieht):

CLI Output 3

5. 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:

CLI Output 4

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 die Sitzung veraltet/Phantom wurde:

CLI Output 5

Untersuchung zu ISE-Protokollen

1. Im guest.log mit der in DEBUG aktivierten Komponente client-webapp antwortet der PSN mit der Stale/Phantom Session, die zu sehen ist.

2. PSN erhält eine Anforderung 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

3. Die Anforderung enthält Arrays von IP- und MAC-Adressen. In diesem Beispiel enthält jedes Array nur einen Wert. Das Protokoll zeigt an, dass die Sitzungs-ID aus der Anforderung NULL ist. Dies gibt an, dass es sich um eine Anforderung von der nicht umleitungsbasierten Überprüfung 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

4. Nach der Zeile mit den Schlüsselwörtern Gesendet http-Antwort, können Sie den Inhalt aus der Antwort:

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

Sobald die ID der veralteten/Phantom-Sitzung bekannt ist, können Sie den Radius-Accounting-Bericht untersuchen, um ein besseres Verständnis darüber zu erhalten, was die Veraltung der Sitzung verursacht hat:

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

2. Dies ist ein Beispiel für einen Bericht, der zeigt, wie die veraltete Sitzung auf ciscolive-ise2 überlassen wurde:

CLI Output 6

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

Identifizieren der Ursache eines Problems ohne Discovery-Neustart

Die gleiche Logik gilt für das vorherige Problem, der einzige Unterschied besteht jedoch darin, dass Sie sich auf die letzte Startzeit des Scans konzentrieren müssen. Bei dieser Art von Problem liegt der Zeitstempel der letzten Überprüfung in der Vergangenheit.

Wenn ein Endbenutzer ein Problem erkennt, ist normalerweise eine Suche durchgeführt worden. 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

Dieser Ansatz ähnelt dem Abschnitt "Erweiterte Fehlerbehebung bei veralteten/Phantom-Sitzungen". Das Hauptelement der Fehlerbehebung ist die DART-Bündeluntersuchung.

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 keine Neustarts der Erkennung stattgefunden haben.

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

Lösung

Klassischer Ansatz - Vermeidung von Problemen

Bisher gab es keine Funktionen auf der ISE, die die in diesem Dokument beschriebenen Probleme lösten. Die einzige Möglichkeit war daher, zur Minimierung der Risiken auf die Best Practices zu vertrauen, die auf Netzwerk- und ISE-Seite implementiert wurden.

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

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

Ein gängiges Gegenargument zu dieser Empfehlung ist, dass ein schlechtes Anwendererlebnis im Betriebssystem auftritt oder Browser angezeigt werden. 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 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 ist in Umgebungen nützlich, in denen die URL-Umleitung nicht unterstützt wird (Implementierungen mit NADs von Drittanbietern).

Implementieren Sie als Lösung mehrere Richtlinien zur Autorisierung für Status ausstehend (eine pro PSN). Jede Richtlinie muss als eine der Bedingungen den Namen des PSN enthalten, bei dem die Authentifizierung erfolgt ist. Im Autorisierungsprofil müssen alle PSNs blockiert werden, mit Ausnahme des Knotens, an dem die Authentifizierung erfolgt ist.

Erstellen von Autorisierungsrichtlinien für zwei Knoten:

Authz Policy

 

  1. Status Ausstehende Richtlinie für PSN1.
  2. Der Name PSN1 wird als Bedingung in der Richtlinie verwendet.
  3. Das Autorisierungsprofil mit ACL blockiert den Zugriff auf alle PSNs mit Ausnahme von PSN1.
  4. Die Richtlinie für den Status "Ausstehend" für PSN2.
  5. Der Name PSN2 wird als Bedingung in der Richtlinie verwendet.
  6. Das Autorisierungsprofil mit ACL blockiert den Zugriff auf alle PSNs mit Ausnahme von PSN2.
  7. Integritätsrichtlinie "Konforme" Autorisierung.

In der folgenden Abbildung wird die Funktionsweise des Ansatzes erläutert:

Client Provisioning Portal 20

  1. Die Authentifizierung trifft auf PSN1.
  2. Als Ergebnis der konfigurierten Autorisierungsrichtlinien weist PSN1 das Autorisierungsprofil zu, das den Zugriff auf alle anderen Knoten mit Ausnahme von PSN1 blockiert.
  3. Das AnyConnect ISE-Statusmodul startet den Erkennungsprozess neu.
  4. Der Prüfpunkt für PSN2 wird vom NAD blockiert, wie dies bei einer zuvor zugewiesenen ACL der Fall ist.
  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. Informationen zu Best Practices für die ISE finden Sie im Bereitstellungsleitfaden für Cisco und F5: ISE-Lastenausgleich mit BIG-IP.
  • Verwenden Sie einen Verklebungszeitgeber, der länger als ein durchschnittlicher Arbeitstag ist, um den Moment abzudecken, in dem der PC in den Ruhemodus wechselt (z. B. 10 statt 8 Stunden).
  • Wenn eine Neuauthentifizierung implementiert ist, verwenden Sie den Timer für die Neuauthentifizierung, der etwas niedriger ist als der Timer für die Stickiness-Authentifizierung (verwenden Sie 8 Stunden, wenn die Stickiness-Funktion 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 den Endpunkt für einen definierten Zeitraum (1-365 Tage) als konform markiert. Der Posture-Leasingwert ist ein Endgeräteattribut, d. h., er wird in der ISE-DB gespeichert. Alle Endgeräteattribute, die das Status-Lease beinhalten, werden über alle Knoten in der ISE-Bereitstellung repliziert.

Wenn PSN eine neue Sitzung für den Endpunkt erhält, kann der Status-Lease verwendet werden, um die Sitzung sofort als konform zu markieren. Für diese Entscheidung verwendet PSN drei Werte:

  1. Für Statusleasing in ISE-Einstellungen definierte Anzahl von Tagen: Navigieren Sie zu Administration > System > Posture > General Settings:

Client Provisioning Portal 21

2. Das Value of PostureExpiry-Attribut ist ein Endpunktattribut, das einen Epoch-Zeitstempel enthält. Der PostureExpiry-Wert wird beim ersten erfolgreichen Statusversuch für den Endpunkt zuerst aufgefüllt, nachdem der ISE-Administrator das Statusleasing aktiviert hat. Später wird 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:

Client Provisioning Portal 22

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

Client Provisioning Portal 23

3. Wenn die Authentifizierung für einen Endpunkt mit Posture Lease auf PSN trifft, wird mithilfe von PostureExpiry und Systemdatum die Anzahl der Tage abgerufen, die seit der letzten erfolgreichen Statusüberprüfung vergangen sind. Wenn der Ergebniswert innerhalb eines in den Einstellungen definierten Leaseintervalls liegt, erhält die Sitzung den Status Compliance. Ist der Ergebniswert höher als der Lease-Wert, 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:

Client Provisioning Portal 24

  1. Die Erstauthentifizierung erfolgt mit PSN1.
  2. Session-ABC wird im Session-Cache erstellt.
  3. Statusüberprüfung erfolgt.
  4. Der Sitzungsstatus ändert sich in Konformität.
  5. COA wird durch Statusänderungen ausgelöst und führt zur erneuten Authentifizierung des Endpunkts, sodass dieser auf die nächste Zugriffsebene angewendet wird.
  6. Der PostureExpiry-Wert wird im Endpunkt gespeichert.
  7. Endpunktdaten werden in der gesamten Bereitstellung repliziert.
  8. Nächste Authentifizierung trifft auf PSN2 zu.
  9. PSN2 überprüft, ob sich der Endpunkt innerhalb eines gültigen Leasing-Zeitraums befindet.
  10. Die Sitzung wird dem Sitzungscache als konform hinzugefügt.
  11. Aufgrund des gültigen Leasingvertrags wird die Sitzung mit dem Status "Konformität" erstellt.

Reauthentifizierungs-Implementierung 

Pushen Sie den Neuauthentifizierungs-Timer von der ISE immer mit der RADIUS-Anforderung, die unter Verbindung bei Neuauthentifizierung verwalten ausgewählt ist. Mit dieser Einstellung wird sichergestellt, dass NAD bei der Neuauthentifizierung dieselbe Sitzungs-ID beibehält.

Client Provisioning Portal 25

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 Netzwerkdesigns die Möglichkeit bieten, verschiedene Subnetze zu verwenden, z. B. den Status Ausstehend und Konformität, garantiert dieser Ansatz, dass jede Änderung des Statusstatus zur Ä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 verfügbar ist, startet der PRA-Fehler den Erkennungsprozess neu.

Moderner Ansatz - Statusfreigabe

Im Rahmen einer implementierten Erweiterung (in Cisco Bug-ID CSCvi35647) von Patch 6 für ISE 2.6 gibt es eine neue Funktion, die die Freigabe des Sitzungsstatus für alle Knoten in der ISE-Bereitstellung implementiert.

Diese Erweiterung ist Bestandteil zukünftiger Versionen für 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 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ändigen Sitzungskontext-Replikationen zwischen PSNs, sondern nur eine begrenzte Anzahl von Attributen, die für jede Sitzung gemeinsam genutzt werden.

Light Session Directory macht kostspielige API-Aufrufe an MNT überflüssig, wenn einer der Knoten in der Bereitstellung den aktuellen Sitzungseigentümer bestimmen muss. Die Owner-Suche ist erforderlich, wenn der COA-Fluss startet. Mit LDD kann jeder PSN einen Besitzer der Sitzung aus dem lokalen Radius-Sitzungsverzeichnis-Cache finden. 

Architektur für die leichte Datenverteilung

Diese Funktion umfasst folgende 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 hat eine begrenzte Anzahl von Attributen im Cache. Dies sind 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
    • PSN-FQDN 
    • NAS-IP-Adresse
    • NAS-IPv6-Adresse
    • Status - Authentifiziert, gestartet, gestoppt
  • RabbitMQ Exchange: Es wird eine Börse gebildet, in der der Publisher, die zugehörige Queue und der 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.
  • Publisher: Das Radius-Sitzungsverzeichnis stellt 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.
  • Verbraucher: Auf allen anderen Knoten stellt das Radius-Sitzungsverzeichnis einen Consumer dar.
note-icon

Anmerkung: Die allgemeine Terminologie und Architektur von RabbitMQ liegt außerhalb dieses Dokumentbereichs.

Im nächsten Beispiel wird die Funktionsweise des COA-Flusses mit dem RSD-Cache erläutert:

Client Provisioning Portal 26

  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 werden auf PSN2 empfangen.
  7. Endpunkt wird neu profiliert 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 zum Senden einer CAO-Anfrage an NAD verwenden kann. Die COA-Nachricht wird zunächst intern an PRRT Runtime (den eigentlichen 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-Directory-Komponente in DEBUG, um Probleme bei der Kommunikation über LDD auf der ISE zu beheben:

Client Provisioning Portal 27

Dies ist ein Beispiel für eine Debug-Meldung aus der Datei lsd.log für die Erstellung und Veröffentlichung einer Sitzung im 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 eine veraltete/Phantom-Sitzung oder eine Neuauthentifizierung auf einem anderen PSN ist, die den Erkennungsneustart nicht ausgelöst hat. Sobald die Sitzung "Compliant" wird, werden diese Informationen in die RSD-Sitzung eingefügt, und jeder PSN der Bereitstellung kann sie später verwenden.

Es gibt einige andere Eckfälle, die die beschriebene Funktion nicht lösen kann. Wenn NAD beispielsweise eine Neuauthentifizierung auf demselben PSN, jedoch mit einer anderen Sitzungs-ID ausführt. Diese 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:

Network

Statusfreigabe über RSD - veraltete/Phantom-Sitzung

Um eine veraltete Sitzung zu erstellen, muss die Authentifizierung zunächst auf skuchere-ise26-1 durchgeführt werden. Anschließend muss NAD neu konfiguriert werden, um die Abrechnung an skuchere-ise26-3 zu senden. Nachdem eine Abrechnungsnachricht an das falsche PSN weitergeleitet wurde, muss NAD (erneut) neu konfiguriert werden, um die Abrechnung an skuchere-ise26-1.

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

Phantom Session Accounting Report

  1. Accounting-Start Nachrichten, die von skuchere-ise26-1 verarbeitet werden.
  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.

Der Endpunkt stellt eine Verbindung mit dem Netzwerk her, aber die Umleitung funktioniert nicht mehr. In der Datei guest.log von PSN for 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. Auf diese Weise können Sie Informationen von PSN abrufen, wo 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, geht er davon aus, 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 Reauthentifizierungs-Timer aktiviert. Später wird NAD neu konfiguriert, um die Authentifizierung und Abrechnung an ein anderes PSN zu senden (skuchere-ise26-3.) Nach Ablauf des Timers für die Neuauthentifizierung wird dieselbe Sitzung auf dem anderen PSN nicht authentifiziert. 

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

Failover Between PSNs

  1. Die Authentifizierung erfolgt auf skuchere-ise26-1, das Autorisierungsprofil mit Umleitung wird zugewiesen.
  2. COA nach erfolgreicher Haltungsbeurteilung.
  3. Die nächste Authentifizierung für das Autorisierungsprofil mit dem konformen Status wird zugewiesen.
  4. Die Authentifizierung trifft auf ein anderes PSN zu, es wird jedoch weiterhin ein Autorisierungsprofil für den kompatiblen Zustand empfangen.

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 Hinzufügen zusätzlicher Logik in den Statusauswahlprozess behoben. Diese Abbildung zeigt, was geändert wurde (Änderungen rot hervorgehoben):

Process

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
3.0
25-Aug-2026
Aktualisierter Titel, Rechtschreibung, Grammatik, eingefügte horizontale Linien in separate Abschnitte zur besseren Lesbarkeit, feste URLs, CCW-Warnungen und alternativer Text.
2.0
31-May-2023
Rezertifizierung
1.0
22-Apr-2020
Erstveröffentlichung
TAC Authored

Beiträge von Cisco Ingenieuren

  • Serhii Kucherenko

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.