Set up Microsoft Entra ID SSO for Sophos Firewall Captive Portal

With Microsoft Entra ID SSO for Captive Portal, Sophos Firewall can authenticate users against Microsoft Entra ID via browser before user-based firewall rules take effect. This is particularly interesting for BYOD networks, guest or partner zones, devices without transparent AD detection or environments where STAS does not fit all clients.

It is important to differentiate: Captive portal is not a VPN portal and not remote access. The user is already on the local or Wi-Fi network and logs in to the browser so that the firewall can assign the subsequent traffic to a user identity. For remote access with Sophos Connect, the separate article Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal is suitable.

If Microsoft Entra ID SSO is already configured for VPN Portal or Sophos Connect, a completely new Entra design is not automatically required. In many cases, the same Microsoft Entra ID server object on the firewall can be reused. Captive Portal still needs the matching Captive portal URL as a Redirect URI, assignment under Authentication > Services, and a separate test of the later user rule.

When Captive Portal with Entra ID SSO makes sense

Captive portal with Entra ID SSO makes sense if users log in with Microsoft 365 anyway and the firewall needs a user identity for certain networks.

Typical applications:

• BYOD or WiFi networks without domain joining.
• Guests or external users with controlled access to a few destinations.
• User-based Internet rules without STAS or SATC.
• Networks where transparent authentication is unreliable.
• Transition scenarios where local AD authentication should be reduced.

For fully managed Windows clients in a classic domain, Captive Portal is not automatically the best solution. There STAS, AD SSO or other transparent procedures can be more ergonomic because users do not have to actively trigger a browser login. Captive portal is more of a fallback or special solution for unmanaged devices.

Separate captive portal, VPN portal and user portal

With Entra ID SSO, portal terms are quickly mixed up. Separation is crucial for configuration.

• Captive Portal: Users on the local network log in via browser so that rules with user identity can take effect. The Entra ID connection is mainly about browser login and user mapping.
• VPN Portal: Remote access users download Sophos Connect or VPN configurations. Entra ID SSO is relevant for remote access and portal login.
• User Portal: Depending on the environment, this portal still contains user functions such as OTP or older personal options.

A general portal overview is available in Sophos portals: SophosID, Central, Support and firewall access. For captive portal you have to check, above all, from which zone the local firewall service can be reached and which firewall rule then processes the actual user traffic.

Requirements

Before setting up, these points should be clarified:

• Sophos Firewall with a SFOS version that supports Microsoft Entra ID SSO.
• Microsoft Entra Tenant with permission for App Registration, Redirect URIs, API Permissions, Admin Consent and Client Secret.
• FQDN and certificate for the captive portal so that users do not see unnecessary browser warnings.
• Accessibility of the Microsoft login endpoints from the affected client network.
• Captive portal is allowed under Administration > Device access for the correct zone.
• Users or groups are cleanly maintained in Microsoft Entra ID.
• Firewall rules use the expected users or groups.
• A test user and fallback access are available.
• Time and NTP on firewall and clients are correct because OAuth/OIDC is time-dependent.
• If Assignment required is active in Microsoft Entra ID, the required users or groups are assigned to the Enterprise Application.

⚠️ Captive portal is a login area on the firewall. It should only be accessible in the zones where it is really needed. Device Access and Local Service ACL are security controls here, not just connection settings.

For hardening local firewall services, Securing Sophos Firewall access: Configure device access correctly is suitable. In this design, MFA is implemented in Microsoft Entra ID, for example via Conditional Access. The local MFA of the Sophos Firewall does not replace the Microsoft login factor with Entra ID SSO. This is usually better from the user’s perspective because the same MFA is used as Microsoft 365, but it must be carefully planned and tested in the tenant.

Plan architecture before configuration

Before the technical configuration, you should decide which task captive portal should specifically solve. Otherwise you quickly end up with a login that works but doesn’t trigger a suitable firewall rule.

Important design questions:

• Which zone uses Captive Portal?: Device access and rule source depend on the zone.
• Which user group is allowed to log in?: The Entra group must match the later firewall rule.
• What goals can be achieved after logging in?: Captive portal does not replace clean segmentation.
• How long should sessions be valid?: Sessions that are too long dilute user allocation, and sessions that are too short disrupt operations.
• What happens in the event of an Entra or Internet disruption?: There needs to be a clear fallback for critical jobs.
• How is the login triggered?: Users need an accessible captive portal URL or a clean redirect.

