Manage Sophos Firewall user groups and the main group correctly

User groups apply shared policies to authenticated users. Before changing a group, answer two questions: Where does the identity come from, and does the affected feature evaluate only the Main Group or additional AD groups as well? Only then can you determine whether to change the group order, a policy assignment, or the firewall or VPN rule itself.

Quick procedure:

Determine the user source and purpose of the group.
Create a local group or import the specific directory group you need.
Under Authentication > Services, check the effective Default group or on the Entra server the Fallback user group.
For AD, document the order under Authentication > Groups > Reorder and the expected main group.
Log off the pilot user and log in again. Then check the fields Group and Other group memberships under Authentication > Users > user > Policies.
Test the affected function with an authorized and an unauthorized user. For network traffic, also check the expected Firewall Rule ID.

⚠️ Reorder is not a harmless sorting option. Moving a group can change the main group for AD users and consequently alter MFA, quotas, access time, remote access, and other policies for many users. Record the order, group policies, and rollback procedure beforehand.

Understanding the group model

A group carries common policies and settings. It does not replace authentication or a firewall rule. Therefore, a user can be in the correct group and still not gain access if the expected rule, VPN policy, zone, route, or return path is missing.

When troubleshooting, consider four separate questions:

Does the identity come from the local database, Active Directory, LDAP, RADIUS, Microsoft Entra ID, or a clientless mapping?
Which group is the main group?
Does the affected function support additional AD group memberships?
Which rule or policy processes the actual data traffic?

Distinguishing local, imported, and clientless groups

Normal and Clientless are group types. Imported describes a group’s origin; it is not a separate Group type.

A local group of type Normal is suitable for users who sign in. A local user’s group is assigned in the user object. With an external user source, local user records are usually created only after the first successful sign-in.

Guest users follow their own time-limited process. Create and safely operate guest users on Sophos Firewall explains the default group, validity, captive portal, and cleanup.

AD and Entra groups are imported with the wizard for the relevant server. The directory remains the source of group memberships; a local group with the same name is no substitute for importing it correctly. See Connect Active Directory to Sophos Firewall for the full AD, LDAPS, and import procedure.

For generic LDAP, Base DN, Authentication attribute, Group name attribute, server order, and Default group must be configured consistently. Sophos recommends memberOf as the group attribute. Connect an LDAP server to Sophos Firewall walks you through the configuration.

A group of type Clientless bundles clientless users and their common settings. These users do not log in via a client; the firewall controls their access based on the IP address. The fixed IP address is stored on the individual clientless user, not in the group object. Setting up Clientless Users on Sophos Firewall describes IP assignment, rule, and negative test.

Do not confuse the Default Group with the Entra fallback

Under Authentication > Services > Firewall authentication methods, Default group determines which group is assigned to a user from an external authentication server if none of the user’s directory groups exist locally. The factory default is Open group. Check the current value rather than assuming the default is still in place. For production use, Avanet recommends a dedicated, restrictive fallback group with no unintended VPN, quota, or sign-in permissions.

Microsoft Entra ID SSO uses the separate Fallback user group in the Entra server configuration. It also applies if the Entra server is selected under Firewall authentication methods. The general default group does not apply in this case.

The order of the authentication servers is also relevant. Sophos Firewall allows a maximum of 20 servers per authentication method and forwards requests in the displayed order. Do not use this order as a workaround for group issues until you have checked the relevant server and its mapping.

Plan the example and record the initial state

The example uses three separate group tasks:

Local_Contractors: local pilot group for a few external employees;
SFOS_Internet_Standard: imported AD group for normal internet access;
SFOS_SSLVPN: imported AD group for an SSL VPN policy.

auth-pilot@example.com serves as the test account, and the logged rule LAN-Users-to-WAN provides the traffic test. example.com is a reserved documentation domain. Replace the names and users with ones that follow your naming convention. A function-based name such as SFOS_SSLVPN remains meaningful even after a reorganization.

Write down before the change:

current group order;
Default group and, if applicable, Fallback user group;
group policies and user-specific overrides;
affected authentication services and VPN policies;
verified administrator access and a second management path if the main group, MFA, or sign-in restrictions are affected;
pilot users, expected Main Group, as well as positive and negative tests.

Create a local user group

Go to Authentication > Groups and click Add:

