Manage Sophos Firewall user groups and the main group correctly

User groups on Sophos Firewall bundle shared policies for authenticated users. They can standardize Access Time, quotas, Traffic Shaping, Remote Access, and Sign-in Restrictions. However, a group does not grant access automatically. Access also depends on the detected identity, the effective main group, the specific firewall or VPN policy, and its position.

The safe short path is:

1. Define where the users come from and which task the group must solve.
2. Use a group of type Normal for regular users; plan IP-based device identities separately as Clientless.
3. Create or import a small pilot group with one clear purpose and as few shared policies as possible.
4. Under Authentication > Services, check the intended Default Group or the fallback group on the Entra server.
5. For Active Directory, document the order under Authentication > Groups > Reorder and define the expected main group.
6. Avoid user overrides or document them explicitly because they override group policies.
7. Trigger a fresh sign-in and check Group and Other group memberships under Authentication > Users.
8. Test the affected function with a positive and a negative user; for traffic, also verify the expected Firewall Rule ID.
9. Add more users only after a successful pilot, then review group order, Default Group, and exceptions regularly.

⚠️ Reorder is not a harmless sorting function. For AD users, moving a group can change the main group and therefore MFA, quotas, Access Time, Remote Access, and other policies for many users. Document the existing order, group policies, pilot users, and rollback path first.

Understand the group model in a few minutes

A group is a shared policy carrier on the firewall. It can assign the same settings to several users so that each account does not have to be maintained individually. It replaces neither authentication nor a firewall rule. A user can appear in the correct group and still have no access if the expected rule, VPN policy, zone, route, or return path is missing.

Four separate questions help during operation:

1. Where does the identity come from? Local, Active Directory, LDAP, RADIUS, Microsoft Entra ID, or an IP-based Clientless mapping.
2. Which group is effective? For AD, this may be the main group or, for supported functions, another group membership.
3. Which group policy applies? Access Time, Quota, Remote Access, and other fields follow different evaluation rules.
4. Which rule permits the traffic? Group policies alone do not open a network path.

Do not mix Normal, imported, and Clientless groups

A local group of type Normal is suitable for users who authenticate through a supported service. A local user receives the group in the user object. With an external user source, local user records are usually created only after the first successful sign-in.

Temporary guest accounts are generated through Guest user settings and inherit a deliberately selected restrictive group. Create and securely manage guest users on Sophos Firewall covers creation, validity, Captive Portal validation, and offboarding.

AD groups are brought in through the import wizard. Membership is maintained in the directory and evaluated at sign-in. The complete server, LDAPS, and import workflow is described in Connect Active Directory to Sophos Firewall. For generic LDAP, plan the search base, memberOf or another group attribute, and the local Default Group separately; Connect an LDAP server to Sophos Firewall explains these fields.

A group of type Clientless solves a different task. It maps an identity to a fixed IP address without a person signing in. This is intended for printers or other clearly attributable systems and is not a substitute for user authentication. Set up Clientless Users on Sophos Firewall describes the safe IP, rule, and negative test.

Choose the Default Group and fallback group deliberately

Under Authentication > Services > Firewall authentication methods, Default group determines which group an external user receives when no matching local group exists. A broad or historically grown Default Group can therefore assign unexpected policies. A deliberately restrictive fallback group whose behavior has been tested positively and negatively is safer.

Microsoft Entra ID SSO uses its own Fallback user group in the Entra server configuration. This setting also applies when the server is used under Firewall authentication methods. Therefore, do not treat the general Default Group and the Entra fallback group as the same setting.

Plan the example and prerequisites

The following example separates three purposes:

• Local_Contractors: local pilot group for a few external staff members;
• SFOS_Internet_Standard: imported AD group for normal internet access;
• SFOS_SSLVPN: imported AD group for an SSL VPN policy;
• auth-pilot@example.com: deliberately created test account;
• LAN-Users-to-WAN: logged firewall rule for the internet test.

example.com is a reserved documentation domain. Replace the group names, user, and rule name with the organization’s naming convention. A good group name describes its function rather than just a department. For example, SFOS_SSLVPN remains understandable if the organizational structure changes later.

Before the first change, record:

• the current order under Authentication > Groups;
• the Default Group and, for Entra ID, the fallback group;
• group policies and user-specific overrides;
• affected authentication services and Remote Access policies;
• a tested administrator account and an independent management path;
• a pilot user with the expected positive and negative behavior.

Create a local user group

Create the shared baseline under Authentication > Groups > Add:

1. Enter Local_Contractors for Name.
2. Select Normal for Group type.
3. Set Surfing quota, Access time, Network traffic, and Traffic shaping only if the group genuinely needs these functions in common.
4. Enable Remote Access fields such as SSL VPN policy or IPsec remote access only for the planned access.
5. Restrict Sign-in restriction to the source addresses or intended range actually required, if the authentication model allows it.
6. Enable Quarantine digest and MAC binding only deliberately.
7. Select Save.

The field names are product-defined. The selected policies depend on the environment. A normal internet group does not automatically need VPN, Quota, or MAC Binding. The fewer tasks a group combines, the easier its effect and rollback are to understand.

Assign users without creating hidden overrides

Create and manage normal local users covers the username, password, group inheritance, authentication method, and validation in full. They can be assigned to a group under Authentication > Users. In group editing, Show group members displays the members, and Add member(s) can add suitable local users. For externally managed identities, the directory remains the source of membership. A manual local assignment does not replace a correct AD, LDAP, or Entra configuration.

User-specific policies take precedence over group policies. An override can be useful for a documented exception or pilot, but it can make a later group change appear ineffective. For every differing user, record which field was overridden, why the exception exists, and how to return to the group value.

