Sophos Firewall: migrare eDirectory prima di SFOS 23

SFOS 23.0 non supporta più il server di autenticazione eDirectory nativo. Se sul firewall rimane una configurazione server eDirectory nativa, l’upgrade del firmware a SFOS 23.0 o versioni successive non riesce. Prima dell’upgrade deve quindi essere operativo un server di autenticazione supportato e la configurazione nativa del server e dell’SSO eDirectory deve essere completamente rimossa.

In SFOS 22.0 MR2 eDirectory continua a funzionare. Questo periodo deve essere utilizzato per un funzionamento parallelo controllato: aggiungere la nuova sorgente, verificare utenti e gruppi con account reali, migrare in modo controllato i servizi di autenticazione ed eliminare eDirectory solo quando il rollback non è più necessario. I servizi Entra ID SSO collegati vengono gestiti insieme. La panoramica di MR2 inquadra le altre modifiche di questa versione.

Procedura rapida

Censire tutte le dipendenze eDirectory in server, gruppi, servizi, regole, VPN e SSO.
Preparare un backup aggiornato, un amministratore locale e un accesso alla console documentato.
Scegliere come destinazione LDAP generico, Active Directory, RADIUS o Microsoft Entra ID SSO in base all’utilizzo.
Aggiungere in parallelo il nuovo server di autenticazione e verificare connessione, utenti e gruppi.
Mappare consapevolmente gruppi e policy sulla nuova sorgente.
Migrare in modo controllato i servizi in Authentication > Services e testarli con account reali; gestire insieme i servizi Entra ID SSO collegati.
Solo dopo la convalida completa, eliminare tutte le configurazioni native di server e SSO eDirectory, creare un nuovo backup e avviare l’upgrade a SFOS 23.

Non si tratta volutamente di una migrazione eseguibile con un solo interruttore. Il firewall utilizza i server di autenticazione per ogni servizio e secondo un ordine definito. Inoltre, le autorizzazioni dipendono spesso da gruppi che, dopo la migrazione, possono avere lo stesso nome ma non necessariamente la stessa assegnazione e lo stesso effetto.

Individuare le dipendenze attuali da eDirectory

Prima della prima modifica deve essere chiaro dove viene effettivamente utilizzato eDirectory. L’inventario deve includere almeno questi ambiti:

In Authentication > Servers sono presenti i server eDirectory ed eventualmente più destinazioni di directory.
In Authentication > Services viene definito per ogni servizio quali server vengono interrogati e in quale ordine.
In Authentication > Groups, le policy di gruppo, il Default Group e l’ordine dei gruppi possono determinare i diritti effettivi di un utente. Con Active Directory si aggiungono la Main Group e le altre appartenenze.
Le regole firewall, le policy Web e Application e il Traffic Shaping possono fare riferimento a utenti o gruppi.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal e Captive Portal dispongono di percorsi di accesso e autorizzazione propri.
MFA e accessi amministrativi possono dipendere dai gruppi e dall’ordine di autenticazione.
I report basati sugli utenti e il riconoscimento trasparente degli utenti continuano a richiedere un’associazione affidabile tra utente e connessione.

Uno screenshot dell’ordine attuale di server, servizi e gruppi è spesso più utile di un semplice elenco di nomi. Per ogni gruppo importante è inoltre opportuno annotare almeno un utente di test positivo e uno negativo. In questo modo sarà possibile verificare in seguito non solo chi ottiene l’accesso, ma anche chi viene correttamente respinto.

Scegliere il metodo di destinazione adatto

Non esiste un sostituto universale 1:1 per ogni ambiente eDirectory. Un’azienda può continuare a utilizzare la directory esistente tramite LDAP, migrare le identità in un’altra directory o combinare più metodi di autenticazione in base al servizio.

Continuare a usare eDirectory tramite LDAP generico

Se eDirectory rimane operativo, Sophos Firewall può interrogarlo per gli accessi utente mediante il tipo di server supportato LDAP server. Questo metodo non modifica automaticamente l’albero della directory, ma richiede una nuova configurazione LDAP con Base DN e attributi di accesso e di gruppo adeguati.

È importante comprenderne il limite: l’SSO eDirectory nativo non è più disponibile da SFOS 23. Il server LDAP generico verifica l’accesso, ma non esegue il riconoscimento trasparente degli utenti. Gli utenti che in precedenza venivano riconosciuti automaticamente necessitano quindi di un nuovo flusso SSO o di accesso. La descrizione completa dei campi è disponibile in Collegare un server LDAP generico a Sophos Firewall.

