Set up Synchronized User ID Authentication on Sophos Firewall

Synchronized User ID Authentication links the Windows sign-in of a managed endpoint to Sophos Firewall. Sophos Endpoint sends the domain user through Security Heartbeat, the firewall validates the user against Active Directory, and then shows the user 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 current Sophos documentation confirms this workflow for Windows 10. It doesn’t describe Server Protection, local Windows users, other directory services, or other Windows versions as equally supported. Don’t migrate such systems to this workflow without separate approval or testing.

Synchronized User ID in eight steps

1. Select one Windows 10 domain client with Sophos Endpoint as the pilot.
2. Check 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 Central, 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 isn’t a general replacement for every Sophos authentication method. It fits when a managed Windows 10 endpoint normally belongs to exactly one AD user and Sophos Endpoint already sends a Security Heartbeat to the firewall.

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 the 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.

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 Central, Windows, Active Directory, and the firewall must map the same user unambiguously.

Prepare the prerequisites

Check Sophos Central and Security Heartbeat

The firewall must be connected to Sophos Central and have a valid Network Protection subscription. The pilot requires Sophos Central Endpoint Protection as a trial or full license. Registration and the heartbeat baseline are covered in Connect Sophos Firewall to Sophos Central.

Under System > Sophos Central, registration and Security Heartbeat must be active. The pilot must appear with a plausible status in Control Center and Sophos Central. Establish this baseline first, then check the identity 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

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.

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 Central, 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, create a narrowly scoped rule for the pilot group or use an existing user rule in a controlled way:

• 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 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 Central 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 match the expected method.
6. Trigger an allowed traffic test through LAN_User_Internet.
7. In Log Viewer, 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.

Troubleshoot systematically

Endpoint doesn’t appear with a green heartbeat

First check Central 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

Check the Windows sign-in, UPN, sAMAccountName, AD server, search scope, and user profile together. A green heartbeat confirms the endpoint connection, not successful AD validation.

Wrong user or wrong group

Compare the UPN domain, AD search scope, imported group, Main Group, and local user objects. Don’t delete user objects before checking dependencies on VPN, portals, 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 isn’t supported for this workflow. The current Sophos Help explicitly names Windows 10. Don’t infer production support for other Windows versions or unknown endpoint types from one successful 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 Central 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.

Sophos uses this file 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. For the persistent variant, remove /content/no_userid in a controlled way and restart access_server. Sophos states that the temporary variant ends only with the next firewall restart.
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

• The pilot is a supported Windows 10 domain client with Sophos Endpoint.
• The firewall, endpoint, and Security Heartbeat are visible in Sophos Central.
• 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