Set up Synchronized User ID Authentication on Sophos Firewall

Synchronized User ID Authentication links the sign-in on a managed endpoint to Sophos Firewall. Sophos Endpoint sends the identity through Security Heartbeat. In the AD workflow for SFOS 22, the firewall validates the domain user through Active Directory; the SFOS 23 help additionally describes Microsoft Entra ID with UPN resolution and group lookup. Successfully mapped users appear under Current activities > Live users.

This approach suits managed workstations on which Sophos Endpoint and Security Heartbeat already work. It doesn’t require an additional authentication agent on the client or server. Sophos Endpoint itself remains a requirement.

⚠️ The SFOS 22 help confirms the older AD workflow for Windows 10 and excludes other directory services. This statement does not apply universally to SFOS 23: a separate Entra ID workflow is documented there. Local users and devices with Server Protection remain excluded. The SFOS 23 page does not specify an operating system version; do not infer additional operating system support from this or from a successful pilot.

SFOS 23: Entra identity through Security Heartbeat

This branch describes sign-in on the endpoint, not interactive SSO sign-in to the VPN Portal or WebAdmin. The Entra integration must already be configured correctly. The shared Entra baseline configuration explains the app, permissions, authentication server and group import; VPN sign-in itself is not a prerequisite for this Heartbeat pilot. For administrator access, Entra ID for WebAdmin applies separately.

Minimum prerequisites and identity resolution

Check these prerequisites before the pilot:

• The firewall runs the intended SFOS 23 build, is connected to Sophos Central or Sophos Fusion, and has a working Security Heartbeat. The licence details retained below explicitly come from the SFOS 22 help; they do not establish any new or changed SFOS 23 licensing requirement. Check entitlement for the version actually in use separately.
• Sophos Endpoint 2025.1 or later is installed on the managed pilot. The SFOS 23 help requires Endpoint on domain-joined devices; do not infer additional support for arbitrary join models or operating systems from this.
• The user account uses the same email address in Sophos Central/Fusion, on the firewall and in the configured directory. The signed-in Entra user must be uniquely identifiable.
• Microsoft Entra ID is successfully configured as an authentication server on the firewall. Under Authentication > Servers, check the Entra server and Test connection; check time synchronisation, reachability, app permissions and group import according to the linked baseline configuration.
• Endpoint sends the signed-in Entra user’s valid UPN through Heartbeat. From Endpoint 2025.1 onwards, the sign-in name, domain name and UPN are sent; older versions do not send a UPN. Without a UPN, the firewall cannot map the Heartbeat to an Entra user. A green Heartbeat alone is therefore not enough.

⚠️ Do not synchronise users from a single domain through AD and Entra ID simultaneously. The Entra prerequisites exclude this combination. Do not reinterpret an existing AD path as an automatic migration: first clarify which directory is responsible and the recovery path; stop the pilot if dual mapping remains unresolved.

The Entra workflow consists of five steps:

1. The user signs in with their Entra ID account on the device protected by Sophos Endpoint.
2. Endpoint sends the identity information to the firewall through Security Heartbeat.
3. The firewall resolves the Entra user using their UPN. Unlike the AD branch, sAMAccountName is not used here as the Entra mapping key.
4. The firewall retrieves the Entra group memberships and activates the user with the appropriate user and group policies and the corresponding Synchronized Security policies.
5. The user appears under Current activities > Live users. The firewall does not use or share passwords in this process.

Validate the Entra pilot and authorisation

The documentation example uses anna.muster@example.com, client IP 10.20.30.101, Entra pilot group SFOS-Internet-Users and rule LAN_User_Internet. Replace the UPN, IP and group with your own pilot values. Deliberately restrict the group to the required test users; the name alone does not prove membership or permission.

