Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal

With Microsoft Entra ID SSO, Sophos Firewall can authenticate users for the VPN Portal and Remote Access via Sophos Connect against Microsoft Entra ID. For many Microsoft 365 environments, this is more sensible than separate local firewall passwords because identity, Conditional Access, and MFA are centrally managed in the Identity Provider.

However, the advantage is only real if the entire chain is well planned: Entra app, Redirect URIs, VPN Portal, Sophos Connect, authentication methods, groups, Device Access, and client profiles must match. This article describes the practical process for VPN Portal, SSL VPN, and IPsec Remote Access with Sophos Connect.

For general Sophos Connect configuration, first see Configure Sophos Connect on Sophos Firewall. This article supplements the identity and SSO-specific steps.

Version selection: The existing menu paths, field names, and service-specific log files in this article refer to SFOS 22. For SFOS 23.0, use the OpenID Connect branch described below and the logs specified there. App permissions, VPN policies, provisioning, MFA, pilot tests, and rollback tests remain part of the same process; changing the server configuration screen alone does not grant VPN access. The availability of SFOS 23 help does not imply a GA date.

What Entra ID SSO does on the firewall

Sophos Firewall integrates Microsoft Entra ID SSO via OAuth 2.0 and OpenID Connect. The firewall uses Entra ID as an authentication server and can log users into multiple services.

For Remote Access, these services are particularly relevant:

• VPN Portal
• SSL VPN via Sophos Connect
• IPsec Remote Access via Sophos Connect

A different process applies to the Captive Portal: Here, a user logs in via a browser on the local network so that user-based rules apply. This case is described separately in Set up Microsoft Entra ID SSO for Sophos Firewall Captive Portal.

Direct Microsoft Entra ID SSO does not cover every traditional firewall login. For the User Portal and Client Authentication Agent, Sophos refers to Microsoft Entra ID Domain Services. This is a separate AD- or LDAP-compatible directory architecture, not an additional switch on the OAuth/OIDC server object. Anyone who needs the User Portal or CAA must therefore not assume that the SSO application configured here automatically authenticates these services.

It is important to distinguish: The firewall continues to handle VPN, policies, user group matching, and access via firewall rules. Entra ID handles identity verification, SSO, and Entra-based MFA.

One Entra ID server, multiple services

The Microsoft Entra ID server is created once on Sophos Firewall under Authentication > Servers. The same server object can then be selected under Authentication > Services for different services, such as VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal, or administrator sign-in.

This doesn’t mean that every service automatically works the same way. Each service needs the matching Redirect URI, the correct authentication method, and its own test path. For VPN Portal, SSL VPN, and IPsec Remote Access, the VPN portal and remote access URL is the relevant URL. If Captive Portal or WebAdmin also use Entra ID SSO, their service URLs must also be added to the Entra app and tested separately.

The administrator service additionally requires Entra roles or groups, local permission profiles, and a tested emergency login. The separate procedure is described in Set up Microsoft Entra ID SSO for Sophos Firewall WebAdmin.

Only one Microsoft Entra ID server can be used per authentication method. For Sophos Connect provisioning, VPN Portal, SSL VPN, and IPsec should therefore deliberately use the same Entra ID server so that gateway value, Redirect URI, and client profile match.

When Entra ID SSO is useful

Entra ID SSO is suitable when users already work with Microsoft 365 and the organisation uses Conditional Access or Entra-MFA as central security controls.

Typical reasons:

• Users should not maintain separate firewall passwords.
• MFA should run via Entra ID instead of Sophos OTP.
• Remote Access should be more closely tied to user status, groups, and Conditional Access.
• Helpdesk and security teams should manage identity processes centrally in Entra ID.
• Local firewall users should be reduced.

Not every environment should switch immediately. In small installations without a clean Entra group model, Sophos’ own MFA may be simpler. For the classic OTP variant, see Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.

Prerequisites and limitations

Before setting up, these points should be met:

