Vai al contenuto
Avanet

Collegare un server LDAP generico a Sophos Firewall

Sophos Firewall

Con il tipo di server LDAP server, Sophos Firewall autentica gli utenti di OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP e altre directory LDAP. La procedura completa comprende quattro parti: creare un gruppo locale, collegare il server LDAP in modo sicuro, attivare il server in Authentication > Services e verificare l’accesso e l’assegnazione al gruppo con un utente reale.

Per Windows Active Directory con LDAPS, importazione dei gruppi o AD SSO è più indicato l’articolo Collegare Active Directory a Sophos Firewall. L’autenticazione RADIUS tramite Microsoft NPS o un gateway MFA è descritta in Configurare un server RADIUS su Sophos Firewall.

Chi deve sostituire il tipo di server eDirectory nativo prima di SFOS 23 trova in Migrare eDirectory prima di SFOS 23 la procedura completa con inventario, scelta della destinazione, funzionamento parallelo e rollback.

Prerequisiti

  • accesso WebAdmin a Sophos Firewall
  • raggiungibilità del server LDAP dal firewall, di norma tramite la porta 389 per STARTTLS o 636 per SSL/TLS
  • un account di bind con accesso in lettura alla parte necessaria della directory
  • Bind DN e Base DN, ad esempio cn=svc-sophos,ou=service,dc=example,dc=net e ou=people,dc=example,dc=net
  • gli attributi utente effettivamente utilizzati, come uid, cn, mail e un attributo di gruppo
  • la corretta catena di attendibilità della CA e una risoluzione DNS funzionante quando è attiva la convalida del certificato

⚠️ Un account di bind deve disporre esclusivamente dell’accesso in lettura al sottoalbero necessario. Non viene utilizzato per apportare modifiche amministrative alla directory, ma solo per autenticare presso il server LDAP le richieste utente del firewall.

Aggiungere il server LDAP

Preparare il gruppo LDAP locale

  1. Aprire Authentication > Groups e selezionare Add.
  2. Creare un gruppo con un nome univoco, ad esempio Utenti-LDAP.
  3. Definire accesso, quote temporali e altre policy di gruppo in base all’uso previsto, quindi salvare.

Questo gruppo verrà utilizzato successivamente come Default group. Non impedisce automaticamente l’accesso: sono le policy assegnate al gruppo e le regole del servizio interessato a stabilire ciò che è consentito.

La logica generale dei gruppi con Default Group restrittivo, override degli utenti, pilota e ripristino è descritta in Gestire in sicurezza i gruppi utenti di Sophos Firewall; l’assegnazione specifica di LDAP deriva poi dall’attributo di gruppo e dallo schema della directory.

Configurare la connessione e il bind

  1. Aprire Authentication > Servers e selezionare Add.
  2. Scegliere LDAP server come Server type.
  3. Assegnare un Server name univoco, ad esempio LDAP-Azienda.
  4. In Server IP/domain, inserire il nome DNS del server LDAP. Se la convalida del certificato è attiva, deve corrispondere a un nome presente nel certificato del server.
  5. Utilizzare Version 3, a meno che la directory non richieda una versione diversa. Google Secure LDAP supporta solo la versione 3.
  6. Per l’uso in produzione, selezionare SSL/TLS o STARTTLS e la porta corrispondente.
  7. Disattivare Anonymous login e inserire il Bind DN e la Password dell’account di lettura.
  8. Attivare Append base DN solo se il server LDAP prevede che la Base DN venga aggiunta durante il bind.
  9. Attivare Validate server certificate non appena nome, DNS e attendibilità della CA sono configurati correttamente. Un Client certificate è necessario solo se il servizio LDAP richiede l’autenticazione reciproca tramite certificati.