1. Document the previous state of directory mapping, user and group objects, rules and HA nodes, as well as independent administrative access. Use an approved test client and test accounts; do not block or delete production accounts.
2. Import the required Entra group according to the baseline configuration and select it in a narrowly scoped, logged rule under Rules and policies > Firewall rules, using Match known users and Users or groups. Restrict the source, destination and services to the pilot; the pilot rule described below shows the fields.
3. Sign out of the pilot completely and sign in again with the Entra account. Check Heartbeat and Current activities > Live users together: the expected user, client IP and Client Type: Heartbeat must match the test sign-in. Document the identity actually displayed; do not assume a particular display name.
4. Generate a new allowed test flow and compare the user, source, destination, service, action, time and Firewall Rule ID in Log viewer. Only the correct flow proves the rule’s effect; a Live users entry alone does not prove group authorisation.
5. Check the same destination path with a separate test user outside the pilot group. This user must not be allowed through the pilot group rule. Another valid rule may still apply: document its Rule ID rather than expecting a blanket block.
6. Validate a missing or invalid UPN, a non-existent or inactive Entra test account, and lack of firewall-to-Entra reachability as negative test cases. Introduce faults only in an isolated, approved test environment, not through tenant-wide blocks or global network blocks. Without such an environment, document the test cases as outstanding, not as successfully tested. Do not expect Entra mapping without a UPN; for account and reachability errors, do not promise a particular error message or immediate sign-out of existing sessions.
7. Test Heartbeat loss and sleep/wake in a controlled way. If Heartbeat is missing, the synchronised user is signed out; other authentication methods may still apply, and traffic may be interrupted until the user signs in again. The following Heartbeat test sequence also applies here.

Entra user is missing or has the wrong group

If Heartbeat is green but there is no matching identity, first check the Endpoint version and the UPN actually reported. Then check whether the Entra account exists and is active, whether firewall services can reach Entra, and whether the Entra configuration has been completed successfully. Run Test connection again under Authentication > Servers. A successful connection test alone proves neither the endpoint’s UPN nor group authorisation.

If the identity is visible but the group or rule is wrong, compare Entra membership, the imported firewall group, user mapping and rule order. Preserve the affected flow with its Rule ID and time. Do not broaden rules, delete user objects or restart services as a precaution. For escalation, preserve the SFOS build, Endpoint version, anonymised UPN, Heartbeat status, client IP, time window and processing HA node together with the logs listed below.

HA and recovery path for the Entra pilot

The SFOS 23 help also describes Synchronized User ID as enabled by default and requires it to be enabled or disabled on both HA devices. The state change is not stored in the backup. The retained shell commands below are also documented in SFOS 23; they switch the feature as a whole, not just Entra. Such a service restart is therefore not a harmless pilot rollback.

Test failover only during an approved maintenance window with independent administrative access. On the node processing traffic afterwards, revalidate Heartbeat, a new Entra sign-in, Live users, the group rule and a new test flow. Do not assume uninterrupted transfer of user state or sessions; the SFOS 22 fixes listed below are not a new SFOS 23 failover guarantee.

For the recovery path, first restore the pilot rule and pilot mappings to their documented previous state, and check the previous authentication path with a fresh sign-in and actual traffic. Do not delete or globally disable Entra apps, servers, permissions or groups shared with VPN, Portal or WebAdmin as part of test clean-up. If the global Synchronized User ID state was also changed during the maintenance window, explicitly restore the intended state on both nodes and check it separately after a restore. Only reactivate an AD recovery path once Entra synchronisation for the same domain has been ended in a controlled way.

The following AD steps and examples are retained as a separate, older SFOS 22 path. AD identity resolution is also described in the SFOS 23 help, but does not replace Entra validation there.

SFOS 22 with AD: Synchronized User ID in eight steps

1. Select one Windows 10 domain client with Sophos Endpoint as the pilot.
2. Check Sophos Fusion (formerly Sophos Central), Security Heartbeat, and the firewall license.
3. Connect Active Directory as an authentication server on the firewall.
4. Compare the UPN domain, sAMAccountName, email address, and user profile across AD, Sophos Fusion, and the firewall.
5. Prepare a narrowly scoped, logged user rule for a pilot group.
6. Sign in to Windows again on the pilot and confirm a green heartbeat.
7. Check the user, IP address, and Client Type under Current activities > Live users, as well as the actual traffic in Log Viewer.
8. Test heartbeat loss, HA behavior, and a controlled recovery path before adding more endpoints.

When Synchronized User ID fits

