Identity Awareness è un sistema distribuito: il PDP, Policy Decision Point, raccoglie e condivide le identità; il PEP, Policy Enforcement Point, applica le restrizioni di accesso. In una topologia estesa i due ruoli stanno su gateway diversi. Per questo «l’utente non viene riconosciuto» non è una diagnosi ma una famiglia di diagnosi: il PDP può non aver mai appreso l’identità, oppure il PEP può non averla mai ricevuta. Il primo compito è stabilire quale delle due.

Verificare il problema iniziale prima di cambiare qualcosa

Il passo che si salta più spesso è anche quello che rende interpretabile tutto il resto: riprodurre il sintomo in condizioni note e annotarlo. Serve un caso concreto — un indirizzo IP, un nome utente, un orario, la regola che avrebbe dovuto corrispondere e l’esito osservato — prima di aprire qualunque finestra di configurazione. Senza quel riferimento non esiste un «dopo» da confrontare con il «prima», e ogni modifica diventa una scommessa.

Verificare significa anche esaminare il gateway alla ricerca di errori di configurazione, non solo l’ambiente attorno: le sorgenti di identità abilitate, la presenza degli Access Role nella policy installata, lo stato dei demoni. Solo quando il sintomo è riproducibile e circoscritto ha senso formulare un’ipotesi.

I comandi che dicono che cosa il gateway sa già

Sul PDP il primo strumento è pdp monitor. pdp monitor all mostra le informazioni di tutte le sessioni connesse, pdp monitor ip quelle di un indirizzo specifico, pdp monitor user quelle di un nome utente, pdp monitor machine quelle di un computer, pdp monitor groups le sessioni di utenti o computer membri di un gruppo, pdp monitor summary i dati di monitoraggio in forma aggregata. Ci sono anche filtri per tipo di client, per versione del client superiore o inferiore a una soglia, per wildcard di rete e per porta sorgente assegnata nelle sole sessioni MUH. pdp status show riporta le informazioni di stato del PDP, per esempio da quando è attivo e da quando ha la configurazione corrente.

Sul PEP la domanda cambia: non «che cosa so», ma «che cosa mi è arrivato». pep show user all mostra lo stato delle sessioni che il PEP conosce, e pep show user query le filtra per identificatore di connessione, computer, gruppo di computer, PDP, ruolo, gruppo utente, identificativo o nome utente, combinando più filtri in AND. pep show pdp all e pep show pdp id mostrano il canale di comunicazione fra PEP e PDP: è il comando che smaschera il caso in cui il PDP conosce l’utente e il PEP non lo vede. pep show stat riporta l’ultimo avvio del demone pepd e l’ultima policy ricevuta. Completano il quadro pep show network pdp, pep show network registration, pep show topology_map e pep show conciliation_clashes, utile quando due sessioni si contendono lo stesso indirizzo.

Se la sorgente di identità è Active Directory, adlog controlla e monitora la funzione ADLOG e aiuta a seguire lo stato degli utenti.

Debug: solo dopo, e con la pulizia in fondo

Quando i comandi di stato non bastano si passa al debug del demone. pdp debug on lo attiva, pdp debug set all all abilita tutti gli argomenti e tutti i livelli di severità, e l’output finisce in $FWDIR/log/pdpd.elg. pdp debug stat mostra lo stato corrente e pdp debug rotate ruota i file incrementando gli indici. La documentazione avverte esplicitamente che il debug incide sulle prestazioni del demone pdpd: al termine si esegue pdp debug reset e poi pdp debug off. Sul PEP esiste la coppia simmetrica con pep debug.

Per i problemi che vivono nel kernel la procedura R82 va seguita nell’ordine: fw ctl debug 0, fwaccel dbg resetall, fw ctl set int simple_debug_filter_off 1, impostazione dei filtri per tupla, fw ctl debug -buf 8200, verifica con fw ctl debug | grep buffer, abilitazione dei moduli con fw ctl debug -m, raccolta con fw ctl kdebug -T -f -o /var/log/kernel_debug.txt, riproduzione del problema, CTRL+C e ripetizione dei tre reset. Fra i moduli kernel disponibili c’è IDAPI, dedicato alle API di identità.

Chiuso il debug il ciclo non è finito: si ripete il test iniziale, nelle stesse condizioni, e si confronta l’esito con quello annotato all’inizio.

Trappole tipiche d’esame

Riconfigurare prima di aver verificato. È l’errore che il vendore mette per primo su questo modulo. Nelle domande a scenario la sequenza corretta comincia quasi sempre con un comando di osservazione — pdp monitor ip, pep show user, pep show pdp — non con una modifica in SmartConsole. Se una risposta parte disabilitando e riabilitando Identity Awareness, di norma è l’esca.

Non guardare il gateway. Cercare la causa solo nella sorgente di identità o nel client, senza esaminare il gateway alla ricerca di errori di configurazione, lascia fuori proprio il punto in cui PDP e PEP si parlano. pep show pdp e pep show stat servono a questo.

Dichiarare risolto senza ripetere il test. Una modifica alle regole non è una verifica: finché non hai rifatto la prova con le nuove regole e con lo stesso caso concreto di partenza, non sai se è cambiato il comportamento o soltanto la configurazione.