Skip to content
Avanet

Sophos Firewall: Migrate eDirectory Before SFOS 23

Sophos Firewall

SFOS 23.0 no longer supports the native eDirectory authentication server. If a native eDirectory server configuration remains on the firewall, the firmware upgrade to SFOS 23.0 or later will fail. A supported authentication server must therefore be working before the upgrade, and the native eDirectory server and SSO configurations must be removed completely.

eDirectory still works in SFOS 22.0 MR2. This time should be used for a controlled parallel operation: add the new source, validate users and groups with real accounts, migrate the authentication services in a controlled manner, and delete eDirectory only when the rollback path is no longer needed. Coupled Entra ID SSO services are handled together. The MR2 overview puts the other changes in this version into context.

Quick process

  1. Inventory all eDirectory dependencies across servers, groups, services, rules, VPN and SSO.
  2. Prepare a current backup, a local administrator and documented console access.
  3. Choose generic LDAP, Active Directory, RADIUS or Microsoft Entra ID SSO as the target, depending on the use case.
  4. Add the new authentication server in parallel and validate the connection, users and groups.
  5. Map groups and policies deliberately to the new source.
  6. Migrate the services under Authentication > Services in a controlled manner and test them with real accounts; handle coupled Entra ID SSO services together.
  7. Only after full acceptance, delete all native eDirectory server and SSO configurations, create another backup and start the SFOS 23 upgrade.

This is deliberately not a change made with a single switch. The firewall uses authentication servers per service and in a defined order. Permissions also often depend on groups which may have the same visible name after the migration but do not automatically have the same assignment or effect.

What currently depends on eDirectory

Before making the first change, it must be clear where eDirectory is actually used. The inventory should cover at least these areas:

  • Authentication > Servers lists the eDirectory servers and possibly several directory targets.
  • Under Authentication > Services, each service defines which servers are queried and in which order.
  • Under Authentication > Groups, group policies, Default Group and group order can determine a user’s effective permissions. Active Directory also has Main Group and additional memberships.
  • Firewall rules, Web and Application policies, and Traffic Shaping can reference users or groups.
  • VPN Portal, SSL VPN, Remote Access IPsec, User Portal and Captive Portal have separate login and authorisation paths.
  • MFA and administrative logins can depend on groups and authentication order.
  • User-based reports and transparent user identification still require a reliable mapping between the user and the connection.

A screenshot of the current server, service and group order is often more useful than a list of names alone. For each important group, also record at least one positive and one negative test user. This makes it possible to verify not only who is granted access later, but also who is correctly rejected.

Choose the right target method

There is no universal 1:1 replacement for every eDirectory environment. An organisation can continue using the existing directory through LDAP, migrate identities to another directory, or combine several authentication methods depending on the service.

Keep the existing eDirectory through generic LDAP

If eDirectory itself remains in place, Sophos Firewall can query it for user logins through the supported LDAP server server type. This approach does not automatically change the directory tree, but it requires a new LDAP configuration with the appropriate Base DN, login attribute and group attribute.

The important limitation is that native eDirectory SSO is no longer available from SFOS 23. The generic LDAP server handles authentication, but not transparent user identification. Users who were previously identified automatically therefore need a new SSO or login flow. The complete field description is available in Connect a generic LDAP server to Sophos Firewall.

Active Directory

Active Directory is suitable when the users already exist in a Windows domain or are deliberately being migrated there. Groups must then be imported, Main Group and policies checked again, and any required transparent user identification built separately. Connect Active Directory to Sophos Firewall explains LDAPS, group import and the service tests.

STAS reports Windows domain logins transparently to the firewall; it does not convert the existing eDirectory SSO configuration. If this identity path is required, plan it as a separate migration using STAS for Sophos Firewall.

RADIUS

RADIUS is suitable when a central authentication service or MFA gateway already exists. The RADIUS server must provide the firewall with the information required for the relevant service; it does not automatically carry over a directory group model. The MFA method must match the service: for example, VPN Portal does not support challenge-based RADIUS MFA. Shared Secret, group attribute, timeouts and further limitations are covered in Set up a RADIUS server on Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO can be useful for documented portal, administrator and Remote Access scenarios. However, it is not a general replacement for every username-and-password query or a method for transparent LAN user identification. Related services must be coordinated for Remote Access: VPN Portal and SSL VPN use the same Entra server; with a provisioning file, this also applies to IPsec. Redirect URIs, groups, Conditional Access and the supported services are described in Microsoft Entra ID SSO for Sophos Connect and VPN Portal.

