ISE-houding implementeren

Inleiding

In dit document worden enkele basislijnconfiguraties beschreven die verschillende gebruiksscenario's met een op omleiding gebaseerde houding aanpakken.

Beperkingen

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

Houding cliëntgedrag

De houdingscliënt kan op deze momenten sondes triggeren:

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

Use cases 

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

In dit geval is de client nog steeds compatibel, maar vanwege herverificatie bevindt de NAD zich in de omleidingsstatus (omleidings-URL en toegangslijst).

Standaard is de Identity Services Engine (ISE) geconfigureerd om elke keer dat verbinding wordt gemaakt met het netwerk een houdingsbeoordeling uit te voeren, meer specifiek voor elke nieuwe sessie.

Deze instelling wordt geconfigureerd onder Work Centers > Posture > Settings > Posture General Settings (Algemene instellingen voor houding).

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

Beleid > Beleidselementen > Resultaten > Autorisatie > Autorisatieprofielen

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

authentication timer reauthenticate server

Opmerking: als er een taakverdelingsfunctie is, moet u ervoor zorgen dat persistentie zodanig is geconfigureerd dat herverificaties kunnen worden teruggestuurd naar de oorspronkelijke beleidsservice (PSN).

Use Case 2 - De Switch is geconfigureerd met de bestelling MAB DOT1X en Priority DOT1X MAB (bedraad)

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, verzendt deze een boekhoudkundige start met methode-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 voldoet. Dit attribuut-waarde (AV)-paar geeft aan dat de NAD de methode gebruikt die is gekozen in de oorspronkelijke verificatie, ongeacht de geconfigureerde volgorde.

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

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

Use Case 4 - Implementaties met loadbalancers (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 dezelfde PSN blijven gaan. Voorafgaand aan de versie/patches die voor deze stap worden vermeld, wordt de houdingsstatus niet gerepliceerd tussen de knooppunten via Light Data Distribution (voorheen Light Session Directory). Hierdoor is het mogelijk voor verschillende PSN’s om verschillende houdingsstatusresultaten terug te geven.

Als de persistentie niet correct is geconfigureerd, kunnen sessies die opnieuw worden geverifieerd, naar een andere PSN gaan dan die oorspronkelijk werd gebruikt. Als dit gebeurt, kan de nieuwe PSN de nalevingsstatus van de sessies markeren als onbekend en het resultaat authZ doorgeven met de toegangscontrolelijst voor omleiding (ACL) / 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 loadbalancers. Het biedt een overzicht op hoog niveau en F5-specifieke configuratie van een best practice-ontwerp voor ISE-implementaties in een omgeving met taakverdeling.

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

Kijk eens naar de sondes in de rode doos in dit diagram.

PSN's slaan sessiegegevens gedurende vijf dagen op, dus soms leven sessiegegevens voor een compatibele sessie nog steeds op het oorspronkelijke PSN, zelfs als de client zich niet langer verifieert met die node. Als de sondes in het rode vak worden beantwoord door een andere PSN dan degene die momenteel de sessie verifieert en die PSN eerder in het bezit heeft gehad en dit eindpunt heeft gemarkeerd, is het mogelijk dat er een mismatch is tussen de houdingsstatus van de houdingsmodule op het eindpunt en de huidige authenticerende PSN.

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

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

Om dit gedrag te voorkomen, kan ISE zo worden geconfigureerd dat alleen detectieprobes van een bepaald eindpunt de PSN kunnen bereiken die momenteel wordt geverifieerd. Configureer hiervoor een ander machtigingsbeleid voor elke PSN in uw implementatie. In deze beleidsregels verwijst u naar een ander authZ-profiel dat een downloadbare toegangscontrolelijst (DACL) bevat waarmee alleen sondes kunnen worden gebruikt voor de PSN die is opgegeven in de voorwaarde authZ. Zie dit voorbeeld:

Elke PSN heeft een regel voor een onbekende houding:

Elk individueel profiel verwijst naar een andere DACL.

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

Elke DACL geeft alleen sonde toegang tot de PSN die de verificatie afhandelt.

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

Gedragsverandering na 2.6 Patch 6, 2.7 Patch 2 en 3.0

De houdingsstatus is toegevoegd aan de RADIUS Session Directory via het Light Data Distribution framework. Telkens wanneer een update van de houdingsstatus wordt ontvangen op een PSN, 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 bereiken op verschillende authenticaties verwijderd en kan elke PSN op alle eindpunten reageren, ongeacht waar ze momenteel zijn geverifieerd.

Overweeg in de vijf use cases in dit document deze gedragingen:

Case 1 gebruiken - Door clientverificatie wordt de NAD gedwongen een nieuwe sessie-ID te genereren. De client voldoet nog steeds, 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 prioriteit DOT1X MAB (bedraad).

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

Case 3 gebruiken - 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 - Implementaties met loadbalancers.

- De best practices die in de taakverdelingsgids zijn gedefinieerd, kunnen nog steeds worden gevolgd, maar in het geval dat de taakverdeler verificaties doorstuurt naar verschillende PSN's, kan de juiste houdingsstatus aan de client worden geretourneerd.

Use Case 5 - Detectieproblemen in fase 2 worden 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 niet nodig.

Overwegingen bij het onderhouden 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 gedurende lange tijd 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 compatibele status.

In dit geval moet periodieke herbeoordeling worden geconfigureerd zodat Posture vereist is om ervoor te zorgen dat het eindpunt op bepaalde tijdstippen voldoet aan het bedrijfsbeleid.

Dit kan worden geconfigureerd onder Workcenters > Houding > Instellingen > Configuraties opnieuw beoordelen.