Active Directory

Active Directory è adatto quando gli utenti sono già presenti in un dominio Windows o vengono consapevolmente migrati in tale dominio. È quindi necessario importare i gruppi, ricontrollare Main Group e policy e configurare separatamente l’eventuale riconoscimento trasparente degli utenti. Collegare Active Directory a Sophos Firewall descrive LDAPS, importazione dei gruppi e test dei servizi.

STAS comunica in modo trasparente al firewall gli accessi al dominio Windows, ma non converte la configurazione SSO eDirectory precedente. Chi necessita di questo percorso di identità deve pianificarlo come migrazione separata con STAS per Sophos Firewall.

RADIUS

RADIUS è adatto quando è già presente un servizio di autenticazione centrale o un gateway MFA. Il server RADIUS deve fornire al firewall le informazioni necessarie per il rispettivo servizio; il modello dei gruppi di directory non viene trasferito automaticamente. Il metodo MFA deve essere compatibile con il servizio: VPN Portal, per esempio, non supporta MFA RADIUS basata su challenge. Shared Secret, attributo di gruppo, timeout e altri limiti sono descritti in Configurare un server RADIUS su Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO può essere utile per gli scenari documentati relativi a portali, amministratori e Remote Access. Non è però un sostituto generale per ogni interrogazione con nome utente e password e non offre un riconoscimento trasparente degli utenti LAN. Per il Remote Access, i servizi collegati devono essere coordinati: VPN Portal e SSL VPN utilizzano lo stesso server Entra; con un file di provisioning, ciò vale anche per IPsec. Redirect URI, gruppi, Conditional Access e servizi supportati sono descritti in Microsoft Entra ID SSO per Sophos Connect e VPN Portal.

L’architettura di destinazione può essere mista. Per esempio, LDAP può inizialmente autenticare gli utenti dell’eDirectory esistente, mentre il Remote Access viene successivamente migrato in modo mirato a RADIUS o Entra ID SSO. È fondamentale che ogni servizio utilizzato disponga di un percorso di destinazione testato prima di eliminare eDirectory.

Mettere in sicurezza l’ambiente prima della prima modifica

Prima del cutover devono essere disponibili i seguenti elementi:

Un backup di Sophos Firewall aggiornato e cifrato.
Un amministratore locale il cui accesso non dipenda da eDirectory o dalla nuova sorgente esterna. In Authentication > Services, Local deve rimanere selezionato in Administrator authentication methods.
Un accesso alla console o un altro accesso di emergenza documentato al firewall.
Screenshot o un inventario scritto dell’ordine di server, servizi e gruppi.
Almeno un account di test per ogni gruppo importante e un account che non deve ottenere l’accesso.
Una finestra di manutenzione, un responsabile della decisione e un criterio di rollback chiaro.

L’accesso WebAdmin viene migrato per ultimo. Prima si verifica che Local sia ancora selezionato e che l’accesso locale funzioni in una finestra privata del browser. In questo modo rimane disponibile un accesso indipendente qualora la nuova autenticazione esterna o la risoluzione dei gruppi non funzionino come previsto.

Configurare il server di destinazione in parallelo

Il nuovo server viene inizialmente aggiunto come server supplementare. Durante la configurazione iniziale, la selezione eDirectory esistente rimane invariata; solo per il test pilota viene modificato un singolo metodo di autenticazione controllabile.

Esempio: collegare eDirectory come server LDAP generico

In Authentication > Servers > Add, una configurazione pilota potrebbe essere simile alla seguente:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: per esempio uid, dopo aver verificato l’oggetto utente
Group name attribute: per esempio groupMembership, dopo aver verificato l’oggetto utente
Validate server certificate: attivato dopo aver configurato come attendibile sul firewall la CA emittente

edir01.example.net, Bind DN e Base DN sono valori di esempio e devono essere adattati al proprio albero di directory. Quando è attiva la convalida del certificato, il nome FQDN configurato deve corrispondere al certificato del server ed essere risolvibile dal firewall. L’account di bind necessita esclusivamente dell’accesso in lettura all’area di directory richiesta.

