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, Connetti Active Directory a Sophos Firewall è la soluzione migliore. 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

Obbligatorio:

Accesso WebAdmin a Sophos Firewall;
raggiungibilità del server LDAP dal firewall sulla porta configurata sul server;
un account Bind con diritti di lettura sull’area della directory richiesta;
il DN di bind e il Base DN, ad esempio cn=svc-sophos,ou=service,dc=example,dc=net e ou=people,dc=example,dc=net;
gli attributi di login, nome visualizzato, indirizzo email, gruppo e, se applicabile, scadenza dell’account;
se è attiva la validazione 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 Bind non richiede permessi di scrittura amministrativa. Limita i suoi diritti di lettura al sottoalbero e agli attributi necessari al firewall per le richieste degli utenti.

Prima di passare a Authentication > Services, documentare i server selezionati, il loro ordine e le opzioni di ereditarietà per ciascun metodo interessato. Registra anche il precedente Default group sotto Firewall authentication methods. Ciò consente di annullare la modifica senza eliminare frettolosamente nuovi oggetti.

Distinguere il DN di associazione, il DN di base e gli 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 DN di base troppo stretto non troverà tutti gli utenti di cui hai bisogno. Una base di ricerca inutilmente ampia può rallentare le ricerche e includere elementi indesiderati. Append base DN aggiunge il DN di base a un DN di associazione incompleto durante l’associazione; Se il DN è già completo, l’opzione resta normalmente disattivata. Fondamentale è 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.

Seleziona 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.

Per Validate server certificate, il nome specificato nel certificato del server e risolvibile dal firewall deve essere sotto Server IP/domain. Sophos lo chiama CNAME nella guida di SFOS 22, mentre la stessa descrizione del campo altrove menziona semplicemente l’IP del server. Il nome del 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. Per gli errori TLS, correggi prima il nome, il DNS, l’ora, la validità e la catena di attendibilità invece di disattivare il controllo del certificato del server come primo passaggio.

Configura il gruppo e il server LDAP

Preparare un gruppo locale

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

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. Le policy specifiche dell’utente hanno la precedenza su quelle di gruppo. La logica completa dei gruppi, con utente pilota, override utente e Main Group, è descritta in Gestire in sicurezza i gruppi di utenti di Sophos Firewall.

Configurare la connessione e il bind

Aprire Authentication > Servers e selezionare Add.
Selezionare LDAP server come Server type.
Assegnare uno Server name univoco, 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.
Accendere Append base DN solo se il server deve aggiungere il DN di base durante il bind.
Se la connessione è sicura, decidere consapevolmente se Validate server certificate è attivato. Per i server LDAP standard, il controllo dopo la corretta preparazione di nome, DNS e attendibilità è la scelta di produzione sicura. Google Secure LDAP segue il caso speciale descritto di seguito. Selezionare dall’elenco l’eventuale Client certificate richiesto.

Imposta 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.
Imposta l’attributo con il nome di accesso come Authentication attribute, spesso uid o mail.
Immettere Display name attribute e Email address attribute per far corrispondere 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 l’Expiry date attribute che corrisponde allo schema. Se non esiste alcun attributo di questo tipo, controlla prima dell’implementazione se il modulo accetta un valore vuoto e come vengono gestiti gli account senza scadenza.
Esegui Test connection e salva con Save.

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.

Abilita 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.
Selezionare il gruppo preparato LDAP-Benutzer come Default group 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; questa combinazione non dovrebbe essere introdotta senza verificare a causa del protocollo e delle procedure VPN ormai superate.

Configura Google Secure LDAP

Prima di configurare il firewall, creare un client LDAP nella Console di amministrazione Google in Apps > LDAP. I suoi Access permissions sono limitati, vengono scaricati il certificato e la relativa chiave privata e vengono generati dati di accesso separati. 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 di iniziare, consultare la documentazione Google aggiornata sulla creazione di client LDAP, sul download del certificato e sulla generazione delle credenziali di accesso.

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 seleziona il formato CER (.cer) sotto Certificates > Certificates > Add e importa sia Certificate che Private key dal download di Google. Il certificato potrebbe sembrare inaffidabile perché Google stesso lo firma; Sophos conferma che Google LDAP funziona ancora. Questa indicazione riguarda il certificato client e non il controllo del certificato del 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: spento
Bind DN e Password: le credenziali LDAP di Google generate
Append base DN: spento
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 è richiesto per la creazione del gruppo LDAP di Google. Le istruzioni ufficiali di Google non impostano esplicitamente Validate server certificate nel loro elenco di valori. Senza un test di laboratorio SFOS-22, non se ne deve dedurre alcuna indicazione tassativa di attivazione o disattivazione; l’opzione viene decisa in base alla procedura generale TLS e alla propria catena di attendibilità.

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 Default group appartiene a Firewall authentication methods.
Accedi al servizio previsto con un utente pilota. Quando accedi per la prima volta, 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 lo Default group previsto.
Verificare non solo l’accesso, ma anche la policy prevista o la regola di test. 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 inoltre 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)' '*' '+'

Questo percorso diagnostico facoltativo non è un comando SFOS e non appartiene ad Advanced Shell. L’esempio presuppone LDAPS e fiducia nella CA del server sul sistema di esecuzione; STARTTLS richiede una chiamata adattata di conseguenza. -W richiede interattivamente la password di bind. Adattare il filtro (uid=max.muster) allo Authentication attribute configurato. '*' e '+' possono emettere molti attributi normali e operativi con dati personali. Prima di allegare o condividere l’output, ad esempio in un ticket, anonimizzarlo.

Isola gli errori per sintomo

Nessuna connessione: Controlla routing, DNS, porta e Connection security. Quindi controllare Bind DN, password e Anonymous login.
Errore TLS o certificato: Controlla il nome dal certificato del server, la risoluzione DNS, l’ora del firewall, la validità e la catena CA. Non disattivare la verifica del certificato come primo passo.
Test connection funziona, ma l’utente non viene trovato: Confronta il DN di base, Authentication attribute e il nome di accesso inserito.
Il login funziona, il gruppo è sbagliato: Controlla Group name attribute e il suo reale valore restituito, mappatura del gruppo locale e Default group. memberOf è una raccomandazione, ma non una mappatura garantita per ogni schema.
Il server viene creato ma non viene utilizzato: Controllare la selezione, l’ordine e l’ereditarietà per il servizio interessato in Authentication > Services.
Il bind a Google Secure LDAP non riesce: Versione 3, porta 636, Anonymous login disattivato, Append base DN disattivato, controlla individualmente lo stato del servizio client, le credenziali e il certificato client Google.
La ricerca è lenta o restituisce account indesiderati: Limita il DN di base alla sottostruttura richiesta.
L’accesso funziona, la policy prevista no: Controlla separatamente l’override dell’utente, la policy di gruppo, la mappatura del gruppo e il firewall o la regola VPN responsabile. Il modello diagnostico completo mostra Risolvere sistematicamente gli errori di autenticazione.

Eseguire il rollback in sicurezza

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

Elimina il nuovo server e gruppo LDAP solo quando non vengono più utilizzati in alcun servizio o policy. Non pulire 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.