Synchronized User ID is not a general replacement for every Sophos authentication method. The retained SFOS 22 AD path fits when a managed Windows 10 endpoint normally belongs to exactly one AD user and Sophos Endpoint already sends a Security Heartbeat. For Entra users under SFOS 23, the prerequisites and validation in the separate branch above apply.

Other operating models require other methods:

• STAS on Sophos Firewall maps Windows sign-ins from domain controllers, STA Agent, and Collector to a client IP.
• SATC for Remote Desktop Services distinguishes multiple sessions behind one RDS or Citrix IP.
• Per-Connection AD SSO distinguishes HTTP and HTTPS connections from multiple users through the Direct Web Proxy.
• Captive Portal or Client Authentication Agent fits when an interactive sign-in is required.

Don’t force a server or terminal server scenario into Synchronized User ID. Sophos explicitly lists Server Protection as unsupported. If multiple users share the same IP or non-web connections must be mapped by session, SATC is the better fit.

If Synchronized User ID and STAS are configured at the same time, Sophos states that the authentication server uses the mechanism whose sign-in request arrives first. Don’t treat this coexistence as a fixed priority. Scope the pilot unambiguously and check Client Type during every validation.

How AD mapping works

The workflow consists of four separate layers:

1. The user signs in to the Windows domain client.
2. Sophos Endpoint sends the domain user to the firewall through Security Heartbeat.
3. The firewall reads the domain from the UPN and the username from sAMAccountName.
4. The firewall validates the user through the matching Active Directory server and activates the user for user-based rules.

The feature doesn’t authenticate local Windows users and doesn’t replace an AD connection. If the UPN domain, directory server, or user profile doesn’t match, a green endpoint can still remain without a usable user identity.

Sophos Firewall doesn’t share or use password information in this process. The heartbeat carries the domain and user information required for the mapping, while validation takes place on the configured AD server.

AD example and replaceable values

This workflow uses the following documentation values:

• Firewall: fw01.example.com
• AD domain and UPN suffix: example.com
• Windows client: WS-101
• Client IP: 10.20.30.101
• Username: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• AD group: SFOS-Internet-Users
• Pilot rule: LAN_User_Internet

example.com, WS-101, 10.20.30.101, the user, and the group are examples and must be replaced with the real values. The object name isn’t the decisive point. Sophos Fusion, Windows, Active Directory, and the firewall must map the same user unambiguously.

Prepare the prerequisites

Check Sophos Fusion and Security Heartbeat

The firewall must be connected to Sophos Fusion and have a valid Network Protection subscription. The pilot requires Sophos Central Endpoint Protection as a trial or full license. These license requirements come from the SFOS 22 Security Heartbeat help; registration and the heartbeat baseline are covered in Connect Sophos Firewall to Sophos Fusion.

Under System > Sophos Fusion, registration and Security Heartbeat must be active. The pilot must appear with a plausible status in Control Center and Sophos Fusion. Establish this baseline first, then check the identity mapping.

According to the SFOS 22 Security Heartbeat help, the endpoint and firewall exchange heartbeat data over an encrypted TLS connection to 52.5.76.173 on TCP 8347. Green means that Sophos protection is working correctly and that no active or inactive malware or PUA has been detected. It doesn’t yet prove that AD validated the user. For connection problems, check transport, the Fusion tenant, and the endpoint certificate separately from user mapping.

Synchronized User ID is enabled by default. Therefore, there is no regular WebAdmin switch that must first be enabled for the pilot. The shell commands described later are only for controlled disabling or re-enabling.

Compare Active Directory and user attributes (AD path)

A suitable Active Directory server must exist and be reachable under Authentication > Servers. Connect Active Directory to Sophos Firewall explains LDAPS, the search base, group import, and server order.

Then go to Authentication > Services > Firewall authentication methods and move the AD server to Selected authentication server. The SFOS 22 Authentication Services help confirms that at least one server must be selected; when several servers are selected, the firewall processes them in the displayed order. Merely adding the server under Servers isn’t enough for firewall authentication.

At least these values must match for the pilot:

