ISE-Status bereitstellen

Einleitung

In diesem Dokument werden einige grundlegende Konfigurationen beschrieben, die verschiedene Anwendungsfälle mit umleitungsbasiertem Status berücksichtigen.

Einschränkungen

Die Konfigurationen in diesem Dokument sind für Cisco NADs geeignet, jedoch nicht unbedingt für Drittanbieter-NADs.

Status-Client-Verhalten

Der Status-Client kann zu folgenden Zeitpunkten Tests auslösen:

• Erstanmeldung
• Änderung Layer 3 (L3)/Netzwerkkarte (NIC) (neue IP-Adresse, Änderung des NIC-Status)

Anwendungsfälle

Anwendungsfall 1: Die Client-Neuauthentifizierung erzwingt, dass die NAD eine neue Sitzungs-ID generiert.

In diesem Anwendungsfall ist der Client noch kompatibel, aber aufgrund der erneuten Authentifizierung befindet sich die NAD im Umleitungsstatus (URL und Zugriffsliste umleiten).

Standardmäßig wird die Identity Services Engine (ISE) so konfiguriert, dass sie bei jeder Verbindung mit dem Netzwerk eine Statusüberprüfung durchführt, und zwar für jede neue Sitzung.

Diese Einstellung wird unter Work Centers > Posture > Settings > Posture General Settings konfiguriert.

Damit der NAD bei der erneuten Authentifizierung keine neue Sitzungs-ID generiert, konfigurieren Sie diese Neuauthentifizierungswerte im Autorisierungsprofil. Der angezeigte Timer für die erneute Authentifizierung stellt keine Standardempfehlung dar. Es sollten daher Timer für die erneute Authentifizierung pro Bereitstellung angezeigt werden, die auf dem Verbindungstyp (Wireless/kabelgebunden), dem Design (den Persistenzregeln für den Load Balancer) usw. basieren.

Richtlinie > Richtlinienelemente > Ergebnisse > Autorisierung > Autorisierungsprofile

Auf Switches müssen Sie jede Schnittstelle oder Vorlage konfigurieren, um den Timer für die Neuauthentifizierung von der ISE zu erhalten. 

authentication timer reauthenticate server

Hinweis: Wenn ein Load Balancer vorhanden ist, müssen Sie sicherstellen, dass die Persistenz so konfiguriert ist, dass erneute Authentifizierungen an den ursprünglichen Policy Service (PSN) zurückgegeben werden können.

Anwendungsfall 2: Der Switch wird mit der Bestellung MAB DOT1X und der Priorität DOT1X MAB (kabelgebunden) konfiguriert.

In diesem Fall können erneute Authentifizierungen beendet werden, da ein Accounting-Stopp für die 802.1x-Sitzung gesendet werden kann, wenn MAB (MAC Authentication Bypass) während der erneuten Authentifizierung versucht wird.

• Der Abrechnungsstopp, der für den MAB-Prozess gesendet wird, wenn die Authentifizierung fehlschlägt, ist richtig, da sich der Benutzername für den Client vom 802.1X-Benutzernamen in den MAB-Benutzernamen ändert.
• Dot1x als Methode-ID im Accounting-Stopp ist ebenfalls korrekt, da die Autorisierungsmethode dot1x war.
• Wenn die Dot1x-Methode erfolgreich ist, sendet sie einen Abrechnungsstart mit der Methode-ID als dot1x. Auch hier ist dieses Verhalten erwartungsgemäß.

Um dieses Problem zu beheben, konfigurieren Sie cisco-av-pair:termination-action-modifier=1 auf dem authZ-Profil, das verwendet wird, wenn ein Endpunkt konform ist. Dieses Attribut-Wert-Paar (AV) gibt an, dass der NAD die in der ursprünglichen Authentifizierung gewählte Methode unabhängig von der konfigurierten Reihenfolge wiederverwendet.

Anwendungsfall 3: Roaming von Wireless-Clients und Authentifizierungen für verschiedene APs werden an unterschiedliche Controller weitergeleitet.

