Create and manage local users on Sophos Firewall

A local user is stored directly on Sophos Firewall and authenticated against its local user database. This works well for small environments, pilot accounts, and individual external contractors. A local account is suitable as a directory-service fallback only if the server order, distinct username, portal access, and behavior when the external source fails have been tested with that service. The SFOS help documents the server order but does not guarantee failover for every error condition.

This article applies to the WebAdmin interface in SFOS 22. Creating a user alone does not grant access. The group, authentication method, portal or client, and firewall or VPN policy must all fit together.

Quick workflow:

1. Define the use case, target group, and required service.
2. Prepare a restrictive Normal group under Authentication > Groups.
3. Under Authentication > Users > Add, enter a permanent username and select User type: User.
4. Assign an individual strong password and the correct group.
5. Leave policy fields unchanged on the user if the group values should apply.
6. Deliberately limit Simultaneous sign-ins and Sign-in restriction.
7. Under Authentication > Services, verify that Local is selected for the service in use.
8. Configure the portal, user rule, or remote access policy separately and as narrowly as possible.
9. Use a pilot account to test a positive and negative sign-in as well as real traffic.
10. Only then enable MFA, add more users, and document offboarding.

⚠️ The username can’t be changed later. Define the naming convention, account type, and ownership before saving. SFOS converts uppercase letters in the username to lowercase. A replacement account has a new identity, so review its rules, quotas, VPN assignments, and audit trails again.

When a local user is appropriate

Local users don’t require Active Directory or an external RADIUS or LDAP server. This makes them simple, but it moves password management, MFA, groups, deactivation, and reviews entirely onto the firewall. This is practical for a few carefully managed accounts. For many employees or frequent onboarding and offboarding, a central directory is usually easier to maintain.

A normal local user is suitable, for example, for:

• a pilot account for the captive portal, user portal, or remote access;
• a small environment without a directory service;
• an individual external contractor with a clear duration and owner;
• a tested fallback with its own username when an external user source is temporarily unavailable.

Do not use one local account for several people. Shared credentials make password changes, MFA, quotas, auditing, and clean offboarding more difficult.

Don’t mix user types

SFOS provides several similar user types that solve different tasks:

• A normal local user signs in with a username and password and receives policies through a normal group or deliberate user overrides.
• A guest user is time-limited, uses the guest user settings, and is typically used through the captive portal.
• A clientless user is identified by an IP address and doesn’t perform an interactive sign-in.
• A local administrator receives User type: Administrator and a device access profile for web admin permissions.
• An AD, LDAP, RADIUS, or Entra user is authenticated by an external source. Depending on the method, the user’s local record is created only after the first successful sign-in.

Use User type: User for a person who should sign in to the captive portal or a VPN service. This doesn’t grant the account web admin or SSH access.

Example and prerequisites

The following example uses:

• username pilotuser01;
• display name Local Pilot User;
• email address pilotuser01@example.com;
• group Local_Pilot_Users;
• firewall rule Local-Pilot-to-WAN;
• allowed sign-in source from 10.20.30.10 through 10.20.30.50.

example.com is a reserved documentation domain, and the address range is in a private example network. Replace the username, email address, group, rule, and addresses with values from your environment. The username is not tied to an email address and therefore remains valid if that address changes. The naming convention should align with help desk procedures, offboarding, and existing directory names.

Clarify the following before creating the account:

• Which service authenticates the user: captive portal, user portal, VPN portal, SSL VPN, IPsec, or another supported access method?
• Which normal group defines the shared baseline?
• Which firewall or remote access policy will permit the required access?
• From which IPv4 addresses may the account sign in?
• How many simultaneous sign-ins are operationally required?
• Is local MFA required, and through which portal will initial enrollment take place?
• Who deactivates the account and checks existing sessions during offboarding?

Managing user groups and the main group on Sophos Firewall explains the shared group logic. Use a Normal group for normal local users. A Clientless group belongs to the IP-based model and isn’t the correct baseline for this sign-in workflow.

Create the local user

Create the account under Authentication > Users > Add:

1. Enter pilotuser01 for Username. SFOS stores the value in lowercase, and it can’t be changed later.
2. Enter Local Pilot User for Name.
3. Set User type to User.
4. Enter and confirm a long, unique password from the approved password process.
5. For Email, enter pilotuser01@example.com or this person’s email address. For a technical account, use a monitored address with a clearly designated owner.
6. For Group, select Local_Pilot_Users.
7. Only change Quarantine digest, policy, and remote access fields when the feature or a documented user exception is required.
8. Set Simultaneous sign-ins and Sign-in restriction appropriately.
9. Click Save.

SFOS rejects commonly used passwords and words detected by its dictionary check. Use a long, unique password from your password process for every account. A copyable example password would immediately become a known secret and is therefore not a secure template.

Group values or user overrides

The user record can contain Surfing quota, Access time, Network traffic, and Traffic shaping, as well as several remote access fields. User-specific values take precedence over group values. If the group should remain the maintainable baseline, don’t override these fields preemptively.

A user override is appropriate for a clearly documented exception, such as a stricter access time during a temporary assignment. Record:

