Connettere un server LDAP generico a Sophos Firewall

Sophos Firewall può autenticare gli utenti tramite il tipo di server LDAP server in base agli attributi della directory e all’appartenenza ai gruppi. In pratica sono necessari quattro passaggi: preparare un gruppo locale, collegare il server LDAP, selezionarlo in Authentication > Services per il servizio desiderato e verificare l’accesso e l’autorizzazione con account di prova reali.

OpenLDAP, 389 Directory Server o FreeIPA sono tipici candidati per una connessione LDAP generica, ma non sono prodotti intercambiabili. Gli attributi, i valori di gruppo restituiti e la scadenza degli account differiscono a seconda dello schema. Questa guida fornisce quindi un esempio adattabile; i valori devono essere verificati sull’oggetto utente reale. Google Secure LDAP è descritto di seguito come una variante a sé stante, documentata da Sophos.

Per Windows Active Directory con LDAPS, importazione di gruppi o AD SSO, è più adatta la guida Connettere Active Directory a Sophos Firewall. RADIUS tramite Microsoft NPS o un gateway MFA è trattato in Configurare un server RADIUS su Sophos Firewall. Se è necessario sostituire il tipo di server eDirectory nativo prima di SFOS 23, è possibile trovare il processo di migrazione completo in Migrazione di eDirectory prima di SFOS 23.

Preparare i valori e il rollback

Sono necessari:

Accesso WebAdmin a Sophos Firewall;
raggiungibilità del server LDAP dal firewall sulla porta configurata sul server;
un account di bind con diritti di lettura sull’area della directory richiesta;
il Bind DN e il Base DN, ad esempio cn=svc-sophos,ou=service,dc=example,dc=net e ou=people,dc=example,dc=net;
gli attributi per il nome di accesso, il nome visualizzato, l’indirizzo email, il gruppo e, se applicabile, la scadenza dell’account;
se è attiva la verifica del certificato, un nome di server risolvibile e la catena di attendibilità CA appropriata.

I valori iniziali abituali sono la porta 389 per STARTTLS e 636 per SSL/TLS. Non sono requisiti fissi di SFOS: una directory può utilizzare una porta diversa, che deve corrispondere a Connection security e alla configurazione del server.

⚠️ L’account di bind non richiede permessi amministrativi di scrittura. Limitare i suoi diritti di lettura al sottoalbero e agli attributi necessari al firewall per le richieste degli utenti.

Prima di modificare la configurazione in Authentication > Services, documentare i server selezionati, il loro ordine e le opzioni di ereditarietà per ciascun metodo interessato. In Firewall authentication methods, annotare anche il precedente valore di Default group. Ciò consente di annullare la modifica senza eliminare frettolosamente nuovi oggetti. Durante le modifiche, mantenere disponibile un accesso amministrativo locale già testato per il ripristino.

Distinguere Bind DN, Base DN e attributi

Un DN va dall’oggetto specifico alla radice della directory. cn=svc-sophos,ou=service,dc=example,dc=net indica l’account di bind nell’esempio. Il Base DN, invece, specifica il punto di partenza della ricerca dell’utente, ad esempio ou=people,dc=example,dc=net.

Un Base DN troppo restrittivo non consente di trovare tutti gli utenti necessari. Una base di ricerca inutilmente ampia può rallentare le ricerche e includere oggetti indesiderati. Append base DN aggiunge il Base DN a un Bind DN incompleto durante il bind; se il DN è già completo, l’opzione resta normalmente disattivata. È determinante il comportamento del server LDAP utilizzato.

Anche gli attributi provengono dallo schema della directory. uid, cn, mail e memberOf sono esempi, non specifiche universali. Sophos consiglia memberOf come Group name attribute, ma utilizza GID nel proprio esempio di configurazione generale. Pertanto, il valore restituito, la mappatura dei gruppi locali e le appartenenze multiple devono essere verificati con utenti di prova reali.

