Configuring Sophos Connect to force a login when using Entra SSO

Configuring Sophos Connect to force a login when using Entra SSO

I had a report from someone who provides SSL VPN to third parties. The client machine was already signed into Microsoft, so Sophos Connect reused that session. It did not prompt for VPN credentials. The connection failed and returned an error instead of asking the user to sign in.

What you see

The usual complaint sounds like this: a user already logged into their machine with a Microsoft account gets no fresh prompt from Sophos Connect. It tries to use the existing session, then fails.

• Client side: Sophos Connect opens the browser and then nothing useful happens. No interactive credential prompt appears.
• Portal or firewall side: You don’t have permission to sign in to the firewall. Contact the firewall’s super administrator.
• User report: it returns an error and does not ask for login.

In practice, third parties cannot connect when their machine already holds a Microsoft session. Local users with the right account may connect fine. The client uses the existing Microsoft or Entra session, gets a token back, and the firewall rejects it.

Where it happens

• Any time the user has an active browser or Windows session tied to Microsoft or Entra. The SSO flow reuses that session.
• The Sophos Connect SSO path for Entra ID in SFOS v21.5 uses the browser-based OIDC flow. Sophos announced this here: https://news.sophos.com/en-us/2025/05/01/sophos-firewall-v21-5-entra-id-sso-for-sophos-connect/
• If the signed-in account does not map to the allowed VPN profiles on the firewall, the token is valid but not authorised. That gives an authentication error rather than a prompt.
• Shared machines, contractor machines, and systems with persistent browser sessions to Azure or Entra are the ones most likely to trip over this.

Find the cause

• Entra or Azure AD SSO uses the browser session or OS-integrated session to authenticate. If there is already an interactive session, the identity provider may use it and return a token for that account without prompting.
• Sophos Connect launches the browser for the OIDC flow, but the client usually does not offer an alternate prompt if the identity provider hands back a token straight away.
• I do not have definite evidence that Sophos exposes a custom OIDC prompt parameter in the .pro file. If Sophos does accept extra OIDC parameters, the standard one to force interaction is prompt=login. Only use that if Sophos documentation confirms it is supported.
• Check the browser flow with developer tools or Fiddler. What you want to see is a redirect to login.microsoftonline.com with an actual sign-in page. What happened here was a redirect that returned a token for the existing account.
• On the firewall, test the Entra or Azure authentication server from Authentication > Server Configuration using Test Connection.
• Check the Sophos Connect logs and Windows Event Viewer for authentication errors. If those logs are vague, capture the HTTP redirects during the OIDC flow. That shows whether the identity provider prompted or not.
• Watch the firewall authentication logs for the username the token was issued for. The pattern here was simple: the token belonged to one account, but that account was not allowed.

Fix

• If third parties need to be asked for credentials, do not give them the Entra SSO profile. Create a separate Sophos Connect .pro profile that uses username and password authentication or RADIUS instead, and distribute that profile only to third parties.
• If Sophos supports custom OIDC parameters, add prompt=login to the auth request to force an interactive login. Check support first before editing the .pro file or the firewall SSO settings.
• Create a separate SSL VPN connection profile on the firewall that does not use the Entra authentication server. Use local database, RADIUS, or LDAP for third parties.
• Export a .pro file for that profile and give it a clear name so third parties use the right one.
• Test it on a machine already signed into Microsoft. The result you want is a username and password prompt from Sophos Connect or the login portal.
• If you keep Entra SSO, check whether Sophos lets you add OIDC parameters. If it does not, open a support case and ask for that capability.

Check it is fixed

• Use three test accounts: a permitted Entra account, a permitted non-Entra account using the new profile, and a third-party account. Each should connect with the intended profile. The third-party account should now get a prompt and authenticate.
• Watch the firewall authentication logs for repeated failed tokens. If the same pattern comes back, the profile split is wrong and Entra SSO is still reaching third parties.
• Ask a contractor to try a connection on a machine signed into Microsoft. Confirm they got a credential prompt and connected. Record the client-side behaviour and the firewall logs for the working attempt.

The root cause was that the identity provider reused an existing Entra session and issued a token for an account the firewall would not accept. The fix is to stop using Entra SSO for third parties, or force an interactive login if Sophos supports it.

Do not assume one Sophos Connect profile suits everyone. Third parties need their own profile. If forcing login from Entra is required, check whether Sophos supports prompt=login or an equivalent in the SSO flow.