• Sophos Firewall with a supported SFOS version.
• Microsoft Entra Tenant with permission to create an app registration.
• Public FQDN for the VPN Portal or Remote Access.
• Valid certificate for the public name.
• VPN Portal is accessible via the required zone.
• Sophos Connect 2.4 or newer on Windows if SSO is to be used in the client.
• Users or groups are properly present in Entra ID.
• Appropriate Microsoft Entra licences for the planned Conditional Access policies.
• Firewall and Entra ID have the correct time.
• Microsoft login URLs are reachable from the clients and, depending on the traffic path, from the firewall.

Important limitations:

• For Sophos Connect SSO, Sophos specifies Windows endpoints with Sophos Connect 2.4 or newer.
• When using Microsoft Entra ID SSO, MFA is used in the Identity Provider. The Sophos Firewall’s own MFA cannot be additionally used for this authentication method.
• Under SFOS 22, only one Microsoft Entra ID server can be selected per authentication method. Under SFOS 23, the limit applies to one OpenID Connect IdP server, not an Entra server in addition to another OIDC provider.
• Users from the same domain should not be synchronised simultaneously via AD and Microsoft Entra ID.
• In HA clusters, it should not be assumed that Microsoft Entra ID SSO works for the WebAdmin of the Auxiliary Firewall.
• SFOS 22: Microsoft 365 Government Community Cloud High (GCC High) isn’t supported for this SSO integration. The SFOS 23 help no longer lists this limitation; this is not treated here as confirmation of GCC High support. For such a tenant, support must be clarified separately before rollout.

⚠️ Conditional Access requires a fixed firmware version: On SFOS 21.5 GA Build 171, Sophos Connect could reuse an existing SSO session without re-evaluating MFA and other Conditional Access requirements. Disconnecting and reconnecting the VPN tunnel did not necessarily suffice. Sophos lists the issue as NC-167126 and provides no official workaround. It is fixed in SFOS 21.5 MR2 Build 323 and SFOS 22.0 MR1 Build 490 for the respective release branches. Where Conditional Access is used as a security boundary, the firewall should first be updated to at least one of these versions. Force SSO re-login reduces the risk on older systems but does not replace the fix.

⚠️ An upgrade to SFOS 22 can turn on SSO automatically: If VPN Portal, Remote Access IPsec, or SSL VPN used Same as firewall under Authentication > Services before the upgrade, SFOS 22.0 or later automatically turns on Microsoft Entra ID SSO for these services. Record the effective methods before upgrading. If Entra SSO is intended, enter the exact VPN portal and remote access URL from the Entra server object in the Entra app afterward and verify it with a real login. Do not use the Sophos Fusion (formerly Sophos Central) reverse SSO URL. If SSO is not intended, explicitly set the required method instead of accepting the inherited state without testing.

Plan architecture

Before technical setup, decide which services will use SSO.

• VPN Portal: Should login to the portal occur via Entra ID?
• SSL VPN: Should SSL VPN via Sophos Connect use Entra SSO?
• IPsec Remote Access: Should IPsec Remote Access via Sophos Connect use Entra SSO?
• Provisioning file: Is an automatic provisioning file used?
• Groups: Which Entra groups are allowed to use VPN?
• MFA: What Conditional Access and MFA rules apply to Remote Access?
• Fallback: What happens if Entra ID or internet access to Microsoft is unavailable?

If a provisioning file is used, the gateway value set in it must match the FQDN or IP used in the Microsoft Entra ID configuration of the firewall as the Redirect URI. After changes to Entra ID or the firewall configuration, users must re-import the updated configuration.

Before making changes, record the current settings under Authentication > Services, server order, VPN groups and policies, Device Access, and distributed client profiles. You also need a local firewall administrator whose sign-in doesn’t depend on Entra ID. This is the technical break-glass path for configuration errors or a Microsoft outage; protect, monitor, and test it separately at regular intervals.

Prepare the Entra application for the firewall

Sophos recommends a dedicated application for the firewall. This limits permissions and makes sign-in logs, Conditional Access, and secret rotation unambiguous.

1. In Microsoft Entra, go to App registrations > New registration.
2. Enter a unique name and select Accounts in this organizational directory only.
3. Select Web as the platform. Add the actual Redirect URI only after SFOS has generated it.
4. Copy the Application (client) ID and Directory (tenant) ID.
5. Under API permissions > Microsoft Graph, add the Sophos-required delegated permissions User.Read.All and Group.Read.All. Only when importing groups with the SFOS assistant, also grant Group.Read.All as an Application permission. Grant admin consent for all permissions.
6. Under Certificates & secrets, create a client secret with a deliberate lifetime, copy its Value immediately to secure storage, and schedule expiry monitoring and rotation.

