Identity Awareness si diagnostica bene solo tenendo separati due ruoli. Il PDP (Policy Decision Point) acquisisce le identità dalle Identity Sources, le concilia e decide chi sta dietro un indirizzo IP; il PEP (Policy Enforcement Point) applica quella decisione al traffico. Su un gateway singolo i due coincidono, in una topologia distribuita no, e quasi tutti i comandi di questo modulo servono a stabilire in quale dei due la catena si interrompe.

Stato dei daemon e canale fra PDP e PEP

pdp status show restituisce lo stato del PDP, fra cui l’ora di avvio e quella di configurazione: un riavvio inatteso spiega da solo una tabella di sessioni vuota. Dal lato opposto, pep show stat mostra l’ultimo avvio del daemon pepd e l’ultimo momento in cui ha ricevuto la policy.

Il canale va guardato da entrambe le estremità. pdp connections pep mostra lo stato della connessione verso tutti i PEP che quel PDP deve aggiornare; pep show pdp, con all o con id, mostra lo stesso canale visto dal PEP. Gli altri sottocomandi di pdp connections coprono le sorgenti esterne: idc elenca gli Identity Collector connessi, ts i Terminal Server.

Leggere le sessioni: chi sta dietro quell’indirizzo

pdp monitor è lo strumento centrale. pdp monitor ip 192.0.2.1 mostra l’utente associato a quell’indirizzo; pdp monitor user parte dal nome dell’utente, machine dal nome del computer, groups dalle sessioni di un gruppo, network accetta una wildcard come 192.168.72.*, all mostra tutte le sessioni connesse e summary i dati aggregati. In diagnosi il sottocomando decisivo è pdp monitor client_type, che filtra per tipo di client — AD Query, Identity Agent, portal, unknown — perché risponde alla sola domanda che conta all’inizio: da dove arriva questa identità.

Sul lato enforcement, pep show user all elenca i client noti al PEP e pep show user query filtra per nome utente, gruppo, ruolo e altri criteri, combinabili in AND fra loro. pep show network pdp e pep show network registration mostrano la tabella di mappatura e quella di registrazione delle reti. Se il PDP conosce la sessione e il PEP no, hai localizzato il guasto senza aprire un debug.

Sorgenti, conciliazione e debug

Le Identity Sources non sono equivalenti. AD Query rileva solo utenti e computer di Active Directory ed è indicata per audit, logging e controllo applicativo; Browser-Based Authentication, nelle varianti Captive Portal e Transparent Kerberos Authentication, serve all’enforcement e non al logging; Identity Agent e Terminal Servers Identity Agent richiedono un client installato ma offrono la precisione più alta; Identity Collector, RADIUS Accounting e Identity Web API coprono grande scala e integrazioni di terze parti.

Per AD Query il punto d’ingresso è adlog, con a sul Security Gateway e l sul Log Server: adlog a dc mostra lo stato della connessione verso il domain controller, adlog a query interroga il database delle identità acquisite, adlog a statistics conta gli eventi ricevuti per indirizzo IP e in totale, adlog a control invia comandi di controllo, adlog a debug accende l’output diagnostico. Se il DC non risponde la verifica si sposta su Windows: servizio Windows Management Instrumentation attivo, credenziali valide, eventi 4624, 4768, 4769 e 4770 nel Security event log, e una regola che permetta ALL_DCE_RPC dal gateway al domain controller.

Quando due sorgenti dichiarano identità diverse per lo stesso IP interviene la Identity Conciliation del PDP, che sceglie fra Override, Reject e Append pesando un punteggio di confidence: Remote Access VPN e Terminal Server Agent 40, Identity Agent 30, Captive Portal 20, Identity Web API 15, Identity Collector e RADIUS 10, AD Query 0. Pesano anche Office Mode, locality e TTL. La configurazione vive nel file pdp_session_conciliation.C sotto $FWDIR/conf/.

Il debug è l’ultimo passo, non il primo: pdp debug on, poi pdp debug set all all, lettura di $FWDIR/log/pdpd.elg, rotazione con pdp debug rotate. Spegnilo con pdp debug off appena chiuso il caso: pesa sulle prestazioni del daemon pdpd.

Trappole tipiche d’esame

Un’identità presente non è un’identità corretta. pdp monitor ip risponde con un nome e la tentazione è fermarsi lì. La domanda successiva è quale sorgente lo abbia fornito: pdp monitor client_type lo dice, e la tabella di confidence spiega perché un’identità da AD Query, che vale zero, viene sostituita da quella di un Identity Agent. Uno scenario in cui «l’utente risulta sbagliato» è spesso conciliazione, non acquisizione fallita.

Se l’identità c’è e la regola non scatta, il problema è l’Access Role. Nessuna quantità di debug del PDP correggerà un ruolo che elenca la rete sbagliata o un gruppo che non contiene quell’utente: i componenti dell’Access Role si sommano, e ne basta uno fuori posto per far mancare il match. Prima di accendere pdp debug, verifica che l’identità soddisfi tutte le condizioni del ruolo.

Il passaggio fra PDP e PEP è un anello a sé. In deployment distribuiti l’identità acquisita dal PDP deve essere condivisa con i PEP, e quel canale si rompe da solo. Se pdp monitor mostra la sessione e pep show user all non la trova, il problema non è nell’Identity Source: controlla pdp connections pep e pep show pdp.