• The domain in the UPN matches the domain of the AD server used by the firewall.
• sAMAccountName is unique in Active Directory and can be found by the firewall.
• The user profile and email address match across AD, Sophos Fusion, and the local firewall user record.
• The required AD group is imported and assigned to the correct firewall user profile.

A different UPN suffix, duplicate sAMAccountName values in unsuitable search scopes, or a mismatched AD server are stop signals. Don’t compensate with a broader user rule.

Prepare the pilot rule

Under Rules and policies > Firewall rules, click Add firewall rule > New firewall rule and create a narrowly scoped rule for the pilot group, or use an existing user rule in a controlled way. In the user identity section, select Match known users before selecting Users or groups:

• Source zones: actual client zone
• Source networks and devices: pilot network or a narrower source range
• Users or groups: SFOS-Internet-Users
• Destination zones: only the required destination path
• Services: only the services required for the test
• Log firewall traffic: enabled

Rule order, logging, and the negative test matter more than a broad allow rule. Create Sophos Firewall rules correctly explains the setup.

Sign in and validate the AD pilot

1. Sign the existing user out of the pilot client completely.
2. Sign in to Windows again as anna.muster@example.com.
3. Check for a green heartbeat in Sophos Fusion and on the firewall.
4. Search for anna.muster and 10.20.30.101 under Current activities > Live users.
5. Confirm that the user, IP address, and Client Type: Heartbeat appear.
6. Trigger an allowed traffic test through LAN_User_Internet.
7. Open Log viewer at the top right, select the firewall module, and compare the username, source, destination, service, Firewall Rule ID, action, and time.
8. Run a negative test with a user outside the pilot group.

An entry under Live users only proves the identity mapping. Only the logged test flow proves that the correct user rule also applies. If the traffic log only shows the IP address or the flow hits another Rule ID, don’t broaden the rule. Check the mapping and rule order.

Deliberately test heartbeat loss

If Security Heartbeat is missing or lost during a sleep/wake transition, the firewall signs out the user detected through Synchronized User ID. Other configured authentication methods may still apply, but user-based traffic may be interrupted until the next sign-in.

For a controlled test:

1. First document the active user, IP, heartbeat status, and rule.
2. Put the pilot into sleep mode and wake it again.
3. Check the heartbeat status and Live users again.
4. Trigger a new traffic test and confirm the actual user and Rule ID used.
5. If the result differs, check the endpoint, path, and logs instead of disabling Synchronized User ID globally as a precaution.

A Missing Heartbeat doesn’t automatically mean malware. Troubleshoot Missing Heartbeat alerts systematically explains the complete diagnostic path.

Put SFOS 22 release notes and known limitations in context

Validation must consider the installed maintenance release, not only “SFOS 22”. This current Synchronized User ID article documents the two concrete NC claims itself. The SFOS 22 upgrade check is responsible only for build and version verification, the approved upgrade path, and change preparation here. The product fixes are: MR1 Build 490 fixes delayed internet access after a manually triggered HA failover with heartbeat authentication (NC-165361); MR2 Build 546 fixes false Missing Heartbeat reports when two endpoints share the same docking station or USB interface (NC-176012). If either symptom occurs on an older 22.0 build, record the exact build first and assess an approved update path.

The Missing Heartbeat troubleshooting runbook also covers NC-147863: with SSL VPN split tunneling to an external firewall, a new VPN adapter can interrupt the heartbeat connection. The user then loses heartbeat authentication and may enter a connect-disconnect loop. If the pilot includes this scenario, test it specifically. Sophos’s workaround is to turn off Match known users in the local firewall’s VPN rule or use captive portal authentication. Limit such a change to the affected VPN rule first, and document its impact and recovery path.

Troubleshoot systematically

Endpoint doesn’t appear with a green heartbeat

First check Fusion registration, the endpoint license, the Network Protection license, firewall association, DNS, time, and the network path. Without a working Security Heartbeat, Synchronized User ID can’t transfer an identity.

User is missing from Live users

For the AD path, check the Windows sign-in, UPN, sAMAccountName, AD server, search scope and user profile together. A green Heartbeat confirms the endpoint connection, not automatically successful AD validation. For Entra users under SFOS 23, use the UPN, account and reachability checks in the Entra branch instead.

