ISE-houding implementeren

Inleiding

In dit document worden enkele basislijnconfiguraties beschreven die betrekking hebben op verschillende use cases met een omleidingsgebaseerde houding.

Beperkingen

De configuraties in dit document werken voor Cisco NAD's, maar niet noodzakelijkerwijs voor NAD's van derden.

Houding clientgedrag

De houdingsklant kan op deze momenten sondes activeren:

• Eerste aanmelding
• Layer 3 (L3)-wijziging/verandering van netwerkinterfacekaart (NIC) (nieuw IP-adres, wijziging van NIC-status)

Use cases 

Use Case 1 - Client Reauthentication dwingt de NAD om een nieuwe sessie-ID te genereren

In dit gebruiksgeval is de client nog steeds compatibel, maar vanwege herverificatie bevindt de NAD zich in de redirect-status (redirect-URL en toegangslijst).

Identity Services Engine (ISE) is standaard geconfigureerd om elke keer dat er verbinding wordt gemaakt met het netwerk, een postuur-evaluatie uit te voeren, meer specifiek voor elke nieuwe sessie.

Deze instelling is geconfigureerd onder Werkcentra > Houding > Instellingen > Houding Algemene instellingen.

Configureer deze herverificatiewaarden in het autorisatieprofiel om te voorkomen dat de NAD een nieuwe sessie-ID genereert bij herverificatie. De weergegeven herverificatietimer is geen standaardaanbeveling en overweeg herverificatietimers per implementatie op basis van het verbindingstype (draadloos/bekabeld), het ontwerp (wat zijn de persistentieregels op de loadbalancer), enzovoort.

Beleid > Beleidselementen > Resultaten > Autorisatie > Autorisatieprofielen

Op switches moet u elke interface of sjabloon configureren om de herverificatietimer van ISE te krijgen. 

authentication timer reauthenticate server

Opmerking: als er een taakverdeler is, moet u ervoor zorgen dat persistentie zo is geconfigureerd dat opnieuw verificaties kunnen worden teruggestuurd naar de oorspronkelijke beleidsservice (PSN).

Use Case 2 - De Switch is geconfigureerd met Order MAB DOT1X en Priority DOT1X MAB (bekabeld)

In dit geval kunnen herverificaties worden beëindigd omdat een boekhoudstop voor de 802.1x-sessie kan worden verzonden wanneer MAC Authentication Bypass (MAB) wordt geprobeerd tijdens herverificatie.

• De boekhoudstop die wordt verzonden voor het MAB-proces wanneer de verificatie mislukt, is correct, omdat de gebruikersnaam voor de client verandert van de 802.1X-gebruikersnaam in de MAB-gebruikersnaam.
• Dot1x als de methode-id in de boekhoudstop is ook correct omdat de autorisatiemethode dot1x was.
• Wanneer de Dot1x-methode slaagt, wordt een begin met de boekhouding verstuurd met method-id als dot1x. Ook hier is dit gedrag zoals verwacht.

Om dit probleem op te lossen, configureert u het cisco-av-pair: termination-action-modifier=1 op het authZ-profiel dat wordt gebruikt wanneer een eindpunt compatibel is. Dit AV-paar (attribuut-waarde) geeft aan dat de NAD de methode hergebruikt die in de oorspronkelijke verificatie is gekozen, ongeacht de geconfigureerde volgorde.

Use Case 3 - Draadloze clients zwerven en verificaties voor verschillende toegangspunten gaan naar verschillende controllers

