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.

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.

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 furnishing

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:

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 consists of two parts: First, an app registration is prepared in Microsoft Entra ID. This app is then registered as an authentication server on the Sophos firewall.

Prepare app registration in Microsoft Entra ID

A separate app registration for the firewall should be created in Microsoft Entra ID. This means that redirect URIs, permissions and client secrets remain cleanly separated from other applications.

Typical process:

1. Open Microsoft Entra admin center.
2. Open App registrations > New registration.
3. Give a meaningful name, for example Sophos-Firewall-Captive-Portal.
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 Entra ID server on the 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-Captive-Portal.
4. Enter Application (client) ID from the Entra app.
5. Enter Directory (tenant) ID.
6. Enter Client secret.
7. Depending on the design, activate Match known users if existing local users or groups are to be mapped.
8. Only use Use web authentication for unknown users if unknown users are to be deliberately handled via a fallback group.
9. Set a fallback group consciously and keep it as restrictive as possible.
10. Test connection.
11. Save.

The fallback group should not receive wide internet or network sharing. Above all, it is a safety net so that a user does not uncontrollably gain more access than planned.> ⚠️ 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:

For Captive Portal, only the Captive Portal Redirect URI should be tested in this flow. The VPN URL is part of the remote access design and is covered in the separate article on Microsoft Entra ID SSO for Sophos Connect and 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 the area for Captive portal 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 filterThe 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. Perform captive portal login with test user.
5. Then trigger real user traffic, for example HTTPS to a permitted destination.
6. 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.

Note Primary Group for Entra Captive Portal

With captive portals with Microsoft Entra ID SSO, you should particularly check which group the firewall actually evaluates for the subsequent user rule. For Entra-ID SSO users, Internet access through Captive Portal can only work if the user’s Primary Group is used in the firewall rule. Secondary groups do not behave the same as with classic on-prem AD users.

In practice, this means: A user can successfully log in to the captive portal and still not meet the expected rule if the rule only points to a secondary Entra group. This error quickly looks like a captive portal, OAuth or browser problem, even though the login itself was correct.

Before a rollout, you should therefore record the following for each test user:

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

To accept it, you should not only check whether the Microsoft login page appears.| test | Expected result | | — | — | | Open captive portal URL from client network | Browser shows 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 | | Primary group rule test | Test user meets the expected user rule | | User traffic after login | correct firewall rule matched with user reference | | Session flow | After a timeout, you need to log in again | | Microsoft login blocked | Log viewer or web logs show understandable reason | | Fallback scenario | Admin knows how to check or temporarily change access in the event of an Entra disruption

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.

For Entra ID SSO via Captive Portal, you should also check whether the firewall rule uses the user’s primary group. If only a secondary group is in the rule, the login can be successful while the actual Internet or target access does not go through the expected user rule.

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 viewers 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.
• Captive portal rules with Entra ID SSO take the test user’s primary group into account.
• 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