Il BYOD onboarding in Cisco ISE permette a un dipendente di registrare autonomamente un dispositivo personale, installare il native supplicant e ottenere un certificato utente/dispositivo, così da passare da una connessione debole (username/password) a una robusta basata su EAP-TLS. ISE supporta due topologie: single-SSID e dual-SSID. La scelta dipende dall’infrastruttura wireless e dall’esperienza utente desiderata, ma la logica di authorization policy e di client provisioning resta il cuore del funzionamento.

Il flusso single-SSID

Nel modello single-SSID esiste un’unica WLAN 802.1X che gestisce sia l’onboarding sia l’accesso finale. Il ciclo tipico:

  1. L’utente si connette alla WLAN sicura autenticandosi con PEAP-MSCHAPv2 (username e password AD).
  2. La regola di authorization riconosce che il dispositivo non è ancora registrato e restituisce un redirect al BYOD portal con relativo url-redirect-acl.
  3. L’utente lancia il Network Setup Assistant / Supplicant Provisioning Wizard (SPW), che configura il profilo 802.1X e installa il certificato (via SCEP verso la CA interna di ISE).
  4. ISE invia una CoA (Change of Authorization) che forza il re-auth sulla stessa SSID.
  5. Alla nuova autenticazione il dispositivo presenta il certificato in EAP-TLS; ora BYOD_Registered = true e la policy concede accesso completo.

Vantaggio: una sola WLAN, transizione trasparente. Requisito critico: la CoA di re-auth deve funzionare, altrimenti il client resta bloccato nello stato di onboarding.

Il flusso dual-SSID

Nel modello dual-SSID si usano due WLAN distinte:

SSID Scopo Autenticazione
Open/Guest Onboarding MAB → Central Web Auth (CWA) + BYOD flow
Secure Accesso produzione 802.1X / EAP-TLS

Il dispositivo si aggancia prima alla SSID aperta: ISE, tramite MAB, restituisce un redirect al guest/BYOD portal. L’utente si autentica, esegue il provisioning del supplicant e installa il certificato, poi il wizard configura automaticamente il profilo per la SSID sicura. Il client si sposta sulla WLAN 802.1X e completa l’accesso con EAP-TLS.

Vantaggio: separazione netta fra rete di onboarding e rete produttiva; utile quando il WLC non gestisce bene la CoA di re-auth sulla stessa SSID. Svantaggio: l’utente deve percepire (o il wizard automatizzare) il cambio di rete.

Client Provisioning e My Devices Portal

La Client Provisioning Policy è la tabella che, in base a sistema operativo, gruppo AD, risultato di posture o tipo di dispositivo, decide quale risorsa distribuire (agent, wizard, profilo). Per il BYOD la risorsa chiave è il Native Supplicant Profile (NSP), che definisce SSID target, tipo di sicurezza e protocollo (tipicamente TLS). Il Network Setup Assistant scaricato è specifico per OS: Windows, macOS, iOS, Android hanno wizard differenti.

Il My Devices Portal dà all’utente finale il controllo del proprio parco dispositivi registrati: aggiungere manualmente un endpoint, marcarlo come Lost/Stolen (che lo sposta nel Blacklist identity group, revocando l’accesso), reintegrarlo o eliminarlo. È lo strumento self-service che riduce il carico sull’help desk.

Separare “registrato” da “in onboarding”

La regola d’oro dell’authorization BYOD: servono due stati distinti. Una regola intercetta i dispositivi non ancora registrati (esito: redirect al BYOD portal); un’altra riconosce quelli già provisioned con certificato valido (esito: PermitAccess). Confondere i due stati produce redirect loop o accessi indebiti.

Trappole tipiche d’esame

  • Client Provisioning Policy non allineata all’OS → il wizard non viene distribuito e l’onboarding fallisce con “no client provisioning resource matched”. Risposta: creare/verificare una regola di provisioning che matchi l’OS reale dell’endpoint e la risorsa NSP corretta.
  • Authorization che non distingue registered da onboarding → l’endpoint con certificato continua a essere rediretto (loop). Risposta: aggiungere la condizione BYOD_Registered EQUALS true (o EAP-TLS + certificato) in una regola più prioritaria che concede PermitAccess.
  • Single-SSID senza CoA → dopo l’installazione del certificato il client resta in stato di onboarding. Risposta: garantire la CoA re-auth e il corretto url-redirect-acl sul WLC.
  • Dual-SSID con 802.1X sulla SSID di onboarding → il flusso corretto usa MAB + CWA sulla SSID aperta; usare 802.1X vanifica lo scopo. Risposta: SSID open con MAB per l’onboarding, secure con EAP-TLS per la produzione.
  • Redirect ACL mancante o errato sul WLC → il traffico verso il portal non viene reindirizzato. Risposta: definire l’ACL di redirect che permette DNS/DHCP e traffico verso ISE, negando il resto fino al provisioning.