ISE-houding implementeren

Inleiding

Dit document beschrijft een aantal basislijnconfiguraties die meerdere gebruikscases met een op omleiding gebaseerde houding behandelen.

Beperkingen

De configuraties in dit document werken voor Cisco NAD’s, maar niet per se voor NAD’s van derden.

Houding van clientgedrag

De postuur client kan op deze momenten sondes veroorzaken:

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

Use cases 

Use Case 1 - De NAD wordt door de client gedwongen om een nieuwe sessie-ID te genereren.

In dit geval van gebruik is de client nog steeds compatibel, maar vanwege herverificatie is de NAD in de omleidingsfase (omleiden van URL en toegangslijst).

In de standaardinstelling is Identity Services Engine (ISE) ingesteld om een postenbeoordeling uit te voeren telkens als er verbinding met het netwerk wordt gemaakt, meer specifiek voor elke nieuwe sessie.

Deze instelling wordt ingesteld onder Werkcentra > Houding > Instellingen > Houding Algemene instellingen.

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

Beleid > Beleidselementen > Resultaten > Vergunning > Vergunningsprofielen

Op switches, moet u elke interface, of malplaatje vormen, om zijn herverificatietijdopnemer van ISE te krijgen. 

authentication timer reauthenticate server

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

Use Case 2 - De switch is geconfigureerd met orde MAB DOT1X en prioriteit DOT1X MAB (bekabeld).

In dit geval kunnen de herverificaties worden beëindigd, omdat een boekhoudkundig einde voor de 802.1x-sessie kan worden verzonden wanneer tijdens de herverificatie wordt geprobeerd om MAC-verificatie te omzeilen (MAB).

• De accounting stop die wordt verzonden voor het MAB-proces wanneer het authenticatie mislukt is correct, omdat de gebruikersnaam voor de client verandert van de 802.1X-gebruikersnaam in de MAB-gebruikersnaam.
• Dot1x als methode-id in de boekhoudstop is ook correct aangezien de ordonnateursmethode dot1x was.
• Als de Dot1x-methode slaagt, wordt er een accounting start verzonden met methode-id als dot1x. Ook hier is dit gedrag zoals verwacht.

Om dit probleem op te lossen moet u het Cisco-av-paar:termination-action-modifier=1 configureren in het gebruikte authZ-profiel wanneer een eindpunt compatibel is. Dit attribuut-value (AV) paar geeft aan dat het NAD de methode hergebruikt die in de oorspronkelijke verificatie is geselecteerd, ongeacht de ingestelde volgorde.

Use Case 3 - Draadloze clients zwerven en authenticaties voor verschillende AP's gaan naar verschillende controllers.