In diesem Fall muss das Wireless-Netzwerk so konzipiert sein, dass die Access Points (APs), die sich in Reichweite zu anderen APs für Roaming befinden, denselben aktiven Controller verwenden. Ein Beispiel hierfür ist der Wireless LAN Controller (WLC) Stateful Switchover (SSO)-Failover. Weitere Informationen über High Availability (HA) SSO für WLC finden Sie im High Availability (SSO) Deployment Guide.

Anwendungsfall 4 - Bereitstellungen mit Load Balancern (vor 2.6 Patch 6, 2.7 Patch P2 und 3.0).

Bei Bereitstellungen mit beteiligten Load Balancern muss sichergestellt werden, dass die Sitzungen auch nach den Änderungen in den vorherigen Anwendungsfällen an dasselbe PSN weitergeleitet werden. Vor den für diesen Schritt aufgelisteten Versionen/Patches wird der Status nicht über Light Data Distribution (ehemals Light Session Directory) zwischen den Knoten repliziert. Dadurch ist es für verschiedene PSNs möglich, unterschiedliche Statusergebnisse zurückzugeben.

Wenn die Persistenz nicht richtig konfiguriert ist, können Sitzungen, die sich erneut authentifizieren, zu einem anderen PSN weitergeleitet werden als dem ursprünglich verwendeten. In diesem Fall könnte das neue PSN den Status der Sitzungen als "unbekannt" markieren, das Ergebnis "authZ" mit der Zugriffskontrollliste (ACL)/URL für die Umleitung weiterleiten und den Zugriff auf die Endgeräte einschränken. Auch diese Änderung an der NAD würde vom Statusmodul nicht erkannt und es würden keine Tests ausgelöst.

Weitere Informationen zur Konfiguration von Load Balancern finden Sie im Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP. Es bietet einen allgemeinen Überblick und eine F5-spezifische Konfiguration eines Best Practice-Designs für ISE-Bereitstellungen in einer Umgebung mit Lastenausgleich.

Anwendungsfall 5 - Erkennungssonden der Stufe 2 werden von einem anderen Server beantwortet, als der Client mit authentifiziert wurde (Vor 2.6 Patch 6, 2.7 Patch 2 und 3.0).

Sehen Sie sich die Sonden in der roten Box in diesem Diagramm an.

PSNs speichern Sitzungsdaten fünf Tage lang, sodass Sitzungsdaten für eine "konforme" Sitzung manchmal immer noch auf dem ursprünglichen PSN verbleiben, selbst wenn sich der Client nicht mehr über diesen Knoten authentifiziert. Wenn die im roten Kästchen eingeschlossenen Sonden von einem anderen PSN als dem beantwortet werden, der derzeit die Sitzung authentifiziert UND der zuvor von PSN gehört wurde und diesen Endpunkt als kompatibel markiert hat, kann es zu einer Diskrepanz zwischen dem Status des Statusmoduls auf dem Endpunkt und dem aktuellen authentifizierenden PSN kommen.

Im Folgenden sind einige gängige Szenarien aufgeführt, in denen diese Diskrepanz auftreten kann:

• Ein Accounting-Stopp wird für einen Endpunkt nicht empfangen, wenn er die Verbindung zum Netzwerk trennt.
• NAD-Failover von einem PSN zu einem anderen
• Ein Load Balancer leitet Authentifizierungen an verschiedene PSNs für dasselbe Endgerät weiter.

Zum Schutz vor diesem Verhalten kann die ISE so konfiguriert werden, dass nur Erkennungssonden von einem bestimmten Endpunkt das PSN erreichen, bei dem sie sich derzeit authentifiziert. Um dies zu erreichen, müssen Sie für jedes PSN in Ihrer Bereitstellung eine andere Autorisierungsrichtlinie konfigurieren. Verweisen Sie in diesen Richtlinien auf ein anderes authZ-Profil, das eine herunterladbare Zugriffskontrollliste (DACL, Access Control List) enthält, die Tests NUR auf den in der authZ-Bedingung angegebenen PSN zulässt. Siehe folgendes Beispiel:

Für jedes PSN gibt es eine Regel für den Status "Unbekannt":

Jedes einzelne Profil referenziert eine andere DACL.

Hinweis: Verwenden Sie für Wireless-Netzwerke Airespace-ACLs.

Jede DACL ermöglicht nur den Testzugriff auf das PSN, das die Authentifizierung übernimmt.

Im vorherigen Beispiel ist 10.10.10.1 die IP-Adresse von PSN 1. Die referenzierte DACL kann für alle zusätzlichen Dienste/IPs nach Bedarf geändert werden, beschränkt jedoch den Zugriff auf das PSN, das die Authentifizierung verarbeitet.

Verhaltensänderung nach 2.6 Patch 6, 2.7 Patch 2 und 3.0

Der Status wurde dem RADIUS-Sitzungsverzeichnis über das Light Data Distribution Framework hinzugefügt. Jedes Mal, wenn ein Statusupdate für ein beliebiges PSN eingeht, wird es auf ALLE PSNs in der Bereitstellung repliziert. Sobald diese Änderung in Kraft ist, werden die Auswirkungen von Authentifizierungen und/oder Tests, die unterschiedliche PSNs erreichen, bei verschiedenen Authentifizierungen beseitigt, und jedes PSN kann auf alle Endpunkte antworten, unabhängig davon, wo sie derzeit authentifiziert werden.

Berücksichtigen Sie in den fünf Anwendungsfällen in diesem Dokument folgende Verhaltensweisen:

Anwendungsfall 1: Die Client-Neuauthentifizierung erzwingt, dass die NAD eine neue Sitzungs-ID generiert. Der Client ist weiterhin kompatibel, aber aufgrund der Neuauthentifizierung befindet sich die NAD im Umleitungsstatus (URL und Zugriffsliste umleiten).

- Dieses Verhalten ändert sich nicht, und diese Konfiguration kann weiterhin auf der ISE und den NADs implementiert werden.

Anwendungsfall 2: Der Switch wird mit der Bestellung MAB DOT1X und der Priorität DOT1X MAB (kabelgebunden) konfiguriert.

- Dieses Verhalten ändert sich nicht, und diese Konfiguration kann weiterhin auf der ISE und den NADs implementiert werden.

Anwendungsfall 3: Roaming von Wireless-Clients und Authentifizierungen für verschiedene APs werden an unterschiedliche Controller weitergeleitet.

- Dieses Verhalten ändert sich nicht, und diese Konfiguration kann weiterhin auf der ISE und den NADs implementiert werden.

Anwendungsfall 4: Bereitstellungen mit Load Balancern

- Die im Load Balancing-Leitfaden definierten Best Practices können weiterhin befolgt werden. Falls jedoch die Authentifizierungen vom Load Balancer an verschiedene PSNs weitergeleitet werden, kann der korrekte Status an den Client zurückgegeben werden.

Anwendungsfall 5: Ermittlungssonden der Stufe 2 werden von einem anderen Server beantwortet, mit dem der Client nicht authentifiziert wird.

- Dies kann kein Problem mit dem neuen Verhalten sein, und das PSN-Autorisierungsprofil ist nicht erforderlich.

Überlegungen beim Verwalten derselben SessionID

Wenn Sie die in diesem Dokument aufgeführten Methoden verwenden, kann es sein, dass ein Benutzer, der weiterhin mit dem Netzwerk verbunden ist, über lange Zeiträume hinweg den Richtlinien entspricht. Auch wenn sie sich erneut authentifizieren, ändert sich die sessionID nicht, und die ISE gibt daher weiterhin das AuthZ-Ergebnis für ihre Regel weiter, die mit dem kompatiblen Status übereinstimmt.

In diesem Fall muss die regelmäßige Überprüfung so konfiguriert werden, dass der Status erforderlich ist, um sicherzustellen, dass das Endgerät die Unternehmensrichtlinien in festgelegten Intervallen erfüllt.

Dies kann unter Work Centers > Posture > Settings > Ressession configuration konfiguriert werden.