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.
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.
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.
In diesem Dokument wird erläutert:
Für ein besseres Verständnis der später beschriebenen Konzepte wird empfohlen:
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:
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:
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.
Dieses Problem manifestiert sich normalerweise in zwei problematischen Szenarien, die jeweils mehrere Ursachen haben können. Die Szenarien:
Um das Problem besser zu verstehen, benötigen Sie detaillierte Informationen zur ISE-Sitzungsverwaltungslogik und zum AnyConnect-Erkennungsprozess.
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.
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:
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
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:
Beim Entfernen von Sitzungen implementiert PSN folgende Logik:
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:
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.
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:
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.
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.
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.
ISE-Statusmodul zur Überwachung einer begrenzten Anzahl von Ereignissen am Endpunkt, um einen Erkennungsprozess auszulösen. Liste der Ereignisse, die die Erkennung auslösen:
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:
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.
Dies kann in den beiden häufigsten Szenarien auftreten:
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.
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. 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:
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:
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.
Analysieren Sie ein DART-Paket, das vom Endgerät übernommen wurde und das Problem reproduzierte.
Um dies zu erreichen, muss das DART-Paketdienstprogramm als Administrator beginnen und eine Protokollbereinigung durchführen.
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:
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
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:
Beispiel für einen Bericht, der zeigt, wie veraltete Sitzungen auf ciscolive-ise2 zurückbleiben:
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:
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.
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.
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.
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.
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
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:
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/
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.
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.
.
Es können die gleichen Best Practices implementiert werden, die im Abschnitt zu veralteten/Phantom-Sitzungen erläutert wurden.
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 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.
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.
Diese Funktion enthält die folgenden Elemente:
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]
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:
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.
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):