Gli attributi di accesso e di gruppo corretti dipendono dall’oggetto utente reale. In un ambiente eDirectory, per esempio, cn o uid possono essere rilevanti per l’accesso e groupMembership per i gruppi. Si tratta di valori da verificare, non di impostazioni universali.

Da un sistema di amministrazione Linux è possibile controllare un oggetto utente in sola lettura:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Il comando non deve essere eseguito nell’Advanced Shell di Sophos Firewall. -W richiede la password di bind in modo interattivo, evitando che venga salvata nella cronologia della shell. Il percorso in LDAPTLS_CACERT, il nome FQDN, i DN, il filtro e gli attributi richiesti devono essere adattati al proprio ambiente. Se il client OpenLDAP locale considera già attendibile la CA tramite il proprio Trust Store o ldap.conf, LDAPTLS_CACERT può essere omesso. In caso contrario, la variabile deve indicare un bundle CA PEM leggibile.

Un possibile output potrebbe essere simile al seguente:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Si tratta di un esempio di lettura, non di uno schema eDirectory garantito. Se groupMembership manca o la directory restituisce valori diversi, è necessario identificare l’attributo effettivo e adattare di conseguenza la configurazione del firewall. Successivamente, occorre verificare separatamente Test connection, un accesso utente reale e il gruppo risultante.

Mappare nuovamente gruppi e policy

Un accesso riuscito non è sufficiente se l’utente viene poi assegnato al gruppo errato. Si supponga che il gruppo precedente VPN-Mitarbeitende sia autorizzato a utilizzare SSL VPN e a raggiungere applicazioni interne mediante una regola basata sugli utenti. Dopo la migrazione è necessario rispondere almeno alle domande seguenti:

L’utente di test appare in Authentication > Users con il gruppo effettivo previsto? Con Active Directory, Main Group e altre appartenenze vengono verificate separatamente.
Il nuovo gruppo è presente in Authentication > Groups e si trova nella posizione corretta?
La configurazione SSL VPN o IPsec fa riferimento al nuovo gruppo effettivo?
L’utente continua a corrispondere alla regola firewall prevista e non a una regola più generale?
Viene ancora applicata la policy MFA desiderata?

Nomi di gruppi visibili identici provenienti da due sorgenti non garantiscono né la stessa appartenenza né la stessa priorità effettiva del gruppo. Con Active Directory, l’ordine dei gruppi e la Main Group possono influenzare VPN, MFA e altre policy. I principi di base sono descritti in Attivare MFA su Sophos Firewall.

Migrare un servizio alla volta

In Authentication > Services, i server di autenticazione vengono selezionati per servizio. Per questo motivo, non si migra tutto contemporaneamente. I servizi Entra ID SSO collegati vengono tuttavia pianificati e convalidati come un unico percorso.

Selezionare innanzitutto un servizio controllabile e un utente pilota.
Selezionare il nuovo server per questo servizio e definire consapevolmente la sua posizione nell’ordine dei server.
Applicare la modifica e testare un accesso corretto e uno intenzionalmente errato.
Verificare utente, gruppo, voce di log e policy effettivamente applicata.
Migrare il servizio successivo solo dopo questa verifica.

Si inizia con un servizio pilota scelto consapevolmente e facilmente controllabile. Seguono quindi gli ambiti effettivamente utilizzati, come Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods e Remote Access IPsec. Con Entra ID SSO, i servizi Remote Access collegati descritti in precedenza vengono migrati in modo coordinato. A causa del rischio di lockout, Administrator authentication methods viene migrato per ultimo. La panoramica dei portali Sophos Firewall spiega quali portali funzionano separatamente e devono essere raggiungibili.

Se lo stesso nome utente esiste sul server precedente e su quello nuovo, l’ordine dei server può nascondere una mappatura errata del gruppo. Per un test controllato, è possibile selezionare temporaneamente solo il nuovo server nel servizio pilota prescelto. L’accesso reale e Authentication > Users mostrano quindi se la nuova sorgente fornisce l’utente con il gruppo previsto.

Convalidare con connessioni reali

Test connection conferma la raggiungibilità e le credenziali del server. La verifica termina però solo quando funzionano il servizio reale e l’autorizzazione associata.

Per ogni gruppo rilevante, la convalida deve dimostrare almeno quanto segue:

Un utente autorizzato può accedere al portale o al servizio VPN previsto.
Un utente non autorizzato viene respinto oppure riceve esclusivamente la policy limitata prevista.
In Authentication > Users, utente e gruppo sono corretti.
Il Log Viewer mostra un evento di autenticazione comprensibile.
Le policy firewall, Web e VPN corrispondono alla regola prevista.
Le destinazioni interne sono raggiungibili tramite il percorso di traffico previsto.
MFA e ruoli amministrativi si comportano come pianificato.

Con Firewall Rule Testing e Log Viewer è possibile verificare quale Rule ID viene applicata a un utente e al relativo traffico. Il riconoscimento trasparente degli utenti o SSO viene testato separatamente; un accesso LDAP riuscito non convalida questo percorso.

Rollback durante la fase pilota

Finché il firewall utilizza ancora SFOS 22.0 MR2 ed eDirectory non è stato eliminato, la configurazione precedente rimane disponibile come rollback controllato. Se un test pilota non riesce, vengono ripristinati tutti i valori modificati per il test: selezione e ordine dei server in Authentication > Services, Default Group e ordine dei gruppi, nonché membri VPN, riferimenti MFA e riferimenti alle policy interessati. Successivamente vengono nuovamente verificati accesso, gruppo e policy.

Il backup protegge la configurazione del firewall, ma non costituisce una migrazione automatica delle identità. Il backup e l’importazione della configurazione non convertono né migrano la configurazione eDirectory contenuta. Dopo l’upgrade, un backup di questo tipo non rappresenta quindi un rollback eDirectory funzionante.

Rimuovere eDirectory e autorizzare SFOS 23

eDirectory viene rimosso solo dopo un periodo di osservazione definito in anticipo. Durante questo periodo, ogni percorso di accesso utilizzato in produzione, ogni gruppo importante, le connessioni VPN utilizzate e le procedure amministrative devono aver funzionato correttamente almeno una volta con la nuova sorgente in condizioni realistiche; errori di autenticazione, gruppo o policy non chiariti impediscono l’autorizzazione alla rimozione.

Per concludere:

Verificare che eDirectory non sia più selezionato in alcun metodo di autenticazione.
Confrontare nuovamente le dipendenze di gruppi, VPN, policy, MFA, amministratori e SSO con l’inventario.
Eliminare dal firewall tutte le configurazioni native di server e SSO eDirectory. Un LDAP server generico appena creato che interroga la stessa directory rimane configurato.
Verificare in Authentication > Servers, Authentication > Services e nell’inventario che non rimangano configurazioni o dipendenze eDirectory native.
Creare un nuovo backup cifrato della configurazione ripulita.
Verificare la guida generale Aggiornamento del firmware Sophos Firewall: preparazione e best practice e le indicazioni correnti su release, upgrade e Known Issues di SFOS 23. Avviare l’upgrade solo dopo queste verifiche.

L’errore di upgrade in presenza di una configurazione server eDirectory nativa e la necessità di rimuoverla prima di SFOS 23 sono confermati da Sophos. Prima dell’upgrade in produzione vengono inoltre verificate le indicazioni definitive su release, upgrade e Known Issues di SFOS 23 per individuare ulteriori dettagli.

Errori tipici

Test connection riesce, ma l’utente viene assegnato al gruppo errato: verificare Base DN, attributi di accesso e di gruppo nell’oggetto utente reale e ordine dei gruppi.
Il test pilota sembra funzionare, ma potrebbe utilizzare ancora eDirectory: selezionare temporaneamente solo il nuovo server nel servizio pilota controllato e verificare quindi utente, gruppo e policy.
User Portal funziona, ma la VPN no: controllare separatamente il metodo di autenticazione e il gruppo di autorizzazione per ogni portale e servizio VPN.
L’accesso LDAP funziona, ma il riconoscimento trasparente no: l’SSO eDirectory nativo non è più disponibile da SFOS 23. LDAP generico verifica l’accesso, ma non offre il riconoscimento trasparente degli utenti.
Dopo la migrazione dei gruppi viene applicata un’altra regola firewall: confrontare gruppo effettivo, ordine dei gruppi e riferimenti diretti a utenti o gruppi nelle policy. Con Active Directory, verificare anche Main Group e le altre appartenenze.
Il backup viene pianificato come futuro rollback eDirectory: in SFOS 23 la configurazione eDirectory contenuta non viene migrata; il rollback deve funzionare prima dell’upgrade.