Il FortiGate non sa chi sei: sa da quale indirizzo IP arriva il pacchetto. FSSO colma quel salto e lega un indirizzo a un utente di dominio e ai suoi gruppi, senza chiedere niente a chi naviga. Nelle domande operative il punto di partenza è quasi sempre lo stesso — un utente che «dovrebbe passare» e non passa — e la risposta sta in uno di tre snodi: chi ha visto l’evento di login, chi ha risolto i gruppi, e quale filtro ha scartato l’utente prima della policy.

DC agent mode contro polling agentless

In DC agent mode il DC agent va installato su ogni domain controller. Intercetta l’evento di logon sul posto e lo passa al collector agent, che lo memorizza e lo inoltra al FortiGate. Il flusso è sempre lo stesso: rilevare l’evento registrando workstation, dominio e utente; risolvere il nome della workstation in un indirizzo IP; determinare i gruppi di appartenenza; spedire al FortiGate indirizzo e lista dei gruppi; scrivere i log del caso.

In modalità agentless — il connettore Poll Active Directory Server — non installi nulla sul dominio: è il FortiGate stesso a interrogare il Security Event log dei DC. Si mette in piedi in pochi minuti, ma porta tre limiti dichiarati: NTLM non è supportato, non tutti gli eventi di sicurezza lo sono (di Kerberos vengono gestiti solo il 4768 e il 4769), e con molti login simultanei il demone può perderne qualcuno. Quando è quest’ultimo il problema — il turno che entra tutto alle otto — la soluzione corretta è passare alla modalità con agenti, non alzare la frequenza di polling.

Su un dominio con più DC, ogni DC agent deve puntare all’indirizzo e alla porta giusti del collector: sbagliarne uno significa perdere in silenzio i login che transitano da quel controller.

Il collector agent fa più di quanto sembri

Trattarlo come un semplice inoltro è l’errore che si paga poi in troubleshooting. Il collector si installa come servizio su un server del dominio e si occupa di risoluzioni DNS, verifica dei gruppi, controllo delle workstation e aggiornamento dei FortiGate sui record di logon. Al FortiGate manda i gruppi Domain Local Security e Global Security.

Le porte vanno sapute a memoria: il collector parla con il FortiGate in TCP 8000 e resta in ascolto in UDP 8002 per gli aggiornamenti dei DC agent. Puoi configurare fino a cinque collector per ridondanza: si prova il primo della lista e si scende al successivo finché uno risponde.

Il connettore si crea in Security Fabric > External Connectors, sezione Endpoint/Identity, voce FSSO Agent on Windows AD. Oltre a indirizzo e password del collector primario, la scelta che pesa è User group source: con Collector Agent i gruppi arrivano spinti dal collector e Apply & Refresh li rilegge; con Local li definisci sul FortiGate scegliendo un server LDAP e selezionando utenti, gruppi e unità organizzative.

Dai gruppi alla policy, e cosa succede se il collector cade

I gruppi FSSO si usano in due modi: infilati direttamente nella firewall policy dal campo Source, scheda User, oppure raccolti in un gruppo locale di tipo Fortinet Single Sign-On (FSSO). La seconda strada conviene appena gli stessi gruppi tornano in due o tre regole.

Quando il collector diventa irraggiungibile gli utenti già autenticati non scompaiono subito: resistono per il tempo di logon-timeout, in minuti, range 1-2880 e default 5.

config user fsso
    edit "ad"
        set server "10.1.100.141"
        set logon-timeout 4
    next
end

Scaduto quel tempo il FortiGate esegue il logoff e la navigazione si ferma. Quando il collector torna, gli utenti vengono risincronizzati e non devono rifare login.

Leggere una lista FSSO vuota

L’ordine di lettura conviene impararlo come sequenza.

# diagnose debug authd fsso list
# diagnose debug authd fsso server-status
# diagnose debug fsso-polling detail 1
# diagnose debug application fssod -1

La prima è la lista che conta: guarda il campo MemberOf e confrontalo con il gruppo ammesso dalla policy. Se la lista è vuota, server-status deve riportare lo stato connected. In agentless, fsso-polling detail 1 mostra la frequenza di polling con i contatori success e fail, lo stato LDAP e il Group Filter: successi e fallimenti alternati indicano rete instabile o DC molto carico, mentre zero e zero indicano credenziali sbagliate.

Lo stato LDAP non è un dettaglio decorativo. Il Security Event log di Windows non contiene l’appartenenza ai gruppi, quindi il FortiGate deve andarsela a prendere via LDAP, e aggiunge l’utente alla lista solo se almeno uno dei suoi gruppi compare nel Group Filter.

Il caso più insidioso è l’altro: alcuni utenti ci sono e uno no. O quel login è andato perso in una raffica, oppure la workstation non ha raggiunto il DC e si è autenticata con credenziali in cache — e allora l’evento nel security log del controller non esiste proprio, per cui nessun debug sul FortiGate lo farà comparire.

Sul fronte degli utenti autenticati in generale, diagnose firewall auth list mostra la riga con type: fsso, il server di provenienza e i group_name, e diagnose firewall auth clear li rimuove. In GUI l’equivalente è Dashboard > Assets & Identities, widget Firewall Users espanso a schermo intero, con Show all FSSO Logons e il pulsante Deauthenticate. Oltre i 2000 utenti la pagina perde ricerca, filtri e grafici.