Under the corresponding Enterprise application > Properties, set Assignment required? to Yes. Then assign only the intended pilot or VPN group and required administrators to the application. This assignment is the first access gate; the SSL/IPsec policy on the firewall remains a second, independent authorisation check. Microsoft documents assigning users and groups to enterprise applications and the Redirect URI rules in detail.

Group-based application assignment requires Microsoft Entra ID P1 or P2 and doesn’t apply to users who are only members through a nested group. Without that licence, or when nested groups are involved, assign the pilot users directly; otherwise, Entra rejects the sign-in even though the VPN group membership may appear correct.

Create Microsoft Entra ID server on the firewall

SFOS 23.0: OpenID Connect with Microsoft Entra ID

Under SFOS 23, Entra ID is configured as a provider in the shared OpenID Connect server object. The existing Entra app is still required; do not create a second app solely because the configuration screen has been renamed. Before making changes, document the existing server object, its service assignments, and the Redirect URIs. An upgrade is only accepted after repeating the portal and tunnel tests.

1. Open Authentication > Servers > Add and select OpenID Connect under Server type.
2. Enter a Server name and select IdP vendor: Microsoft Entra ID.
3. Under Client ID, enter the Entra app’s Application (client) ID, and under Client secret, enter its secret value.
4. Under OpenID Connect URLs > Issuer URL, enter the Directory (tenant) ID. For this provider, the documented SFOS field expects the tenant ID; do not replace it with an issuer URL you have constructed yourself. The other URL settings do not apply to Microsoft Entra ID.
5. Under Redirect URIs, either select Use firewall URL or use Enter manually to enter the intended firewall FQDN or IP address. When managing a single firewall through Sophos Fusion, set the hostname manually; the reverse SSO URL is not an appliance callback.
6. Open Show URLs and enter the exact VPN portal and remote access URL as a web Redirect URI in the Entra app. With provisioning, the gateway value must match the firewall FQDN or IP used here. Changes require the client configuration to be re-imported.
7. Under User attributes, retain the defaults Display name: name, Username: upn, and Email address: email. Different attributes are only justified by a supported token whose structure actually differs.
8. Leave IdP authentication for firewall administrators turned off for VPN-only user services and select a Fallback group with narrowly scoped permissions. Administrator mapping is a separate step in the WebAdmin article.
9. Run Test connection, save only after a successful test, and assign the server to VPN Portal, SSL VPN, and, where applicable, IPsec under Authentication > Services. Click Apply for each service. SSL VPN and VPN Portal always use the same server; with provisioning, this also applies to IPsec.

After an upgrade, also check the existing warning about Same as firewall: automatic activation for inherited VPN methods applies to SFOS 22.0 and later, including the corresponding version change to SFOS 23. A documented server migration replaces neither checking the effective methods nor a real login that verifies redirects, groups, MFA, and the tunnel.

SFOS 22: Microsoft Entra ID SSO

The following server configuration screen with Directory (tenant) ID, User attribute mapping, and Fallback user group belongs to SFOS 22. For SFOS 23, use the fields in the preceding branch.

The menu path is:

Authentication > Servers

Steps on the firewall:

1. Open Add.
2. Select Microsoft Entra ID SSO as the Server type.
3. Assign a descriptive server name.
4. Enter the Application (client) ID from the Entra app.
5. Enter the Directory (tenant) ID.
6. Enter the Client secret.
7. Check or manually set the Redirect URI FQDN.
8. Set the fallback group.
9. If WebAdmin SSO is needed, plan role or group mapping to administrator profiles.
10. Perform Test connection.
11. Save.

For pure VPN SSO scenarios, no administrator role mapping is needed. The server should be planned as a user service, not as a general admin access.

Under User attribute mapping, SFOS automatically obtains the user attributes from the Entra token. Under User policies, configure a Fallback user group. This group should not have broad VPN rights: if an imported Entra group is missing, the user would otherwise land in an over-privileged fallback. A narrow group model is safer than deriving access solely from a claim or a successful Entra sign-in.

