Skip to content
Avanet
Sign in

Manage Sophos Firewall user groups and the main group correctly

Sophos Firewall

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:

  1. Determine the user source and purpose of the group.
  2. Create a local group or import the specific directory group you need.
  3. Under Authentication > Services, check the effective Default group, or on the Entra server, the Fallback user group.
  4. For AD, document the order under Authentication > Groups > Reorder and the expected main group.
  5. Log off the pilot user and log in again. Then check the fields Group and Other group memberships under Authentication > Users > user > Policies.
  6. Test the affected function with an authorised and an unauthorised 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. A user can therefore 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:

  1. Does the identity come from the local database, Active Directory, LDAP, RADIUS, Microsoft Entra ID or a clientless mapping?
  2. Which group is the main group?
  3. Does the affected function support additional AD group memberships?
  4. 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. For AD, Sophos also documents manually creating the group in both AD and the firewall as an alternative. Group assignment and permissions must still be checked after a fresh sign-in. 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, the rule and the 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.

Conflicting AD descriptions of the first login: The AD setup guide describes automatic assignment to the Default group on first login; the AD FAQ, however, mentions the Default group only when none of the user’s AD groups exist on the firewall. For users who belong only to an OU and not to any directory group, the AD server overview explicitly names Open group, whereas the group overview and the FAQ refer to the configured Default group. These descriptions are inconsistent and do not establish a special, universally applicable first-login group or any priority it would take. The configured Default group must be distinguished from the factory default, Open group.

Before rollout, check the actual Default group and its inherited permissions. Check the first login separately using two new, dedicated pilot accounts: one with an AD group that has already been imported into the firewall, and one whose AD groups have not been imported there. For both accounts, check the Group and Other group memberships fields under Policies, as well as access that should be allowed and access that should explicitly not be allowed. If an unexpected group assignment occurs, stop the rollout and clarify the cause. Do not delete production groups or broaden fallback permissions for these checks.

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 change 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 reorganisation.

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, and positive and negative tests.

Create a local user group

Go to Authentication > Groups and click Add:

  1. Enter Local_Contractors as the group name.
  2. For Group type, choose Normal.
  3. 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.
  4. 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.
  5. Limit Sign-in restriction as much as possible with Selected nodes or Node range to the required sources. Selected nodes allows only the specified IP addresses; Node range allows addresses within the specified IP range. Any node allows login from any network.
  6. Turn on Quarantine digest and MAC binding only if the group needs these functions. Quarantine digest sends a summary of quarantined emails to the user’s mailbox. MAC binding restricts sign-in to the intended devices.
  7. Click Save.

The product defines the field names and their behaviour; 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. Under the user’s Policies, check 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 retest only the affected function. 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 full. In the group object, assign only a policy that you have already planned.

Understanding group fields in the XML API

If you manage groups through automation, the XML model provides UserGroup as the group object, GroupDetail as the configuration body and GroupMembers with GroupName and UserName as membership data. This is not an AD membership import; for directory users, the directory remains authoritative. Use the XML API safely covers authentication, explicit operation wrappers and evaluation of the XML response.

The following fragment shows only the documented structure for the existing pilot examples. It is not a complete Add/Edit request; the operation wrapper and other required configuration fields are missing. The omission of fields does not imply that a change preserves existing values.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

Replace the group name and user with the precisely planned local target. 192.0.2.10 is an IPv4 documentation address and must be replaced with an allowed sign-in source that is actually required. The XML field names remain unchanged. They map to the UI fields as follows:

  • SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
  • DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
  • SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, not the Clientless group type.
  • SophosConnectClient: IPsec remote access via the Sophos Connect Client.

For LoginRestriction, the reference example distinguishes between AnyNode, SelectedNodes and NodeRange. AnyNode corresponds to Any node and does not restrict the sign-in source; it is not a troubleshooting default. SelectedNodes uses NodeList with individual IPAddress entries. NodeRange instead uses FromIP and ToIP, for example 192.0.2.10 to 192.0.2.20. Both range boundaries are also documentation values and must be replaced with the smallest required IPv4 range, without broadening existing restrictions. Although the table marks FromIP and ToIP as mandatory fields, their description limits them to Node range; this does not establish a general requirement for the other variants.