Inserire la base di ricerca e gli attributi

  1. In Base DN, inserire il punto iniziale della ricerca utenti, ad esempio ou=people,dc=example,dc=net. Get base DN può recuperare la base di ricerca proposta dal server.
  2. Impostare Authentication attribute sull’attributo di accesso, spesso uid o mail.
  3. Inserire Display name attribute ed Email address attribute in base all’oggetto utente, ad esempio cn e mail.
  4. In Group name attribute, inserire l’attributo dal quale il firewall riceve le informazioni sui gruppi dell’utente. Sophos consiglia memberOf, ma il valore corretto dipende dallo schema della directory.
  5. Se la directory fornisce una data di scadenza dell’account, inserire l’Expiry date attribute appropriato.
  6. Eseguire Test connection e salvare con Save.

Secondo Sophos, Test connection verifica la connessione e le credenziali. Solo un accesso reale consente di verificare se la Base DN include tutti gli utenti necessari e se i gruppi vengono assegnati correttamente.

Scegliere la crittografia corretta

LDAP in chiaro trasmette le credenziali senza crittografia ed è adatto, al massimo, a un test isolato. In produzione, la connessione deve essere protetta con SSL/TLS, di norma sulla porta 636, oppure con STARTTLS, di norma sulla porta 389.

Occorre distinguere due ruoli dei certificati:

  • Validate server certificate verifica l’identità del server LDAP remoto. Server IP/domain deve corrispondere a un nome DNS valido nel certificato, ossia al Common Name o a un Subject Alternative Name. Se il firewall non riesce a risolvere questo nome, aggiungere una voce DNS adeguata in Network > DNS > DNS host entry. Configurare e testare le DNS Host Entry su Sophos Firewall spiega TTL, reverse lookup e test del resolver. Anche la CA emittente deve essere considerata attendibile.
  • Client certificate identifica il firewall presso un servizio LDAP che richiede l’autenticazione reciproca tramite certificati. Questo certificato non sostituisce la convalida del certificato del server.

In caso di errore TLS, correggere prima il nome del server, la risoluzione DNS, la validità e la catena della CA. La disattivazione della convalida del certificato del server non deve essere la soluzione predefinita.

Inserire correttamente Bind DN e Base DN

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

  • Un DN procede dall’oggetto specifico alla radice della directory, ad esempio cn=svc-sophos,ou=service,dc=example,dc=net.
  • La Base DN inizia nel punto in cui deve partire la ricerca degli utenti. Se gli utenti si trovano in più unità organizzative, deve essere collocata abbastanza in alto nell’albero da includerli tutti.
  • Una Base DN troppo ristretta non restituisce utenti corrispondenti anche se il server è raggiungibile. Una base di ricerca inutilmente ampia può rallentare le ricerche e includere oggetti indesiderati.
  • Append base DN aggiunge la Base DN a un Bind DN incompleto durante il bind. Se il DN è già completo, l’opzione rimane normalmente disattivata; fa fede il comportamento del server LDAP.

Attivare gruppi e servizi

Group name attribute non è un’impostazione universale per ogni struttura di gruppi LDAP. Durante l’accesso, il firewall legge l’attributo configurato nell’oggetto utente e utilizza le informazioni sui gruppi restituite per l’assegnazione. Sophos consiglia memberOf, e Google Secure LDAP utilizza questo valore. OpenLDAP, 389-ds o FreeIPA possono tuttavia richiedere un valore diverso a seconda dello schema, dell’overlay e dell’oggetto utente.

Non dedurre l’attributo utente solo dal tipo di gruppo groupOfNames o posixGroup. È determinante ciò che l’oggetto utente reale restituisce e se il gruppo corrispondente è mappato correttamente sul firewall. Se il firewall non trova un’assegnazione di gruppo corrispondente, l’utente viene inserito nel Default group configurato.

Attivare quindi il server:

  1. Aprire Authentication > Services.
  2. In Firewall authentication methods, selezionare il server LDAP e spostarlo nella posizione desiderata in Selected authentication servers. Il firewall interroga più server in questo ordine.
  3. Selezionare il gruppo Utenti-LDAP creato in precedenza come Default group e fare clic su Apply.
  4. Se gli utenti devono accedere a User Portal, VPN Portal, tramite SSL VPN, a un altro servizio VPN o come amministratori, selezionare il server LDAP anche nel metodo di autenticazione corrispondente.

Configurare Google Secure LDAP