⚠️ Client Secrets are production credentials. Expiry date, rotation, responsibility, and documentation should be clarified before rollout.

Set authentication methods

After creating the Microsoft Entra ID server, it must be assigned to the appropriate services under Authentication > Services.

For Remote Access, these areas are relevant:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

If a provisioning file is used, the same Microsoft Entra ID server should be used for VPN Portal, IPsec, and SSL VPN. With provisioning files, the same server selection for authentication methods is important so that client profile, portal, and remote access method match.

Without a provisioning file, SSL VPN and VPN Portal must still use the same Microsoft Entra ID server; Remote Access IPsec can then use a different Entra server object. With a provisioning file, however, VPN Portal, SSL VPN, and IPsec must point to the same object. This distinction should be documented deliberately rather than inferred later from a tenant error in the SSO dialog.

After each change:

1. Select the server in the respective method.
2. Drag the server to the correct position if multiple servers are present.
3. Apply for each changed service.
4. Use a test user before rolling out the change widely.

Enter Redirect URIs in Microsoft Entra ID

For SSO to work, the firewall URLs must be stored as Redirect URIs in the Entra app.

Steps:

1. Open Authentication > Servers on the firewall.
2. Open the Microsoft Entra ID server.
3. Copy the required URLs:
   • Web admin console URL if WebAdmin SSO is used
   • Captive portal URL if Captive Portal is used
   • VPN portal and remote access URL for VPN Portal, Remote Access IPsec, and SSL VPN
4. Switch to Microsoft Entra ID > App registrations in the Azure Portal.
5. Open the application for the Sophos Firewall.
6. Under Manage > Authentication, add a web platform or edit the existing web platform.
7. Paste the copied Redirect URIs.
8. Save.

A common error is a different hostname in the client profile, Redirect URI, certificate, and public DNS. These values should be consciously aligned before rollout.

If not Remote Access but Captive Portal is protected, the Captive Portal-specific process should also be checked: Device Access for the client zone, Captive Portal authentication method, user group, and later firewall rule matching.

Allow VPN Portal via Device Access

Microsoft Entra ID SSO for Remote Access uses the VPN Portal port to communicate with the firewall. For internet access, therefore allow VPN Portal in the WAN row under Administration > Device access. Only enable it for additional zones when clients actually need to reach the portal from those zones.

This does not mean that the VPN Portal should be opened worldwide without consideration. Remote Access is a publicly accessible attack surface. For productive environments, additionally check:

• valid public certificate
• MFA and Conditional Access in Entra ID
• as narrow country or source restriction as realistic
• logging and review of login attempts
• clear deactivation of no longer needed users

The hardening of local firewall services is described in Device Access and Local Service ACL on Sophos Firewall.

If many failed logins, distributed sources, or Entra account lockouts are already occurring, Detect and contain VPN Portal brute force combines the firewall logs with Entra checks, safe ACL restriction, and follow-up verification.

Allow Microsoft login URLs

Clients and affected firewall paths must be able to reach Microsoft Entra ID endpoints. This includes several Microsoft login and CDN URLs, such as login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net, and other Azure/Microsoft Online domains.

In restrictive environments, it should not be discovered only at rollout that login pages, JavaScript, or token endpoints are blocked. It is sensible to:

• Use the complete Microsoft Entra login allowlist for FQDN Hosts and proxy exceptions.
• Name FQDN Hosts or FQDN Host Groups clearly.
• Set firewall rules for DNS and HTTPS consciously.
• Additionally check Web Exceptions for direct Web Proxy.
• Activate logging until SSO login is stable.

With a Direct Web Proxy, the allow rule to the FQDN Host Group is not sufficient on its own. The linked allowlist guidance provides the exact URL patterns and the procedure for configuring Web > Exceptions. Keep the exception limited to the required login and CDN patterns.

Check groups and VPN permissions

SSO alone does not grant VPN access. The user must also be allowed in the appropriate Remote Access configuration.

Import Entra groups selectively

To import groups, the firewall application needs the Microsoft Graph Group.Read.All permission as an Application permission, with admin consent granted. Then open Assistant for importing groups for the Entra server under Authentication > Servers. Instead of importing every group without review, the assistant can filter by attributes such as Display name or Description.