Selezionare crittografia e certificati

Plaintext invia le credenziali dell’utente non crittografate e non è una buona configurazione di produzione. SSL/TLS crittografa la connessione dall’inizio; STARTTLS aggiorna una connessione LDAP inizialmente non crittografata a TLS.

Quando si utilizza Validate server certificate, il campo Server IP/domain deve contenere il nome riportato nel certificato del server e risolvibile dal firewall. Sophos lo chiama CNAME nella guida di SFOS 22, mentre la stessa descrizione del campo altrove menziona semplicemente l’IP del server. Il nome riportato nel certificato è quindi la scelta sicura per un’implementazione TLS controllata. Se il firewall non riesce a risolverlo, è possibile creare una voce in Network > DNS > DNS host entry. TTL, ricerca inversa e test del resolver sono illustrati in Configurare le voci host DNS su Sophos Firewall.

Validate server certificate controlla il certificato del server LDAP remoto. L’opzione facoltativa Client certificate specifica un certificato utilizzato dal firewall per stabilire una connessione sicura al servizio LDAP; Google Secure LDAP richiede esplicitamente il certificato generato da Google. In caso di errori TLS, correggere prima nome, DNS, ora, validità e catena di attendibilità, anziché disattivare il controllo del certificato del server come prima misura.

Configurare il gruppo e il server LDAP

Preparare un gruppo locale

Aprire Authentication > Groups e selezionare Add.
Immettere un valore univoco per Group name, ad esempio LDAP-Benutzer.
Selezionare il valore di Group type per il metodo di accesso previsto. Normal richiede l’accesso dell’utente; Clientless controlla l’accesso in base a un indirizzo IP.
Configurare le policy necessarie per utenti, accesso remoto e autenticazione e salvare con Save.

Per Surfing quota e Access time, scegliere consapevolmente i limiti necessari. Sophos utilizza nell’esempio didattico Unlimited internet access e Allowed all the time; si tratta di policy di esempio, non di un requisito per LDAP. Per un accesso pilota limitato, sono più adatti la durata di utilizzo effettivamente necessaria e l’intervallo orario consentito. Lasciare gli altri campi ai valori predefiniti solo se questi sono coerenti con la propria policy di accesso.

Il gruppo verrà successivamente utilizzato come Default group. Di per sé non consente né blocca il traffico: l’accesso dipende dalle policy del gruppo e dalle regole del servizio interessato. Per le policy utente e le VPN di accesso remoto diverse da SSL VPN, le impostazioni specifiche dell’utente hanno la precedenza sulle policy di gruppo. Questa regola di precedenza non si applica alle SSL VPN di accesso remoto: un utente può accedere alle risorse di tutte le policy full tunnel e split tunnel applicabili a lui o ai suoi gruppi. Una policy utente più restrittiva non annulla quindi automaticamente le autorizzazioni più ampie dei gruppi SSL VPN. Ciò non garantisce che ogni schema LDAP rappresenti allo stesso modo le appartenenze multiple; l’assegnazione ai gruppi e le risorse effettivamente raggiungibili devono essere verificate nella fase pilota. La logica completa dei gruppi, con fase pilota, eccezioni specifiche per utente e gruppo principale, è descritta in Gestire in sicurezza i gruppi di utenti di Sophos Firewall.

Configurare la connessione e il bind

