Il profiling consente a ISE di scoprire, classificare e assegnare un tipo (endpoint type) a ogni dispositivo che si connette alla rete, basandosi su attributi raccolti da più probe (DHCP, RADIUS, HTTP, SNMP, NMAP, DNS, NetFlow, AD). Il vero valore del profiling in ottica di authorization emerge quando lo si combina con la Change of Authorization (CoA): un endpoint può essere riclassificato dopo l’autenticazione, e ISE deve poter aggiornare il suo livello di accesso senza attendere una nuova sessione.

Perché serve la CoA nel profiling

Quando un endpoint si autentica, il profiling potrebbe non avere ancora abbastanza attributi per una classificazione precisa. Un dispositivo può presentarsi inizialmente come Unknown o come profilo generico e solo qualche secondo dopo, raccolti gli attributi DHCP o HTTP User-Agent, essere promosso a un profilo specifico (es. da generico a Cisco-IP-Phone). Senza CoA, quel dispositivo resterebbe con l’autorizzazione ottenuta al momento della prima authentication. La CoA permette a ISE di inviare al Network Access Device (switch, WLC) un messaggio RADIUS che forza la riautorizzazione della sessione, applicando la policy corrispondente al nuovo profilo.

Global CoA e tipi di CoA

La configurazione della CoA per il profiling è globale e si imposta in Administration > System > Settings > Profiling. I valori disponibili sono:

Tipo CoA Comportamento
No CoA Default. Il profiling aggiorna il profilo nel database ma non riautorizza sessioni già attive.
Port Bounce ISE forza il bounce della porta (shut/no shut). Utile per far ripartire il DHCP e rieseguire la sessione da zero. Usato tipicamente con un solo endpoint per porta.
Reauth ISE invia una CoA di reauthentication: la sessione viene riautorizzata mantenendo la connettività L2, senza bounce fisico della porta.

Attenzione al default: se la global CoA resta su No CoA, la riprofilazione non produce alcun cambiamento di accesso in tempo reale; l’endpoint riprofilato otterrà la nuova policy solo alla successiva riautenticazione naturale.

Esiste anche il controllo per profilo, tramite l’attributo del profiler policy (“Create an Identity Group for the policy” / associazione a un Endpoint Identity Group) e le opzioni CoA granulari a livello di regola di profiling.

Costruire l’authorization basata sul profilo

Le authorization rule possono usare tre livelli di granularità legati al profiling:

  • Endpoint Identity Group: gruppo statico o popolato dinamicamente (es. Cisco-IP-Phone, Workstation, Profiled). Condizione tipica: IdentityGroup:Name EQUALS Endpoint Identity Groups:Profiled:Cisco-IP-Phone.
  • Logical Profile: raggruppa più profili sotto un’etichetta funzionale (es. un logical profile IP-Phones che aggrega Cisco, Avaya, Polycom). Condizione: EndPoints:LogicalProfile EQUALS IP-Phones. È il modo più scalabile e resiliente ai cambi di modello.
  • Device Type / attributi endpoint: es. EndPoints:EndPointPolicy, oppure attributi come DeviceRegistrationStatus.

Esempio concettuale di regola: se il logical profile è IP-Phones → assegna la DACL o il VLAN voice e un permesso di rete ristretto; se l’endpoint è in Workstation con posture Compliant → accesso pieno; altrimenti → VLAN di quarantena/remediation.

Rule: Voice-Access
  Condition: EndPoints:LogicalProfile EQUALS IP-Phones
  Result:    PermitAccess + Voice-DACL + Voice-Domain

Il vantaggio del logical profile è che aggiungere un nuovo modello di telefono richiede solo di mapparlo al logical profile, senza toccare le authorization rule.

Trappole tipiche d’esame

  • Scenario: un endpoint viene riprofilato ma il suo accesso non cambia mai finché non si riconnette. → Risposta giusta: la global CoA è impostata su No CoA; va cambiata in Reauth (o Port Bounce) perché la riprofilazione riautorizzi la sessione attiva.
  • Scenario: dopo aver abilitato la CoA, le sessioni entrano in flapping continuo (autorizzazioni che cambiano ripetutamente). → Risposta giusta: causato da profiling non stabilizzato o da CoA troppo aggressiva; preferire Reauth invece di Port Bounce, evitare Port Bounce dove ci sono più endpoint per porta (bounceresti tutti), e assicurarsi che le regole non si contendano la classificazione.
  • Scenario: l’authorization rule usa un Endpoint Identity Group ma i dispositivi cadono nella regola di default perché il profiling non è ancora completo al momento dell’auth. → Risposta giusta: prevedere una regola per lo stato iniziale (accesso limitato per Unknown/Profiled generico) e affidarsi alla CoA per riautorizzare a profiling completato; non condizionare l’accesso critico a un profilo che potrebbe non essere ancora disponibile al primo passaggio.
  • Scenario: si vuole che una nuova marca di telefono ottenga automaticamente la voice policy senza modificare le regole. → Risposta giusta: usare un Logical Profile che aggrega i profili telefono; la regola punta al logical profile, non al singolo EndPointPolicy.
  • Scenario: Port Bounce non riporta l’endpoint con il nuovo accesso su un access point wireless. → Risposta giusta: Port Bounce è pensato per switch cablati; su wireless usare Reauth (il bounce fisico della porta non ha senso per una sessione Wi-Fi gestita dal WLC).