During import, Surfing quota, Access time, Network traffic, and Traffic shaping can be assigned to all or individual groups. Only assign these policies when the group actually needs them. The firewall and Microsoft Entra ID must have synchronized time, or the import itself may fail.

If the Entra group exists on the firewall, SFOS assigns the user to that group. If it does not, the Fallback user group configured on the Entra server applies. This remains true when the Entra server is used under Firewall authentication methods; the Default group there does not replace the fallback group. After import, the new group must also be allowed in the applicable IPsec or SSL VPN policy.

To check:

• Entra group has been imported into the firewall or is correctly mapped.
• Group is selected under Allowed users and groups for Remote Access IPsec.
• Group is selected under Policy members for SSL VPN.
• Firewall rules allow traffic from the VPN zone only to the required destinations.
• User is not only authenticated but also receives the expected policy.

If the tunnel is connected but no traffic flows, it is often not SSO that is the cause, but rule set, routing, DNS, or NAT. For analysis, see Test firewall rule with Log Viewer, Policy Test, and Packet Capture.

Check UPN, email, and group matching

With Microsoft Entra ID SSO, user identity and group matching should be checked particularly carefully. A login can be successful at the Identity Provider and still be incorrectly assigned on the firewall if UPN, email address, imported group, or local user ID do not match.

This is especially relevant in environments where users historically have different values:

• User Principal Name: max.muster@example.com is often expected as the actual login name.
• Email Address: m.muster@example.com can differ and cause confusion during assignment or portal login.
• Display Name: Max Muster is readable by humans but not suitable as a technical ID.
• Group: VPN-Users must be imported on the firewall and used in the correct Remote Access configuration.

The sign-in format also matters when migrating from on-premises Active Directory to Entra ID. AD commonly uses sAMAccountName@domain, while Entra ID uses UserPrincipalName@domain. SFOS treats different strings as separate user objects even when they belong to the same person. Align the format before migration where possible. If different names are used deliberately, duplicates are created; remove old AD users only after rules, groups, reporting, and the new Entra login have been verified.

The former Known Issue NC-157635 caused SSL VPN or IPsec portal logins to fail when the email address and UPN differed. Sophos fixed it in SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261, and 22.0 EAP0 Build 274. Checking user attributes remains useful when individual accounts have problems because it can reveal mismatched local user objects or group permissions.

Practical test procedure:

1. Open test user in Microsoft Entra ID.
2. Compare UPN and email address.
3. Check if the user is a member of the planned VPN group.
4. Open the imported group on the firewall and check if the user appears as expected.
5. Under Authentication > Services, check if the correct Microsoft Entra ID server is selected for VPN Portal, SSL VPN, and IPsec.
6. Perform a test login and check Log Viewer and oauth_sso_vpn.log.

If only individual users are affected, an attribute or group problem is more likely than a general Entra ID server error. If all users are affected, first check Tenant ID, Client ID, Client Secret, Redirect URIs, time, and Microsoft endpoints.

For user rules after successful VPN login, additionally: The firewall rule must see the user or group in the actual traffic. If the tunnel is up but the planned user rule does not match, the analysis from Sophos Firewall Rule Not Matching: Check Causes fits.

Introduce MFA and Conditional Access in a controlled way

Scope the Conditional Access policy to the firewall’s Enterprise Application and initially evaluate it with pilot users or in Report-only mode. A typical baseline requires MFA and considers locations or device states allowed by the organisation. The appropriate conditions depend on risk, licensing, and the operating model, so a universal policy to copy would be unsafe. Microsoft recommends planning policies and evaluating them in Report-only mode before enforcement.

Following Microsoft’s recommendation, maintain at least two cloud-only Entra emergency access accounts, stored separately, monitored, and excluded from Conditional Access. They don’t replace the local firewall administrator: if internet access, Entra ID, or the application itself fails, only an independent login can repair the firewall configuration. Don’t assign these accounts to the VPN application merely to test bypassing it. Microsoft documents their setup and monitoring in Manage emergency access accounts.

Test Sophos Connect and provisioning