Captive Portal should not be used as a replacement for VLANs, zones, or minimal firewall rules. The firewall knows the user better after login, but the network architecture must still remain clean. For the basic logic of zones, Configure Sophos Firewall zones and interfaces is suitable.

Create Microsoft Entra ID server

The setup has two parts: first, an App Registration is prepared in Microsoft Entra ID or an app deliberately created for the firewall is extended. Then this app is entered on Sophos Firewall as an Authentication Server, or an existing Microsoft Entra ID server is extended for Captive Portal use.

Prepare app registration in Microsoft Entra ID

Use a dedicated App Registration for the firewall in Microsoft Entra ID. This keeps Redirect URIs, permissions, and client secret separate from other applications. The app doesn’t have to be created again for each firewall service; it can contain several service URLs for the same firewall if VPN Portal, Captive Portal, or WebAdmin are all meant to use Entra ID SSO.

Typical process:

1. Open Microsoft Entra admin center.
2. Open App registrations > New registration.
3. Give it a meaningful name, for example Sophos-Firewall-SSO.
4. As a rule, select your own tenant as the supported account type.
5. Use Platform Web.
6. Note down Application (client) ID and Directory (tenant) ID.
7. Create a client secret under Certificates & secrets and immediately save the secret value securely.
8. Under API permissions add the required Microsoft Graph permissions, typically User.Read.All and Group.Read.All.
9. Grant Admin consent for the permissions.
10. If Assignment required is used, assign the permitted users or groups to the Enterprise Application.

Without appropriate API permissions and admin consent, the login can get through to the Microsoft login, but the firewall cannot then correctly evaluate user or group data. In practice, this often looks like a captive portal problem, even though the cause lies in Microsoft Entra ID.

Create or reuse Entra ID server on Sophos Firewall

The menu path on the Sophos Firewall is:

Authentication > Servers

Basic process:

1. Open Add.
2. Select the Microsoft Entra ID SSO option as Server type.
3. Assign a descriptive name, for example Entra-SSO-Firewall.
4. Enter Application (client) ID from the Entra app.
5. Enter Directory (tenant) ID.
6. Enter Client secret.
7. Set a fallback group consciously and keep it as restrictive as possible.
8. Test connection.
9. Save.

The fallback group should not receive broad internet or network access. It is a safety net, not a shortcut around authorization.

⚠️ Client secrets are productive access data. Expiration date, rotation, and responsibility should be documented. An expired secret often seems like a normal login problem from the user’s perspective, but is actually a configuration or operational problem.

Enter redirect URIs correctly

The redirect URI that matches the firewall must be entered in the App Registration in Microsoft Entra ID. It is crucial that the FQDN, certificate, port and path match exactly. Small differences in hostname, port, protocol or slash are enough for the OAuth/OIDC process to fail.

The Sophos Firewall displays the required service URLs on the Entra ID server. The Captive portal URL is particularly relevant for this article. If WebAdmin or Remote Access with Entra ID SSO are also used, these services have their own URLs:

• Web admin console URL: Entra ID SSO for WebAdmin Console.
• Captive portal URL: Entra ID SSO for Captive Portal in the local network.
• VPN portal and remote access URL: Entra ID SSO for VPN Portal and Sophos Connect.

If the same Entra ID server is already used for Remote Access, add the Captive portal URL to the existing Redirect URIs in the Entra app. Captive Portal should still be tested separately because the login path, Device Access, group matching, and the later firewall rule create different failure modes than Sophos Connect or VPN Portal.

Set captive portal authentication method

After creating the Entra server, the authentication method for Captive Portal must point to the correct server.

The relevant area is under:

Authentication > Services

To check:

1. Open Firewall authentication methods.
2. Add or drag Microsoft Entra ID server to the correct position.
3. Only keep other authentication servers if they serve as a deliberate fallback.
4. Apply the change with Apply.
5. Perform a test login with a single user.

If several authentication methods are active in parallel, it must be clear which server is responsible for which user group. Mixed operation of Entra ID and local AD authentication can work, but significantly increases the troubleshooting effort. The Sophos Known Issues List documents Entra SSO cases where mixed Entra and on-prem AD sessions can lead to no permission-like errors.

In addition, you should check under Authentication > Web authentication how the captive portal is opened in the browser. HTTPS is important for Entra ID SSO. The option Use insecure HTTP instead of HTTPS should not be activated because the Entra-OAuth flow over HTTP is not properly supported and would be unnecessarily insecure.

The following is helpful for operation:

