Il modello di accesso alla rete controllato da ISE

L’obiettivo del network access control (NAC) è impedire che un dispositivo raggiunga la rete prima di aver dimostrato la propria identità. In un’infrastruttura Cisco questo si realizza con tre attori che formano il cosiddetto triangolo AAA:

  • Supplicant — il software sull’endpoint (es. il modulo 802.1X di Windows/Linux o Cisco AnyConnect/Secure Client) che presenta le credenziali.
  • Authenticator — lo switch o il WLC (in IOS-XE) che fa da intermediario e da PEP (Policy Enforcement Point): apre o chiude la porta, applica VLAN, dACL, SGT.
  • Authentication server — Cisco ISE, che agisce da RADIUS server e da PDP (Policy Decision Point).

L’endpoint dialoga con l’authenticator via EAPoL (EAP over LAN) a livello 2, mentre l’authenticator incapsula quelle credenziali dentro RADIUS verso ISE. È fondamentale ricordare: EAP viaggia end-to-end tra supplicant e ISE, lo switch fa solo da relay e non “vede” le credenziali interne.

Il flusso RADIUS

RADIUS usa UDP/1812 (authentication) e UDP/1813 (accounting). Lo scambio segue quattro tipi di messaggio principali:

Messaggio Chi lo invia Significato
Access-Request Authenticator → ISE “Ecco identità/credenziali da valutare”
Access-Challenge ISE → Authenticator Richiesta di ulteriori dati (tipico in EAP multi-step)
Access-Accept ISE → Authenticator Autorizzazione + attributi (VLAN, dACL, SGT…)
Access-Reject ISE → Authenticator Accesso negato

In una sessione EAP, tra Request e Accept c’è tipicamente una serie di Access-Challenge, perché il metodo EAP (PEAP, EAP-TLS…) richiede più round-trip. Gli attributi di autorizzazione arrivano dentro l’Access-Accept sotto forma di RADIUS AV pair (es. Tunnel-Private-Group-ID per la VLAN).

Il CoA (Change of Authorization), su UDP/3799, permette a ISE di modificare o terminare una sessione già attiva senza che l’endpoint si riautentichi da zero: è il meccanismo che rende possibili posture, profiling dinamico e quarantena. Senza CoA abilitato sull’authenticator, funzioni come il re-profiling non applicano il nuovo permesso.

802.1X contro MAB

802.1X è l’autenticazione forte: richiede un supplicant sull’endpoint e valida credenziali (certificati, username/password) tramite EAP. Offre mutua autenticazione (con EAP-TLS) e chiavi crittografiche.

MAB (MAC Authentication Bypass) serve per endpoint senza supplicant — stampanti, telecamere IP, badge reader, dispositivi IoT. Lo switch cattura il MAC address del primo frame e lo invia a ISE come username/password in un normale Access-Request. ISE lo confronta con gli Internal/External Identity Store (endpoint group).

Il fallback sulla porta

L’ordine dei metodi è cruciale. Con la configurazione classica, la porta prova prima 802.1X: attende le risposte EAPoL fino allo scadere dei timer dot1x (per default tx-period 30s × max-reauth-req 2 = circa 90s) e solo allora ricade su MAB. Nelle piattaforme IOS-XE moderne si usano Flexible Authentication (authentication order/priority) o Cisco Identity-Based Networking Services (IBNS 2.0) con policy-map type control subscriber per gestire l’ordine e il fallback in modo deterministico.

Host mode: chi può stare dietro una porta

L’host mode definisce quanti e quali endpoint sono ammessi su una singola porta:

  • single-host — un solo MAC; un secondo MAC genera security violation.
  • multi-domain (MDA) — un endpoint in data domain + uno in voice domain (tipico PC + IP phone).
  • multi-auth — ogni MAC viene autenticato singolarmente (scenario con hub/switch non gestito a valle).
  • multi-host — il primo endpoint autentica la porta e tutti gli altri passano senza autenticazione (poco sicuro).

Trappole tipiche d’esame

  • Scenario: un dispositivo IoT non ha supplicant e deve entrare in rete → risposta: configurare MAB, non 802.1X; MAB non richiede software sull’endpoint.
  • Scenario: “MAB è sicuro quanto 802.1X?” → risposta: no; il MAC è facilmente falsificabile, quindi MAB va rafforzato con il profiling di ISE (device sensor, DHCP/CDP/LLDP probe) e autorizzazioni restrittive.
  • Scenario: l’endpoint MAB impiega circa 90 secondi prima di ottenere accesso → risposta: è l’attesa dei timer dot1x prima del fallback; ridurre tx-period/max-reauth-req o usare authentication order mab dot1x per invertire la priorità.
  • Scenario: ISE aggiorna il profilo di un endpoint ma il permesso non cambia → risposta: manca il CoA (UDP/3799) abilitato sull’authenticator; senza CoA la sessione attiva non viene riautorizzata.
  • Scenario: su una porta MDA arrivano PC e IP phone ma il phone non passa → risposta: serve multi-domain (MDA); single-host ammette un solo MAC e blocca il secondo dominio.
  • Scenario: più MAC dietro uno switch non gestito devono autenticarsi ognuno → risposta: multi-auth, non multi-host (che autenticherebbe solo il primo lasciando passare gli altri).