Aprire Authentication > Servers e selezionare Add.
Per Server type, selezionare LDAP server.
Assegnare un valore univoco a Server name, ad esempio LDAP-Firma.
Immettere l’IP del server o il nome del dominio in Server IP/domain. Per Validate server certificate, utilizzare il nome riportato nel certificato del server e risolvibile dal firewall.
Selezionare la Version 2 o 3 supportata dal server. Google Secure LDAP richiede la versione 3.
Impostare insieme Connection security e Port. In un ambiente di produzione utilizzare SSL/TLS o STARTTLS.
Disattivare Anonymous login e inserire Bind DN e Password dell’account di lettura.
Attivare Append base DN solo se il firewall deve aggiungere il Base DN a un Bind DN incompleto durante il bind.
Se la connessione è sicura, decidere consapevolmente se attivare Validate server certificate. Per i server LDAP standard, dopo aver preparato correttamente nome, DNS e catena di attendibilità, la verifica è la scelta sicura per l’ambiente di produzione. Google Secure LDAP segue il caso particolare descritto di seguito. Selezionare dall’elenco l’eventuale Client certificate richiesto.

Impostare la base di ricerca e gli attributi

Immettere il punto di partenza della ricerca utente in Base DN. Get base DN può ottenere la base di ricerca offerta dal server.
Impostare come Authentication attribute l’attributo contenente il nome di accesso, spesso uid o mail.
Immettere i valori di Display name attribute e Email address attribute appropriati per l’oggetto utente, ad esempio cn e mail.
Immettere l’attributo del gruppo restituito sull’oggetto utente in Group name attribute. memberOf è la raccomandazione di Sophos, ma deve corrispondere allo schema e al formato restituito.
Immettere il valore di Expiry date attribute appropriato per lo schema. Se non esiste alcun attributo di questo tipo, verificare prima dell’implementazione se il modulo accetta un valore vuoto e come vengono gestiti gli account senza scadenza.
Eseguire Test connection e salvare con Save.

Display name attribute e Email address attribute sono campi facoltativi per il server LDAP generico. Il nome visualizzato rende più facilmente riconoscibile l’oggetto utente locale; l’attributo email fornisce l’indirizzo associato. Per la creazione dei gruppi LDAP di Google, invece, l’attributo email è obbligatorio. Un Expiry date attribute indica la scadenza dell’account, non la durata di una sessione VPN. Sophos indica Date nell’esempio didattico generale e expiry per Google; il nome dell’attributo appropriato dipende dallo schema utilizzato.

Secondo Sophos, Test connection controlla la connessione e le credenziali di bind. Il test non dimostra né che il DN di base includa tutti gli utenti né che un’autorizzazione di gruppo o di servizio si applichi correttamente. A questo scopo è necessario un login reale.

Solo per l’automazione tramite API nel passaggio da SFOS 22 a SFOS 23: Nella documentazione dell’API LDAP cambiano le righe di Status Message Information: per Add LDAP server, da 200/500/502/503 a 200/400/401/403/409/500; per Edit LDAP server, da 200/500/503 a 200/400/401/403/404/500. 409 compare solo per Add, 404 solo per Edit. Anche i simboli di presentazione passano da Message.LDAP* a Message.CP*. Queste righe e questi simboli della documentazione non garantiscono i codici o i messaggi effettivamente trasmessi, né stabiliscono una corrispondenza fissa da 502/503 a 409/404. Per l’automazione tramite API, consultare la documentazione della versione utilizzata e verificare le risposte effettive del firewall di destinazione prima di adottare una corrispondenza. Questa verifica dell’API è separata; restano necessari il controllo Test connection nella GUI e un accesso reale.

Prima di ogni aggiunta o modifica automatizzata di un server LDAP: La documentazione di riferimento delle API per SFOS 22 e 23 presenta contraddizioni riguardo a IntegrationType: l’esempio riporta LooseIntegration/TightIntegration e contrassegna DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute ed ExpiryDateAttribute con il commento Only For Tight Integration; la tabella dei parametri descrive entrambe le modalità, ma ammette solo 1. Non dedurre da queste informazioni né il supporto di una modalità, né il significato di 1, né la possibilità di omettere attributi condizionali. L’esempio non è un payload pronto per l’invio; anche i valori testuali utilizzati per le opzioni di attivazione e disattivazione e per la sicurezza della connessione non corrispondono alle codifiche riportate nelle tabelle. Prima di apportare una modifica, verificare lo schema o la documentazione di riferimento delle API della versione di destinazione e controllare in sola lettura la configurazione effettiva di destinazione e una risposta API correlata. Se la corrispondenza rimane poco chiara, non eseguire alcuna automazione basata su di essa, ma utilizzare la procedura GUI verificata oppure chiarire le specifiche API con il supporto Sophos. I passaggi GUI descritti sopra restano separati da questa verifica; rimangono necessari Test connection e test reali per l’identità, i gruppi, la scadenza dell’account, se applicabile, e ciascun servizio utilizzato.

