Il problema: autenticare chi non ha un supplicant

In molti scenari reali un endpoint si collega alla rete cablata o wireless senza un supplicant 802.1X configurato e senza credenziali machine. Pensa a un ospite in sala riunioni, a un consulente con il proprio laptop o a un dispositivo BYOD non ancora onboarded. Per questi casi Cisco ISE usa la Web Authentication: l’utente viene intercettato e portato su un portale web dove inserisce le proprie credenziali. La variante più diffusa e flessibile è la Central Web Authentication (CWA), in cui il portale è ospitato direttamente sul PSN (Policy Service Node) di ISE.

Il flusso CWA passo per passo

CWA parte quasi sempre da un MAB (MAC Authentication Bypass) fallito o “continuato”. La sequenza è la seguente:

  1. L’endpoint si collega, il NAD (switch o WLC) non vede 802.1X e ripiega su MAB, inviando il MAC address in un Access-Request RADIUS a ISE.
  2. Il MAC non è noto (o corrisponde a una regola guest): ISE non nega l’accesso ma risponde con un Access-Accept che contiene gli attributi per il redirect. Concettualmente ISE dice “accettato, ma con permessi limitati e traffico web da dirottare”.
  3. Gli attributi restituiti sono due elementi distinti e complementari:
    • cisco-av-pair url-redirect — l’URL del portale sul PSN (contiene FQDN, porta 8443 e il sessionId).
    • cisco-av-pair url-redirect-acl — il nome della redirect ACL che decide quale traffico dirottare verso il portale.
    • Opzionalmente una dACL (downloadable ACL) che definisce cosa l’endpoint può effettivamente raggiungere in questa fase pre-autenticazione.
  4. Lo switch applica il redirect: il traffico HTTP/HTTPS dell’utente viene reindirizzato al portale di ISE. L’utente inserisce le credenziali (guest, sponsor, self-registration…).
  5. Superata l’autenticazione al portale, ISE deve cambiare i permessi senza far riconnettere l’utente: invia quindi una CoA (Change of Authorization) al NAD.
  6. La CoA (tipicamente CoA-Reauth) forza il NAD a rilanciare l’autorizzazione. La sessione viene rivalutata dall’authorization policy, che ora — grazie agli attributi post-login (guest flow, group, ecc.) — matcha una regola diversa e assegna il profilo finale: VLAN guest, dACL permissiva, o accesso pieno.

Il punto chiave d’esame è che la CoA è ciò che chiude il cerchio: senza di essa l’utente resterebbe bloccato nello stato di redirect anche dopo aver inserito le credenziali corrette.

Central Web Auth vs Local Web Auth

Aspetto Central Web Auth (CWA) Local Web Auth (LWA)
Dove risiede il portale Sul PSN di ISE Sul NAD (switch/WLC)
Meccanismo di riautorizzazione CoA da ISE Nessuna CoA nativa; il NAD gestisce localmente
Personalizzazione portale Centralizzata, coerente su tutta la rete Per singolo NAD, meno scalabile
Funzioni avanzate (posture, BYOD, profiling) Supportate Limitate/assenti
Sessione RADIUS Mantiene lo stesso sessionId end-to-end Spezzata tra web-auth locale e RADIUS

CWA è la scelta preferita in deployment ISE perché è centralizzata, scalabile e abilita l’intero ecosistema (posture, device registration, self-service). LWA sopravvive in scenari legacy o dove il portale deve funzionare anche se il PSN è irraggiungibile.

Redirect ACL vs dACL: la distinzione critica

Questi due oggetti vengono spessissimo confusi ed è il cuore delle trappole d’esame:

  • La redirect ACL è definita localmente sullo switch/WLC. ISE ne trasmette solo il nome; il contenuto deve già esistere sul NAD. Il suo permit significa “dirotta questo traffico verso il portale”, il deny significa “non dirottare” (lascialo passare secondo la dACL).
  • La dACL viene scaricata da ISE e definisce il vero permesso di forwarding.
ip access-list extended REDIRECT-ACL
 deny   udp any any eq domain
 deny   ip any host <PSN-IP>
 permit tcp any any eq www
 permit tcp any any eq 443

Nota la logica invertita: il deny ip any host <PSN-IP> serve proprio a non reindirizzare il traffico diretto al PSN, altrimenti il portale non sarebbe mai raggiungibile.

Trappole tipiche d’esame

  • Scenario: l’utente resta sul portale e dopo il login non ottiene l’accesso finale. → Manca la CoA o il NAD non è configurato come RADIUS client CoA (porta UDP 1700, shared secret): senza CoA non avviene la riautorizzazione.
  • Scenario: la redirect ACL è configurata solo su ISE. → Sbagliato. La redirect ACL è locale sul NAD; ISE invia solo il nome. Se il nome non corrisponde a un’ACL esistente sullo switch, il redirect fallisce.
  • Scenario: il portale ISE non si apre / loop di redirect. → La redirect ACL non consente (non fa “deny”) il traffico verso il PSN: bisogna escludere l’IP del PSN e il DNS dal reindirizzamento, altrimenti anche le richieste al portale vengono dirottate.
  • Scenario: distinguere redirect ACL e dACL. → La redirect ACL decide cosa dirottare (permit = redirect), la dACL decide cosa è permesso. Sono due oggetti separati con semantiche opposte.
  • Scenario: portale su ISE o sul NAD? → Se il requisito cita posture, BYOD o coerenza centralizzata, la risposta è CWA (portale sul PSN), non LWA.