Sommario

Introduzione

Restrizioni

Comportamento client postura

Scenari d'uso

Caso di utilizzo 1 - Riautenticazione client Impone a NAD di generare un nuovo ID sessione

Caso di utilizzo 2 - Lo switch è configurato con ordine MAB DOT1X e priorità DOT1X MAB (cablato)

Caso di utilizzo 3 - I client wireless eseguono roaming e le autenticazioni per diversi access point a controller diversi

Caso di utilizzo 4 - Distribuzioni con load balancer (Patch 6 precedente alla 2.6, Patch P2 2.7 e Patch 3.0)

Caso di utilizzo 5 - Le sonde di rilevamento della fase 2 ricevono una risposta da un server diverso da quello con cui il client viene autenticato (patch precedente alla 2.6, patch 2.7 e 3.0)

Patch 6, Patch 2 e Patch 3.0 di modifica del comportamento successiva alla 2.6

Considerazioni sulla gestione dello stesso ID sessione

Introduzione

Questo documento descrive alcune configurazioni di base che risolvono diversi casi di utilizzo con la postura basata sul reindirizzamento.

Restrizioni

Le configurazioni riportate in questo documento funzionano per i Cisco NAD, ma non necessariamente per i NAD di terze parti.

Comportamento client postura

Il client di postura può attivare le sonde in questi momenti:

- Accesso iniziale

- Modifica layer 3 (L3)/Modifica NIC (Network Interface Card) (nuovo indirizzo IP, modifica stato NIC)

Scenari d'uso

Caso di utilizzo 1 - Riautenticazione client Impone a NAD di generare un nuovo ID sessione

In questo caso di utilizzo, il client è ancora conforme, ma a causa della riautenticazione, NAD si trova nello stato di reindirizzamento (URL di reindirizzamento e elenco degli accessi).

Per impostazione predefinita, Identity Services Engine (ISE) è configurato in modo da eseguire una valutazione della postura ogni volta che si connette alla rete, in modo più specifico per ogni nuova sessione.

Questa impostazione è configurata in Centri di lavoro > Postura > Impostazioni > Impostazioni generali postura.

Per evitare che NAD generi un nuovo ID sessione alla riautenticazione, configurare i valori di riautenticazione nel profilo di autorizzazione. Il timer di riautenticazione visualizzato non è un suggerimento standard e considera i timer di riautenticazione per distribuzione in base al tipo di connessione (wireless/cablata), alla progettazione (quali sono le regole di persistenza nel bilanciamento del carico) e così via.

Criterio > Elementi criterio > Risultati > Autorizzazione > Profili autorizzazione

Sugli switch, è necessario configurare ciascuna interfaccia, o modello, per ottenere il timer di riautenticazione da ISE.

authentication timer reauthenticate server

Nota: Se è disponibile un servizio di bilanciamento del carico, è necessario verificare che la persistenza sia configurata in modo che le riautenticazioni possano essere restituite al servizio criteri originale (PSN).

Caso di utilizzo 2 - Lo switch è configurato con ordine MAB DOT1X e priorità DOT1X MAB (cablato)

In questo caso, le riautenticazioni possono essere terminate perché è possibile inviare un arresto dell'accounting per la sessione 802.1x quando si tenta di ignorare l'autenticazione MAC (MAB) durante la riautenticazione.

- L'arresto dell'accounting inviato per il processo MAB quando l'autenticazione non riesce è corretto, in quanto il nome utente del client cambia da 802.1X a MAB.

- Anche il dot1x come ID metodo nell'interruzione della contabilità è corretto, in quanto il metodo di autorizzazione era dot1x.

- Quando il metodo Dot1x ha esito positivo, invia un inizio di accounting con ID metodo come dot1x. Anche qui, questo comportamento è come previsto.

Per risolvere il problema, configurare cisco-av-pair:terminal-action-modifier=1 sul profilo authZ utilizzato quando un endpoint è conforme. Questa coppia attributo-valore (AV) specifica che NAD riutilizza il metodo scelto nell'autenticazione originale indipendentemente dall'ordine configurato.

Caso di utilizzo 3 - I client wireless eseguono roaming e le autenticazioni per diversi access point a controller diversi

In questo caso, la rete wireless deve essere progettata in modo che i punti di accesso (AP) a portata di altri AP per il roaming utilizzino lo stesso controller attivo. Un esempio è rappresentato dal failover di switching stateful (SSO) del controller WLC (Wireless LAN Controller). Per ulteriori informazioni su High Availability (HA) SSO per WLC, vedere High Availability (SSO) Deployment Guide.

Caso di utilizzo 4 - Distribuzioni con load balancer (Patch 6 precedente alla 2.6, Patch P2 2.7 e Patch 3.0)

Nelle distribuzioni con bilanciamenti del carico coinvolti, è importante assicurarsi che, dopo aver apportato le modifiche nei casi di utilizzo precedenti, le sessioni continuino a passare allo stesso PSN. Prima delle versioni/patch elencate per questo passo, lo stato della postura non viene replicato tra i nodi tramite Light Data Distribution (in precedenza Light Session Directory). Per questo motivo, è possibile che diversi PSN restituiscano risultati di stato di postura diversi.

Se la persistenza non è configurata correttamente, le sessioni che eseguono nuovamente l'autenticazione potrebbero passare a un numero PSN diverso da quello utilizzato in origine. In questo caso, il nuovo PSN potrebbe contrassegnare lo stato di conformità delle sessioni come sconosciuto e passare il risultato authZ con l'elenco di controllo di accesso (ACL)/URL di reindirizzamento e limitare l'accesso agli endpoint. Anche in questo caso, questo cambiamento sul NAD non sarebbe stato riconosciuto dal modulo di postura e le sonde non sarebbero state attivate.

