Configuring Sophos Connect to Force Login When Using SSO Entra

I had a report from someone who provides SSL VPN to third parties. The client machine was already signed into Microsoft. 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. I walked through cause and fixes below.

What you see

Typical user reports look like this: “I’m having an authentication problem with SSO. When a user is already logged into their machine with a Microsoft login, Sophos Connect doesn’t ask for new authentication and instead tries to force login with the existing account.” That quote is from a real thread on Reddit where the poster asked about forcing a login in the .pro file. The visible failure often shows two symptoms.

Exact error lines and messages

• Client side: the Sophos Connect client opens the browser and then nothing obvious happens. No interactive prompt for credentials appears.
• Portal / 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 doesn’t request login.”

What users experience

• Third parties cannot connect when their machine holds a corporate Microsoft session.
• Local users with the right account may connect fine.
• The client attempts SSO using the existing Microsoft/Entra session and gets back a token that the firewall rejects.

Where it happens

Scenarios with single sign-on

• Any time the user has an active browser or Windows session bound to Microsoft/Entra. The SSO flow reuses that session.
• The Sophos Connect SSO path, introduced for Entra ID in SFOS v21.5, triggers the browser-based OIDC flow. See Sophos announcement about Entra ID SSO: https://news.sophos.com/en-us/2025/05/01/sophos-firewall-v21-5-entra-id-sso-for-sophos-connect/

Impact on third-party users

• If the signed-in account does not map to the allowed VPN profiles on the firewall, the token is valid but unauthorised. The result is an authentication error, not a prompt. That blocks third-party access.

Specific environments affected

• Shared machines where multiple people log in.
• Contractor or partner machines that already have a corporate Microsoft session.
• Machines with persistent browser sessions to Azure/Entra.

Find the cause

Microsoft login session reuse details

• Entra/Azure AD SSO uses the browser session or OS-integrated session to authenticate. The identity provider will, by default, use any current interactive session. That gives a token for the signed-in account without prompting. If that account is not authorised for the VPN, the firewall rejects it.

Configuration settings in Sophos Connect

• Sophos Connect, when configured for Entra SSO, launches the browser for the OIDC flow. The client itself usually does not prompt for alternative credentials if the IDP returns a token immediately. I do not have definitive evidence that Sophos exposes a custom OIDC prompt parameter in the .pro file. If Sophos does accept additional OIDC parameters, the standard OIDC parameter to force an interactive login is prompt=login. Use that only if Sophos documentation confirms support.

Logs and troubleshooting techniques

• Capture the browser SSO flow with developer tools or Fiddler. Expected: a redirect to login.microsoftonline.com with an interactive login page. Actual in this case: a redirect that returns a token for the existing account.
• On the firewall, test the Entra/Azure authentication server from Authentication > Server Configuration, using the Test Connection option and watch the response.
• Check the Sophos Connect client logs and Windows Event Viewer for authentication errors. If the client logs are unclear, capture the HTTP redirects during the OIDC flow. That proves whether the IDP prompted or not.
• On the firewall, watch authentication logs for the exact token claim and username mapped. Expected vs actual: expected a login prompt and correct authorised username; actual a token for a different username and an unauthorised response.

Fix

Configuration changes in the .pro file or firewall

• If you need third parties to be asked for their credentials, do not use the Entra SSO profile for them. Create a separate Sophos Connect .pro profile that uses username/password authentication or RADIUS, not Entra SSO. Distribute that profile to third parties only.
• If Sophos supports custom OIDC parameters, adding prompt=login to the auth request will force the IDP to show the interactive prompt. Confirm support before editing the .pro file or the firewall’s SSO settings.

Steps to prompt for login

1. Create a new SSL VPN connection profile on the firewall that excludes the Entra authentication server. Use a standard authentication method such as local database, RADIUS, or LDAP for third parties.
2. Export a .pro file from the firewall for that profile. Give it a clear name so third parties use it.
3. Test with a machine that has an active Microsoft session. The desired result is now a username/password prompt from the Sophos Connect client or the login portal.
4. If you prefer to keep Entra SSO, check whether Sophos has an option to add OIDC parameters. If present, add prompt=login. If not present, open a support case asking for that capability.

Testing the new setup

• On a machine already signed into Microsoft, import the new .pro file and try to connect. Expected: a prompt for credentials or a portal login. Actual: successful connect or an explicit login error that tells you the username is not allowed.
• Use the firewall authentication test and the capture of the browser flow to verify the IDP showed an interactive prompt.

Check it’s fixed

Verifying successful connections

• 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 using the intended profile. The third-party account should now get a prompt and be able to authenticate.

Monitoring for recurring issues

• Monitor authentication logs on the firewall for failed tokens that match the pattern “token issued for account X but not authorised”. Track frequency. If it reappears, adjust distribution of profiles so Entra SSO is not given to third parties.

User feedback post-fix

• Ask a contractor to attempt a connection on a machine that is signed into Microsoft. Confirm they received a credential prompt and could connect. Record the client-side behaviour and the firewall logs for the successful attempt.

Root cause and remediation, in one sentence

• The IDP reused an existing Entra session and issued a token for an account that the firewall did not accept; remediation is to stop using Entra SSO for third parties or force an interactive login via OIDC if Sophos supports it.

Practical takeaway

• Do not assume a single Sophos Connect profile fits all users. Use separate profiles for third parties. If forcing login from Entra is necessary, open a support case and ask Sophos whether the client or firewall supports prompt=login or an equivalent parameter in the SSO flow.