Collegare un server LDAP generico a Sophos Firewall

Active Directory è su Sophos Firewall il server di autenticazione più diffuso, ma non l’unico. Chi gestisce OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP o un’altra directory LDAP pura può collegare Sophos Firewall allo stesso modo come client LDAP. Il tipo di server si chiama volutamente LDAP Server, non Active Directory, anche se tecnicamente Active Directory stesso è una directory LDAP.

Questo articolo tratta in modo mirato il caso generico: un servizio di directory senza i campi specifici di AD come nomi di dominio o Kerberos. Per ambienti Active Directory con LDAPS, importazione gruppi e AD SSO è più adatto invece Collegare Active Directory a Sophos Firewall. Per l’autenticazione basata su RADIUS, ad esempio tramite Microsoft NPS o un gateway MFA, l’articolo giusto è Configurare un server RADIUS Sophos Firewall.

Quando un server LDAP generico è adatto

Un server LDAP su Sophos Firewall ha senso quando:

• Utenti e gruppi si trovano in una directory che non è Active Directory, ad esempio OpenLDAP, 389 Directory Server o FreeIPA.
• Una directory cloud offre un’interfaccia LDAP, ad esempio Google Secure LDAP o un proxy LDAP davanti a Entra ID o Okta.
• Più sistemi si autenticano già contro la stessa directory LDAP e il firewall deve usare la stessa fonte.
• Non serve Kerberos né NTLM, ma è sufficiente una semplice autenticazione bind.

Se invece è in uso un Windows Server con Active Directory Domain Services, il tipo di server AD specializzato è di solito la scelta migliore, perché mappa correttamente campi aggiuntivi come i nomi di dominio. Il tipo di server LDAP generico funziona anche contro Active Directory, ma mappa meno automatismi specifici di AD.

Prerequisiti

• Accesso al WebAdmin di Sophos Firewall.
• Raggiungibilità del server LDAP dal firewall, di solito porta 389 (plaintext/StartTLS) o 636 (LDAPS).
• Un account bind con diritti di lettura sul sottoalbero rilevante, specificato come Distinguished Name (DN).
• La Base DN sotto cui vengono cercati gli utenti, ad esempio ou=people,dc=firma,dc=local.
• Conoscenza dell’attributo che funge da nome di login, spesso uid, sAMAccountName o mail.
• Per connessioni cifrate: il certificato del server o la catena di certificati, se il firewall deve validarli.

⚠️ Un account bind dovrebbe avere solo diritti di lettura sul sottoalbero necessario. Non viene usato per modifiche amministrative nella directory, ma solo per autenticare al server LDAP le richieste degli utenti provenienti dal firewall.

Creare il server LDAP

1. Aprire Authentication > Servers.
2. Selezionare Add e come Server type scegliere LDAP server.
3. In Server name assegnare un nome univoco, ad esempio LDAP_Firma_Intern.
4. In Server IP/domain inserire l’indirizzo IP o il nome DNS del server LDAP.
5. In Version scegliere la versione LDAP supportata dal server, di solito Version 3.
6. In Connection security scegliere tra Plaintext, SSL/TLS o STARTTLS.
7. In Port impostare la porta corretta, se non si usa la porta standard.
8. Disattivare Anonymous login, a meno che il server non consenta richieste bind anonime.
9. In Bind DN inserire l’account tecnico come Distinguished Name, ad esempio cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Inserire la relativa Password.
11. In Base DN inserire l’ambito di ricerca per gli utenti, ad esempio ou=people,dc=firma,dc=local.
12. In Authentication attribute inserire il campo che funge da nome di login, spesso uid.
13. Facoltativamente impostare Display name attribute e Email address attribute, ad esempio cn e mail.
14. Facoltativamente impostare Group name attribute, se si vogliono valutare le appartenenze ai gruppi.
15. Eseguire Test connection e verificare il risultato.
16. Selezionare Save.

I campi in sintesi:

Un Test connection riuscito dimostra solo che server, porta, account bind e base di ricerca sono fondamentalmente raggiungibili. Se gli utenti giusti vengono trovati e i gruppi assegnati correttamente va verificato dopo con un vero utente di test.

Scegliere correttamente la cifratura

Per ambienti produttivi la connessione tra firewall e server LDAP dovrebbe essere cifrata, tramite LDAPS sulla porta 636 oppure tramite STARTTLS sulla porta classica 389. LDAP in plaintext invia password bind e in parte dati utente in chiaro e dovrebbe essere usato solo in scenari di test interni ben protetti.

Con Validate server certificate il firewall verifica se il certificato presentato dal server LDAP è affidabile. Con certificati autofirmati, come quelli usati ad esempio da Google Secure LDAP, il certificato può risultare non affidabile anche se la connessione funziona. In questo caso va deciso consapevolmente se adattare la verifica del certificato o importare il certificato nel firewall.

Esempio: Google Secure LDAP

Google Secure LDAP mostra bene come collegare una directory cloud tramite LDAP generico:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN e Password: credenziali provenienti dalle LDAP client credentials generate nella Google Admin Console.
• Certificato: il certificato client rilasciato da Google con chiave privata viene caricato sul firewall.
• Attributi: uid per il login, cn per il nome visualizzato, mail per l’indirizzo e-mail, memberOf per i gruppi.