Per ulteriori informazioni su come configurare i load balancer, vedere la Guida all'implementazione di Cisco e F5: ISE Load Balancing con BIG-IP. Offre una panoramica di alto livello e la configurazione specifica F5 di un progetto di best practice per le implementazioni ISE in un ambiente con carico bilanciato.

Caso di utilizzo 5 - Le sonde di rilevamento della fase 2 ricevono una risposta da un server diverso da quello con cui il client viene autenticato (patch precedente alla 2.6, patch 2.7 e 3.0)

Date un'occhiata alle sonde all'interno del riquadro rosso in questo diagramma.

I PSN memorizzano i dati della sessione per cinque giorni, quindi a volte i dati della sessione per una sessione conforme rimangono attivi sul PSN originale anche se il client non esegue più l'autenticazione con tale nodo. Se alle richieste incluse nella casella rossa viene risposto da un PSN diverso da quello che attualmente autentica la sessione e che il PSN ha precedentemente posseduto e contrassegnato come conforme all'endpoint, è possibile che vi sia una mancata corrispondenza tra lo stato di postura del modulo di postura sull'endpoint e il PSN di autenticazione corrente.

Di seguito sono riportati alcuni scenari comuni in cui può verificarsi questa mancata corrispondenza:

- Quando un endpoint si disconnette dalla rete, non viene ricevuta alcuna interruzione di accounting.

- Failover di NAD da un PSN a un altro.

- Un load balancer inoltra le autenticazioni a diversi PSN per lo stesso endpoint.

Per proteggersi da questo comportamento, ISE può essere configurato in modo da consentire solo alle sonde di rilevamento di un particolare endpoint di raggiungere il numero PSN su cui è attualmente autenticato. Per ottenere questo risultato, configurare un criterio di autorizzazione diverso per ogni PSN nella distribuzione. In questi criteri, fare riferimento a un profilo authZ diverso contenente un elenco di controllo di accesso scaricabile (DACL, Downloadable Access Control List) che consente di eseguire le richieste SOLO al numero PSN specificato nella condizione authZ. Vedere questo esempio:

Ogni PSN dispone di una regola per lo stato di postura sconosciuto:

Ogni singolo profilo fa riferimento a un DACL diverso.

Nota: Per le configurazioni wireless, usare gli ACL Airespace.

Ogni DACL consente solo l'accesso probe al PSN che gestisce l'autenticazione.

Nell'esempio precedente, 10.10.10.1 è l'indirizzo IP del PSN 1. Il DACL a cui si fa riferimento può essere modificato per qualsiasi servizio/IP aggiuntivo in base alle esigenze, ma limita l'accesso solo al PSN che gestisce l'autenticazione.

Patch 6, Patch 2 e Patch 3.0 di modifica del comportamento successiva alla 2.6

Lo stato della postura è stato aggiunto nella directory di sessione RADIUS tramite il framework Distribuzione dati luce. Ogni volta che si riceve un aggiornamento dello stato di postura in un PSN, questo viene replicato in TUTTI i PSN della distribuzione. Una volta applicata la modifica, le implicazioni delle autenticazioni e/o delle richieste che raggiungono diversi PSN su diverse autenticazioni vengono rimosse e qualsiasi PSN può rispondere a tutti gli endpoint indipendentemente dal punto in cui sono attualmente autenticati.

Nei cinque casi di utilizzo descritti in questo documento, tenere in considerazione i seguenti comportamenti:

Caso di utilizzo 1 - La riautenticazione del client forza NAD a generare un nuovo ID sessione. Il client è ancora conforme, ma a causa della riautenticazione, NAD si trova nello stato di reindirizzamento (URL di reindirizzamento e elenco degli accessi).

- Il comportamento non cambia e la configurazione può essere ancora implementata su ISE e sui NAD.

Caso di utilizzo 2 - Lo switch è configurato con ordine MAB DOT1X e priorità DOT1X MAB (cablato).

- Il comportamento non cambia e la configurazione può essere ancora implementata su ISE e sui NAD.

Caso di utilizzo 3 - I client wireless eseguono il roaming e le autenticazioni per i diversi access point vengono inviate a controller diversi.

- Il comportamento non cambia e la configurazione può essere ancora implementata su ISE e sui NAD.

Caso di utilizzo 4 - Distribuzioni con load balancer.

- È ancora possibile seguire le best practice definite nella guida al bilanciamento del carico, ma nel caso in cui le autenticazioni vengano inoltrate a diversi PSN dal bilanciamento del carico, è possibile restituire al client lo stato di postura corretto.

Caso di utilizzo 5 - I probe di individuazione della fase 2 ricevono risposta da un server diverso da quello con cui il client viene autenticato

- Questo non può essere un problema con il nuovo comportamento e il profilo di autorizzazione per PSN non è necessario.

Considerazioni sulla gestione dello stesso ID sessione

Quando si utilizzano i metodi elencati in questo documento, un utente che rimane connesso alla rete potrebbe potenzialmente rimanere conforme per lunghi periodi di tempo. Anche se vengono riautenticati, l'ID sessione non cambia e pertanto ISE continua a passare il risultato AuthZ per la regola corrispondente allo stato di conformità.

In questo caso, è necessario configurare la rivalutazione periodica in modo che la postura sia necessaria per garantire che l'endpoint rimanga conforme alle policy aziendali a intervalli definiti.

Questa può essere configurata in Centri di lavoro > Postura > Impostazioni > Configurazioni di rivalutazione.