Abilitare LDAP per i servizi richiesti

Aprire Authentication > Services.
In Firewall authentication methods, spostare il server LDAP in Selected authentication servers. Se deve essere interrogato per primo, spostarlo in prima posizione.
Per Default group, selezionare il gruppo preparato LDAP-Benutzer e fare clic su Apply.
Selezionare il server separatamente per tutti i metodi effettivamente utilizzati: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods e SSL VPN authentication methods.
Utilizzare le opzioni di ereditarietà come Set authentication methods same as firewall, Same as firewall o Same as VPN solo se si desidera utilizzare l’elenco di server ereditato.

È possibile selezionare un massimo di 20 server per metodo di autenticazione. Se sono presenti più server, il firewall li interrogherà nell’ordine mostrato. Il metodo di autenticazione degli amministratori non si applica al Super Administrator. Per L2TP e PPTP, Sophos documenta solo PAP per LDAP; a causa del protocollo e delle tecnologie VPN ormai obsolete, questa combinazione non dovrebbe essere introdotta senza verifiche preliminari.

Passaggi aggiuntivi per gli accessi amministrativi: Al primo accesso, un utente autenticato esternamente tramite LDAP viene inizialmente creato come utente standard, anche se nella directory ha un ruolo amministrativo. Accedere prima con l’account previsto a un servizio abilitato, come il portale utente o il portale VPN. Quindi, utilizzando l’accesso amministrativo locale esistente, modificare l’utente appena creato in Authentication > Users, impostare User type su Administrator, selezionare un Profile limitato ai diritti necessari e salvare con Save. La sola selezione del server in Administrator authentication methods non è sufficiente. Verificare poi con questo account l’accesso a WebAdmin e le operazioni amministrative consentite e non consentite; mantenere comunque disponibile l’accesso locale di ripristino già testato.

Configurare Google Secure LDAP

Prima di configurare il firewall, creare un client LDAP nella Console di amministrazione Google in Apps > LDAP. Limitare le sue Access permissions, scaricare il certificato con la relativa chiave privata e generare credenziali di accesso separate. La password non è più visibile dopo aver chiuso la finestra di dialogo. Se il nome utente o la password sono errati o non sono più disponibili, generare nuove credenziali di accesso nella Console di amministrazione Google e poi aggiornare Bind DN e Password nella configurazione del server LDAP del firewall.

Google può modificare l’interfaccia e i passaggi della Console di amministrazione. Prima della configurazione, consultare quindi la documentazione Google aggiornata sulla creazione di client LDAP, sul download del certificato e sulla generazione delle credenziali di accesso. La disponibilità del servizio per la propria edizione Google è spiegata in Google Secure LDAP; le autorizzazioni di accesso devono corrispondere all’ambito di utenti e gruppi previsto.

La procedura documentata da Sophos nella Console di amministrazione Google può essere seguita così:

