I due laboratori di questo modulo lavorano in coppia. Il primo mette in scena un attore che si comporta come non dovrebbe; il secondo chiede di spiegare perché la policy non lo tratta come previsto. La difficoltà non sta nei comandi, che hai già visto: sta nell’ordine con cui li usi e nella disciplina con cui registri quello che vedi.

Preparare il banco prima di attivare il sintomo

Un laboratorio di Identity Awareness senza stato iniziale registrato produce diagnosi non falsificabili. Prima di toccare qualsiasi cosa serve una regola che usi davvero l’identità e un modo per osservarla.

L’oggetto che porta l’identità nella policy è l’Access Role, che si crea in SmartConsole da New > More > User/Identity > Access Role e può contenere quattro componenti: Networks, Users, Machines e Remote Access Clients. Si usa nelle colonne Source e Destination dell’Access Control Policy e richiede la Software Blade Identity Awareness attiva sul gateway. Perché il laboratorio produca prove, la regola deve anche avere un valore nella colonna Track diverso da None: senza log non c’è niente da leggere.

Fissa la baseline con pdp monitor all e pep show user all prima dell’attivazione, e tienila da parte. È l’unico modo per distinguere, dopo, ciò che il laboratorio ha cambiato da ciò che era già così.

Lab: Activate the Bad Actor

L’attivazione produce un sintomo osservabile: traffico che passa e non dovrebbe, o che viene bloccato e non dovrebbe. La prima lettura si fa nel log, e ha tre esiti che aprono tre strade diverse.

Nessun evento per quella connessione: il match è avvenuto su un’altra regola, più in alto nella rule base, oppure la regola che ha deciso non traccia. Sei in un problema di policy, non di identità.

Evento presente ma senza utente: al momento della decisione il gateway non aveva un’identità per quell’indirizzo. Sei in un problema di acquisizione o di condivisione.

Evento con l’utente atteso, ma abbinato alla regola sbagliata: l’identità è arrivata e il problema sta nella definizione dell’Access Role o nell’ordine delle regole.

Un avvertimento che vale per tutti e tre: il campo utente nel log dice che un’identità è stata associata alla connessione, non quale sorgente l’abbia fornita né quanto valga.

Lab: Troubleshoot Identity Awareness, la catena in ordine

Percorri gli anelli sempre nello stesso ordine, e fermati appena uno risponde male.

Esiste un’identità per quell’IP? pdp monitor ip con l’indirizzo. Se non c’è nulla, il resto della catena è irrilevante.

Da dove viene? pdp monitor client_type distingue AD Query, Identity Agent, portal e unknown. La risposta cambia sia l’affidabilità dell’identità sia il punto in cui continuare a cercare.

Il PEP la conosce? pep show user all, oppure pep show user query con un filtro. Se il PDP la vede e il PEP no, guarda il canale: pdp connections pep da una parte, pep show pdp dall’altra.

L’Access Role corrisponde? I quattro componenti del ruolo vanno soddisfatti insieme: una rete elencata male basta a far fallire il match anche con l’utente giusto.

Solo adesso il debug. pdp debug on, pdp debug set all all, lettura di $FWDIR/log/pdpd.elg, e pdp debug off appena chiuso il caso, perché il debug pesa sul daemon pdpd. Per un problema di AD Query, adlog a dc e adlog a statistics dicono in due comandi se il domain controller risponde e se gli eventi arrivano davvero.

Annota per ogni anello il comando eseguito e la riga di output che hai usato per decidere. Una diagnosi che non sai rifare non è una diagnosi.

Trappole tipiche d’esame

Il nome nel log non è la prova che cerchi. Lo scenario tipico mostra un log con un utente e chiede perché la regola si comporta in modo strano. La risposta quasi mai è «l’identità manca»: più spesso l’identità c’è ma viene da una sorgente diversa da quella che immagini, e la conciliazione del PDP ha preferito o scartato una sessione. Verifica sempre la sorgente con pdp monitor client_type prima di concludere.

Un ruolo mal definito somiglia moltissimo a un’acquisizione fallita. Sintomo identico — il traffico dell’utente non incontra la regola attesa — ma causa e rimedio opposti. Se pdp monitor ip restituisce l’utente con i suoi gruppi, l’acquisizione funziona, e continuare a indagare sulle Identity Sources è tempo perso: il difetto è nei componenti dell’Access Role o nella posizione della regola.

In laboratorio PDP e PEP spesso coincidono, all’esame quasi mai. Su un gateway singolo i due ruoli vivono sulla stessa macchina e la distinzione sembra accademica, tanto che è facile saltare il controllo del canale. Le domande però descrivono topologie distribuite, dove l’identità acquisita dal PDP deve raggiungere i PEP che applicano la policy. Quando i sintomi non tornano, la coppia pdp connections pep e pep show user all è il controllo che separa un guasto della sorgente da un guasto della condivisione.