In deze situatie moet het draadloze netwerk zo worden ontworpen dat de access points (AP's) die binnen het bereik van andere AP's liggen voor zwerven, dezelfde actieve controller gebruiken. Een voorbeeld is de Wireless LAN Controller (WLC) stateful switchover (SSO)-failover. Voor meer informatie over Hoge Beschikbaarheid (Ha) SSO voor WLC, zie de Gids van de Plaatsing van Hoge Beschikbaarheid (SSO).

Use Case 4 - implementaties met taakverdeling (Pre 2.6 Patch 6, 2.7 Patch P2, en 3.0).

Bij implementaties met betrokken load balancers is het belangrijk om ervoor te zorgen dat nadat u de wijzigingen in de vorige gebruikscases 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 houding niet herhaald tussen de knooppunten via Light Data Distribution (voorheen Light Session Directory). Hierdoor is het mogelijk dat verschillende PSNs verschillende postuur status resultaten retourneren.

Als persistentie niet goed is geconfigureerd, kunnen sessies die opnieuw worden geverifieerd naar een ander PSN gaan dan het oorspronkelijke PSN. Als dit gebeurt, kan de nieuwe PSN de sessiestatus van de naleving als onbekend markeren en het authZ resultaat doorgeven met de redirect toegangscontrolelijst (ACL)/URL en de endpoints toegang beperken. Opnieuw, zou deze verandering op NAD niet worden erkend door de postuur module en sondes niet worden geactiveerd.

Voor meer informatie over het configureren van taakverdeling, raadpleegt u de implementatiegids Cisco en F5: ISE-taakverdeling met BIG-IP. 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 - Fase 2 detectiesondes worden beantwoord door een andere server dan de client wordt geauthenticeerd met (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 vijf dagen op, dus soms blijven sessiegegevens voor een 'compatibele' sessie nog steeds op de oorspronkelijke PSN, zelfs als de client niet langer authenticeert met dat knooppunt. Als de sondes in het rode vak worden beantwoord door een PSN anders dan die die momenteel de sessie authenticeert EN dat PSN eerder dit eindpunt heeft bezeten en gemarkeerd dat voldoet, is het mogelijk dat er een verschil is tussen de postuur status van de postuur module op het eindpunt en de huidige authenticatie van PSN.

Hier zijn een paar veelvoorkomende scenario's waarin deze mismatch kan optreden:

• Een accounting stop wordt niet ontvangen voor een eindpunt wanneer het verbinding maakt met het netwerk.
• De NAD is van het ene PSN naar het andere niet overgegaan.
• Met een taakverdeler worden verificaties doorgestuurd naar verschillende PSN's voor hetzelfde eindpunt.

Om tegen dit gedrag te beschermen, kan ISE worden geconfigureerd om alleen detectiesondes van een bepaald eindpunt toe te staan om het PSN te bereiken dat op dit moment wordt geverifieerd. Om dit te bereiken, moet u een ander autorisatiebeleid voor elke PSN in uw implementatie configureren. In dit beleid wordt een ander authZ-profiel met een DACL (Downloadbare toegangscontrolelijst) aangegeven, waarmee alleen sondes kunnen worden uitgevoerd naar de PSN die in de authZ-voorwaarde is gespecificeerd. Zie dit voorbeeld:

Elke PSN heeft een regel voor onbekende postuur status:

Elk individueel profiel verwijst naar een andere DACL.

Opmerking: voor draadloos, gebruik Aironet ACL’s.

Elke DACL geeft alleen sondertoegang tot het PSN dat de verificatie verwerkt.

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 extra services/IP’s, 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 van de houding is toegevoegd aan de RADIUS Session Directory via het Light Data Distribution framework. Elke keer wordt een postuurestatus-update ontvangen op een PSN, gerepliceerd naar ALLE PSN's in de implementatie. Zodra deze wijziging van kracht is, worden de implicaties van verificaties en/of sondes die verschillende PSN’s bereiken op verschillende verificaties verwijderd en kan elke PSN reageren op alle endpoints, ongeacht waar ze momenteel worden geverifieerd.

In de vijf gebruikscases in dit document dient u rekening te houden met deze gedragingen:

Use Case 1 - De NAD wordt door de client gedwongen om een nieuwe sessie-ID te genereren. De client is nog steeds compatibel, maar vanwege herverificatie is de NAD in de omleidingsstatus (doorverwijzen naar 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 orde MAB DOT1X en prioriteit 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 authenticaties voor verschillende AP's 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 load balancers.

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

Use Case 5 - Fase 2 detectiesondes worden beantwoord door een andere server dan de client wordt geauthenticeerd met

- Dit kan geen probleem zijn bij het nieuwe gedrag en het profiel voor een PSN-autorisatie is niet nodig.

Overwegingen bij het onderhouden van dezelfde SessionID

Wanneer u de in dit document vermelde methoden gebruikt, kan een gebruiker die verbonden blijft met het netwerk mogelijk lange tijd compatibel blijven. Hoewel ze opnieuw authenticeren, verandert de sessieID niet en daarom blijft ISE het AuthZ resultaat voor hun regel die overeenkomt met de conforme status.

In dit geval moet de Periodieke Herbeoordeling zo worden geconfigureerd dat Posture vereist is om ervoor te zorgen dat het eindpunt met bepaalde tussenpozen compatibel blijft met het bedrijfsbeleid.

Dit kan worden ingesteld onder Werkcentra > Houding > Instellingen > Redessmentconfiguraties.