1. Open Captive Portal in a new browser window.
2. Keep the captive portal window open during the session.
3. Consciously have users log out via the captive portal if the association is to be terminated.
4. After logging in, check under Current activities > Live users whether the user is visible.

Depending on the interface and certificate, the standard URL https://<Firewall-IP>:8090 can also help for testing. A clean FQDN with a suitable certificate is much more pleasant for productive operation.

Check device access and portal accessibility

Captive Portal is a local service of the firewall. A normal firewall rule alone does not allow this access. Accessibility is controlled under Administration > Device access for the respective zone.

You should check:

• Captive portal is only allowed in the required zones.
• This means that WebAdmin and SSH are not accidentally also widely accessible.
• Certificate and FQDN match the user URL.
• DNS in the client network resolves the portal name correctly.
• Local Service ACL Exception Rules are only set when they are really necessary.

If Captive Portal is not accessible from a network, you should not create a normal Allow rule first. The cause is often device access, local service ACL, DNS, certificate or incorrect zone mapping.

Consider Microsoft login and web filtering

The client must reach Microsoft login pages and related resources during login. Otherwise, in restrictive networks, the SSO flow can stop at a point that looks to users like a firewall or browser error.

To check:

• DNS resolution for Microsoft login domains works.
• HTTPS to Microsoft login endpoints is allowed.
• Web filter, TLS inspection or proxy do not block the login page.
• Time on firewall and client is plausible.
• Browser cookies are not rendered unusable by a strict policy.

In restrictive environments, you should explicitly check the Microsoft login and Entra endpoints. Depending on the tenant, browser and Microsoft login path, these domains are relevant, among others:

• login.microsoftonline.com
• *.login.microsoftonline.com
• *.microsoftonline.com
• *.msauth.net
• *.msftauth.net
• aadcdn.msauth.net
• aadcdn.msftauth.net
• aadcdn.msftauthimages.net
• graph.microsoft.com

If the web filter, a proxy or TLS inspection takes effect before login, these targets should not be unnecessarily decrypted or blocked. You should check the Allow URL section of the Entra ID documentation for very restrictive policies.

If Web Protection or TLS Inspection is active, the login with a test user should be observed in the log viewer. Sometimes the problem is not Captive Portal itself, but a web policy, a TLS exception, or a client network that doesn’t fully reach Microsoft endpoints.

Test user groups and firewall rules

After a successful captive portal login, the actual firewall rule must see the user or group in the traffic. This is the most important practical test.

Typical process:

1. Check users in Microsoft Entra ID.
2. Compare UPN, email address and group membership.
3. Check Entra group on Sophos Firewall.
4. Enable Match known users and Use web authentication for unknown users in the user rule.
5. Perform captive portal login with test user.
6. Then trigger real user traffic, for example HTTPS to a permitted destination.
7. In the Log Viewer, check whether the user, group, source zone, source network and Rule ID match the expected rule.

A successful browser login only proves authentication. It does not prove that the later user rule applies. If the rule counter remains at 0 or no user is visible in the log viewer, you should use the flow from Sophos Firewall rule does not work: Check the causes.

Group matching and the earlier Primary Group limitation

The intended Entra group must be present on the firewall for user rules. After login, check under Current activities > Live users and in Log Viewer which group the user was assigned to and which Rule ID processes the traffic.

There was a known limitation in SFOS 20.0 GA Build 222: With NC-167130, internet access through a secondary Entra group did not work; the rule had to contain the Primary Group or the individual user. Sophos lists this issue as fixed in SFOS 21.5 MR2 Build 323 and SFOS 22.0 MR1 Build 490. On current builds, the Primary Group is therefore no longer a general design requirement.

Before a rollout, record these points for each test user:

• Entra group: The target group and membership are known.
• Group on the Sophos Firewall: The same group is imported or mapped correctly.
• Firewall rule: The intended group is included in the user or group condition.
• Test traffic after login: Log Viewer shows the user, group, Rule ID, and expected action.
• Older affected build: Use the Primary Group or an individual-user test rule and plan the update.

This does not affect Sophos Connect VPN with Microsoft Entra ID SSO. For remote access, the separate process for Microsoft Entra ID SSO for Sophos Connect and VPN Portal should therefore be checked.

Validation after rollout

For acceptance, do not only check whether the Microsoft login page appears.

