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, individual external contractors, or a deliberately maintained fallback. However, creating the account alone doesn’t grant access. The group, authentication method, portal or client, firewall or VPN policy, and subsequent verification must all fit together.

The safe short path is:

1. Define the use case, target user, 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. A new account with a different name creates a new identity and can split rules, quotas, VPN assignments, logs, and audit trails.

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 deliberately 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 documented fallback when an external user source is temporarily unavailable.

A local account isn’t recommended as a shared 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, its local record is only created at 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.

Plan the 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 10.20.30.0/24.

example.com is a reserved documentation domain; 10.20.30.0/24 is only used here as a private example network. Replace the username, email address, group, rule, and network with values from the local environment. The username is deliberately function-neutral and doesn’t contain an email address, so a later email change doesn’t alter the sign-in identity. In production, the naming scheme should match the help desk, offboarding process, 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 carries the shared baseline?
• Which firewall or remote access policy permits the later 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.
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 the actual responsible address.
6. For Group, select Local_Pilot_Users.
7. Only change policy and remote access fields when a documented user exception is intended.
8. Set Simultaneous sign-ins and Sign-in restriction appropriately.
9. Click Save.

SFOS rejects commonly used passwords and dictionary words found in its database. This article deliberately doesn’t show an example password. A copyable password in documentation would immediately become a known secret and wouldn’t be 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 only a policy that is already understood in the user record.

Limit sign-in count and source

Simultaneous sign-ins limits concurrent sessions. Global setting adopts the value for new users under Authentication > Services. Alternatively, set an individual 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 the example, use the actual management, user, or VPN source network rather than blindly copying 10.20.30.0/24. A selection that’s too narrow blocks legitimate sign-ins. Any node, however, only broadens the possible sign-in source and doesn’t 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.

Connect the authentication method and access

A saved user can only sign in to a service that actually queries the local database. Under Authentication > Services, select Local for the intended service.

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.

Portal, rule, or VPN policy remains separate

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.

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 the expected rule or policy 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 inside and outside the boundary.
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 matching group, or an unintended function genuinely has no access. This separates password validation from policy and rule behavior.

If it’s unclear whether the local database, service selection, user status, group, or subsequent rule is failing, Troubleshoot Sophos Firewall authentication errors systematically provides the complete sequence. For deeper analysis, /log/access_server.log contains authentication, authorization, and accounting events; Log Viewer remains the first step.

Operate passwords, MFA, and usage

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. Make the user portal reachable only from the required zones and don’t expose it broadly to WAN merely for password maintenance.

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 normal sign-in and recovery path work.

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 restarts surfing and network traffic counters and therefore isn’t used as a generic sign-in fix.

Deactivate and remove the account cleanly

When a person leaves or the account’s purpose ends, don’t immediately delete it without review:

1. Check dependencies in rules, groups, remote access policies, quotas, MFA, and documentation.
2. Under Authentication > Users, select the user and use Change status to make it 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. Check firewall and VPN logs for further attempts or residual traffic.
6. Only delete the account after dependencies are resolved, or keep it inactive according to the retention process.

Don’t treat deactivation as a guarantee that every existing connection ends automatically. Check sessions, tunnels, and traffic separately. After reactivation, repeat the positive and negative tests.

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 isn’t authenticated, use the separate Sophos Firewall user ID limit workflow instead of changing passwords or rules on suspicion.

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

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. Only return a value to group inheritance after comparing it with 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

• The account’s use case, owner, and expiry date are documented.
• Username and user type were chosen deliberately before saving.
• A Normal group carries the shared baseline.
• User overrides are avoided or justified.
• Simultaneous sign-ins and Sign-in restriction fit the use case.
• Local is selected for every required authentication service.
• Portal, firewall rule, or VPN policy was configured separately.
• Positive and negative sign-in tests and real traffic were verified.
• Live Users, Authentication Log, and the expected rule or policy agree.
• MFA and recovery are tested when MFA is used.
• A responsible person owns password changes, usage, and offboarding.
• Deactivation, existing sessions, and later deletion are separate steps.

Frequently asked questions