Voor deze situatie moet het draadloze netwerk zo worden ontworpen dat de toegangspunten (AP's) die binnen handbereik zijn van andere AP's voor roaming, dezelfde actieve controller gebruiken. Een voorbeeld hiervan is de failover van de Wireless LAN Controller (WLC) stateful switchover (SSO). Zie de implementatiegids voor hoge beschikbaarheid (High Availability, HA) voor meer informatie over hoge beschikbaarheid (High Availability, SSO).

Use Case 4 - Implementaties met load balancers (Pre 2.6 Patch 6, 2.7 Patch P2 en 3.0)

Bij implementaties waarbij load balancers betrokken zijn, is het belangrijk om ervoor te zorgen dat nadat u de wijzigingen in de vorige use cases hebt aangebracht, de sessies naar hetzelfde PSN blijven gaan. Voorafgaand aan de versie/patches die voor deze stap worden vermeld, wordt de status van de positie tussen de knooppunten niet gerepliceerd via Light Data Distribution (voorheen Light Session Directory). Hierdoor is het mogelijk voor verschillende PSN's om verschillende statusresultaten van de houding te retourneren.

Als persistentie niet correct is geconfigureerd, kunnen sessies die opnieuw worden geverifieerd naar een ander PSN gaan dan het PSN dat oorspronkelijk werd gebruikt. Als dit gebeurt, kan het nieuwe PSN de status van de naleving van de sessies als onbekend markeren en het authZ-resultaat doorgeven met de ACL (Redirect Access Control List) / URL en de toegang tot de eindpunten beperken. Nogmaals, deze verandering op de NAD zou niet worden herkend door de houdingsmodule en sondes zouden niet worden geactiveerd.

Zie Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP voor meer informatie over het configureren van load balancers. Het biedt een overzicht op hoog niveau en een F5-specifieke configuratie van een best practice-ontwerp voor ISE-implementaties in een taakgebalanceerde omgeving.

Use Case 5 - Discovery-sondes in fase 2 worden beantwoord door een andere server dan waarmee de client is geverifieerd (Pre 2.6 Patch 6, 2.7 Patch 2 en 3.0)

Bekijk de sondes in de rode doos in dit diagram.

PSN's slaan sessiegegevens vijf dagen op, dus soms blijven sessiegegevens voor een conforme sessie nog steeds op het oorspronkelijke PSN staan, zelfs als de client niet langer met dat knooppunt verifieert. Als de sondes in het rode vak worden beantwoord door een andere PSN dan die welke momenteel de sessie verifieert en die PSN eerder heeft bezeten en gemarkeerd als compatibel met dit eindpunt, is het mogelijk dat er een mismatch is tussen de postuur status van de houdingsmodule op het eindpunt en de huidige authenticatie van PSN.

Hier zijn een paar veel voorkomende scenario's waar deze mismatch kan optreden:

• Een boekhoudstop wordt niet ontvangen voor een eindpunt wanneer de verbinding met het netwerk wordt verbroken.
• De NAD faalde van de ene PSN naar de andere.
• Een load balancer stuurt verificaties door naar verschillende PSN's voor hetzelfde eindpunt.

Om dit gedrag te voorkomen, kan ISE zo worden geconfigureerd dat alleen detectiesondes van een bepaald eindpunt het PSN kunnen bereiken waarop het zich momenteel authenticeert. Configureer om dit te bereiken een ander autorisatiebeleid voor elk PSN in uw implementatie. In dit beleid verwijst u naar een ander authZ-profiel dat een DACL (Downloadable Access Control List) bevat, waarmee u ALLEEN sondes kunt uitvoeren naar het PSN dat in de authZ-voorwaarde is opgegeven. Zie dit voorbeeld:

Elke PSN heeft een regel voor onbekende houding status:

Elk individueel profiel verwijst naar een andere DACL.

Opmerking: Gebruik ACL's van AirSpace voor draadloze verbindingen.

Elke DACL staat alleen toegang toe tot de PSN-sonde die de verificatie verwerkt.

In het vorige voorbeeld is 10.10.10.1 het IP-adres van PSN 1. De DACL waarnaar wordt verwezen, kan worden gewijzigd voor aanvullende services/IP's indien nodig, maar beperkt de toegang tot alleen het PSN dat de verificatie verwerkt.

Gedragsverandering Post 2.6 Patch 6, 2.7 Patch 2 en 3.0

De status Posture is toegevoegd aan de RADIUS Session Directory via het Light Data Distribution framework. Elke keer dat een update van de status van de houding op een PSN wordt ontvangen, wordt deze gerepliceerd naar ALLE PSN's in de implementatie. Zodra deze wijziging van kracht is, worden de implicaties van authenticaties en / of sondes die verschillende PSN's op verschillende authenticaties bereiken, verwijderd en kan elk PSN op alle eindpunten reageren, ongeacht waar ze momenteel worden geverifieerd.

Overweeg in de vijf gebruiksgevallen in dit document deze gedragingen:

Use Case 1 - Client reauthentication dwingt de NAD om een nieuwe sessie-ID te genereren. De client is nog steeds compliant, maar vanwege herverificatie bevindt de NAD zich in de redirect-status (redirect-URL en toegangslijst).

- Dit gedrag verandert niet en deze configuratie kan nog steeds worden geïmplementeerd op ISE en de NAD's.

Use Case 2 - De switch is geconfigureerd met de volgorde MAB DOT1X en prioritair DOT1X MAB (bekabeld).

- Dit gedrag verandert niet en deze configuratie kan nog steeds worden geïmplementeerd op ISE en de NAD's.

Use Case 3 - Draadloze clients zwerven en verificaties voor verschillende toegangspunten gaan naar verschillende controllers.

- Dit gedrag verandert niet en deze configuratie kan nog steeds worden geïmplementeerd op ISE en de NAD's.

Use Case 4 - Implementatie met load balancers.

- De best practices die in de werklastverdelingsgids zijn gedefinieerd, kunnen nog steeds worden gevolgd, maar als de werklastverdeler verificaties naar verschillende PSN's doorstuurt, kan de juiste status van de werkhouding aan de klant worden geretourneerd.

Use Case 5 - In fase 2 worden detectiesondes beantwoord door een andere server dan waarmee de client is geverifieerd

- Dit kan geen probleem zijn met het nieuwe gedrag en het autorisatieprofiel per PSN is overbodig.

Overwegingen bij het bijhouden van dezelfde sessie-ID

Wanneer u de methoden gebruikt die in dit document worden vermeld, kan een gebruiker die verbonden blijft met het netwerk mogelijk langdurig compliant blijven. Hoewel ze opnieuw authenticeren, verandert de sessie-ID niet en daarom blijft ISE het AuthZ-resultaat doorgeven voor hun regel die overeenkomt met de compliant-status.

In dit geval moet Periodic Reassessment zodanig worden geconfigureerd dat Posture vereist is om ervoor te zorgen dat het eindpunt op gedefinieerde tijdstippen in overeenstemming blijft met het bedrijfsbeleid.

Dit kan worden geconfigureerd onder Work Centers > Posture > Settings > Reassessment configurations.

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
4.0	30-Jul-2026	Hercertificering - bijgewerkte alt-tekst, spelling en opmaak.
3.0	14-Apr-2025	Bijgewerkte Alt-tekst, spelling en opmaak om te voldoen aan de richtlijnen van Cisco.
2.0	21-Feb-2024	Verkorte introductie, bijgewerkte vermeldingen van "moet" en "wil". Alt tekst toegevoegd aan afbeeldingen.
1.0	19-Feb-2020	Eerste vrijgave