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.
In diesem Dokument werden die Verwendung und Konfiguration eines umleitungslosen Statusflusses und Tipps zur Fehlerbehebung beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Für ein besseres Verständnis der später beschriebenen Konzepte wird empfohlen, folgende Schritte durchzuführen:
Vergleich früherer ISE-Versionen mit dem ISE-Statusverlauf in ISE 2.2
ISE-Sitzungsmanagement und Status
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Der ISE-Statusflow besteht aus den folgenden Schritten:
0. Authentifizierung/Autorisierung Wird in der Regel unmittelbar vor Beginn des Status-Flows durchgeführt, kann aber in bestimmten Anwendungsfällen wie der Statusüberprüfung (PRA) umgangen werden. Da die Authentifizierung selbst keine Statuserkennung auslöst, wird dies nicht bei jedem Statusfluss als wesentlich erachtet.
Dieses Dokument konzentriert sich auf den Erkennungsprozess des ISE-Statusflusses.
Cisco empfiehlt, die Umleitung für den Erkennungsprozess zu verwenden. In einigen Fällen ist jedoch eine Umleitung nicht möglich, z. B. bei Netzwerkgeräten von Drittanbietern, bei denen die Umleitung nicht unterstützt wird. Dieses Dokument bietet eine allgemeine Anleitung und Best Practices für die Implementierung und Fehlerbehebung von umleitungslosen Zuständen in solchen Umgebungen.
Eine vollständige Beschreibung des umleitungslosen Datenflusses finden Sie unter Frühere ISE-Versionen vergleichen mit ISE-Statusfluss in ISE 2.2.
Es gibt zwei Arten von Statusermittlungssonden, die keine Umleitung verwenden:
Connectiondata.xml ist eine Datei, die vom Cisco Secure Client automatisch erstellt und verwaltet wird. Es besteht aus einer Liste von PSNs, mit denen der Client zuvor eine Verbindung für Statusfragen hergestellt hat. Daher handelt es sich hierbei nur um eine lokale Datei, deren Inhalt nicht auf allen Endpunkten dauerhaft ist.
Der Hauptzweck von connectionData.xml besteht darin, als Sicherungsmechanismus für Erkennungssonden der Phasen 1 und 2 zu fungieren. Falls die Weiterleitungs- oder Call Home List-Diagnosetools ein PSN mit einer aktiven Sitzung nicht finden können, sendet der Cisco Secure Client eine direkte Anforderung an jeden der in connectionData.xml aufgeführten Server.
Ein häufiges Problem, das durch die Verwendung von connectionData.xml-Tests verursacht wird, ist eine Überlastung der ISE-Bereitstellung aufgrund einer großen Anzahl von HTTPS-Anforderungen, die von den Endpunkten gesendet werden. Es ist wichtig zu beachten, dass connectionData.xml zwar als Backup-Mechanismus wirksam ist, um vollständige Ausfälle sowohl für Umleitungs- als auch für umleitungslose Statusmechanismen zu vermeiden, jedoch keine nachhaltige Lösung für eine Statusumgebung darstellt. Daher ist es erforderlich, die Design- und Konfigurationsprobleme zu diagnostizieren und zu beheben, die den Ausfall der Haupterkennungssonden verursachen und zu Erkennungsproblemen führen.
Die Call Home List (Liste der Anrufer-Standorte) ist ein Abschnitt des Statusprofils, in dem eine Liste von PSNs zur Verwendung für die Statusanzeige festgelegt ist. Im Gegensatz zu connectiondata.xml wird diese Datei von einem ISE-Administrator erstellt und verwaltet und erfordert möglicherweise eine Entwurfsphase für die optimale Konfiguration. Die Liste der PSNs in der Call Home-Liste muss mit der Liste der Authentifizierungs- und Abrechnungsserver übereinstimmen, die im Netzwerkgerät oder Load Balancer für RADIUS konfiguriert ist.
Call Home List-Tests ermöglichen die Verwendung einer MnT-Suche während der aktiven Sitzungssuche, falls die lokale Suche in einem PSN fehlschlägt. Dieselbe Funktion wird nur dann auf die Prüfpunkte connectionData.xml erweitert, wenn diese während der Phase-2-Erkennung verwendet werden. Aus diesem Grund werden alle Sonden der Stufe 2 auch als Sonden der neuen Generation bezeichnet.
Da ein umleitungsloser Erkennungsprozess häufig einen komplexeren Datenfluss und eine höhere Verarbeitungsleistung auf PSNs und MnT im Vergleich zu einem Umleitungsfluss erfordert, können sich bei der Implementierung zwei allgemeine Herausforderungen ergeben:
Um diese Herausforderungen zu bewältigen, wird empfohlen, die Call Home-Liste so zu entwerfen, dass die Anzahl der PSNs, die ein Endgerät für den Status verwenden kann, begrenzt wird. Bei mittleren und großen Bereitstellungen muss die Bereitstellung verteilt werden, damit mehrere Call Home-Listen mit einer reduzierten Anzahl von PSNs erstellt werden können. Daher sollte die Liste der PSNs, die für die RADIUS-Authentifizierung für ein bestimmtes Netzwerkgerät verwendet werden, auf die gleiche Weise begrenzt werden, damit sie mit der entsprechenden Call Home-Liste übereinstimmen.
Die folgenden Aspekte können bei der Entwicklung der PSN-Verteilungsstrategie berücksichtigt werden, um die maximale Anzahl von PSNs in jeder Call Home-Liste zu bestimmen:
Tipp: Verwenden Sie Netzwerkgerätegruppen, um die Netzwerkgeräte entsprechend dem Design zu klassifizieren.
Netzwerkgerätegruppen können verwendet werden, um Netzwerkgeräte anhand der entsprechenden RADIUS-Serverliste und der Call Home-Liste zu identifizieren und ihnen zuzuordnen. Im Fall von Hybrid-Umgebungen können sie auch verwendet werden, um Geräte zu identifizieren, die die Umleitung von Geräten unterstützen, die dies nicht tun.
Wenn die während der Designphase entwickelte Verteilungsstrategie Netzwerkgerätegruppen verwendet, führen Sie die folgenden Schritte aus, um diese für die ISE zu konfigurieren:
In den in diesem Leitfaden verwendeten Beispielen wird die Location Device Group (Standort-Gerätegruppe) verwendet, um die RADIUS-Serverliste und die Call Home List (Anrufleitliste) zu identifizieren, und eine benutzerdefinierte Posture Device Group (Status-Gerätegruppe) wird verwendet, um die Umleitung von umleitungslosen Statusgeräten zu identifizieren.
Es gibt zwei Möglichkeiten, den Client mit der richtigen Software und dem richtigen Profil auszustatten, um den Status in einer Umgebung ohne Umleitung auszuführen:
Hinweis: In Schritt 4 des Abschnitts für die Client-Bereitstellungsrichtlinie finden Sie Anweisungen zum Überprüfen des Ports im Client-Bereitstellungsportal, falls erforderlich.
Warnung: Stellen Sie sicher, dass sich die gleichen Cisco Secure Client-Dateien auch auf den Headends befinden, mit denen Sie eine Verbindung herstellen möchten: Secure Firewall ASA, ISE usw. Selbst bei Verwendung der manuellen Bereitstellung muss die ISE für die Client-Bereitstellung mit der entsprechenden Softwareversion konfiguriert werden. Detaillierte Anweisungen finden Sie im Abschnitt Konfiguration der Client-Bereitstellungsrichtlinie.
Tipp: Installieren Sie das Diagnose- und Reporting-Tool, das zur Fehlerbehebung verwendet werden soll.
Das ISE Client Provisioning Portal kann zur Installation des Cisco Secure Client ISE Posture-Moduls und des Statusprofils von der ISE verwendet werden. Es kann auch verwendet werden, um das Statusprofil alleine zu übertragen, wenn das ISE Posture-Modul bereits auf dem Client installiert ist.
Hinweis: Um den Portal-FQDN nutzen zu können, müssen die Clients sowohl die PSN-Admin-Zertifikatkette als auch die Portal-Zertifikatkette im vertrauenswürdigen Speicher installiert haben, und das Admin-Zertifikat muss den Portal-FQDN im SAN-Feld enthalten.
Die Client-Bereitstellung muss auf der ISE konfiguriert werden, und zwar unabhängig von der Art der Bereitstellung (Pre-Deployment oder Web Deployment), mit der Cisco Secure Client auf den Endpunkten installiert wird.
Um den Port zu finden, der in der Call Home-Liste verwendet werden soll, navigieren Sie zu Work Centers > Posture > Client Provisioning > Client Provisioning Portal, wählen Sie das verwendete Portal aus, und erweitern Sie Portal Settings (Porteinstellungen).
Warnung: Wenn Cisco Secure Client bereits auf den Clients bereitgestellt wurde, stellen Sie sicher, dass die ISE-Version mit der Version auf den Endgeräten übereinstimmt. Wenn ASA oder FTD für die Web-Bereitstellung verwendet wird, sollte auch die Version auf diesem Gerät übereinstimmen.
Hinweis: Verwenden Sie bei mehreren Call Home-Listen das Feld Andere Bedingungen, um das richtige Profil an die entsprechenden Clients weiterzuleiten. In diesem Beispiel wird die Device Location Group verwendet, um das Statusprofil zu identifizieren, das in die Richtlinie eingefügt wird.
Tipp: Wenn mehrere Client-Bereitstellungsrichtlinien für dasselbe Betriebssystem konfiguriert sind, wird empfohlen, sie sich gegenseitig auszuschließen, d. h., ein Client sollte jeweils nur eine Richtlinie erreichen können. RADIUS-Attribute können in der Spalte Other Conditions (Andere Bedingungen) verwendet werden, um eine Richtlinie von einer anderen zu unterscheiden.
permit udp any any eq domain
permit udp any any eq bootps
permit ip any host
permit ip any host
deny ip any any
Achtung: Einige Geräte von Drittanbietern unterstützen möglicherweise keine DACLs. In diesem Fall müssen Sie eine Filter-ID oder andere anbieterspezifische Attribute verwenden. Weitere Informationen finden Sie in der Herstellerdokumentation. Wenn keine DACLs verwendet werden, müssen Sie die entsprechende ACL im Netzwerkgerät konfigurieren.
Hinweis: Wenn keine DACLs verwendet werden, verwenden Sie Filter-ID aus Common Tasks oder den erweiterten Attributeinstellungen, um den entsprechenden ACL-Namen zu übertragen.
Das Vorhandensein veralteter oder Phantom-Sitzungen in der Bereitstellung kann intermittierende und scheinbar zufällige Fehler mit umleitungsloser Statuserkennung verursachen, die dazu führen, dass Benutzer in einem unbekannten/nicht anwendbaren Status auf der ISE feststecken, während die Benutzeroberfläche des Cisco Secure Client einen konformen Zugriff aufweist.
Veraltete Sitzungen sind alte Sitzungen, die nicht mehr aktiv sind. Sie werden durch eine Authentifizierungsanforderung und einen Accounting-Start erstellt, aber auf dem PSN wird kein Accounting-Stopp empfangen, um die Sitzung zu löschen.
Phantom-Sitzungen sind Sitzungen, die in einem bestimmten PSN nie aktiv waren. Sie werden durch ein Accounting-Interim-Update erstellt, es wird jedoch kein Accounting-Stopp auf dem PSN empfangen, um die Sitzung zu löschen.
Um ein veraltetes/Phantom-Sitzungsproblem zu identifizieren, überprüfen Sie das beim Systemscan auf dem Client verwendete PSN, und vergleichen Sie es mit dem PSN, der die Authentifizierung durchführt:
Die ISE-Versionen oberhalb von ISE 2.6 Patch 6 und 2.7 Patch 3 implementieren RADIUS Session Directory als Lösung für veraltete/Phantom-Sitzungen im umleitungslosen Statusfluss.
Hinweis: Dieser Service bezieht sich auf die Kommunikationsmethode, die für RSD zwischen PSNs verwendet wird und unabhängig vom Status der ISE Messaging Service-Einstellung für Syslog ausgeführt werden sollte, die über die ISE-Benutzeroberfläche festgelegt werden kann.
Hinweis: Es wird erwartet, dass während der Neugenerierung der Zertifikate Warnungen aufgrund von Warteschlangenverbindungsfehlern mit der Ursache Unbekannte Zertifizierungsstelle oder Nicht verweigert beobachtet werden. Überwachen Sie die Warnungen nach der Zertifikatgenerierung, um zu bestätigen, dass das Problem behoben wurde.
Leistungsprobleme wie eine hohe CPU-Auslastung und ein hoher Lastdurchschnitt im Zusammenhang mit einem umleitungslosen Status können sich auf PSN- und MnT-Knoten auswirken und werden häufig von den folgenden Ereignissen begleitet oder ihnen vorangehen:
Wenn die Leistung der Bereitstellung durch einen umleitungslosen Status beeinträchtigt wird, ist dies häufig ein Hinweis auf eine ineffektive Implementierung. Es wird empfohlen, die folgenden Aspekte zu überarbeiten:
So reduzieren Sie die Auswirkungen:
RADIUS-Accounting ist für das Sitzungsmanagement auf der ISE unverzichtbar. Da der Status von einer aktiven Sitzung abhängt, kann sich eine falsche oder fehlende Accounting-Konfiguration auch auf die Statuserkennung und die ISE-Leistung auswirken. Es ist wichtig zu überprüfen, ob die Abrechnung auf dem Netzwerkgerät korrekt konfiguriert ist, um Authentifizierungsanforderungen, Abrechnungsstart, Abrechnungsstopp und Abrechnungsaktualisierungen für jede Sitzung an einen einzigen PSN zu senden.
Um die auf der ISE empfangenen Abrechnungspakete zu überprüfen, navigieren Sie zu Operations > Reports > Reports > Endpoints and Users > RADIUS Accounting.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
24-Jul-2023 |
Erstveröffentlichung |