Captive Portal Guidelines and Limitations

When you configure and deploy captive portal in an identity policy, users from specified realms authenticate using threat defense to access your network.

Note

When a remote access VPN user has already actively authenticated through a managed device acting as a secure gateway, captive portal active authentication will not occur, even if configured in an identity policy.

Captive portal and policies

You configure captive portal in your identity policy and invoke active authentication in your identity rules. Identity policies are associated with access control policies and access control policies define access to resources in the network. For example, you might exclude users in the US-West/Finance group to access Engineering servers or you can prohibit users from accessing nonsecure applications on the network.

You configure some captive portal identity policy settings on the identity policy's Active Authentication tab page and configure the rest in the identity rule associated with the access control policy.

An active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive or VPN identity cannot be established selected. In each case the system transparently enables or disables TLS/SSL decryption, which restarts the Snort process.

Caution

Adding the first or removing the last active authentication rule when TLS/SSL decryption is disabled (that is, when the access control policy does not include a decryption policy) restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort Restart Traffic Behavior for more information.

When the captive portal authenticates users that match an identity rule, any user in a Microsoft Active Directory or LDAP group that has not been downloaded is identified as Unknown. To avoid users being identified as Unknown, configure the realm or realm sequence to download users in all groups you expect to authenticate with captive portal. Unknown users are handled according to the associated access control policy; if the access control policy is configured to block Unknown users, these users are blocked.

To make sure the system downloads all users in a realm or realm sequence, make sure the groups are in the Available Groups list in the realm's configuration.

For more information about synchronizing users and groups, see Synchronize Users and Groups.

Routed interface required

Captive portal active authentication can be performed only by a device with a routed interface configured. If you are configuring an identity rule for captive portal and your captive portal device contains inline and routed interfaces, you must configure interface rule conditions in the access control policy to target only the routed interfaces on the device.

If the identity policy associated with your access control policy contains one or more captive portal identity rules and you deploy the policy on the CDO that manages one or more devices with routed interfaces configured, the policy deployment succeeds and the routed interfaces perform active authentication.

Required certificate and certificate authorities

Before you can use the captive portal for user control and awareness, you must have all of the following:

  • To authenticate with Microsoft AD, export the server's root certificate and import it into the CDO as a trusted CA certificate.

  • An internal certificate object for authenticating with the managed device to which the identity policy is deployed.

  • An internal certificate authority for the required decryption rule.

Captive portal requirements and limitations

Note the following requirements and limitations:

  • Captive portal does not support HTTP/3 QUIC connections.

  • The system supports up to 20 captive portal logins per second.

  • There is a maximum five minute limit between failed login attempts for a failed login attempt to be counted toward the count of maximum login attempts. The five minute limit is not configurable.

    (Maximum login attempts are displayed in connection events: Analysis > Connections > Events.)

    If more than five minutes elapse between failed logins, the user is redirected to captive portal for authentication and will not be designated a failed login user or a guest user, and will not be reported to the CDO.

  • Captive portal does not negotiate TLS v1.0 connections.

    Only TLS v1.1, v1.2, and TLS 1.3 connections are supported.

  • The only way to be sure a user logs out is for the user to close and reopen the browser. Unless that happens, in some cases, the user can log out of captive portal and be able to access the network without authenticating again using the same browser.

  • Your access control rule must allow traffic destined for the IP address and port of the device you plan to use for captive portal.

  • To perform captive portal active authentication on HTTPS traffic, you must use a decryption policy to decrypt the traffic from the users you want to authenticate. You cannot decrypt the traffic in the connection between a captive portal user's web browser and the captive portal daemon on the managed device; this connection is used to authenticate the captive portal user.

  • To limit the amount of non-HTTP or HTTPS traffic that is allowed through the managed device, you should enter typical HTTP and HTTPS ports in the identity policy's Ports tab page.

    The managed device changes a previously unseen user from Pending to Unknown when it determines that the incoming request does not use the HTTP or HTTPS protocol. As soon as the managed device changes a user from Pending to another state, access control, Quality of Service, and decryption policies can be applied to that traffic. If your other policies don't permit non-HTTP or HTTPS traffic, configuring ports on the captive portal identity policy can prevent undesired traffic from being allowed through the managed device.

Kerberos prerequisites

If you're using Kerberos authentication, the managed device's host name must be less than 15 characters (it's a NetBIOS limitation set by Windows); otherwise, captive portal authentication fails. You set the managed device host name when you set up the device. For more information, see an article like this one on the Microsoft documentation site: Naming conventions in Active Directory for computers, domains, sites, and OUs.

DNS must return a response of 64KB or less to the hostname; otherwise, the AD connection test fails. This limit applies in both directions and is discussed in RFC 6891 section-6.2.5.