The API reference lists Enable or Disable for each of QuarantineDigest, MACBinding, L2TP, PPTP and SophosConnectClient, and documents Disable as the default. This is reference information, not evidence of the group’s currently stored state. When QuarantineDigest is enabled, the quarantine summary is sent daily by email. PPTP remains excluded from new designs; L2TP remains only the limited compatibility option described above.

Limitations of the reference example: It separates settings for Normal groups from a Clientless branch that shows QoSPolicy. However, it is contradictory regarding GroupType: the sample contains Normal/Clienless, the description names Normal or Clientless and identifies the data type as INTEGER. The sample also contains colon placeholders rather than complete XML content. Neither a corrected Clientless encoding nor a numeric mapping may be inferred from this. For a write operation, use a value read or exported from the installed version whose mapping has already been established; otherwise, use the safe UI procedure. Slash-separated alternatives such as Enable/Disable are not single values to copy.

The sample also shows After with a nested Name as a position specification. The second table row for Name mentions moveto, but does not establish an independently executable operation. Treat a position change like Reorder: it can change the Main Group. Beforehand, record the order, memberships, current and intended policy state, and rollback procedure; afterwards, check with the pilot and restore the saved order if the effect is unexpected. The sample establishes neither replacement or merge behaviour for GroupMembers nor update semantics for After or omitted fields.

Before a narrowly scoped Add/Edit write operation, record the target name and intended state. Afterwards, evaluate the actual XML operation result, read back exactly the named group and perform the positive and negative tests described above on the affected service. For Add and Edit, the reference maps 502 to the key UserGroupRecordExists and 503 to the key UserGroupDuplicateIPInLoginRestriction. If the corresponding result occurs, first check the intended existing group name or duplicate addresses in SelectedNodes, respectively. Do not blindly resend the request or broaden LoginRestriction. These mappings establish reference keys, not the full rendered runtime messages.

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

AD queries must work before the import: the server requires the correct NetBIOS domain, Domain name, an ADS username with permission to search, read and query group memberships, and its Password. A domain administrator account is not required for group import. Connection security offers SSL/TLS as the default and STARTTLS as an encrypted alternative; Plaintext transmits credentials unencrypted and is not a secure production option. The Port must match the selected connection type. When using Validate server certificate, upload the AD server certificate under Certificates > Certificates > Add > Upload certificate; Server IP/domain must use the CNAME specified in the certificate. If the firewall cannot resolve this name, check internal DNS resolution or Network > DNS > DNS host entry. The complete server setup is covered in the AD article linked above.

The Search queries limit the set of users included. For example, OU=VPN_Users,DC=example,DC=com searches the OU VPN_Users in the documentation domain example.com; replace the OU and domain components with the actual distinguished name. A narrower search base keeps the user scope manageable, but must not exclude the intended users. Only users included in the search can appear as live users through this server. Test connection checks connectivity and credentials, but does not yet prove that a normal user is assigned to the correct group. Strictly enforced LDAP Channel Binding and LDAP Signing are not supported; clarify any such AD security requirement before integration rather than bypassing it as a group issue.

The actual import proceeds as follows:

  1. Click Import for the intended AD server, then click Start in the Import group wizard.
  2. Select the appropriate Base DN for the group search. It must include the required groups and is distinct from the search base for users.
  3. Select only the intended AD groups, for example SFOS_Internet_Standard and SFOS_SSLVPN.
  4. Select the shared group policies, then check the selection and results.
  5. Under Authentication > Groups, check both groups and their policies. The wizard imports groups, not all user records or memberships immediately.
  6. Under Authentication > Services > Firewall authentication methods, check that the AD server is selected for the intended service. If AD should be queried first in this setup procedure, move the server to the first position and click Apply. In an existing environment, preserve the previously planned server order rather than changing it indiscriminately.

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

This does not apply only to Domain Users: if, for example, SFOS_Internet_Standard becomes the user’s primary AD group, that particular membership is not imported as a regular AD membership. As a result, the next matching imported group may become the main group. The firewall determines the main group from its own group list; it is not the primary group in AD.

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.

If STAS and Synchronized User ID are both configured, the authentication server uses whichever mechanism delivers the sign-in request first. If pilot results differ, also check Client Type rather than immediately reordering groups or servers.

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 synchronised; 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 matches 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 remote access IPsec or SSL VPN policies in use; 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 the user’s additional imported AD groups.