In Apps > LDAP, iniziare con ADD CLIENT, inserire un nome per il client LDAP e una Description, quindi selezionare CONTINUE. Un nome univoco come Sophos-Firewall-Pilot facilita la successiva identificazione.
Limitare le Access permissions all’ambito di utenti e gruppi necessario e confermare con ADD LDAP CLIENT.
Selezionare Download certificate. Lo ZIP contiene il file del certificato .cer e la chiave privata .key. Estrarre entrambi i file in una cartella di lavoro protetta e annotarne la posizione per la successiva importazione. La chiave privata non deve essere inserita nei ticket né in condivisioni non protette.
Proseguire con CONTINUE TO CLIENT DETAILS, aprire la scheda Authentication e selezionare GENERATE NEW CREDENTIALS. Conservare in modo sicuro Username e Password prima di selezionare CLOSE; questi valori verranno utilizzati successivamente come Bind DN e Password, non le credenziali di un amministratore Google.

Le credenziali di accesso Google non sostituiscono il certificato client. Per questa variante, Sophos Firewall richiede sia il certificato con la chiave privata sia le credenziali di bind generate.

Quindi attivare il client in Service status con ON for everyone e salvare con SAVE. Questo stato del servizio attiva il client ma non sostituisce le Access permissions impostate in precedenza.

Prima di importare il certificato, verificare in Administration > Time se il firewall riceve l’ora corretta tramite NTP. Secondo Sophos, un orologio impostato manualmente in modo errato può causare il fallimento dell’importazione dei certificati. Quindi, in Certificates > Certificates > Add, selezionare il formato CER (.cer) e importare sia Certificate sia Private key dal download di Google. Il certificato può risultare non attendibile perché è firmato da Google stesso; Sophos conferma che Google LDAP funziona comunque. Questa indicazione riguarda il certificato client e non la verifica del certificato del server LDAP.

Durante l’importazione, assegnare un nome univoco al certificato. Tramite Choose File, selezionare il file .cer estratto per Certificate e il relativo file .key per Private key, confermare ciascuna selezione con Open e infine selezionare Save. Solo dopo il salvataggio è possibile selezionare questo certificato in Client certificate nel server LDAP.

I seguenti valori si applicano al 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: immettere il valore o recuperarlo con Get base DN
Authentication attribute: UID
Display name attribute: CN
Email address attribute: mail
Group name attribute: memberOf
Expiry date attribute: expiry

mail è obbligatorio per la creazione dei gruppi LDAP di Google. La guida Sophos per Google Secure LDAP non imposta esplicitamente Validate server certificate nel proprio elenco di valori. Da ciò non si può dedurre alcun obbligo di attivazione o disattivazione; l’opzione viene decisa in base alla procedura generale TLS e alla propria catena di attendibilità. La visualizzazione di un certificato client Google non attendibile non è un motivo per disattivare la verifica del certificato del server remoto.

Verificare la connessione Google con Test connection e salvare il server con Save. Quindi preparare un gruppo LDAP locale come descritto sopra e selezionare il server Google in Authentication > Services per i servizi necessari. Anche per Google, la sola creazione dell’oggetto server non rende ancora utilizzabile alcun servizio; il successivo accesso pilota verifica identità, gruppo e autorizzazione.

Verificare l’accesso e l’assegnazione ai gruppi

Il collaudo comprende connessione, identità e autorizzazione:

Test connection deve confermare la connessione e le credenziali di bind.
In Authentication > Services controllare l’elenco dei server, l’ordine e l’ereditarietà di ciascun metodo utilizzato. Il campo Default group appartiene a Firewall authentication methods.
Accedere al servizio previsto con un utente pilota. Al primo accesso, il firewall crea localmente l’utente autenticato esternamente.
In Authentication > Users, verificare che l’utente e il gruppo vengano visualizzati come previsto.
Effettuare un test positivo per ciascun gruppo di directory rilevante. Verificare inoltre con un utente senza un’assegnazione di gruppo locale adeguata se si applica il valore previsto di Default group.
Verificare non solo l’accesso, ma anche la policy prevista o la regola di test. Per SSL VPN, testare le risorse consentite e bloccate tenendo conto delle policy utente e di gruppo applicabili; non dedurre i diritti effettivi dalla sola presenza di una policy utente restrittiva. Quindi utilizzare una password errata come test negativo.
Per l’accesso degli utenti, l’autorizzazione e l’accounting, controllare access_server.log; per problemi del portale VPN, controllare anche vpnportal.log.
Se viene utilizzato un attributo di scadenza, includere un account di prova con stato di scadenza noto.

