Il modulo M8 si gioca su tre laboratori consecutivi che descrivono un metodo prima ancora di una tecnologia: esaminare, correggere, riprovare. Chi salta il primo o il terzo passo è segnalato per nome dal corso ufficiale, ed è lì che l’esame costruisce le sue domande.

Fotografare il gateway prima di toccarlo

Il lab parte da un sintomo: una regola che usa un Access Role non lascia passare — o non blocca — il traffico atteso. La tentazione è aprire subito il wizard di Identity Awareness, ma una riconfigurazione cancella le prove del guasto.

Si comincia dai daemon: cpwd_admin list dice se pdpd e pepd sono vivi e da quando. Poi si guarda che cosa il gateway crede di sapere sugli utenti. Sul Policy Decision Point, pdp monitor all elenca le sessioni note, pdp monitor ip e pdp monitor user restringono al caso del lab, pdp monitor client_type separa AD Query, Identity Agent, portal e unknown, pdp monitor summary dà il quadro d’insieme. Sul Policy Enforcement Point, pep show user mostra le sessioni effettivamente ricevute, pep show pdp il canale verso il PDP, pep show network la mappatura rete-PDP e pep show stat l’ultima policy arrivata.

Lo scarto fra i due comandi è già una diagnosi: se il PDP vede l’utente e il PEP no, il guasto è nella distribuzione delle identità, non nella loro acquisizione. pdp connections pep, pdp connections idc e pdp connections ts dicono quali PEP, Identity Collector e Terminal Server sono realmente connessi.

Con AD Query il quadro si completa con adlog a dc per lo stato dei domain controller, adlog a statistics per gli eventi NT ricevuti e adlog a query per il database delle identità acquisite. Per scendere di livello, pdp debug set all all seguito da pdp debug on scrive in $FWDIR/log/pdpd.elg e pep debug set all all in $FWDIR/log/pepd.elg; un pdp debug rotate prima della riproduzione separa il caso dal rumore precedente.

Riconfigurare solo ciò che l’esame ha indicato

La riconfigurazione parte da SmartConsole: Gateways & Servers, doppio clic sul Security Gateway o sul Cluster, scheda Network Security, voce Identity Awareness. Alla prima abilitazione si apre il wizard, che propone AD Query, Browser-Based Authentication e Terminal Servers; le altre sorgenti si aggiungono dopo. AD Query chiede credenziali di amministratore di dominio per leggere i log di sicurezza dei domain controller; Browser-Based Authentication chiede l’IP su cui pubblicare il captive portal.

Scegliere la sorgente è metà del troubleshooting, perché ciascuna ha un limite dichiarato. AD Query è la più semplice ma vede solo utenti e computer di Active Directory ed è pensata per audit, logging e enforcement interno. Browser-Based Authentication copre ospiti e client non-AD, però pretende un’azione dell’utente e non è consigliata per il logging. Identity Agent dà SSO e la precisione che serve davanti ai server sensibili; Identity Collector scala sugli ambienti grandi e integra Active Directory, Cisco ISE e NetIQ eDirectory; il Terminal Servers Identity Agent è l’unico che distingue più utenti dietro un solo IP. Un lab in cui «spariscono» gli utenti Citrix non si risolve girando manopole su AD Query.

Dal lato policy l’oggetto da verificare è l’Access Role, che raccoglie Networks, Users and user groups, Computers and computer groups e Remote Access Clients e si usa come Source o Destination nella Access Control Rule Base. Costruito sul gruppo sbagliato produce lo stesso identico sintomo di un’identità mancante. Dopo ogni modifica va installata la policy: senza install, pep show stat mostrerà ancora la vecchia ora di ricezione.

Provare le nuove regole e chiudere il ciclo

Il terzo lab non è una formalità. Si ripete lo stesso test iniziale — stesso utente, stessa postazione, stesso servizio — e si verifica su tre piani: il traffico passa o viene bloccato come previsto; pep show user e pdp monitor ip mostrano l’identità attesa con il client type giusto; il log in Logs & Monitor riporta il nome utente e la regola corretta. Se l’identità c’è ma la regola non scatta, il difetto è nell’Access Role o nell’ordine delle regole, non in Identity Awareness.

Quando il risultato resta ambiguo si scende al pacchetto con fw monitor, ricordando che i filtri INSPECT non si applicano al traffico accelerato. A fine lab si spengono i debug e si riacquisisce la sessione utente con logout e nuovo login, per escludere una cache.

Trappole tipiche d’esame

Riconfigurare prima di aver verificato. È l’errore che il vendore cita per primo. Aprire il wizard di Identity Awareness cancella lo stato che avrebbe spiegato il guasto: dopo, pdp monitor e pep show user raccontano la nuova configurazione, non il problema. Nelle domande a scenario, la risposta che «riconfigura» come primo passo è quasi sempre il distrattore.

Non esaminare il gateway. Molte tracce mettono l’errore nel gateway e non nella sorgente: un daemon fermo in cpwd_admin list, un PEP che non riceve policy, una sorgente abilitata nel wizard ma senza prerequisiti. Chi parte dall’Active Directory salta il punto in cui il difetto è visibile.

Dichiarare risolto senza riprovare. Vedere l’identità in pdp monitor non significa che la regola scatti: il test va ripetuto nelle stesse condizioni e confermato dal log. Una risposta che si ferma alla correzione è incompleta anche quando la correzione è giusta.