• which field differs from the group value;
• why the exception is required;
• when it will be reviewed or removed;
• how the original group value becomes effective again.

Access time for users and surfing and network traffic quotas explain each policy in full. Assign a policy to the user record only after you understand its behavior.

Limit sign-in count and source

Simultaneous sign-ins limits concurrent sessions. Global setting uses the value configured for new users under Authentication > Services. Alternatively, set a user-specific value or choose Unlimited. Unlimited sessions are rarely required for a normal personal user and make shared credentials harder to detect.

Sign-in restriction limits the IPv4 addresses from which the user may sign in:

• Any node: allow sign-in from any reachable source;
• User group nodes: inherit the group setting;
• Selected nodes: enter individual intended IPv4 addresses;
• Node range: allow a contiguous IPv4 range.

For this example, select Node range and enter 10.20.30.10 as the start address and 10.20.30.50 as the end address. Replace both values with the smallest contiguous range from which the user actually signs in. If you need individual, noncontiguous IPv4 addresses, use Selected nodes. A selection that’s too narrow blocks legitimate sign-ins; Any node does not replace a firewall rule, portal ACL, or MFA.

Don’t enable MAC binding for this basic workflow. It supports client-based authentication but not remote access VPN or captive portal. If it’s enabled without a MAC address, SFOS automatically binds the first detected MAC address at the initial sign-in. On mobile devices, after Wi-Fi changes, or on shared clients, this can quickly become an unexpected dependency.

Configure authentication and access

A saved user can only sign in to a service that queries the local database. Under Authentication > Services, enable the Local method in the list for the service in use.

The areas are separate:

• Firewall authentication methods for firewall traffic and the captive portal;
• User portal authentication methods for the user portal;
• VPN portal authentication methods for the VPN portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods for these VPN methods;
• SSL VPN authentication methods for remote access SSL VPN.

Multiple sources are queried in the displayed order. A successful test on the user portal therefore doesn’t automatically prove that the same user is correctly configured for SSL VPN or IPsec.

You can select no more than 20 servers per authentication method. For the user portal and VPN portal, the inheritance option is Set authentication methods same as firewall. For SSL VPN, SFOS shows Same as VPN or Same as firewall, depending on the selected reference. Check this option and the resulting order before adding or moving Local.

Configure access separately

The local identity doesn’t open a network path. The captive portal additionally requires device access, web authentication, and a suitable user rule. The complete workflow is in Set up and test the Sophos Firewall captive portal.

The user portal and VPN portal are also separate services. The Sophos Firewall portal model explains ports, purpose, device access, and WAN boundaries. Maintain remote access policies in the relevant VPN guides and don’t consider them complete merely because a field is set on the user object.

Interpret remote access fields correctly

For remote access methods other than SSL VPN, user-specific policy values take precedence over the group. SSL VPN follows different logic: The user receives the resources from every full- and split-tunnel policy that contains either the user or one of their supported groups. The SSL VPN policy field is therefore not a simple replacement for group policies.

SSL VPN IP address only appears when static addresses are enabled under SSL VPN global settings. The IPv4 or IPv6 address must be unused and come from the static range created there automatically. If a RADIUS server assigns addresses, its assignment takes precedence. IPsec remote access, by contrast, enables access with Sophos Connect and can receive its own lease address.

L2TP and PPTP are legacy methods. After assignment, the user must first sign in to the VPN portal and create a password before a connection is possible. The current assessment and migration path for L2TP are in L2TP remote access; do not plan PPTP for new access. Clientless SSL VPN policy opens only the assigned browser bookmarks and is not a full tunnel. The separate workflow is in Clientless access.

For a user-based firewall rule, define the source, destination, service, and user or group as narrowly as possible. Keep Log firewall traffic enabled during acceptance testing. The rule fundamentals are covered in Understand and securely configure Sophos Firewall rules.

Verify with positive and negative tests

A visible account with Active status isn’t yet proof of success. Test the pilot through the exact service that will be used later:

1. Sign in as pilotuser01 in a private browser window or from a clean test client.
2. Under Current activities > Live users, verify username, source IP, and Client Type.
3. In Log Viewer > Authentication, verify the successful sign-in, local authentication, and timestamp.
4. Generate the intended traffic and verify Local-Pilot-to-WAN or its Firewall Rule ID as the expected match in the firewall or VPN log.
5. Use an explicitly disallowed source or function as a negative test.
6. If a quota or access time is active, test its effect separately within and outside the configured limit.
7. Document the result, selected group, user overrides, and authentication method.

A negative sign-in shouldn’t fail only because an intentionally incorrect password was used. Also verify that an unauthorized source, a user without the required group, or a function that should not be available genuinely receives no access. This separates password validation from policy and rule behavior.

If it is unclear whether the user status, authentication method, group, or access rule is causing the error, Troubleshoot Sophos Firewall authentication errors systematically provides the sequence of checks. For detailed analysis, /log/access_server.log contains authentication, authorization, and accounting events; Log Viewer remains the first step.

Manage passwords, MFA, and usage