For Sophos Connect: After Entra ID configuration or changes to the SSO configuration, the client configuration must be re-imported.

Test macOS separately: For Microsoft Entra ID SSO with Sophos Connect 2.1 or later on macOS (not 2.0), follow the macOS browser workflow. auto starts in the embedded browser and switches to the system browser when the relevant Conditional Access requirements apply; embedded has no automatic fallback. Selecting system through an approved .pro is covered by the provisioning schema, not by manual edits to .ovpn or .scx. Complete sign-in, including MFA, in the browser opened by the client, return to the client, and check the tunnel, DNS, and access. Switching browsers does not bypass device compliance: meet the requirements or contact IT, without weakening Conditional Access. The following Windows test still applies to Sophos Connect 2.4 or later.

Test procedure:

1. Install the current Sophos Connect Client on Windows.
2. Import the appropriate provisioning or VPN configuration.
3. Check if the SSO option is visible and clickable in the client.
4. Log in with Entra ID.
5. Trigger MFA or Conditional Access as planned and verify the result in the Entra sign-in logs.
6. Check tunnel status.
7. Check VPN IP, DNS, internal targets, and firewall rule match.
8. Test a forced SSO re-login on a shared device.

For the final test, open the menu in the upper-right corner of the Sophos Connect Client, select Force SSO re-login, and confirm with OK. Only then must the next user sign in with their own Entra credentials. Simply disconnecting the tunnel is not equivalent. On shared Windows devices, this step remains part of a proper user switch even with current firmware.

Record each test with its time, user, VPN type, and expected result. In the Entra sign-in logs, application, user, MFA or Conditional Access result, and error code must correspond to the attempt; SFOS must show the same event in oauth_sso_vpn.log or the Authentication module of Log Viewer. This avoids treating a visible tunnel alone as proof.

Before broad rollout, perform at least these tests in your own environment:

• An assigned pilot user signs in to the VPN Portal; an unassigned user is rejected.
• Each SSL VPN and/or IPsec profile actually in use connects through Sophos Connect, receives the expected VPN address, and reaches only approved DNS and application destinations.
• Test MFA and every intended Conditional Access condition with a positive and a deliberately unmet case; confirm the outcome in the Entra sign-in logs.
• A user without an allowed VPN group can’t progress to a usable tunnel or portal session.
• Force SSO re-login requires the next user’s identity on a shared Windows device.
• The local break-glass administrator can sign in through the intended restricted management path without changing productive Entra authentication.

For client installation on Windows, see Install Sophos Connect Client on Windows. For SSL VPN with Sophos Connect, additionally see Set up Sophos SSL VPN with Sophos Connect on Windows.

State-preserving rollback

Don’t remove the previous authentication method until both the pilot and rollback have passed. Keep old VPN configuration files under controlled access; don’t overwrite them or distribute them to new users.

If SSO disrupts access, sign in with the independent local administrator and restore exactly the recorded servers and their order for VPN Portal, SSL VPN, and IPsec under Authentication > Services. Click Apply for every changed service. Pilot devices then import the retained old profile and verify portal sign-in, tunnel establishment, DNS, and an approved internal destination.

Don’t delete the Entra app, new server object, imported groups, or client secret until old access works again and the logs confirm it. If Device Access was expanded only for SSO, restore that setting to its recorded original state only afterward; otherwise, you could block the restored VPN path at the same time. This preserves both configurations long enough for diagnosis and a second migration attempt.

Operation and security

Entra ID SSO shifts login security more into the Identity Provider. This is good if Entra ID is well managed. It is problematic if groups, Conditional Access, or app secrets are maintained casually.

In operation, these points should be regularly checked:

• App Secret does not expire unexpectedly.
• Entra groups contain only authorised users.
• Conditional Access applies to Remote Access.
• Break-glass and fallback accesses are documented.
• VPN Portal is only as widely accessible as necessary.
• Sophos Connect versions are up to date.
• Old client profiles are removed from circulation after changes.
• Logs are checked early in case of login problems.

For the client side, an independent update process should also exist. The article Check and Securely Update Sophos Connect Client Version summarises which Windows, macOS, SSO, OTP, and provisioning topics should be checked before a rollout.

Troubleshooting