• Open the Captive Portal URL from the client network: The browser shows the expected Entra login or Sophos redirect.
• Login with allowed user: Login successful, user appears on the firewall.
• Login with not allowed user: Access is comprehensibly denied.
• Group rule test: The test user matches the expected user rule.
• User traffic after login: The correct firewall rule matches with user identity.
• Session flow: After a timeout, you need to log in again.
• Microsoft login blocked: Log viewer or web logs show understandable reason.
• Fallback scenario: Access during an Entra outage can be checked or temporarily changed.

Especially with BYOD networks, you should test with multiple browsers and devices. Private browsing modes, blocked third-party cookies, old saved logins, or multiple Microsoft accounts on the same device can produce different results.

Troubleshooting

Captive portal is not reachable

First check Administration > Device access for the affected zone. Then check DNS, certificate, portal FQDN, local service ACL and zone mapping. If access goes to the firewall itself, a normal firewall rule is not the first checkpoint.

Microsoft login starts but doesn’t come back

Compare redirect URI, FQDN, certificate and port. The exact URL that the Sophos Firewall uses for Captive Portal must be stored in Microsoft Entra ID. Proxy or TLS inspection rules can also interfere with the return.

When Microsoft shows the error AADSTS50011, the redirect URI in the app registration usually does not match the URL that the firewall is using. Then the protocol, FQDN, port and path must be compared exactly.

An internal error appears after Microsoft login

A 500 Internal Server Error or a similarly generic error after a successful Microsoft login often indicates a lack of Microsoft Graph permissions, a lack of admin consent or a problem with the client secret. Then you should check the API permissions, admin consent, secret validity and enterprise app assignment in Microsoft Entra ID.

Username and password do not work directly

Entra ID SSO is a browser and OAuth/OIDC flow. Users do not log in directly to the firewall with classic credentials, but are redirected to Microsoft. If a client or flow only supports username and password without browser redirect, this method does not fit.

MFA does not appear or appears differently than expected

With Entra ID SSO, MFA is controlled in Microsoft Entra ID. On-premises firewall MFA is not the correct control point for this SSO flow. If MFA is required, you should check conditional access, user groups, exclusions and test users in Microsoft Entra ID.

User sees no permission or is rejected after prolonged operation

Clear browser cookies and check if the same user is used in parallel via Entra ID SSO and local AD authentication. When mixing Entra and On-Prem AD for the same user, the authentication design should be simplified or at least documented cleanly.

Login works, but the user rule doesn’t match

Then captive portal is probably no longer the only problem. Check source zone, source network, user group, rule position and log viewer. Often a more general rule is above the user rule or the traffic comes from a different network than expected.

Also check whether the intended Entra group is imported and whether the user is assigned to it on the firewall. Only on the SFOS 20.0 GA Build 222 affected by NC-167130 must the Primary Group or the individual user be present in the rule for this issue.

Only individual users are affected

Compare UPN, email address, display name, group membership and imported group. With Entra ID SSO, you should not assume that the visible name and technical identifier are identical. If email address and UPN historically diverge, mapping errors easily arise.

Which logs help?

oauth_sso_captive.log is particularly relevant for captive portal with Entra ID SSO. Additionally, Log Viewer with the Authentication module, access_server.log and, depending on the subsequent problem, web, firewall or authentication logs help. The allocation of the most important files can be found in Sophos Firewall Troubleshooting: Services and Logs.

Checklist

• Captive portal use case is clear: BYOD, guests, unmanaged devices or fallback.
• FQDN and certificate for the captive portal are clean.
• Microsoft Entra ID app with Redirect URI, Client ID, Tenant ID and Client Secret is documented.
• Microsoft Graph API permissions and admin consent are set.
• Enterprise app assignments are checked if Assignment required is active.
• Client Secret has expiration date, owner and rotation process.
• Captive Portal Redirect URI was taken over by the firewall and entered exactly into Entra ID.
• Authentication > Services uses the correct Entra server for Captive Portal.
• Authentication > Web authentication uses HTTPS and appropriate browser window settings.
• Administration > Device access only allows captive portal in required zones.
• Microsoft login endpoints can be reached from the client network.
• Web filtering and TLS inspection do not block the SSO flow.
• MFA and Conditional Access are planned and tested in Microsoft Entra ID.
• Entra group and firewall group match.
• The intended Entra group is imported and is actually evaluated for the test user.
• Test user can log in and then hit the expected firewall rule.
• Log viewer shows user, rule ID and action.
• oauth_sso_captive.log and access_server.log are known for support cases.
• Fallback for Entra or Portal failure is documented.

Frequently Asked Questions