Two additional fields appear under Policies only when both prerequisites are met for each field:

  • Group SSL VPN policies: The user belongs to multiple AD groups, and at least two of those groups are included in remote access SSL VPN policies.
  • Group clientless SSL VPN policies: The user belongs to multiple AD groups, and at least two of those groups are included in clientless SSL VPN policies.

If either field is missing, first check the user’s AD memberships, the imported groups and their inclusion in the relevant VPN policy. Membership in multiple AD groups alone is not enough for the field to appear. Do not broaden production VPN permissions to make the field visible. The display is not an access test either; how the permissions are actually combined is explained below.

Under Authentication > Groups > Reorder, change the order by dragging and dropping groups. Click Close to close the dialogue. 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, moving a group could resolve a VPN issue while simultaneously changing MFA, quotas 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 without checking.

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.

For clientless SSL VPN, permissions from all policies containing any of the user’s AD groups are taken into account. Therefore, check not only the expected policy but also any additional bookmarks or resources made available through other groups.

Hotspots take only the main group into account.

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

  • WAF rules and My policy overrides;
  • 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 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. Assess these services based on the main group or a direct user assignment, not solely on the displayed value.

For functions with multiple-group support, the order of the respective rules or policies 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 quotas also use SFOS_SSLVPN.

For web policies, there are two separate decisions: first, the matching firewall rule determines the web policy. Within that policy, the first rule matching both the user and the website applies. If the pilot user belongs to both example groups and the first web rule blocks sports websites for SFOS_SSLVPN, a sports website will be blocked even if SFOS_Internet_Standard is the user’s main group and a later rule allows news websites for that group. IPS and Application control, by contrast, use the policy assigned to the matching firewall rule; the group order does not cause these policies to be combined further.

For MFA, you can explicitly include the user instead of selecting a group, or apply MFA to all users. Inclusion solely through Other group memberships is not sufficient. Hotspots in the User Portal depend exclusively on the main group; an additional AD group does not extend this list.

Verify the effect of the group

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

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

To check quota usage, 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 enabled.

Check firewall rules with Log Viewer, Policy Test and Packet Capture shows the complete traffic test. If the choice of service, identity or main group is already unclear, Systematically fix Sophos Firewall authentication errors takes you 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 recorded order and policy assignment, log the user in again, and repeat the positive and negative tests.

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:

  1. First delete the user in AD. As long as they exist there, the firewall can create them again during a later login.
  2. Under Authentication > Users, click Purge AD 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.
  3. In HA, start the process on Primary. The records are 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 rollback involves more than a single policy change.

Safely delete a named group via the API

Before any deletion, specify the exact Name of the target group and preserve its policies, order, members and uses. The older API table marking Name as optional is not permission to delete an unnamed group: the description requires a name to identify the object. Beforehand, check the actual group users, VPN assignments including L2TP/IPsec, the selection for external authentication, firewall rule references and use as the default guest group. If the group is still needed, carry out an explicitly planned, narrowly scoped migration or stop. Do not force removal, clean up users or relax access restrictions merely to make the deletion succeed. The AD sequence described above and the distinction from Purge AD users still apply.

The deletion reference links result rows to JavaScript message keys for such dependencies. These categories do not supply the missing rendered message texts. Use the XML API safely applies to request construction and XML result handling; the group deletion reference provides no payload example; confirm the complete Delete wrapper before use. If the request is rejected, retain the group and specifically check the reference shown in the result. Even after a success result, read back exactly the target, verify its absence and repeat the planned service and access tests.

Users and groups share the internal ID range up to 65535. A high visible object count alone does not prove a limit problem. If a user shows a User ID above 65535 and does not become a live user, this behaviour 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 and Other group memberships. Then take one targeted next step for each symptom.

New AD group does not appear

Restart the AD server’s import wizard and, in HA, run it on Primary. Then check under Authentication > Groups that the specific group you need exists. Do not create a broad replacement group just to make a login work.

LDAP user ends up in the default group

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

Entra user ends up 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 quotas do not

Firewall rules support additional AD groups, whereas MFA and quotas do not. Under Authentication > Users > user > Policies, check the main group, any overrides and the actual policy assignment. The rule taking effect does not prove that MFA or quotas evaluate 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 itself and add the user directly to it. Importing only the parent group is not enough.