Il sponsor portal di Cisco ISE è l’interfaccia web attraverso cui personale interno autorizzato (receptionist, IT helpdesk, line manager) crea e gestisce gli account per gli ospiti, senza dover toccare la GUI amministrativa di ISE. È il fulcro del guest access credentialed: il visitatore riceve credenziali reali (username/password) generate da uno sponsor, in alternativa ai flussi self-registration o hotspot.
Chi può fare cosa: sponsor group e permessi
L’autorizzazione dello sponsor è governata da due costrutti distinti che vanno tenuti separati:
- Sponsor group: definisce cosa può fare uno sponsor una volta autenticato. Contiene i permessi granulari — quali guest type può assegnare, se può creare account singoli, in bulk o via import CSV, quali colonne vede, e su quali account può operare (solo i propri, quelli del gruppo, o tutti).
- Sponsor portal: definisce come lo sponsor si autentica e l’esperienza (autenticazione, layout, notifiche). Un portale è associato a un identity source sequence.
La logica di ingresso è: lo sponsor si autentica al portale → ISE lo mappa a uno sponsor group in base ai suoi gruppi di appartenenza → i permessi di quel group determinano l’operatività.
Autenticazione via Active Directory
Nella stragrande maggioranza dei deployment gli sponsor sono utenti di dominio: il portale usa un identity source sequence che punta ad Active Directory (via AD join point), e la mappatura allo sponsor group avviene sulla base dei gruppi AD. Esempio: gli utenti del gruppo AD Helpdesk finiscono nello sponsor group ALL_ACCOUNTS, mentre Reception finisce in GROUP_ACCOUNTS con permessi ridotti. Questa mappatura è la condizione di membership dello sponsor group ed è il punto dove si commettono gli errori più gravi (vedi trappole).
Guest type e durata
Il guest type è il template che definisce le proprietà temporali e di accesso dell’account:
| Attributo | Ruolo |
|---|---|
| Maximum Access Time | Durata massima concedibile (es. 8 ore, 5 giorni, 90 giorni) |
| Login/Endpoint options | Numero max di device simultanei, logout on inactivity |
| Sponsor groups che possono usarlo | Limita chi può creare account di quel tipo |
Guest type tipici predefiniti sono Contractor (durata lunga, es. 1 anno), Daily e Weekly. Uno sponsor può impostare la validità dell’account solo entro i limiti fissati dal guest type — non oltre.
Ciclo di vita dell’account guest
Gli stati attraversati da un account seguono una sequenza precisa, spesso oggetto di domande:
- Created — lo sponsor genera l’account; stato iniziale tipico Awaiting Initial Login (non ancora usato).
- Notification — le credenziali sono consegnate al guest via email, SMS o stampa. Richiede SMTP/SMS gateway configurati.
- Active — dopo il primo login riuscito, l’account è attivo e valido fino alla scadenza.
- Suspended — lo sponsor (o l’admin) può sospendere manualmente un account, bloccando l’accesso senza cancellarlo; è reinstatable.
- Expired — al superamento del maximum access time / end date l’account scade e non consente più il login (CoA lo disconnette).
- Purge — gli account scaduti non vengono rimossi automaticamente alla scadenza: restano nel database finché la Guest Purge Policy (schedulata, default ogni 15 giorni) li elimina definitivamente. Purge ≠ Expire.
Integrazione con CWA
Le credenziali guest vengono validate nel flusso Central Web Authentication (CWA): lo switch/WLC reindirizza il traffico non autenticato al guest portal, il guest inserisce le credenziali create dallo sponsor, ISE le valida e invia un CoA per applicare l’autorizzazione finale (VLAN/dACL). Sponsor portal e guest portal sono quindi due facce dello stesso processo.
Trappole tipiche d’esame
- Scenario: uno sponsor di reception riesce a creare account Contractor da 1 anno pur dovendo emettere solo pass giornalieri → il suo sponsor group ha permessi troppo ampi (guest type consentiti non ristretti). Risposta: limitare i guest type assegnabili nello sponsor group, non nel guest type stesso.
- Scenario: nuovi utenti AErrore comune. Uno sponsor autentica ma non vede opzioni per creare account → manca la mappatura tra il suo gruppo AD e uno sponsor group. Senza match, l’accesso al portale è negato o privo di permessi.
- Scenario: account guest scaduti continuano ad accumularsi nel database → confusione tra Expire e Purge. La rimozione avviene solo con la Guest Purge Policy schedulata, non alla scadenza.
- Scenario: si vuole bloccare temporaneamente un ospite mantenendo l’account → usare Suspend (reversibile), non delete/purge.
- Scenario: le credenziali non arrivano al guest → verificare SMTP/SMS gateway e le notification settings del portale; senza di essi la fase di notification fallisce anche se l’account è creato correttamente.