4.5 Captive Portal and Access Roles

What Captive Portal Is

Captive Portal is a browser-based authentication page that the Security Gateway presents to users it cannot identify through AD Query, Identity Collector, or Identity Agent. When an unidentified user attempts to browse to a web destination, the gateway intercepts the HTTP(S) request and returns the portal page instead. The user enters credentials, the gateway validates them against a configured authentication source, and on success the gateway caches an IP-to-user mapping for that session.

Captive Portal is therefore both an identity source (it creates a mapping) and a fallback for unidentified traffic. A complete identity design usually ends with Captive Portal: everything that can be identified agentlessly or by an agent is identified, and the rest falls through to interactive authentication.

Authentication Sources for Captive Portal

Captive Portal can validate credentials against:

• Active Directory (domain users and groups).
• RADIUS servers (VPN-style authentication, OTP tokens, NAC integrations).
• The gateway's local user database (for small deployments or break-glass accounts).
• Tara OTP and other supported strong-authentication backends.

The chosen source is configured on the gateway's Identity Awareness / Captive Portal settings. Multiple sources can be chained so the gateway tries AD first and falls back to RADIUS.

How the Redirect Works

To present the portal page, the gateway must intercept the user's HTTP(S) request. Two methods are used:

• HTTP redirect. For cleartext HTTP, the gateway returns a 302 redirect to the portal URL. Simple and transparent to the user.
• HTTPS interception. For HTTPS, the gateway must decrypt the initial connection to inject the redirect, which requires HTTPS Inspection to be enabled and the gateway's CA to be trusted by the endpoint. Without HTTPS Inspection, the redirect for HTTPS destinations can fail with certificate warnings.

The portal page is served by the gateway itself on a dedicated port (commonly 881 or similar, configurable). After authentication, the browser is redirected back to the originally requested URL.

Access Roles

An Access Role is the policy object that brings identity into the rulebase. It combines:

• Users / Groups: from AD, RADIUS, or local DB (for example, CORP\HR-Admins).
• Networks: IP ranges, networks, or address ranges (for example, Corporate-Wi-Fi, VPN-Pool, Any).
• Machines: AD machine accounts or endpoint groups.
• Sessions: authentication method (Captive Portal, Identity Agent, AD Query), valid for matching rules that should apply only to a specific source.

A connection matches an Access Role only if every populated dimension matches. Empty dimensions are treated as wildcards. This means one Access Role can express "HR-Admins from Corporate-Wi-Fi or VPN, on HR laptops, authenticated by Identity Agent" in a single object.

Using Access Roles in Policy

In the Access Control policy, Access Roles appear in the Source column alongside traditional network objects. A typical identity-based rule reads:

• Source: AR_HR-Admins (an Access Role matching CORP\HR-Admins from Corporate-Wi-Fi or VPN-Pool).
• Services: http, https, sql-srv.
• Action: Accept.
• Track: Log.

Because the Access Role already encodes the user/group and network conditions, you do not need separate rules for each combination. The gateway looks up the source IP in the identity cache at connection time and decides whether the Access Role matches.

If the source IP has no mapping and Captive Portal is configured as the fallback for that rule, the gateway redirects the user to authenticate. After successful authentication, the new mapping is cached and the user's next connection matches the rule. Existing connections are not re-evaluated.

Captive Portal Behavior and Limits

• The portal triggers only for new connections that hit a rule requiring identity. Connections to destinations that are allowed for any user (or for unidentified users) do not trigger the portal.
• Identity is not retroactive. A user authenticated through Captive Portal will not have their pre-existing HTTPS session re-evaluated; only new connections after the mapping is cached are matched against identity rules.
• Browser-initiated traffic only. Captive Portal triggers on HTTP(S) browsing. Non-browser TCP sessions (SSH, RDP, native mobile apps) will not trigger the redirect and will fail or hang if the rule requires identity. For those, an agent or AD Query must already have a mapping.
• Certificate trust. Without HTTPS Inspection and a trusted gateway CA, HTTPS redirects produce browser warnings that users often mistake for attacks.
• Per-user TTL. The mapping created by Captive Portal has its own TTL; the user must re-authenticate after it expires unless activity refreshes it.

Putting It All Together

A robust R82 identity design stacks the sources:

1. AD Query identifies domain-joined desktops agentlessly.
2. Identity Agent covers roaming laptops and non-Windows endpoints.
3. Identity Collector aggregates both plus RADIUS/Syslog feeds and pushes to every gateway.
4. Captive Portal authenticates guests, BYOD, and anything still unidentified.
5. Access Roles turn all of that into matchable policy objects in the rulebase.

This stack is what the exam expects you to describe when asked about a complete Identity Awareness deployment.

Exam Traps

• Captive Portal authenticates the user, not the machine. The mapping is IP-to-user; machine identity still requires the agent or AD Query.
• Captive Portal requires HTTP redirect or HTTPS Inspection. Without HTTPS Inspection, HTTPS destinations will not redirect cleanly.
• Access Roles combine identity dimensions; they are not the same as network objects. The exam may ask which object type allows user-and-network matching — the answer is the Access Role.
• Identity is not retroactive. This rule appears in almost every Check Point identity question: existing sessions are not re-evaluated after a new mapping appears.