Skip to content
Avanet

Sophos Firewall: AD SSO fails after an SFOS 22 upgrade

Sophos Firewall

After an upgrade from SFOS 21.5 or earlier to SFOS 22.0 GA, Active Directory Single Sign-On with Kerberos and NTLM can fail immediately. The firewall continues to forward traffic but no longer recognizes the affected domain users. User-based firewall rules therefore do not match as intended.

⚠️ The cleanup must only be used in the Advanced Shell and when the upgrade path and symptoms match. Do not run the command as a blanket measure if the firewall is already on MR1 Build 490 or later, the issue existed before the upgrade or an HA cluster is affected.

If the firewall is still running SFOS 22.0 GA and nasm.log contains a matching unknown option error from the time of the failure, NASM can be rebuilt in a targeted manner. The following checks prevent the cleanup from being used for a normal DNS, SPN or domain-join problem.

Two different issue IDs are documented for this failure: NC-176853 and NC-176039. KBA-000048429 itself gives no NC identifier. This article records the concrete release status directly: both ledgers point to SFOS 22.0 MR1 Build 490 as the fixed release; the KBA names it SFOS v22.0.1 MR-1. Neither NC ID is therefore treated as uniquely canonical. Before a change, verify dynamic details about approved builds, the current maintenance release, and the upgrade path with the SFOS 22 upgrade check. The cleanup is a targeted repair for the GA upgrade case described here, not a general solution for every AD SSO problem.

When this procedure applies

This procedure is intended for the following situation:

  • upgrade from SFOS 21.5 or earlier to SFOS 22.0 GA
  • AD SSO with Kerberos and NTLM worked before the upgrade
  • domain users can no longer authenticate through AD SSO afterwards
  • identity-based rules no longer recognize users
  • other firewall functions and sign-ins that do not use AD continue to work

A successful Test connection under Authentication > Servers does not rule out this issue. The test confirms the connection to the domain controller and the credentials, but not the complete AD SSO flow.

If Test connection already fails, the likely cause is reachability, DNS, the port, the certificate or the service account. These basics are explained in Connect Active Directory to Sophos Firewall.

Check the error in nasm.log

Sign in to the firewall over SSH and open 5. Device Management > 3. Advanced Shell. SSH access to Sophos Firewall is explained separately.

Then search for the confirmation signal specific to this issue:

grep "unknown option" /log/nasm.log

This match confirms the upgrade issue only when its timestamp corresponds to the upgrade and the failure; an old entry does not prove a current problem.

If the command returns no output, the required confirmation signal is missing. Do not run the cleanup speculatively. Check DNS, SPN, the domain join, Redirection Location, browser trust and the normal Kerberos/NTLM configuration first; involve Sophos Support if the upgrade path and symptoms still match.

Perform a targeted NASM cleanup

During a firmware change, SFOS recreates the NASM directories for the Samba version in use. During the affected upgrade, this step can remain incomplete. The new NASM then loads older, incompatible Samba components and AD SSO fails.

Before making the change, document the current firmware version, the time of the failure and the output from nasm.log. A local or alternative administrator login should be available in case authentication is unavailable during the work.

Sophos identifies the cleanup as the preferred solution for a firewall currently running SFOS 22.0 GA. Run this command in the Advanced Shell:

opcode -ds nosync nasm_cleanup

The command forces cleanup and regeneration of the NASM environment aligned with Samba 4.22.1; a restart is normally not required afterwards. Sophos specifies neither a particular success message nor an undo command. Verify the result with a new AD SSO sign-in rather than relying on a single shell response. If the result is unexpected, do not repeat the command; give Sophos Support the baseline information you recorded and reference KBA-000048429.

Verify AD SSO with real user traffic

After the cleanup, another Test connection is not enough. Use a domain user and a genuinely user-based rule for the check:

  1. On a domain client, open a new browser connection that uses AD SSO and a user-based firewall rule.
  2. Under Current activities > Live users, check whether the domain user appears again.
  3. Open Log viewer in the upper-right corner, select Authentication in the module selector and check Log Comp to see whether Kerberos or NTLM is used. Kerberos authentication initialized successfully and NTLM authentication channel established successfully confirm successful initialization.
  4. In the firewall log, check whether the user, group and Firewall Rule ID match the intended rule.
  5. Test the application or destination that was unavailable before the cleanup.

The issue is resolved only when the user identity and rule match are both correct. If the Authentication log instead shows Cannot initialize Kerberos authentication or Cannot establish NTLM authentication channel, the AD channel is not operational yet. If only a Captive Portal sign-in appears again or the user remains absent, also check SPN, DNS resolution, Redirection Location and browser trust. The relevant authentication files are listed under Sophos Firewall services and logs.

Permanent solution and alternative without Advanced Shell

Upgrade to a fixed SFOS version

The KBA names SFOS v22.0.1 MR-1 as the fixed release; despite the NC-176853/NC-176039 identifier discrepancy, both current ledgers identify SFOS 22.0 MR1 Build 490 as the fix destination. As of September 4, 2026, SFOS 22.0 MR2 Build 546 is the current 22.0 release. Recheck this dynamic status with the SFOS 22 upgrade check before making a change. Install the latest maintenance release approved for your model and upgrade path rather than deliberately targeting an obsolete intermediate release. The same check also covers the upgrade path, backup, storage, HA and rollback route before the firmware change.

If the same symptom first appears on MR1 Build 490 or a later version, the GA upgrade issue described here is no longer a clear match. Do not repeat the cleanup. Run the normal AD SSO diagnosis instead and involve Sophos Support if necessary.

When Advanced Shell is not available

When Advanced Shell is unavailable, another firmware change can recreate the NASM directories instead:

  • If the firewall has already booted back into SFOS 21.5, boot into SFOS 22.0 GA again.
  • If the firewall is running SFOS 22.0 GA, first boot into the available SFOS 21.5 firmware slot and then back into SFOS 22.0 GA.

This round trip triggers the creation of the NASM directories again. It causes downtime and is not the same as a normal restart. In WebAdmin, go to Backup and firmware > Firmware and select Boot firmware image for the inactive slot. The two firmware partitions keep separate configurations. The earlier configuration is active while SFOS 21.5 is running; when the firewall returns to the 22.0 partition, its corresponding configuration becomes active again. Do not make production configuration changes during the detour because the partitions do not share them.

Plan a maintenance window, take a current externally stored backup and confirm that the inactive firmware is compatible and available before starting. Console access is a prudent safeguard. After each boot, verify the active version in the Control Center. No HA-specific node sequence is defined; for an HA cluster, coordinate either remedy with Sophos Support. If these prerequisites are missing, upgrading directly to a fixed release or coordinating the procedure with Sophos Support is safer.

When the cleanup is not the right solution

nasm_cleanup is not a general repair command. A different diagnostic path is required when:

  • the firewall is already running SFOS 22.0 MR1 Build 490 or later
  • the issue existed before the upgrade
  • Test connection to the AD server fails
  • only individual users, groups or browsers are affected
  • STAS, Microsoft Entra ID SSO, RADIUS or a normal LDAP sign-in is affected
  • DNS, SPN, the domain join, certificates or browser trust do not work correctly
  • the upgrade path or time of the failure does not match the issue described here
  • an HA cluster is affected; no HA-specific node sequence is defined

In these cases, a cleanup does not correct a misconfiguration and can hide the actual cause. First narrow down the affected authentication path. Sophos Support is the right escalation point when the behaviour is unclear or differs from this case.