SFOS 23.0: Use /log/oauth_sso_svc.log for the OIDC sign-in flow; check /log/sfos-macro-cfg.log for Test connection errors containing x509: certificate signed by unknown authority. The Authentication module in Log Viewer remains relevant for VPN Portal, IPsec, and SSL VPN. The references below to oauth_sso_vpn.log and the service-specific restart apply to SFOS 22.

After correcting a demonstrably incomplete CA chain, first repeat Test connection. Only if a restart is still required afterwards and an interruption to the OIDC sign-in services in use is acceptable during the maintenance window, use the Advanced Shell command documented by Sophos for SFOS 23:

service oauth_sso_svc:restart -ds nosync

Then repeat Test connection, a new VPN Portal login, and the tunnel actually in use. Restarting the shared service is not exclusive to VPN; other services using this OIDC object must also be retested separately. No restart replaces DNS, time, permission, or CA checks.

SSO button is not usable in Sophos Connect Client

If the client reports that SSO is not configured, first test the connection to the Microsoft Entra ID server on the firewall. Then check under Authentication > Services if the Entra ID server is correctly set for SSL VPN or IPsec and VPN Portal.

User is not allowed to log in to the VPN Portal

Then SSO may work in principle, but the VPN permission is missing. Check if the Entra group is included in the Remote Access IPsec configuration under Allowed users and groups or in SSL VPN under Policy members.

Only individual users cannot log in

Then first check UPN, email address, group membership, and imported firewall group. Especially for users with differing email addresses, changed names, or migrated accounts, the technical ID may look different than expected.

Microsoft reports wrong tenant or wrong application

Then often authentication methods, Entra app, Tenant ID, or server selection on the firewall do not match. Especially with multiple Entra ID servers, check if VPN Portal, SSL VPN, and IPsec use the same expected server.

Redirect or login ends on error page

Compare FQDN, certificate, public DNS, Redirect URI, and gateway value of the provisioning file. Even small deviations in hostname, port, or path can disrupt the OAuth/OIDC flow.

Test connection fails with an x509 error

If oauth_sso_vpn.log shows x509: certificate signed by unknown authority, a root or intermediate CA may be missing from the certificate chain to Microsoft Entra ID. The Known Issue NC-176806 was fixed in SFOS 22.0 MR2 Build 546; other incomplete certificate chains or TLS errors are still possible.

In the Advanced Shell, check the chain supplied by Microsoft:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

1. Check the certificate chain and issuer in the output.
2. Obtain only the missing root or intermediate CA from a trusted source. Do not import a server certificate as a CA.
3. Add and apply the CA under Certificates > Certificate Authority.
4. Open the Entra ID server under Authentication > Servers and run Test connection again.
5. Only if the test still fails and a brief interruption of current VPN SSO sign-ins is acceptable, restart the VPN SSO service in the Advanced Shell:

service oauth_sso_vpn:restart -ds nosync

Then run Test connection again. Restarting the service is an optional final step, not the first measure for an x509 error.

Group import does not work

Check the time of the firewall, tenant data, app permissions, client secret, and reachability of Microsoft endpoints. If existing local groups do not match Entra groups, decide whether to clean, map, or manually manage them.

Connection is up, but internal systems are not reachable

Then authentication is probably no longer the main error. Check VPN IP, DNS, firewall rules, NAT, routing, and target system. In the Log Viewer, it should be visible which rule hits traffic from the VPN zone.

Checklist

• Entra app with Client ID, Tenant ID, and Client Secret is documented.
• Redirect URIs for VPN Portal and Remote Access are entered in Entra ID.
• Public FQDN, certificate, and provisioning gateway match.
• VPN Portal is consciously allowed under Device Access.
• Microsoft login URLs are reachable.
• Authentication Services use the correct Entra ID server.
• VPN groups are imported and allowed in SSL/IPsec policies.
• UPN, email address, and group membership have been checked with a test user.
• Sophos Connect 2.4 or newer is in use on Windows.
• Client profiles have been re-imported after changes.
• Entra-MFA and Conditional Access have been checked with a test user.
• oauth_sso_vpn.log, Log Viewer, and Access Server logs are known for troubleshooting.

Frequently Asked Questions