The complete creation and validation of Access Time policies, Surfing and Network Traffic quotas, and MFA for Sophos Firewall remains in the respective specialist articles. Only assign the policy that has already been planned in the group object.

Operate imported AD groups in a controlled manner

AD groups are imported to the firewall under Authentication > Servers > Import. In an HA cluster, perform the import on the Primary device. The import wizard brings in only the selected groups. A group created later in AD therefore does not appear on the firewall automatically and must be imported again or deliberately created to match.

Nested AD groups are not evaluated. If a subgroup is to be used for a firewall rule, VPN policy, or another function, that exact subgroup must be imported. A user’s primary AD group is also not imported as a regular membership. Explicit security groups are therefore better suited to policies than the default AD group Domain Users.

After changing AD memberships, imported groups, or group order, trigger a new sign-in. Only then does the firewall evaluate the groups again and update the user object.

Understand the main group and group order

For an AD user, Authentication > Users shows two different levels:

• Group: the first matching group in the firewall list and therefore the main group;
• Other group memberships: the user’s other imported groups.

Change the order under Authentication > Groups > Reorder. If auth-pilot@example.com belongs to SFOS_Internet_Standard and SFOS_SSLVPN, the matching group higher in the list becomes the main group at the next sign-in.

Do not change this order spontaneously for a single incident. First determine which function is affected and whether it supports other groups at all. Moving a group can otherwise repair a VPN case while changing MFA, Quota, or Access Time for other users.

Multiple groups are evaluated differently by each function

The following boundary applies explicitly to Active Directory group memberships. Do not transfer it to LDAP, RADIUS, or Microsoft Entra ID without verification.

Multiple AD groups can be considered for:

• 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 Full Tunnel policy is involved, the result is a Full Tunnel. Therefore, validate this combination with a real client test rather than only comparing group names.

Only the main group or an explicit user assignment is considered 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.

For functions that support multiple groups, the order of the relevant rule or policy still matters. A firewall rule can, for example, match through SFOS_SSLVPN even though SFOS_Internet_Standard is the main group. This does not mean that MFA or Quota also uses SFOS_SSLVPN.

Test the group effect with a real user

A saved group and a visible user are not yet proof of success. Use the same workflow for the pilot that will later apply in production:

1. End the pilot user’s existing session and trigger a fresh sign-in.
2. Under Authentication > Users, document the status, Group, Other group memberships, and possible user overrides.
3. Under Current activities > Live users, check the username, source IP, and Client Type.
4. For a user firewall rule, generate the expected flow and verify the Firewall Rule ID in Log Viewer.
5. For Access Time, Quota, MFA, or Remote Access, test the affected service separately.
6. Run the same flow as a negative test with a user who is not in the pilot group.
7. Record the result, time, group order, and effective policy.

Test firewall rules with Log Viewer, Policy Test, and Packet Capture shows the complete traffic test. If it is already unclear whether the service selection, identity, main group, or later rule is failing, Troubleshoot Sophos Firewall authentication failures systematically leads through the full verification chain.

Changes, rollback, and operation

Treat group changes like policy changes:

1. Document the original state and affected users.
2. Change only one group, policy, or position at a time.
3. Reauthenticate the pilot user.
4. Check the main group, other memberships, and the specific function again.
5. If the effect is unexpected, restore the previous group order and policy assignment.
6. Trigger another fresh sign-in and repeat the positive and negative tests.

Clean up an AD group in the directory first and then on the firewall. A user who still exists in AD can be created locally again at a later sign-in. Therefore, Purge AD users is not a synchronization button and not a routine step after changing a group.

Users and groups share the internal ID range up to 65535. A large visible object count alone does not prove a limit issue. If a user shows a User ID above 65535 and does not become a Live User, follow the separate procedure for the Sophos Firewall user ID limit.

Troubleshoot by symptom

New AD group does not appear on the firewall

New groups are not synchronized automatically. Run the import wizard again and, in HA, do so on the Primary. Then check under Authentication > Groups whether the exact required group is present. Do not create a broad substitute group merely to make a sign-in work.

User has the wrong main group

First document AD memberships, imported groups, and the current order. Then check whether the expected group exists on the firewall at all. Evaluate a planned change under Reorder only after a new sign-in, and test it with several representative users.

Firewall rule matches, but MFA or Quota does not apply

Firewall rules support other AD groups, while MFA and quotas do not. In the user object, check which group appears under Group as the main group. Then check user-specific overrides and the actual policy assignment. A matching rule does not prove that MFA or Quota evaluates groups in the same way.

Group change affects only one user incorrectly

Compare the user-specific policy fields under Authentication > Users. An individual override takes precedence over the group policy. Do not change the value blindly; first compare it with the documented exception and the intended inheritance state.

User is placed in the Default Group

For AD or another classic authentication server, a matching local group or group mapping is probably missing. Check the import, group name, search base, and returned attributes. For Microsoft Entra ID SSO, check the Entra server’s Fallback user group instead. Do not broaden the Default Group merely to hide the actual mapping error.

Nested AD group does not apply

Import the required subgroup itself and add the user directly to it. Then trigger a new sign-in and check Group and Other group memberships. Importing only the parent group is not sufficient.

Operations checklist

• The group purpose and responsible user source are documented.
• Local, imported, and Clientless groups are not mixed.
• The Default Group or Entra fallback group is selected deliberately and restrictively.
• Group order and expected main groups are documented.
• User overrides are justified or removed.
• The specific function supports the group membership being used.
• The pilot user was reauthenticated and checked under Authentication > Users.
• Positive and negative tests confirm the expected policy or Firewall Rule ID.
• Remote Access, MFA, Access Time, and quotas were validated separately when used.
• The rollback path for group order and policy assignment is recorded.

Frequently asked questions