Il policy set come contenitore ordinato

In Cisco ISE, il Policy Set è l’unità organizzativa che raccoglie, per un determinato scenario di accesso (VPN, wired dot1x, wireless, MAB, guest), tre elementi valutati in sequenza rigorosa top-down:

  1. una condizione d’ingresso (la riga del policy set stesso);
  2. gli Allowed Protocols (o un Server Sequence);
  3. le Authentication Policy e, a seguire, le Authorization Policy interne.

ISE percorre l’elenco dei policy set dall’alto verso il basso e si ferma sul primo la cui condizione d’ingresso fa match. In fondo esiste sempre il Default policy set, che cattura tutto ciò che non ha trovato corrispondenza prima. Questo comportamento “primo match vince” è la chiave per capire quasi tutte le trappole d’esame.

Condizione d’ingresso e allowed protocols

La condizione d’ingresso seleziona lo scenario. Attributi tipici sono RADIUS:NAS-Port-Type (Ethernet vs Wireless-802.11), DEVICE:Device Type, DEVICE:Location, RADIUS:Called-Station-ID o RADIUS:Service-Type. Una volta entrati nel policy set, gli Allowed Protocols definiscono quali metodi EAP/non-EAP ISE è disposto a negoziare: PAP/ASCII per MAB, EAP-TLS, PEAP, EAP-FAST, TEAP, EAP-TTLS.

Punto critico: se il supplicant propone un metodo non incluso nell’allowed protocols, l’autenticazione fallisce prima ancora di consultare l’identity store. Un EAP-TLS che “non parte” è spesso un allowed protocols che non lo abilita, non un problema di certificati.

Authentication: “chi sei” e “dove ti verifico”

La Authentication Policy ha un solo scopo: stabilire l’identità e decidere contro quale identity source validarla. Ogni regola punta a un Identity Source singolo o a un Identity Source Sequence (es. AD, poi LDAP, poi Internal Users). L’output dell’autenticazione non è una decisione di accesso: è un esito (authenticated / failed / dropped) e un’identità da passare alla fase successiva.

Per ogni regola di authentication si configurano tre comportamenti su condizioni particolari:

Opzione Significato Default
If Authentication failed credenziali errate/certificato non valido Reject
If User not found identità assente nello store Reject
If Process failed store irraggiungibile (es. AD down) Drop

Drop non manda un Access-Reject: ISE semplicemente non risponde, così il NAS può fare failover su un altro server RADIUS. Confondere Reject e Drop è un classico item d’esame.

Authorization: “cosa ottieni”

Superata l’autenticazione, ISE valuta la Authorization Policy, sempre top-down. Qui le condizioni sono ricche: AD group membership, risultati di posture, EndPoints:LogicalProfile (profiling), TrustSec, ora del giorno, tipo di device. La regola che matcha per prima assegna un Authorization Profile (o uno Security Group Tag in scenari TrustSec).

L’Authorization Profile è l’insieme concreto di attributi RADIUS restituiti al NAS: Access-Accept con VLAN assignment, dACL (downloadable ACL), Airespace-ACL-Name, URL-redirect per posture o CWA, SGT, reauthentication timer. È qui — e solo qui — che si decide l’accesso effettivo alla rete.

Da ricordare: authentication e authorization sono indipendenti. Un utente può autenticarsi correttamente e comunque ricevere DenyAccess in authorization (es. non appartiene al gruppo AD richiesto). Sono due decisioni separate.

La default rule e l’ordine delle regole

Sia in authorization sia a livello di policy set esiste una regola finale immutabile. In Authorization Policy la Default rule è tipicamente DenyAccess: scatta quando nessuna condizione precedente fa match. DenyAccess è un profilo che produce Access-Reject; l’utente resta fuori dalla rete anche se l’autenticazione era andata a buon fine.

L’ordine è quindi tutto. Le regole vanno scritte dalla più specifica alla più generica: una riga larga posta in cima “consuma” il traffico e impedisce alle righe sottostanti (più mirate) di essere valutate.

Trappole tipiche d’esame

  • Regola generica troppo in alto → una authorization rule con condizione ampia (es. solo AD:ExternalGroups EQUALS Domain Users) messa sopra a una più specifica cattura tutto: la specifica sotto non viene mai raggiunta. Risposta: spostare la regola specifica sopra la generica.
  • Nessun match in authorization → l’utente si autentica ma non ottiene rete. Causa: cade sulla Default rule = DenyAccess. Risposta: aggiungere/riordinare una authorization rule che matchi quella condizione.
  • Metodo EAP che fallisce subito → non è il certificato: il metodo non è negli Allowed Protocols del policy set. Risposta: abilitare EAP-TLS/PEAP nell’allowed protocols.
  • AD irraggiungibile e NAS senza failover → l’opzione If Process failed è impostata su Reject invece di Drop. Risposta: usare Drop per consentire il failover RADIUS.
  • Policy set sbagliato che intercetta il traffico → un policy set con condizione d’ingresso ampia, posto sopra, cattura la sessione prima di quello corretto. Risposta: riordinare i policy set o rendere più specifica la condizione d’ingresso.