The target architecture can be mixed. For example, LDAP can initially authenticate users from the existing eDirectory while Remote Access is later migrated specifically to RADIUS or Entra ID SSO. The important point is that every service in use has a tested target path before eDirectory is deleted.

Secure the environment before the first change

The following should be ready before the cutover:

  • A current, encrypted Sophos Firewall backup.
  • A local administrator whose login does not depend on eDirectory or the new external source. Under Authentication > Services, Local must remain selected under Administrator authentication methods.
  • Documented console access or another emergency access method to the firewall.
  • Screenshots or a written inventory of the server, service and group order.
  • At least one test account for each important group, plus an account that must not be granted access.
  • A maintenance window, a designated decision-maker and a clear rollback criterion.

Migrate WebAdmin access last. First verify that Local remains selected and that the local login works in a private browser window. This preserves an independent access method if the new external authentication or its group resolution does not work as expected.

Build the target server in parallel

Add the new server first. During the initial server setup, leave the existing eDirectory selection unchanged; change exactly one manageable authentication method only when starting the pilot test.

Example: Connect eDirectory as a generic LDAP server

Under Authentication > Servers > Add, a pilot configuration could look like this:

  • Server type: LDAP server
  • Server name: EDIR-LDAP-PILOT
  • Server IP/domain: edir01.example.net
  • Version: 3
  • Connection security: SSL/TLS
  • Port: 636
  • Bind DN: cn=sfos-bind,ou=service,o=Example
  • Base DN: ou=users,o=Example
  • Authentication attribute: for example uid, after checking the user object
  • Group name attribute: for example groupMembership, after checking the user object
  • Validate server certificate: enabled after configuring the issuing CA as trusted on the firewall

edir01.example.net, the Bind DN and the Base DN are example values and must match the local directory tree. When certificate validation is enabled, the configured FQDN must match the server certificate and be resolvable by the firewall. The bind account needs read access only to the required directory scope.

The real user object determines which login and group attributes are appropriate. In an eDirectory environment, for example, cn or uid may be relevant for login and groupMembership for groups. These are candidates to check, not universal defaults.

A user object can be queried read-only from a Linux administration system:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

This command does not belong in the Sophos Firewall Advanced Shell. -W prompts interactively for the bind password so that it is not stored in the shell history. The LDAPTLS_CACERT path, FQDN, DNs, filter and requested attributes must be adapted to the local environment. If the local OpenLDAP client already trusts the CA through its trust store or ldap.conf, LDAPTLS_CACERT can be omitted. Otherwise, the variable points to a readable PEM CA bundle.

Example output could look like this:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

This is a read-only example, not a promised eDirectory schema. If groupMembership is absent or the directory returns other values, identify the actual attribute and adapt the firewall configuration accordingly. Then validate Test connection, a real user login and the resulting group separately.

Remap groups and policies

A successful login is not enough if the user is then assigned to the wrong group. Suppose the existing VPN-Mitarbeitende group is allowed to use SSL VPN and reaches internal applications through a user rule. After the migration, at least these questions must be answered:

  1. Does the test user appear under Authentication > Users with the expected effective group? For Active Directory, check Main Group and additional memberships separately.
  2. Is the new group present and in the correct position under Authentication > Groups?
  3. Does the SSL VPN or IPsec configuration reference the new effective group?
  4. Does the user still match the intended firewall rule rather than a more general rule?
  5. Does the required MFA policy still apply?

Matching visible group names from two sources guarantee neither the same membership nor the same effective group priority. With Active Directory, group order and Main Group can affect VPN, MFA and other policies. The fundamentals are covered in Enable MFA for Sophos Firewall.

Migrate one service at a time