Wrong user or wrong group

For AD, compare the UPN domain, AD search scope, imported group, Main Group and local user objects. For Entra under SFOS 23, Entra membership and UPN mapping in the separate branch also apply. Do not delete user objects before checking dependencies on VPN, Portal, rules, quotas and reporting.

User is visible, but the rule doesn’t apply

Check the source zone, source network, user or group, service, destination, and rule order. The actual flow must show the expected Firewall Rule ID in Log Viewer. A visible identity alone doesn’t confirm authorization.

Server or unconfirmed Windows version

Server Protection is not supported for either path. The SFOS 22 help explicitly names Windows 10 for AD; the SFOS 23 page does not specify an operating system version. For other operating systems, join models or unknown endpoint types, do not infer production approval from the availability of documentation or the behaviour of a single pilot.

Read the relevant logs

These read-only checks are useful in Advanced Shell:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log shows heartbeat events, access_server.log helps with authentication and authorization, and hbtrust.log with the Sophos Fusion trust relationship. One log alone isn’t complete proof. Preserve the time window, user, endpoint, IP, Rule ID, and affected HA node together. Sophos Firewall log files and services explains more log paths.

If it remains unclear whether the directory, method, local user record, or rule is failing, Troubleshoot authentication failures systematically provides a cross-method diagnostic sequence.

Disable the feature in a controlled way

⚠️ The following commands change the authentication state and restart access_server. First document active users, affected rules, an alternative access method, and the recovery path. In HA, both nodes must be handled deliberately.

The official SFOS 22 and SFOS 23 instructions specify these commands for persistent disabling:

touch /content/no_userid
service access_server:restart -ds nosync

This variant disables the feature only until the next firewall restart:

touch /tmp/no_userid
service access_server:restart -ds nosync

To re-enable the feature, remove the persistent file and restart the service:

rm /content/no_userid
service access_server:restart -ds nosync

After each change, check a fresh Windows sign-in, Live users, actual traffic, and the logs. The disabled state isn’t stored in configuration backups. After a restore, check the intended state again and set it on both HA nodes if required.

HA, backups, and operations

In an HA cluster, Synchronized User ID is enabled or disabled on both devices. Each node only stores the logs for traffic and events it processes. For an incident, check the node that was active or processing the traffic at that time.

A controlled HA test requires a new Windows sign-in and a new traffic flow. Don’t assume that the user state or active sessions continue without interruption. After failover, validate at least the heartbeat, Live users, the user rule, and the logs again.

The state of /content/no_userid isn’t included in a backup. This exception must be documented explicitly in operating procedures, restore tests, and the RMA workflow.

Rollback

1. Document the current heartbeat, user, rule, and HA state.
2. Disable the pilot rule or restore its documented previous state.
3. Only if the global feature state was changed during the test, restore the documented previous state in a controlled way. For intentional re-enabling after persistent disabling, remove /content/no_userid and restart access_server; do not indiscriminately enable a feature that was previously disabled. According to Sophos, the temporary variant ends with the next firewall restart. Do not trigger a restart solely for test clean-up outside an approved maintenance window.
4. Establish the same intended state on both HA nodes.
5. Sign in to Windows again on the pilot and check the heartbeat and Live users.
6. Retest the user rule and alternative authentication path with actual traffic.
7. Only then remove temporary test objects or pilot assignments.

Checklist for the SFOS 22 AD path

• The pilot is a supported Windows 10 domain client with Sophos Endpoint.
• The firewall, endpoint, and Security Heartbeat are visible in Sophos Fusion.
• The Network Protection and endpoint licenses are valid.
• The AD server, UPN domain, sAMAccountName, email address, and user profile match.
• The pilot group is imported and the user rule is narrowly scoped and logged.
• Live users shows the expected user and the correct client IP.
• Actual traffic hits the expected Firewall Rule ID.
• Heartbeat loss and sleep/wake were tested in a controlled way.
• HA nodes, logs, the restore limitation, and the recovery path are documented.
• Synchronized User ID wasn’t overstretched as a replacement for SATC, STAS, or other directory services.

Frequently asked questions