Enter Local_Contractors as the group name.
For Group type choose Normal.
Only select the required common policies:
- Surfing quota limits usage time by period and cycle.
- Access time allows or denies recurring periods.
- Network traffic limits the transmitted data volume.
- Traffic shaping assigns a QoS policy with priority and bandwidth limits.
Set SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP, and IPsec remote access only for access you actually intend to provide. Do not use PPTP in new designs; L2TP remains a limited compatibility option, as explained in L2TP Remote Access on Sophos Firewall.
Limit Sign-in restriction as much as possible with Selected nodes or Node range to the required sources. Any node allows login from any network.
Turn on Quarantine digest and MAC binding only if the group needs these functions.
Click Save.

The product defines the field names and their behavior; your environment determines which settings to select. An internet-access group does not automatically require VPN, quota, or MAC binding. Groups with a clearly defined purpose are easier to test and roll back.

Assign local users and identify overrides

Create and manage normal local users covers usernames, passwords, group inheritance, and acceptance testing in detail. Assign local users to a group under Authentication > Users. When editing a group, select Show group members to view its members and Add member(s) to add the appropriate local users. For externally managed identities, the directory remains the source of membership.

Whether a rule or policy uses user or group settings depends on the actual user/group selection. Check for the user under Policies whether a personal value is selected instead of the group setting. If the group policy should apply again, specifically restore the previously documented inheritance state and test only the affected function again. An override remains sensible if a justified exception is explicitly documented.

Sophos distinguishes two cases for the selection in the affected rule or policy:

Only the group selected: The firewall uses the group settings, not automatically the user override.
The user and their group selected: The firewall uses the user settings.

A limited pilot makes the distinction visible: For auth-pilot@example.com in Local_Contractors, record a group value A and a different user value B for the same supported setting. A and B are placeholders for two deliberately planned test values in your environment. In an isolated test rule or test policy with user/group selection, first inspect the actual selection: only Local_Contractors means A; auth-pilot@example.com together with Local_Contractors means B. Test the affected service or data path with a fresh sign-in in each case; for firewall traffic, also check the Firewall Rule ID. Afterwards, restore the previously recorded selection and both settings and test again. Do not broaden a production rule or change the group order for this test.

This selection is not the Main Group order. The multiple-group support limitations and combination of matching SSL VPN policies described below still apply; this does not establish universal user-policy precedence for every service.

The dedicated articles explain how to configure access-time policies, surfing and network traffic quotas, and MFA for Sophos Firewall. In the group object, assign only a policy that you have already planned.

Import directory groups in a controlled way

Active Directory Groups

Go to Authentication > Servers and start the import wizard for the configured AD server. In an HA cluster, the import must be done on Primary. The wizard imports only the groups you select. A group created later in AD therefore does not appear automatically and must be imported again.

Nested AD groups are not evaluated. If a subgroup should apply to a firewall rule or VPN policy, exactly that subgroup must be imported. A user’s primary AD group is not imported as a regular membership either. For policies, explicit security groups are therefore more suitable than the AD default group Domain Users.

After changes to AD memberships, imported groups, or the group order, the user must log in again. Only then does the firewall re-evaluate the groups and update the user object.

Entra Groups

For the Entra group import, the app registration in Microsoft Graph requires the application permission Group.Read.All with Admin Consent. The firewall and Microsoft Entra ID clocks must be synchronized; otherwise, the connection may fail.

Then go to Authentication > Servers and open the group import wizard for the Microsoft Entra ID server. You can import all groups or only groups whose Display name or Description match a filter. Surfing quota, Access time, Network traffic, and Traffic shaping can be assigned to all or individual imported groups. Newly imported groups must also be added to the used Remote Access IPsec or SSL VPN policies; the import alone does not grant VPN access.

Evaluate main groups and multiple groups correctly

Open the user under Authentication > Users and scroll to Policies:

Group shows the first matching group in the firewall list and thus the main group.
Other group memberships shows further imported AD groups of the user.

Under Authentication > Groups > Reorder, change the order by dragging and dropping groups. Click Close to close the dialog. If auth-pilot@example.com belongs to SFOS_Internet_Standard and SFOS_SSLVPN, the matching group listed higher will become the main group at the next login.

This order affects more than the issue you are currently troubleshooting. Before making a change, check whether the affected function supports additional groups. Otherwise, a shift could resolve a VPN case while simultaneously changing MFA, quota, or access time for other users.

Functions with support for multiple AD groups

The following matrix applies explicitly to Active Directory. Do not assume that it also applies to LDAP, RADIUS, or Microsoft Entra ID.

The following features can evaluate multiple AD groups:

Firewall rules and SSL/TLS inspection rules;
SD-WAN routes;
Web policies;
IPS and Application control policies;
Policy test;
Remote access SSL VPN;
Clientless SSL VPN.