Se i valori dello schema non sono chiari, un amministratore può interrogare l’oggetto utente in sola lettura da un sistema di amministrazione Linux o direttamente 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)' '*' '+'

Questa procedura diagnostica facoltativa non è un comando SFOS e non deve essere eseguita nella Advanced Shell. L’esempio presuppone LDAPS e l’attendibilità della CA del server sul sistema di esecuzione; STARTTLS richiede un comando adattato di conseguenza. -W richiede interattivamente la password di bind. Adattare il filtro (uid=max.muster) all’attributo configurato in Authentication attribute. '*' e '+' possono restituire molti attributi normali e operativi contenenti dati personali. Prima di allegare o condividere l’output, ad esempio in un ticket, anonimizzarlo.

Isolare gli errori in base al sintomo

Nessuna connessione: Verificare routing, DNS, porta e Connection security. Quindi controllare Bind DN, password e Anonymous login.
Errore TLS o del certificato: Verificare il nome riportato nel certificato del server, la risoluzione DNS, l’ora del firewall, la validità e la catena CA. Non disattivare la verifica del certificato come prima misura.
Test connection funziona, ma l’utente non viene trovato: Confrontare Base DN, Authentication attribute e nome di accesso inserito.
L’accesso funziona, ma il gruppo è errato: Controllare Group name attribute e il suo valore effettivamente restituito, la mappatura dei gruppi locali e Default group. memberOf è una raccomandazione, ma non una mappatura garantita per ogni schema.
Il server è stato creato ma non viene utilizzato: Controllare selezione, ordine ed ereditarietà per il servizio interessato in Authentication > Services.
Il bind a Google Secure LDAP non riesce: Controllare singolarmente la versione 3, la porta 636, la disattivazione di Anonymous login e di Append base DN, lo stato del servizio client, le credenziali e il certificato client Google.
La ricerca è lenta o restituisce account indesiderati: Limitare il Base DN al sottoalbero necessario.
L’accesso funziona, ma la policy prevista non si applica: Controllare separatamente le impostazioni specifiche dell’utente, la policy di gruppo, la mappatura dei gruppi e la regola firewall o VPN pertinente. Per SSL VPN, includere tutte le policy utente e di gruppo applicabili e le risorse effettivamente consentite; una policy utente restrittiva da sola non è sufficiente. Il modello diagnostico completo è illustrato in Risolvere sistematicamente gli errori di autenticazione.
L’accesso al portale funziona, ma l’accesso a WebAdmin no: In Authentication > Users, verificare il ruolo amministrativo assegnato manualmente e il Profile. Quindi controllare la selezione del server in Administrator authentication methods e le regole di accesso al dispositivo applicabili. Non rinunciare all’accesso locale di ripristino prima di aver verificato il nuovo metodo.

Eseguire il rollback in sicurezza

In caso di implementazione non riuscita, ripristinare innanzitutto la selezione, l’ordine e l’ereditarietà dei server precedentemente documentati per ciascun metodo interessato. In Firewall authentication methods, ripristinare inoltre il precedente valore di Default group. Effettuare un test positivo e uno negativo utilizzando il metodo di autenticazione precedente e verificare i relativi log.

Eliminare il nuovo server LDAP e il gruppo solo quando non vengono più utilizzati in alcun servizio o policy. Non rimuovere gli utenti LDAP creati automaticamente con Purge AD users: la guida di SFOS 22 documenta questa funzione solo per Active Directory. Se è necessario rimuovere tali utenti, chiarire in anticipo la modalità supportata per la propria configurazione con il supporto Sophos.