Un server di autenticazione remoto è un oggetto che da solo non autentica nessuno: serve quando finisce in un gruppo, e il gruppo in una policy. Gli errori stanno nei dettagli: quale attributo identifica l’utente, da dove parte la ricerca, cosa succede se non risponde.

LDAP: identificatore, DN e tipo di bind

Si configura in User & Authentication > LDAP Servers o con config user ldap: porta 389 in chiaro, 636 per LDAPS.

Il Common Name Identifier (cnid) è l’attributo con cui il FortiGate identifica l’utente, ed è case sensitive. Su Active Directory la scelta pratica è sAMAccountName: con cn gli utenti dovrebbero digitare il nome visualizzato, “Mario Rossi” invece di “mrossi”, e le autenticazioni falliscono senza che nulla sembri rotto.

Il Distinguished Name (dn) è il punto da cui parte la ricerca: dc=azienda,dc=com prende tutta la radice del dominio, ou=VPN-Users,dc=azienda,dc=com una singola OU.

Il bind type è la scelta che cambia davvero il comportamento:

  • Simple: bind con nome e password del client; il server cerca solo contro il DN e non scende nei sottoalberi, quindi va bene solo se gli utenti stanno esattamente sotto quel DN.
  • Anonymous: cerca dal DN e ricorre nei sottoalberi, ma molti server LDAP lo rifiutano.
  • Regular: bind con username e password forniti, poi ricerca dal DN con ricorsione nei sottoalberi. Su Active Directory è la modalità da usare per leggere l’appartenenza ai gruppi.

Lo username del regular bind accetta utente@dominio, il formato NetBIOS o il DN completo, e deve essere un account di servizio con privilegi minimi, mai un domain admin.

I gruppi annidati non vengono cercati di default, perché la ricerca ricorsiva costa: se sono a più livelli serve set search-type recursive, disponibile solo per Active Directory e non per OpenLDAP.

Connessione sicura: la trappola del certificato

Secure Connection offre STARTTLS sulla porta 389 o LDAPS sulla 636. Il punto da ricordare: se non si seleziona anche il certificato della CA emittente, la validazione del certificato del server non viene eseguita, nemmeno con Secure Connection abilitato. Il traffico è cifrato ma nessuno verifica con chi parla. Il certificato radice va nello store Remote CA, e sceglierne uno sbagliato fa fallire la connessione.

Il server identity check, attivo di default quando si sceglie un certificato, confronta il campo Server IP/Name con il certificato: se esiste una Subject Alternative Name ignora il Common Name e cerca nei SAN, altrimenti ripiega sul CN. Se il server è configurato per IP e il certificato porta solo l’FQDN, il controllo fallisce: si scrive l’FQDN.

config user ldap
    edit "LDAP-AD"
        set server "dc01.azienda.com"
        set cnid "sAMAccountName"
        set dn "dc=azienda,dc=com"
        set type regular
        set username "svc-fortigate@azienda.com"
        set secure ldaps
        set ca-cert "CA_Cert_1"
    next
end

RADIUS: profilo, metodo e ridondanza

RADIUS lavora su UDP, porte 1812 e 1813 oppure 1645 e 1646 (RFC 2865 e 2866). Il segreto condiviso con MD5 protegge tipicamente le sole credenziali: per cifrare tutto serve set transport-protocol tls, cioè RADSEC.

Authentication method corrisponde ad auth-type. Con auto il FortiGate negozia PAP, MSCHAP_v2 e CHAP in quest’ordine; se si sa già cosa vuole il server, per esempio MSCHAPv2 con NPS, impostarlo esplicitamente elimina tentativi inutili.

nas-ip dichiara quale indirizzo il FortiGate usa verso il server; se manca vale l’IP dell’interfaccia che lo raggiunge, e poiché NPS riconosce i client dall’indirizzo, con più uscite conviene fissarlo. La porta invece non sta nel profilo ma è globale, in config system global con set radius-port. E all-usergroup aggiunge il server a ogni gruppo utenti: comodo e pericoloso in parti uguali.

La ridondanza ha tre forme con tre comportamenti diversi, ed è materia da domanda d’esame:

  • Secondo (e terzo) server nello stesso profilo: il successivo viene interrogato solo se il primo non risponde; un Access-Reject ferma la catena.
  • Due profili nello stesso gruppo utenti: il FortiGate manda l’Access-Request a entrambi contemporaneamente e l’autenticazione riesce se almeno uno risponde Access-Accept.
  • Due profili in due gruppi diversi sulla stessa policy: valutati nell’ordine in cui compaiono.

Dal server al gruppo, e come si verifica

La policy referenzia il gruppo, mai il server. In un gruppo Firewall convivono i Members, utenti definiti localmente anche di tipo remoto, e i Remote Groups, cioè i server: si provano prima gli account locali, poi i server.

Il default è più permissivo di quanto ci si aspetti: un server aggiunto come remote group fa corrispondere qualunque account valido su di esso. Per restringere si usa il matching sul VSA Fortinet-Group-Name, trasportato dall’AVP 26.

config user group
    edit "RADIUS_IT"
        set member "RADIUS_NPS"
        config match
            edit 1
                set server-name "RADIUS_NPS"
                set group-name "IT"
            next
        end
    next
end

Per tornare a “qualsiasi gruppo” si cancella la voce sotto config match: scrivere Any come group-name fa cercare la stringa letterale. Ai remote group inoltre non si applicano i FortiToken: se serve MFA su un utente di dominio va creato un utente di tipo remoto, con config user local e set type ldap, e aggiunto come member.

Prima della policy conviene provare dalla CLI, che restituisce anche i gruppi visti.

diagnose test authserver ldap LDAP-AD mrossi Password123

Se l’output riporta il successo ma mancano i gruppi annidati, la risposta è search-type recursive, non una policy da riscrivere.