To change an existing local account’s password as an administrator in SFOS 22 and 23, open the relevant user under Authentication > Users and click Change password. First verify the account and its owner, and prepare a new long, unique password through the approved password process. Enter the new password, save the change, and securely deliver the secret to the authorized person. Then test a fresh sign-in with the new password to the service actually used. This WebAdmin operation is separate from self-service in the user portal; externally authenticated accounts remain managed by their respective user source. This does not guarantee that existing sessions are automatically terminated.

A local user can change the password under User portal > Personal > Change Password. This applies to the local database, not externally authenticated AD, LDAP, or RADIUS accounts. Under Personal > Personal Details, the user can also change the display name. The username and email address remain read-only there and are maintained by the administrator on the user object. Make the user portal reachable only from the required zones; do not expose it broadly to the WAN solely to allow users to maintain these details.

For additional protection, select the account under Authentication > Multi-factor authentication. With Generate OTP token with next sign-in, the user enrolls the token through the user portal or VPN portal. MFA for Sophos Firewall explains the hash algorithm, portal access, recovery, and pilot rollout. Enable MFA only after the regular sign-in and recovery process have been tested.

Under Authentication > Users > > View usage, the firewall shows assigned quotas, surfing time, and data usage. Traffic must match a user-based firewall rule with Log firewall traffic for this data to appear. Reset user accounting resets surfing and network traffic counters and therefore isn’t used as a generic sign-in fix.

Roll back the change and remove the account

Before the pilot phase, document the existing order under Authentication > Services and every group, portal, rule, and VPN setting you change. This ensures that rollback does not rely on guessed defaults. When a person leaves, a pilot fails, or the account is no longer needed, work in reverse order:

1. Check dependencies in rules, groups, remote access policies, quotas, MFA, and documentation.
2. Under Authentication > Users, select the user and set Change status to Inactive.
3. Attempt a fresh sign-in as a negative test.
4. Under Current activities > Live users, check existing sessions and use Disconnect for a normal user when required.
5. Remove the user from firewall rules and remote access policies, or restore the documented previous selection.
6. Restore changed group, portal, and authentication service settings exactly to their recorded previous state.
7. Check firewall, VPN, and configuration logs for further attempts, residual traffic, and the changes made.
8. Only delete the account after dependencies are resolved, or keep it inactive according to the retention process.

The SFOS help does not confirm that deactivation terminates all existing connections. Check and disconnect sessions and tunnels separately. After reactivation, repeat the positive and negative tests.

Before a risky deletion, you can export the User configuration object with Include dependent entity under Backup and firmware > Import export. This export contains sensitive data, including passwords, and must be encrypted and stored in an access-controlled location. The correct Secure Storage Master Key must also be available for a later import. An import updates the existing configuration and applies imported values where objects overlap. Exported shared dependencies can therefore also be overwritten. Review the content and impact before importing, preferably in a suitable test environment.

A full backup is not a quick rollback for one user: a restore replaces the entire configuration, restarts the firewall, and discards later changes. Backup and restore on Sophos Firewall explains the process.

In an HA cluster, make the change on the primary appliance and then verify synchronization status. Logs and reports are not synchronized between nodes and must be considered separately during troubleshooting.

Users and groups share internal IDs. A high object count alone doesn’t prove a problem. However, if a user shows a User ID above 65535 and cannot authenticate, use the separate Sophos Firewall user ID limit workflow instead of changing passwords or rules speculatively.

Troubleshoot by symptom

Username and password are rejected

Under Authentication > Users, verify that the account is local, active, and stored with the expected username. Then check under Authentication > Services whether Local is selected for the specific service. A successful sign-in to another portal doesn’t prove this service selection.

Sign-in works, but the user rule doesn’t match

Under Current activities > Live users, verify the identity, source IP, and Client Type. Then check rule position, Source Zone, user or group, and Firewall Rule ID in Log Viewer. A network rule above the user rule may already be matching the traffic.

A group change has no effect

Look for user-specific values for quota, access time, traffic shaping, or remote access. These overrides take precedence over the group. Restore group inheritance only after checking the value against the documented exception.

User can sign in from an unexpected source

Check Sign-in restriction on both the user and group. Also verify the service in use, device access, and network rule. A setting of Any node isn’t automatically compensated for by MFA or a narrow firewall rule.

View usage remains empty

Verify that the user is recognized as a live user and that traffic matches a user-based rule with Log firewall traffic. Then check the time range, quota assignment, and actual test traffic. Reset user accounting doesn’t generate missing logs or repair the wrong rule.

Operational checklist

• Live users shows pilotuser01, the expected source IP, and the intended Client Type.
• The authentication log confirms local sign-in; Local-Pilot-to-WAN or its Firewall Rule ID matches the test traffic.
• An incorrect password, disallowed source, and unauthorized function provide the expected negative evidence.
• User overrides, Simultaneous sign-ins, Sign-in restriction, and any expiry date are documented.
• MFA enrollment and the recovery process have been tested if MFA is used.
• The previous state, ownership, deactivation, session disconnection, and later deletion are documented.

Frequently asked questions