Questo esempio è applicabile ad altri provider LDAP con struttura simile. Ciò che conta sempre è quale attributo il provider effettivamente popola per nome di login, nome visualizzato, e-mail e appartenenza al gruppo.

Inserire correttamente Bind DN e Base DN

La fonte di errore più comune con un nuovo server LDAP è una sintassi DN scritta o interpretata in modo errato.

Regole importanti:

• Un DN viene scritto dalla parte più specifica a quella più generale, ad esempio cn=svc-sophos,ou=service,dc=firma,dc=local.
• La Base DN per la ricerca utenti deve essere il sottoalbero in cui si trovano effettivamente gli oggetti utente rilevanti, non necessariamente la radice della directory.
• Se gli utenti si trovano in più unità organizzative, la Base DN deve essere scelta abbastanza in alto nell’albero da includere tutti i container rilevanti.
• Append base DN determina se la Base DN viene aggiunta anche al Bind DN. Questo dipende dal server e in caso di problemi va testato in modo mirato.

Se la Base DN è scelta in modo troppo ristretto, il firewall può segnalare un test di connessione riuscito ma non trovare poi alcun utente. Se la Base DN è scelta in modo troppo ampio, la ricerca può durare inutilmente a lungo o includere oggetti indesiderati.

Mappare gruppi e attributi

Per regole firewall, Web Policies o autorizzazioni VPN basate su gruppi, il Group name attribute è decisivo. Determina quale attributo LDAP il firewall interpreta come appartenenza al gruppo.

Schemi tipici:

• Le directory con schema classico groupOfNames o posixGroup usano spesso un attributo come memberOf o valutano l’appartenenza al gruppo tramite riferimenti inversi.
• Le directory cloud con proxy LDAP, ad esempio Google Secure LDAP, spesso forniscono i gruppi direttamente nell’attributo memberOf dell’oggetto utente.
• Se lo schema non è chiaro, un browser LDAP o uno strumento a riga di comando come ldapsearch aiuta a esaminare completamente l’oggetto utente prima di configurare il firewall.

Dopo la configurazione va testato almeno un utente per ogni gruppo rilevante. Un singolo login riuscito non dimostra che l’assegnazione dei gruppi funzioni correttamente per tutti i gruppi.

Attivare il server LDAP per i servizi

Un server LDAP creato non autentica ancora nessuno da solo. Deve essere assegnato anche in Authentication > Services al servizio desiderato, ad esempio VPN Portal, SSL VPN, Captive Portal o login amministrativo.

Procedura pratica:

1. Aprire Authentication > Services.
2. Selezionare il servizio interessato, ad esempio Firewall authentication methods o VPN.
3. Aggiungere il server LDAP appena creato come fonte di autenticazione.
4. Verificare l’ordine se vengono usati più server in parallelo.
5. Verificare il servizio previsto con un utente di test.

Se sono attivi più server di autenticazione contemporaneamente, ad esempio LDAP e utenti locali, l’ordine va scelto consapevolmente. Il firewall interroga i server nell’ordine inserito.

Testare e validare la connessione

Dopo il salvataggio la configurazione va testata su più livelli:

1. Test connection nella maschera del server: conferma raggiungibilità, account bind e Base DN.
2. Login di un utente di test sul servizio di destinazione: conferma che l’autenticazione funzioni davvero.
3. Verificare l’appartenenza al gruppo: conferma che il Group name attribute venga interpretato correttamente.
4. Testare un utente o una password errati: conferma che i login falliti vengano rifiutati correttamente.
5. Verificare il Log Viewer: mostra se le richieste di autenticazione arrivano ed elaborate come previsto.

Un utente di test che si accede correttamente ma non risulta assegnato al gruppo atteso indica di solito un Group name attribute errato o uno schema di gruppo inatteso.

Errori tipici

• Sintassi DN errata: Bind DN o Base DN sono invertiti, scritti male o usano separatori errati. Verificare la sintassi rispetto allo schema della directory.
• Base DN scelta troppo ristretta: il test di connessione ha successo, ma gli utenti reali non vengono trovati. Posizionare la Base DN più in alto nell’albero della directory.
• Porta o cifratura errate: LDAPS sulla porta 389 o plaintext sulla porta 636 non funzionano. Porta e Connection security devono corrispondere.
• Certificato non affidabile: con certificati autofirmati il firewall può classificare la connessione come non affidabile. Importare consapevolmente il certificato o adattare la verifica in modo mirato.
• Anonymous login attivo anche se il server lo rifiuta: il bind fallisce. Disattivare Anonymous login e inserire Bind DN/Password.
• L’attributo del gruppo non corrisponde allo schema: il login funziona, ma le policy di gruppo non si applicano. Verificare l’attributo rispetto allo schema LDAP effettivo, ad esempio con ldapsearch.
• Server LDAP non assegnato in Authentication > Services: il server è creato ma non usato da alcun servizio. Recuperare l’assegnazione in Authentication > Services.
• Più server di autenticazione nell’ordine sbagliato: un altro server risponde per primo e produce un comportamento inatteso. Verificare l’ordine in Authentication > Services.

FAQ