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.

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.

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.

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.
• 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.
• Only one Microsoft Entra ID server can be selected per authentication method.
• 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.

Plan architecture

Before technical setup, decide which services will use SSO.

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.

Create Microsoft Entra ID server on the firewall

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.

⚠️ Client Secrets are productive 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.

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. Therefore, the VPN Portal must be allowed for the required zone under Administration > Device access.

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.

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:

• Check the Microsoft URL list from the current Sophos and Microsoft documentation.
• 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.

Check groups and VPN permissions

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

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:

A special case is documented in the Known Issues list, where Azure AD users cannot log in to the SSL VPN or IPsec portal if the email address and UPN are different. In practice, this means: For Entra ID SSO problems, not only check Redirect URI and Client Secret but also user attributes.

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.

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 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.
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 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.

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.

With SFOS 22 MR1, Sophos improved the re-evaluation of Conditional Access policies for reused SSO sessions. For environments using Entra-MFA as a security boundary, this is an important reason to keep the firewall version up to date.

Troubleshooting

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.

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