Che cosa chiede davvero un lab «Activate the Bad Actor»

Nei laboratori del corso il guasto non capita: lo attivi tu. «Activate the Bad Actor» significa introdurre di proposito un difetto controllato nell’ambiente e poi lavorarci sopra come se fosse arrivato da una segnalazione. È un esercizio di metodo, e il metodo è la parte che l’esame verifica.

La prima mossa non è il guasto, è la fotografia di partenza. Prima di attivare qualsiasi cosa registri lo stato sano: chi entra in SmartConsole e da dove, l’elenco dei Trusted Clients con cp_conf client get, lo stato dei processi con cpwd_admin list, il fingerprint del server con fwm fingerprint localhost 443. Senza questa base non potrai dire se ciò che vedi dopo è il difetto o una condizione che c’era già.

La seconda regola è una variabile per volta. Se attivi due difetti insieme, il sintomo che osservi non è attribuibile e la correzione che funziona non è identificabile. Annota ogni modifica mentre la fai: nel lab serve per ripristinare, sul campo serve per la nota di chiusura.

La terza è che il guasto va descritto come lo descriverebbe l’utente, non come lo conosci tu: «SmartConsole resta in attesa e poi va in timeout» è un fatto, «il server è rotto» è un’ipotesi travestita da fatto.

Il percorso di isolamento quando SmartConsole non entra

Il laboratorio sul login a SmartConsole ha un percorso stabile, e conviene impararlo come sequenza perché l’esame chiede spesso quale sia il passo successivo.

Si parte dal messaggio. Un errore di rete o un’attesa che finisce in timeout indicano che il Security Management Server non risponde: la verifica è la raggiungibilità dell’indirizzo e poi lo stato dei processi sul server. Un rifiuto immediato con credenziali dichiarate corrette sposta l’indagine sull’autorizzazione. Un avviso sul fingerprint riguarda l’identità del server. Una sessione che si apre ma non lascia modificare nulla non è un guasto di login: è la connessione in sola lettura o il permission profile dell’amministratore.

Sul ramo «il server non risponde» lo strumento è cpwd_admin list: un processo con STAT a T, o un contatore #START che cresce con START_TIME sempre recente, dice che qualcosa muore e viene riavviato in ciclo. cpstat con il flavour del sistema operativo aggiunge CPU, memoria e disco, e un disco pieno sul Management Server produce sintomi che dal client sembrano problemi di autenticazione.

Sul ramo «il server rifiuta» si controlla l’elenco dei Trusted Clients, in SmartConsole da un’altra postazione autorizzata in Manage & Settings > Permissions & Administrators > Trusted Clients, oppure dal server con cpconfig alla voce GUI Clients o con cp_conf client get. Poi si guarda l’account: esiste, è abilitato, ha un permission profile, il metodo di autenticazione usato è quello previsto. Le voci dell’elenco possono essere Any, indirizzo, range, netmask, nome host o wildcard: un nome host che non risolve più sullo stesso indirizzo respinge esattamente come un IP sbagliato.

Sul ramo «identità del server» si confronta il valore mostrato dal client con l’output di fwm fingerprint localhost 443 eseguito sul server, nel contesto del Domain Management Server con mdsenv se l’ambiente è Multi-Domain.

Chiudere il lab: ripristino e prova di non regressione

Un laboratorio non finisce quando il sintomo sparisce: finisce quando sai perché è sparito. Tre passaggi lo chiudono davvero.

Il primo è la conferma sul sintomo originale, non su un suo sostituto: se il caso era «l’amministratore X non entra dalla postazione Y», la prova è l’accesso di X da Y, non il tuo accesso da un’altra macchina. Il secondo è la rimozione del guasto che hai attivato e di tutto ciò che hai toccato per diagnosticarlo: una regola aperta per prova, un’aggiunta temporanea ai Trusted Clients, un servizio riavviato a mano restano lì se non li rimuovi, e diventano il guasto del laboratorio successivo. Il terzo è il verbale: sintomo osservato, ipotesi scartate con la prova che le ha scartate, causa, correzione applicata.

Se dopo aver ripristinato l’ambiente il sintomo torna, non hai trovato la causa: hai trovato un suo effetto collaterale, e la diagnosi ricomincia dalla fotografia di partenza.

Trappole tipiche d’esame

  • Il laboratorio parla di gateway, la soluzione vive sul Management Server. Negli scenari di login a SmartConsole vengono spesso citati gateway, policy e traffico, ma il client dialoga con il Security Management Server o con il Domain Management Server. Ogni opzione che propone di reinstallare la policy, riavviare servizi sul gateway o controllare la connettività verso il gateway è una risposta fuori bersaglio.
  • Le credenziali giuste non aprono una porta chiusa. Quando la traccia sottolinea che la password è corretta e che altri amministratori entrano, il candidato istintivamente reimposta la password o ricrea l’utente. Il sospetto principale è invece l’elenco dei Trusted Clients: cerca nella traccia la postazione, la subnet o la VPN da cui la persona si sta collegando.
  • La richiesta di confermare il fingerprint viene scambiata per il guasto attivato. In un lab su postazione nuova o su profilo Windows nuovo la finestra del fingerprint compare perché il valore non è ancora salvato nelle impostazioni utente: è il comportamento previsto. Trattarla come il «bad actor» porta a rigenerare certificati e a perdere il difetto vero, che resta dov’è.