Under Authentication > Services, authentication servers are selected per service. This is why not everything is migrated at once. Coupled Entra ID SSO services, however, are planned and accepted as one related path.

  1. First choose a manageable service and a pilot user.
  2. Select the new server for this service and set its position in the server order deliberately.
  3. Apply the change and test both a correct and an intentionally incorrect login.
  4. Check the user, group, log entry and the policy that actually matched.
  5. Only then migrate the next service.

Start with a deliberately selected service that is easy to control. Then move on to the areas actually in use, such as Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods and Remote Access IPsec. For Entra ID SSO, migrate the coupled Remote Access services described above in a coordinated manner. Because of the lockout risk, migrate Administrator authentication methods last. Sophos Firewall portals overview explains which portals operate separately and must be reachable.

When the same username exists on the old and new servers, server order can hide incorrect group mapping. For a controlled test, temporarily select only the new server for the chosen pilot service. The real login and Authentication > Users then show whether the new source supplies the user with the expected group.

Validate with real connections

Test connection confirms the server’s reachability and credentials. Validation is complete only when the real service and the permissions tied to it work.

For each relevant group, acceptance should demonstrate at least the following:

  • An authorised user can log in to the intended portal or VPN service.
  • An unauthorised user is rejected or receives only the intended restricted policy.
  • The user and group are correct under Authentication > Users.
  • Log Viewer shows a traceable authentication event.
  • Firewall, Web and VPN policies match the expected rule.
  • Internal targets are reachable through the intended traffic path.
  • MFA and administrative roles behave as planned.

Firewall Rule Testing and Log Viewer can show which Rule ID applies to a user and their traffic. Test transparent user identification or SSO separately; a successful LDAP login does not confirm this path.

Rollback during the pilot phase

As long as the firewall still runs SFOS 22.0 MR2 and eDirectory has not been deleted, the old configuration remains available as a controlled rollback path. If a pilot fails, revert every value changed for it: the server selection and order under Authentication > Services, Default Group and group order, and affected VPN members, MFA references and policy references. Then validate the login, group and policy again.

The backup protects the firewall configuration, but it is not an automatic identity migration. Backups and configuration imports do not convert or migrate the eDirectory configuration they contain. Such a backup is therefore not a working eDirectory rollback path after the upgrade.

Remove eDirectory and clear the way for SFOS 23

Remove eDirectory only after an observation period defined in advance. During this period, every production login path, each important group, the VPN connections in use and the administrative workflows must have worked without errors through the new source at least once under realistic conditions. Unresolved authentication, group or policy errors prevent approval for deletion.

To complete the migration:

  1. Verify that eDirectory is no longer selected in any authentication method.
  2. Compare the group, VPN, policy, MFA, administrator and SSO dependencies against the inventory again.
  3. Delete all native eDirectory server and eDirectory SSO configurations from the firewall. A newly added generic LDAP server that queries the same directory remains in place.
  4. Under Authentication > Servers, Authentication > Services and in the inventory, verify that no native eDirectory configuration or dependency remains.
  5. Create a new encrypted backup of the cleaned configuration.
  6. Review the general guide Sophos Firewall firmware update: preparation and best practices, as well as the current SFOS 23 release, upgrade and known-issue notes. Only then start the upgrade.

Sophos has confirmed the upgrade failure when a native eDirectory server configuration remains and the need to remove it before SFOS 23. Before the production upgrade, also review the final SFOS 23 release, upgrade and known-issue notes for further details.

Common pitfalls

  • Test connection succeeds, but the user is assigned to the wrong group: Check the Base DN, login attribute and group attribute against the real user object, as well as the group order.
  • The pilot appears to work, but it may still be using eDirectory: Temporarily select only the new server for the controlled pilot service, then check the user, group and policy.
  • User Portal works, but VPN does not: Check the authentication method and permission group separately for each portal and VPN service.
  • LDAP login works, but transparent identification does not: Native eDirectory SSO is no longer available from SFOS 23. Generic LDAP validates the login but does not provide transparent user identification.
  • A different firewall rule matches after the group change: Compare the effective group, group order and direct user or group references in the policies. For Active Directory, also check Main Group and additional memberships.
  • The backup is planned as a later eDirectory rollback path: The eDirectory configuration it contains is not migrated on SFOS 23; the rollback path must work before the upgrade.