Check the Sophos Firewall User-ID Limit and Clean Up AD Users

If new or individual users are no longer authenticated even though the directory, group, and password are correct, the internal User ID of Sophos Firewall may be the cause. Sophos also identifies cases in which affected users cannot download an .ovpn configuration from the VPN Portal.

Sophos documents a shared internal ID range through 65535 for users and groups. Users with a higher ID are not authenticated and cannot appear as Live Users. However, the symptoms alone do not prove that the limit has been reached; the ID actually assigned is what matters.

The current Sophos help pages count this range differently: Authentication > Users states a maximum of 65,535 user IDs, while Current activities > Live users states 65,536. For diagnosis, the reliable boundary remains the same in both descriptions: 65535 is supported, while a higher value is not.

Check the User-ID Limit Quickly

The specific ID is visible in WebAdmin:

1. Open Authentication > Users.
2. Select Show additional properties and display User ID.
3. Find the affected user and note their ID.
4. If possible, check a working user from the same group for comparison.
5. Under Current activities > Live users, check whether the user appears after signing in.

The result is clear:

• User ID up to 65535: The documented limit has not been exceeded for this user. The general authentication troubleshooting workflow then guides the checks of the server, service, Live Users, group, MFA, portal, and subsequent traffic path.
• User ID above 65535: The user object is outside the supported range. The firewall does not authenticate this user. Sophos also identifies a missing .ovpn download as a possible functional problem.
• User is missing from the list: Users from external authentication servers normally appear here only after their first successful sign-in to a firewall service. Check the actual authentication path first.

⚠️ The number of visible users is not sufficient for diagnosis. Groups also occupy IDs, and gaps in the numbering are possible. Only the User ID column shows whether the specific user is affected.

A demonstrably successful sign-in to the VPN Portal speaks against the User-ID limit as the main cause. If the .ovpn is missing, remains empty, or cannot be generated, Sophos Firewall: .ovpn missing or 0 bytes separates policy, user, certificate, and system errors. The User-ID limit is only one possible diagnostic branch.

What the Internal User ID Means

The User ID is the internal numeric assignment of a user or group object on the firewall. It is neither an Active Directory SID nor a Microsoft Entra Object ID, and it is not the Synchronized user ID authentication feature.

A simple example shows the limit:

• 60000 is within the supported range.
• 65535 is the last supported ID.
• 65536 is already outside the supported range.

Users from Active Directory, RADIUS, and other external authentication servers are not imported completely in advance. Their local record is generally created when they authenticate to a firewall service for the first time. Groups and existing user objects consume the same ID range.

Manually created Clientless Users are also part of the local identity structure. Set up Clientless Users on Sophos Firewall provides their safe configuration and test procedure; however, a high object count alone still doesn’t prove a User ID problem.

Sophos recommends deleting users and groups that are no longer required so that free IDs can be reused. However, this does not imply automatic renumbering: Deleting old objects does not document or guarantee that an existing user with an excessively high ID will immediately receive a lower number.

Check Dependencies Before the Clean-Up

Cleaning up users or groups affects the identity and policy structure. Before a larger change, a current firewall backup should be available. A list of the objects to be removed, their User IDs, and their known uses is also required.

Check at least the following dependencies for every user and group:

• SSL VPN and IPsec Remote Access policies;
• user-based firewall, web, and application policies;
• MFA, OTP, or token assignments;
• Main Group and other group memberships;
• SSL/TLS inspection rules;
• directory source and behavior at the next sign-in.

Do not delete objects merely because they are old or have a high ID. Clearly obsolete test accounts, former employees, and unused groups come first. Do not blindly remove and recreate production identities.

Clean Up AD Users in a Controlled Manner

Use Purge AD Users Correctly

Purge AD users removes local records for AD users who have already been deleted from Active Directory. Individual users do not need to be selected: The firewall compares the records with AD and removes only users who no longer exist there.

The safe procedure is:

1. Check that the configured AD server is reachable and processes sign-ins normally.
2. First delete users who are no longer required from Active Directory.
3. On the firewall, open Authentication > Users.
4. Run Purge AD users.
5. Check that only the expected records have disappeared.

An account that is only disabled in AD but still exists there is not removed automatically by this procedure. If the local record of a user who still exists in AD is removed from the firewall, it may be created again during a later sign-in. Set Up Active Directory on Sophos Firewall explains the configuration and group import.

In an HA cluster, Purge AD users is started on the Primary device. The firewall removes the records on the Primary and Auxiliary devices; the result should be checked on both. Sophos documents that the purge does not interrupt sign-in, sign-out, or accounting events. However, this does not guarantee the behavior of every active VPN session. For very large clean-ups, a maintenance window, authentication monitoring, and a rollback plan are advisable.

Clean Up Local Users and Groups

Delete local users, test accounts, and groups that are no longer required specifically under Authentication > Users or Authentication > Groups. Purge AD users does not clean up AD groups. First remove an AD group that is no longer required from AD and then remove it separately from the firewall.

Perform the clean-up in small, traceable steps:

1. Document clearly obsolete objects and their references.
2. Remove or replace references in rules, VPN policies, or other configurations in a controlled manner.
3. Delete a small set of objects that are no longer required.
4. Test production sign-in, group and policy assignment, and MFA.
5. Only then continue with the next clean-up step.

Disabling a local account is not sufficient if its ID is to be reused. Broad group imports should also be limited to the groups actually required for VPN, portals, rules, or user policies.

Verify the Result

A clean-up is not successful merely because fewer objects are visible. Afterwards, test the same user path again:

1. Under Authentication > Users, check that only the expected AD records were removed.
2. In an HA cluster, compare the result on the Primary and Auxiliary devices.
3. Display the User ID of the affected account again.
4. Authenticate the user to the service that is actually affected.
5. Under Current activities > Live users and in the authentication logs, check whether the sign-in was successful.
6. If the original error affected VPN access, test the VPN Portal, .ovpn download, and tunnel afterwards.
7. Cross-check a representative production AD sign-in, including group, policy, and MFA.

If the ID remains above 65535, the limit problem has not been resolved. Deleting additional production objects or repeatedly recreating the affected account is not a safe diagnostic method. A Sophos Support case containing the firmware version, user source, User ID, timestamp, authentication log, and documented clean-up steps is more appropriate.

Prevent User-ID Problems

User hygiene should be part of normal firewall operations:

• import only the directory groups that are actually required;
• clean up former employees in the directory first and then on the firewall;
• delete local test and project accounts after use;
• check old user and group objects after directory restructuring;
• compare User IDs early when unusual authentication or VPN Portal problems occur;
• document Main Groups, MFA, and policy dependencies;
• perform larger clean-ups with a backup, a small change set, and a functional test.

The firewall should know only the identities it actually requires for authentication, policies, portals, Remote Access, and reporting. It does not replace a proper identity lifecycle in the directory service.

FAQ