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.

Sophos fixed the underlying upgrade issue in SFOS 22.0 MR1 Build 490. The cleanup is therefore 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 message documented by Sophos:

grep "unknown option" /log/nasm.log

A match confirms the faulty Samba/NASM state. The timestamp must correspond to the upgrade and the failure; an old entry does not prove a current problem.

No output does not reliably rule out the issue. Without the matching upgrade path and the symptoms described above, however, the cleanup should not be run speculatively. Check DNS, SPN, the domain join, Redirection Location, browser trust and the normal Kerberos/NTLM configuration first.

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.

Run this command in the Advanced Shell:

opcode -ds nosync nasm_cleanup

The command cleans up the affected NASM structure and recreates it for Samba 4.22.1. According to Sophos, a restart is normally not required. A specific success message is not documented, so verify the result with a new AD SSO sign-in rather than relying on a single shell response.

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. Under Log viewer > Authentication, confirm that Kerberos or NTLM is used successfully and that no new matching NASM errors occur.
  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 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 permanent solution is an upgrade to SFOS 22.0 MR1 Build 490 or later. Before another firmware change, check the upgrade path, backup, storage, HA and rollback route with the SFOS 22 upgrade check.

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

Sophos provides another firmware change as an alternative:

  • 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. A current backup, an available and bootable firmware slot, console access, a maintenance window and a verified rollback route are therefore mandatory. 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 and there is no procedure approved by Sophos for both nodes

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.