Sapere a che cosa serve Identity Awareness non basta per questo modulo. L’esame chiede i due oggetti concreti con cui l’identità entra in produzione — l’Identity Collector che la raccoglie e l’Access Role che la porta dentro una regola — e il punto esatto in cui i due si incontrano nell’Access Control Policy.

Identity Collector: un agent su Windows Server

La documentazione R82 lo descrive come un client agent dedicato installato su Windows Server nella rete. Raccoglie informazioni di identità e di indirizzo IP da più Identity Sources, organizzate in Query Pool: ogni pool si collega a un Identity Awareness Gateway, che riceve ed elabora i dati raccolti per il controllo degli accessi e per l’auditing.

Tre dettagli distinguono chi ha letto da chi ha intuito. Primo: gira su Windows Server, non sul Security Gateway e non sul Security Management Server. Secondo: il confronto fra le fonti di acquisizione lo indica per gli ambienti su larga scala con domain controller Microsoft Active Directory, e annota che è gestito localmente e che richiede i permessi Event Log Readers. Terzo: è un agent, quindi appartiene alle fonti che richiedono un componente installato, a differenza di AD Query o della Browser-Based Authentication, che non ne richiedono.

La configurazione di dettaglio dell’agent non sta nella guida Identity Awareness ma nell’Identity Awareness Clients Administration Guide: è un rimando da ricordare, perché spiega perché certe opzioni non si trovano in SmartConsole.

Access Role: quattro condizioni in un oggetto solo

L’Access Role si crea dall’Object Explorer di SmartConsole — scorciatoia Ctrl+E — con New > User / Identity > Access Role. Dopo il nome e un commento facoltativo, l’oggetto si definisce su quattro schede.

Networks: Any network, oppure Specific networks da aggiungere.

Users: Any user; All identified users, cioè gli utenti identificati da un metodo di autenticazione supportato; oppure utenti e gruppi specifici.

Machines: Any machine; All identified machines, cioè i computer identificati da un metodo supportato; oppure macchine e gruppi specifici. Qui è disponibile anche l’opzione Enforce IP Spoofing protection per i computer con Full Identity Agent.

Remote Access Clients: Any Client oppure Specific Client, selezionando un client esistente o creandone uno nuovo.

L’errore di lettura più frequente è trattare l’Access Role come un semplice gruppo di utenti importato da Active Directory. Non lo è: è un oggetto che porta con sé anche una condizione di rete, una di macchina e una di client di accesso remoto. Lasciare Any network e Any machine è una scelta consapevole, non un valore neutro da ignorare.

L’incontro con la policy: Source, Destination e la cella Action

Una volta creato, l’Access Role si usa nelle colonne Source e Destination delle regole dell’Access Control Policy. È lì che l’identità smette di essere informazione e diventa enforcement: la stessa regola che prima elencava subnet ora nomina ruoli.

Resta il caso dell’utente ancora sconosciuto. Se tutti i campi della regola combaciano tranne il campo Source che contiene un Access Role, e il traffico è HTTP, il gateway può reindirizzare l’utente non autenticato al Captive Portal perché si identifichi. Non è un’azione a sé stante: nella regola con un Access Role nel campo Source si fa tasto destro sulla cella Action e si sceglie More; si apre la finestra Action Settings, dove nel campo Action si seleziona Accept, Ask o Inform e in fondo si spunta la casella Enable Identity Captive Portal. La cella risultante si legge nella forma Accept (display Captive Portal), Ask (display Captive Portal) o Inform (display Captive Portal). Dopo l’autenticazione l’identità è nota e il gateway applica subito l’azione della regola, senza ulteriori reindirizzamenti.

Chiude il ciclo l’installazione della policy: finché non viene installata, l’oggetto esiste in SmartConsole ma non esiste sul gateway.

Trappole tipiche d’esame

  • «Any user» e «All identified users» non sono sinonimi. All identified users copre gli utenti identificati da un metodo di autenticazione supportato: chi nessuna fonte riesce a identificare resta fuori. Una regola che «non si applica a nessuno» è spesso un Access Role che chiede identità in una rete dove nessuna Identity Source la fornisce.
  • Le altre schede dell’Access Role continuano a valere. Un Access Role corretto sugli utenti ma vincolato a Specific networks non copre il traffico che arriva da un’altra rete, per esempio dai client di accesso remoto. Prima di sospettare il gruppo, si riaprono le schede Networks, Machines e Remote Access Clients.
  • Il Captive Portal non è una voce della colonna Action. Non si cerca un’azione «Redirect»: si sceglie Accept, Ask o Inform e si spunta Identity Captive Portal. E il reindirizzamento riguarda il traffico HTTP, quindi non è la risposta giusta per un client che non naviga.
  • Identity Collector non si configura dal gateway. È un agent su Windows Server, gestito localmente, con i propri Query Pool e il requisito dei permessi Event Log Readers. Una domanda che chiede dove si aggiunge il domain controller da cui leggere gli eventi non ha risposta in SmartConsole.
  • Un Query Pool si collega a un Identity Awareness Gateway. Se un gateway non riceve identità, si guarda prima a quale pool è associato: il sintomo di un problema di comunicazione con la fonte è identico a quello di una regola scritta male, ma la causa e il rimedio sono altrove.
  • Oggetto creato non è policy installata. L’Access Role appena definito, come la fonte appena aggiunta, entra in vigore solo con l’installazione della policy.