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.

Per questo problema sono documentati due ID diversi: NC-176853 e NC-176039. La stessa KBA-000048429 non indica alcun ID NC. Questo articolo riporta direttamente lo stato concreto della versione: entrambi i registri indicano SFOS 22.0 MR1 Build 490 come versione corretta; la KBA la denomina SFOS v22.0.1 MR-1. Nessuno dei due ID viene quindi considerato l’unico canonico. Prima di una modifica, verificare i dati dinamici su build approvate, maintenance release corrente e percorso di upgrade con il controllo per l’upgrade a SFOS 22. Il cleanup è 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 segnale di conferma specifico per questo problema:

grep "unknown option" /log/nasm.log

Questa corrispondenza conferma l’errore di upgrade descritto solo se il timestamp coincide con l’upgrade e il guasto; una voce vecchia non dimostra un problema attuale.

Se il comando non restituisce risultati, manca il segnale di conferma necessario. Non eseguire il cleanup sulla base di un sospetto. Verificare prima DNS, SPN, domain join, Redirection Location, attendibilità del browser e la normale configurazione Kerberos/NTLM; se il percorso di upgrade e i sintomi continuano a corrispondere, coinvolgere Sophos Support.

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.

Sophos indica il cleanup come soluzione preferita per un firewall che esegue attualmente SFOS 22.0 GA. Eseguire nella Advanced Shell:

opcode -ds nosync nasm_cleanup

Il comando forza il cleanup e la rigenerazione dell’ambiente NASM in linea con Samba 4.22.1; in seguito normalmente non serve un riavvio. Sophos non specifica né un particolare messaggio di riuscita né un comando di annullamento. Il risultato va quindi verificato con un nuovo accesso AD SSO e non sulla base di una singola risposta della shell. Se l’esito è imprevisto, non ripetere il comando e fornire a Sophos Support le informazioni raccolte prima dell’intervento indicando la KBA-000048429.

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. Aprire Log viewer in alto a destra, selezionare Authentication nel selettore dei moduli e consultare Log Comp per verificare se viene usato Kerberos o NTLM. Kerberos authentication initialized successfully e NTLM authentication channel established successfully confermano un’inizializzazione riuscita.
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 il log Authentication mostra invece Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel, il canale AD non è ancora operativo. Se compare di nuovo soltanto un accesso Captive Portal o se l’utente resta assente, vanno controllati anche SPN, risoluzione DNS, Redirection Location e attendibilità 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 KBA indica SFOS v22.0.1 MR-1 come versione corretta; nonostante la discrepanza tra gli ID NC-176853 e NC-176039, entrambi i registri attuali indicano SFOS 22.0 MR1 Build 490 come destinazione con la correzione. Al 4 settembre 2026, SFOS 22.0 MR2 Build 546 è la versione 22.0 corrente. Prima di una modifica, verificare nuovamente questo stato dinamico con il controllo per l’upgrade a SFOS 22. È preferibile installare la maintenance release più recente approvata per il proprio modello e percorso di upgrade, anziché scegliere deliberatamente una versione intermedia ormai superata. Lo stesso controllo copre anche percorso di upgrade, backup, storage, HA e via di ritorno prima del cambio firmware.

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

Se Advanced Shell non è disponibile, un altro cambio firmware può ricreare le directory NASM:

• 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. In WebAdmin, aprire Backup and firmware > Firmware e scegliere Boot firmware image per lo slot inattivo. Le due partizioni conservano configurazioni separate. Durante l’esecuzione di SFOS 21.5 è attiva la configurazione precedente; tornando alla partizione 22.0 si riattiva la configurazione corrispondente. Non apportare modifiche alla configurazione di produzione durante il passaggio, perché le partizioni non le condividono.

Prima di iniziare, pianificare una finestra di manutenzione, conservare esternamente un backup aggiornato e verificare che il firmware inattivo sia compatibile e disponibile. L’accesso console è una precauzione opportuna. Dopo ogni avvio, controllare nel Control Center quale versione è attiva. Non è definita una sequenza specifica per i nodi HA; in un cluster HA, coordinare entrambe le soluzioni con Sophos Support. 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; non è definita una sequenza specifica per i nodi HA

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.