Prima di configurare il firewall, creare un client LDAP nella Console di amministrazione Google. Definire i relativi diritti di accesso, scaricare il certificato con la chiave privata e generare credenziali separate. La password non viene più visualizzata dopo la chiusura della finestra di dialogo di Google.

Importare il certificato client Google con il relativo certificato e la chiave privata in Certificates > Certificates > Add. Sophos Firewall può visualizzarlo come non attendibile perché è autofirmato da Google, ma funziona comunque per l’autenticazione del client. Questa indicazione non riguarda la convalida del certificato del server.

Utilizzare i seguenti valori per il server LDAP:

  • Server IP/domain: ldap.google.com
  • Version: 3
  • Connection security: SSL/TLS
  • Port: 636
  • Anonymous login: disattivato
  • Bind DN e Password: le credenziali LDAP di Google generate
  • Append base DN: disattivato
  • Client certificate: il certificato Google importato
  • Base DN: inserirla oppure recuperarla con Get base DN
  • Authentication attribute: UID
  • Display name attribute: CN
  • Email address attribute: mail
  • Group name attribute: memberOf
  • Expiry date attribute: expiry

mail è necessario per creare gruppi LDAP di Google. Dopo il salvataggio, seguire gli stessi passaggi previsti per una directory locale: definire il gruppo LDAP locale, attivare il server in Authentication > Services e testare un accesso reale con la relativa assegnazione al gruppo.

Verificare la connessione e l’assegnazione ai gruppi

Un collaudo affidabile comprende più livelli:

  1. Test connection conferma la connessione e le credenziali di bind.
  2. Un utente accede al servizio previsto, ad esempio a VPN Portal o Captive Portal.
  3. In Authentication > Users, verificare che l’utente e il gruppo vengano visualizzati come previsto.
  4. Se vengono utilizzati più gruppi LDAP, testare almeno un utente di ogni gruppo rilevante. Una policy o una regola di test conferma che funzionino sia l’accesso sia l’autorizzazione del gruppo corrispondente.
  5. Una password errata viene rifiutata e il Log viewer mostra un errore di autenticazione comprensibile.

Se lo schema non è chiaro, un amministratore può esaminare l’oggetto utente in sola lettura da un sistema di amministrazione Linux o dal server LDAP:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

-W richiede la password di bind in modo interattivo, affinché non venga memorizzata nella cronologia della shell. '*' mostra gli attributi normali e '+' quelli operativi; se viene utilizzato un altro attributo di accesso, adattare di conseguenza il filtro di ricerca. Questo comando non deve essere eseguito nell’Advanced Shell di Sophos Firewall. È importante verificare se l’oggetto utente restituisce effettivamente gli attributi e i valori di gruppo previsti. L’output può contenere dati personali della directory e deve essere anonimizzato prima di essere allegato a un ticket o condiviso.

Errori comuni

  • Nessuna connessione: Controllare routing, DNS, porta e Connection security. Verificare quindi Bind DN, password e Anonymous login.
  • Errore TLS o del certificato: Controllare i nomi DNS nel certificato del server, la risoluzione DNS, la validità e la catena della CA. Non disattivare la convalida del certificato del server come prima misura.
  • Test connection riesce, ma l’utente non viene trovato: La Base DN è spesso troppo ristretta oppure Authentication attribute non corrisponde al nome di accesso.
  • L’accesso riesce, ma l’utente viene inserito nel Default group: Controllare Group name attribute nell’oggetto utente reale, la mappatura dei gruppi locali e l’ordine dei gruppi. memberOf è un esempio comune, ma non è garantito per ogni schema.
  • Google Secure LDAP non esegue il bind: Controllare versione 3, porta 636, Anonymous login disattivato, Append base DN disattivato, credenziali e certificato client Google.
  • Il server è configurato ma non viene utilizzato: Controllare l’assegnazione, l’ordine e il Default group in Authentication > Services.
  • La ricerca è lenta o restituisce account indesiderati: Restringere la Base DN al sottoalbero necessario.
  • Un altro server di autenticazione risponde per primo: Correggere l’ordine dei server selezionati per il servizio interessato.