Sophos Firewall: AD SSO non funziona dopo l'upgrade a SFOS 22

Dopo un upgrade da SFOS 21.5 o precedente a SFOS 22.0 GA, Active Directory Single Sign-On con Kerberos e NTLM può smettere immediatamente di funzionare. Il firewall continua a inoltrare il traffico, ma non riconosce più gli utenti di dominio interessati. Di conseguenza, le regole firewall basate sugli utenti non vengono applicate come previsto.

⚠️ Il cleanup deve essere usato solo nella Advanced Shell e soltanto se il percorso di upgrade e i sintomi corrispondono. Non eseguire il comando in modo generico se il firewall usa già MR1 Build 490 o successivo, se il problema esisteva prima dell’upgrade o se è interessato un cluster HA.

Se il firewall esegue ancora SFOS 22.0 GA e nasm.log contiene un errore unknown option del momento in cui si è verificato il problema, NASM può essere ricreato in modo mirato. Le verifiche seguenti impediscono di usare il cleanup per un normale problema di DNS, SPN o domain join.

Sophos ha corretto l’errore di upgrade alla base del problema in SFOS 22.0 MR1 Build 490. Il cleanup è quindi una riparazione mirata per il caso di upgrade GA qui descritto, non una soluzione generale per ogni problema AD SSO.

Quando si applica questa procedura

La procedura è pensata per il seguente caso:

• upgrade da SFOS 21.5 o precedente a SFOS 22.0 GA
• AD SSO con Kerberos e NTLM funzionava prima dell’upgrade
• in seguito gli utenti di dominio non riescono più ad autenticarsi tramite AD SSO
• le regole basate sull’identità non riconoscono più gli utenti
• le altre funzioni del firewall e gli accessi non basati su AD continuano a funzionare

Un Test connection riuscito in Authentication > Servers non esclude questo errore. Il test conferma la connessione al Domain Controller e le credenziali, ma non l’intero flusso AD SSO.

Se fallisce già Test connection, la causa probabile riguarda raggiungibilità, DNS, porta, certificato o account di servizio. Queste basi sono spiegate in Collegare Active Directory a Sophos Firewall.

Verificare l’errore in nasm.log

Accedere al firewall tramite SSH e aprire 5. Device Management > 3. Advanced Shell. L’accesso SSH a Sophos Firewall è spiegato separatamente.

Cercare quindi il messaggio documentato da Sophos:

grep "unknown option" /log/nasm.log

Una corrispondenza conferma lo stato difettoso di Samba/NASM. Il timestamp deve coincidere con l’upgrade e il guasto; una voce vecchia non dimostra un problema attuale.

Una risposta vuota non esclude con certezza l’errore. Senza il percorso di upgrade corrispondente e i sintomi descritti, il cleanup non deve però essere eseguito alla cieca. Occorre prima verificare DNS, SPN, domain join, Redirection Location, fiducia del browser e la normale configurazione Kerberos/NTLM.

Pulire NASM in modo mirato

Durante un cambio firmware, SFOS ricrea le directory NASM per la versione Samba in uso. Nell’upgrade interessato, questo passaggio può rimanere incompleto. Il nuovo NASM carica quindi componenti Samba più vecchi e incompatibili e AD SSO smette di funzionare.

Prima della modifica vanno documentati la versione firmware attuale, il momento del guasto e l’output di nasm.log. Deve essere disponibile un accesso amministratore locale o alternativo nel caso in cui l’autenticazione non sia disponibile durante l’intervento.

Eseguire nella Advanced Shell:

opcode -ds nosync nasm_cleanup

Il comando pulisce la struttura NASM interessata e la ricrea per Samba 4.22.1. Secondo Sophos, normalmente non serve un riavvio. Non è documentato un messaggio di riuscita specifico; il risultato va quindi verificato con un nuovo accesso AD SSO e non sulla base di una singola risposta della shell.

Verificare AD SSO con traffico utente reale

Dopo il cleanup, un altro Test connection non basta. La verifica si esegue con un utente di dominio e una regola realmente basata sugli utenti:

1. Su un client di dominio, aprire una nuova connessione browser che utilizzi AD SSO e una regola firewall basata sugli utenti.
2. In Current activities > Live users, verificare che l’utente di dominio compaia di nuovo.
3. In Log viewer > Authentication, controllare che Kerberos o NTLM venga utilizzato correttamente e che non compaiano nuovi errori NASM corrispondenti.
4. Nel log firewall, verificare che utente, gruppo e Firewall Rule ID corrispondano alla regola prevista.
5. Testare l’applicazione o la destinazione che non era raggiungibile prima del cleanup.

Il problema è risolto solo quando sono corretti sia l’identità utente sia il match della regola. Se compare di nuovo soltanto un accesso Captive Portal o se l’utente resta assente, vanno controllati anche SPN, risoluzione DNS, Redirection Location e fiducia del browser. I file di autenticazione rilevanti sono elencati in Servizi e log di Sophos Firewall.

Soluzione permanente e alternativa senza Advanced Shell

Aggiornare a una versione SFOS corretta

La soluzione permanente è un upgrade a SFOS 22.0 MR1 Build 490 o successivo. Prima di un altro cambio firmware, verificare percorso di upgrade, backup, storage, HA e via di ritorno con il controllo per l’upgrade a SFOS 22.

Se lo stesso sintomo compare per la prima volta su MR1 Build 490 o una versione successiva, l’errore di upgrade GA descritto qui non corrisponde più chiaramente. Non ripetere il cleanup: eseguire la normale diagnosi AD SSO e, se necessario, coinvolgere Sophos Support.

Se Advanced Shell non è disponibile

Sophos indica come alternativa un altro cambio firmware:

• Se il firewall è già stato riavviato in SFOS 21.5, avviarlo nuovamente in SFOS 22.0 GA.
• Se il firewall esegue SFOS 22.0 GA, avviarlo prima nello slot firmware SFOS 21.5 disponibile e poi tornare a SFOS 22.0 GA.

Questo passaggio avanti e indietro avvia nuovamente la creazione delle directory NASM. Provoca un’interruzione e non equivale a un normale riavvio. Sono quindi obbligatori un backup attuale, uno slot firmware disponibile e avviabile, accesso console, una finestra di manutenzione e una via di ritorno verificata. Se mancano questi requisiti, è più sicuro aggiornare direttamente a una versione corretta o coordinare la procedura con Sophos Support.

Quando il cleanup non è la soluzione corretta

nasm_cleanup non è un comando di riparazione generale. Serve un altro percorso diagnostico quando:

• il firewall esegue già SFOS 22.0 MR1 Build 490 o successivo
• il problema esisteva prima dell’upgrade
• Test connection con il server AD fallisce
• sono interessati solo singoli utenti, gruppi o browser
• sono interessati STAS, Microsoft Entra ID SSO, RADIUS o un normale accesso LDAP
• DNS, SPN, domain join, certificati o fiducia del browser non funzionano correttamente
• il percorso di upgrade o il momento del guasto non corrisponde all’errore descritto
• è interessato un cluster HA e non esiste una procedura approvata da Sophos per entrambi i nodi

In questi casi, un cleanup non corregge una configurazione errata e può nascondere la causa effettiva. Occorre prima circoscrivere il percorso di autenticazione interessato. Sophos Support è il punto di escalation corretto quando il comportamento non è chiaro o differisce da questo caso.