For remote access SSL VPN, permissions from matching user and group policies are combined. If any matching policy specifies a full tunnel, the result is a Full Tunnel. Check this combination with a real client test.

Only the main group or an explicit user assignment is taken into account for:

WAF rules, My policy overrides and Hotspots;
Remote access IPsec VPN, L2TP and PPTP;
Surfing quota, Access time, Network traffic and Traffic shaping;
Quarantine digest, MAC binding and Sign-in restriction;
MFA.

With WAF, L2TP, PPTP, and remote access IPsec, the user policy may display Enable even though the permission comes only from Other group memberships and access is therefore not allowed. Evaluate these services based on the main group or a direct user assignment, not solely based on the display.

For functions with multiple group support, the order of the respective rule or policy still determines the outcome. A firewall rule can apply via SFOS_SSLVPN, even though SFOS_Internet_Standard is the main group. This does not mean that MFA or Quota also use SFOS_SSLVPN.

Verify the effect of the group

A saved group and a visible user are not yet proof of success:

End the existing session of the pilot user and log in again.
Under Authentication > Users > user > Policies, record the status, Group, Other group memberships, and possible overrides.
Under Current activities > Live users, check the username, source IP, and Client Type.
For a user-based firewall rule, trigger the intended traffic and check the Firewall Rule ID in Log Viewer.
Test access time, quota, MFA, and remote access through the service that is actually affected.
Repeat the same attempt with a user outside the pilot group as a negative test.

To check the quota, open Authentication > Users > user > View usage. Usage data is only available if a user-based firewall rule processes the traffic and Log firewall traffic is activated.

Check firewall rules with Log Viewer, Policy Test, and Packet Capture shows the complete traffic test. If service selection, identity, or main group is already unclear, Systematically fix Sophos Firewall authentication errors goes through the entire verification chain.

Revert changes and clean up groups

Change only one group policy or position at a time. If the pilot test produces an unexpected result, restore the noted order and policy assignment, log the user in again, and repeat positive and negative testing.

AD groups are first deleted in the directory and then separately under Authentication > Groups on the firewall. Purge AD users does not remove groups.

For AD users:

First delete the user in AD. As long as they exist there, the firewall can create them again during a later login.
Click on Purge AD users under Authentication > Users. You do not need to select the users beforehand; the firewall checks the AD server and only removes users that have already been deleted there.
Start the process on Primary in HA. The records will be removed on Primary and Auxiliary. The cleanup does not interrupt sign-in, sign-out, or User Accounting.

A configuration export contains imported and locally created AD groups, but no users from external authentication servers. A full backup, on the other hand, includes all users and groups. Keep this limitation in mind when the rollback affects more than just a single policy change.

Users and groups share the internal ID range up to 65535. A high visible object inventory alone does not prove a limit problem. If a user shows a User ID over 65535 and does not become a live user, this behavior is consistent with the Sophos Firewall User ID limit.

Narrow down errors by symptom

Log the affected user back in after each correction and check Group as well as Other group memberships. After that, one targeted next step per symptom is sufficient.

New AD group does not appear

Restart the import wizard of the AD server and run it in HA on the Primary. Then check under Authentication > Groups whether exactly the required group exists. Do not create a broad replacement group just to make a login work.

LDAP user lands in the default group

Check Base DN, Authentication attribute and Group name attribute on the LDAP server, then check the server order under Authentication > Services and Default group. Execute Test connection for the LDAP server. The AD import wizard is not responsible for this mapping.

Entra user lands in the fallback group

Check whether the Entra group was imported and whether the token provides the expected group. Then check the Fallback user group directly on the Entra server. The general Default group under Authentication > Services is not used for this mapping.

User has the wrong main group

Compare AD memberships, imported groups, and the current order. Check the new order only after the next login and with several representative users.

Firewall rule applies, but MFA or quota does not

Firewall rules support additional AD groups, whereas MFA and quotas do not. Check the main group, possible overrides, and the actual policy assignment under Authentication > Users > user > Policies. The rule effect does not prove that MFA or quota evaluates the same group.

A group change fails to take effect for one user

Compare the user-specific policy fields and the actual user/group selection in the affected rule or policy: selecting only the group uses group values; selecting the user and their group uses user values. Also check the feature limitations for the main group and multiple groups. Only restore the group value if the documented exception is no longer needed.

Nested AD group does not work

Import the required subgroup yourself and add the user there directly. Importing only the parent group is not enough.