La differenza fra autenticazione attiva e passiva sta in chi fornisce l’identità: nella prima è l’utente, a cui il FortiGate chiede le credenziali; nella seconda una fonte esterna che dice al FortiGate chi c’è dietro un indirizzo IP. Convivono sullo stesso apparato, e il monitor degli utenti è dove si capisce quale ha funzionato.

Attiva: il FortiGate chiede le credenziali

L’autenticazione attiva si innesca quando una firewall policy ha un utente o un gruppo nel campo Source: il traffico che corrisponde a tutto il resto ma di identità ignota fa scattare la richiesta di credenziali. La sfida però viaggia solo su quattro protocolli, ed è il dettaglio che manda in crisi le installazioni.

config user setting
    set auth-type http https ftp telnet
    set auth-secure-http enable
end

L’utente deve prima connettersi con un protocollo supportato per poter poi usare gli altri. Se il primo traffico che genera è fuori da questi quattro, la sfida non arriva mai e il traffico viene bloccato: è la causa più comune del ticket “l’autenticazione non funziona”.

Attenzione ai default: auth-lockout-threshold vale 3, ma auth-lockout-duration vale 0, quindi nessun account viene mai bloccato. E soprattutto c’è auth-on-demand, il cui default implicitly fa cadere il traffico non autenticato sulla policy successiva: gli utenti si autenticano solo se nessun’altra policy corrisponde. Con una policy identity-based e sotto una policy generica, il traffico prende in silenzio la seconda e nessuno si autentica mai. Per forzare la sfida sulla prima policy corrispondente serve set auth-on-demand always.

Il captive portal sta sull’interfaccia

Il captive portal non si configura nella policy ma sull’interfaccia, e questo cambia il perimetro: tutti gli utenti su quella interfaccia devono autenticarsi.

config system interface
    edit "internal"
        set security-mode captive-portal
        set security-groups "Dipendenti"
        set security-exempt-list "stampanti"
    next
end

Il Role dell’interfaccia deve essere LAN o Undefined, e il portale può stare sul FortiGate (Local) o su un server esterno (External). Con Restricted to Groups compare la pagina di login e passano solo i gruppi scelti; con Allow all compare il disclaimer e decidono le policy. Poiché il vincolo copre tutta l’interfaccia serve quasi sempre una lista di esenzione (config user security-exempt-list) per stampanti e apparati che non sanno autenticarsi.

Passiva: FSSO e il tipo di gruppo giusto

Con FSSO l’identità arriva dalla rete Windows. L’agente rileva il logon, risolve il nome della workstation in un indirizzo IP, determina i gruppi di appartenenza e invia al FortiGate indirizzo e lista dei gruppi: quando l’utente apre una sessione, la policy lo riconosce già.

Il Collector Agent parla con il FortiGate su TCP 8000 e ascolta su UDP 8002 gli aggiornamenti dei DC agent; se ne configurano fino a cinque per ridondanza, provati nell’ordine della lista. In alternativa c’è la modalità agentless: il FortiGate interroga direttamente il Security Event log dei domain controller col connettore Poll Active Directory Server.

L’errore ricorrente è il tipo di gruppo: quello da mettere nella policy deve essere Fortinet Single Sign-On, set group-type fsso-service, con i gruppi di dominio come membri. Un gruppo di tipo firewall con lo stesso server LDAP fra i remote group non corrisponderà mai a un logon FSSO. Va guardato anche logon-timeout sotto config user fsso, da 1 a 2880 minuti con default 5: quanto restano validi i logon noti se cade la connessione al collector. Su un collegamento instabile cinque minuti significano utenza non autenticata a ogni singhiozzo. Con RSSO, infine, il FortiGate non parla col server RADIUS: legge solo i record di accounting inoltrati.

Quanto dura una sessione autenticata

I tipi di timeout sono tre. idle-timeout è il default: il contatore riparte finché passano dati, quindi si riautentica solo chi è rimasto inattivo troppo a lungo. hard-timeout parte con la sessione e alla scadenza obbliga tutte le sessioni dell’utente a riautenticarsi. new-session lascia vivere le sessioni esistenti ma blocca le nuove.

config user setting
    set auth-timeout-type idle-timeout
    set auth-timeout 30
end

Il valore è in minuti, default 5, e nella GUI si configura solo l’idle timeout, da 1 a 1440. Esiste anche set authtimeout per gruppo, ignorato in due casi: valore zero, che è il default, e utente in più gruppi RADIUS.

Il monitor degli utenti

Il Firewall Users monitor elenca gli utenti firewall e proxy autenticati in questo momento. Si raggiunge da Dashboard > Assets & Identities espandendo a schermo intero il widget Firewall Users; col template Comprehensive è la voce Firewall User Monitor.

Tre cose da sapere. I logon FSSO non compaiono finché non si clicca Show all FSSO Logons in alto a destra: non trovare gli utenti di dominio non significa che FSSO sia rotto. Il pulsante Proxy accanto alla ricerca mostra chi si è autenticato via explicit proxy e ZTNA, un elenco separato. E oltre i 2000 utenti la pagina perde ricerca, filtri e grafici, perché i risultati sono caricati in modo lazy.

Da qui si deautentica un utente, dalla toolbar o col tasto destro; in CLI valgono gli stessi comandi.

diagnose firewall auth list
diagnose firewall auth clear
diagnose wad user list

diagnose firewall auth clear rende ripetibile un test: dopo aver cambiato un gruppo o una policy, azzerare le sessioni obbliga a ripassare dalla trafila, e si misura la configurazione nuova, non una in cache. L’equivalente proxy è diagnose wad user clear.