Control Users with Captive Portal

The Captive Portal Identity Source

Captive portal is one of the authoritative identity sources supported by the Firepower System. It is an active authentication method where users authenticate onto the network using a managed device.

You typically use captive portal to require authentication to access the internet or to access restricted internal resources; you can optionally configure guest access to resources. After the system authenticates captive portal users, it handles their user traffic according to access control rules. Captive portal performs authentication on HTTP and HTTPS traffic only.


Note


HTTPS traffic must be decrypted before captive portal can perform authentication.


Captive portal also records failed authentication attempts. A failed attempt does not add a new user to the list of users in the database. The user activity type for failed authentication activity reported by captive portal is Failed Auth User.

The authentication data gained from captive portal can be used for user awareness and user control.

License Requirements for Captive Portal

FTD License

Any

Classic License

Control

Requirements and Prerequisites for Captive Portal

Model Support

Any except NGIPSv.

Supported Domains

Any

User Roles

  • Admin

  • Access Admin

  • Network Admin

Captive Portal Guidelines and Limitations

When you configure and deploy captive portal in an identity policy, users from specified realms authenticate through the following device to access your network:

  • ASA FirePOWER devices in routed mode running Version 9.5(2) or later

  • Firepower Threat Defense devices in routed mode


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.


Routed Interface Required

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

If the identity policy referenced by your access control policy contains one or more captive portal identity rules and you deploy the policy on a Firepower Management Center that manages:

  • One or more devices with routed interfaces configured, the policy deployment succeeds and the routed interfaces perform active authentication.

    The system does not validate the type of interface in ASA with FirePOWER devices. If you apply a captive portal policy to an inline (tap mode) interface on an ASA with FirePOWER device, the policy deployment succeeds but users in traffic matching those rules are identified as Unknown.

  • One or more NGIPSv devices, the policy deployment fails.

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.

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

Captive portal authenticates any user in the associated realm, even if that user does not belong to a downloaded group. The system identifies users in non-downloaded groups as Unknown; Unknown users match no identity rules. To avoid that, configure the realm to download users in all groups you expect to authenticate with captive portal.

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

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


Caution


Adding the first or removing the last active authentication rule when SSL decryption is disabled (that is, when the access control policy does not include an SSL 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.

Captive Portal Requirements and Limitations

Note the following requirements and limitations:

  • 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 will continue to be redirected to captive portal for authentication, will not be designated a failed login user or a guest user, and will not be reported to the Firepower Management Center.

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

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

  • You cannot use a realm sequence with the captive portal.

  • The only way to be sure a user logs out is 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.

  • If a realm is created for a parent domain and the managed device detects a login to a child of that parent domain, the user's subsequent logout is not detected by the managed device.

  • To use an ASA FirePOWER device (in routed mode and running ASA version 9.5(2) or later) for captive portal, use the captive-portal ASA CLI command to enable captive portal for active authentication and define the port as described in the ASA Firewall Configuration Guide (Version 9.5(2) or later): https://www.cisco.com/c/en/us/support/security/adaptive-security-appliance-asa-software/products-installation-and-configuration-guides-list.html.

  • You 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 an SSL 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 SSL 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.

How to Configure the Captive Portal for User Control

High-level overview of how to control user activity with captive portal:

Before you begin

To use the captive portal for active authentication, you must set up an AD or LDAP realm (but not a realm sequence), access control policy, an identity policy, an SSL policy, and associate the identity and SSL policies with the access control policy. Finally, you must deploy the policies to managed devices. This topic provides a high-level summary of those tasks.

An example of the entire procedure begins in Configure the Captive Portal Part 1: Create an Identity Policy.

Perform the following tasks first:

  • Confirm that your Firepower Management Center manages one or more devices with a routed interface configured.

    In particular, if your Firepower Management Center manages ASA with FirePOWER devices, see Captive Portal Guidelines and Limitations.

  • To use encrypted authentication with the captive portal, either create a PKI object or have your certificate data and key available on the machine from which you're accessing the Firepower Management Center. To create a PKI object, see PKI Objects.

Procedure


Step 1

Create and enable a realm as discussed in the following topics:

A realm sequence is not supported for the captive portal.

Captive portal authenticates any user in the associated realm, even if that user does not belong to a downloaded group. The system identifies users in non-downloaded groups as Unknown; Unknown users match no identity rules. To avoid that, configure the realm to download users in all groups you expect to authenticate with captive portal.

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

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

Step 2

Create an active authentication identity policy for captive portal.

The identity policy enables selected users in your realm access resources after authenticating with the captive portal.

For more information, see Configure the Captive Portal Part 1: Create an Identity Policy.

Step 3

Configure an access control rule for the captive portal that allows traffic on the captive portal port (by default, TCP 885).

You can choose any available TCP port for the captive portal to use. Whatever your choice, you must create a rule that allows traffic on that port.

For more information, see Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule.

Step 4

Add another access control rule to allow users in the selected realms to access resources using the captive portal.

This enables users to authenticate with captive portal.

For more information, see Configure the Captive Portal Part 3: Create a User Access Control Rule.

Step 5

Configure an SSL decrypt - resign policy for the Unknown user so captive portal users can access web pages using the HTTPS protocol.

The captive portal can authenticate users only if the HTTPS traffic is decrypted before the traffic is sent to the captive portal. Captive portal is seen by the system as the Unknown user.

For more information, see Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy.

Step 6

Asscociate the identity and SSL policies with the access control policy from step 2.

This final step enables the system to authenticate users with the captive portal.

For more information, see Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy.


What to do next

See Configure the Captive Portal Part 1: Create an Identity Policy.

Configure the Captive Portal Part 1: Create an Identity Policy

Before you begin

This five-part procedure shows how to set up the captive portal using the default TCP port 885 and using a Firepower Management Center server certificate for both the captive portal and for SSL decryption. Each part of this example explains one task required to enable the captive portal to perform active authentication.

If you follow all the steps in this procedure, you can configure captive portal to work for users in your domains. You can optionally perform additional tasks, which are discussed in each part of the procedure.

For an overview of the entire procedure, see How to Configure the Captive Portal for User Control.

Procedure


Step 1

Log in to the Firepower Management Center if you have not already done so.

Step 2

Click Policies > Access Control > Identity and create or edit an identity policy.

Step 3

(Optional.) Click Add Category to add a category for the captive portal identity rules and enter a Name for the category.

Step 4

Click Active Authentication.

Step 5

Choose the appropriate Server Certificate from the list or click Add (add icon) to add a certificate.

Note

 

Captive portal does not support the use of Digital Signature Algorithm (DSA) or Elliptic Curve Digital Signature Algorithm (ECDSA) certificates.

Step 6

Enter 885 in the Port field and specify the Maximum login attempts.

Step 7

(Optional.) Choose an Active Authentication Response Page as described in Captive Portal Fields.

The following figure shows an example.

Step 8

Click Save.

Step 9

Click Rules.

Step 10

Click Add Rule to add a new captive portal identity policy rule, or click Edit (edit icon) to edit an existing rule.

Step 11

Enter a Name for the rule.

Step 12

From the Action list, choose Active Authentication.

The system can enforce captive portal active authentication on HTTP and HTTPS traffic only. If an identity rule Action is Active Authentication (you are using captive portal) or if you are using passive authentication and you check the option on Realms & Settings page to Use active authentication if passive or VPN identity cannot be established, use TCP ports constraints only.

Step 13

Click Realm & Settings.

Step 14

From the Realms list, choose a realm to use for user authentication.

A realm sequence is not supported.

Step 15

(Optional.) Check Identify as Guest if authentication cannot identify user. For more information, see Captive Portal Fields.

Step 16

Choose an Authentication Protocol from the list.

Step 17

(Optional.) To exempt specific application traffic from captive portal, see Exclude Applications from Captive Portal.

Step 18

Add conditions to the rule (port, network, and so on) as discussed in Rule Condition Types.

Step 19

Click Add.

Step 20

At the top of the page, click Save.


What to do next

Continue with Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule.

Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule

This part of the procedure shows how to create an access control rule that allows the captive portal to communicate with clients using TCP port 885, which is the captive portal's default port. You can choose another port if you wish, but the port must match the one you chose in Configure the Captive Portal Part 1: Create an Identity Policy.

Before you begin

For an overview of the entire captive portal configuration, see How to Configure the Captive Portal for User Control.

Procedure


Step 1

Log in to the Firepower Management Center if you have not already done so.

Step 2

If you haven't done so already, create a certificate for the captive portal as discussed in PKI Objects.

Step 3

Click Policies > Access Control > Access Control and create or edit an access control policy.

Step 4

Click Add Rule.

Step 5

Enter a Name for the rule.

Step 6

Choose Allow from the Action list.

Step 7

Click Ports.

Step 8

From the Protocol list under the Selected Destination Ports field, choose TCP.

Step 9

In the Port field, enter 885 .

Step 10

Click Add next to the Port field.

The following figure shows an example.

Step 11

Click Add at the bottom of the page.


What to do next

Continue with Configure the Captive Portal Part 3: Create a User Access Control Rule.

Configure the Captive Portal Part 3: Create a User Access Control Rule

This part of the procedure discusses how to add an access control rule that enables users in a realm to authenticate using captive portal.

Before you begin

For an overview of the entire captive portal configuration, see How to Configure the Captive Portal for User Control.

Procedure


Step 1

In the rule editor, click Add Rule.

Step 2

Enter a Name for the rule.

Step 3

Choose Allow from the Action list.

Step 4

Click Users.

Step 5

In the Available Realms list, click the realms to allow.

Step 6

If no realms display, click Refresh (refresh icon).

Step 7

In the Available Users list, choose the users to add to the rule and click Add to Rule.

Step 8

(Optional.) Add conditions to the access control policy as discussed in Rule Condition Types.

Step 9

Click Add.

Step 10

On the access control rule page, click Save.

Step 11

In the policy editor, set the rule position. Click and drag or use the right-click menu to cut and paste. Rules are numbered starting at 1. The system matches traffic to rules in top-down order by ascending rule number. The first rule that traffic matches is the rule that handles that traffic. Proper rule order reduces the resources required to process network traffic and prevents rule preemption.


What to do next

Continue with Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy.

Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy

This part of the procedure discusses how to create an SSL access policy to decrypt and resign traffic before the traffic reaches the captive portal. The captive portal can authenticate traffic only after it has been decrypted.

Before you begin

For an overview of the entire captive portal configuration, see How to Configure the Captive Portal for User Control.

Procedure


Step 1

If you haven't done so already, create a certificate object to decrypt SSL traffic as discussed in PKI Objects.

Step 2

Click Policies > Access Control > SSL.

Step 3

Click New Policy.

Step 4

Enter a Name and choose a Default Action for the policy. Default actions are discussed in SSL Policy Default Actions.

Step 5

Click Save.

Step 6

Click Add Rule.

Step 7

Enter a Name for the rule.

Step 8

From the Action list, choose Decrypt - Resign.

Step 9

From the with list, choose your PKI object.

Step 10

Click Users.

Step 11

Above the Available Realms list, click Refresh (refresh icon).

Step 12

In the Available Realms list, click Special Identities.

Step 13

In the Available Users list, click Unknown.

Step 14

Click Add to Rule.

The following figure shows an example.

Step 15

(Optional.) Set other options as discussed in TLS/SSL Rule Conditions.

Step 16

Click Add.

Step 17

At the top of the page, click Save.


What to do next

Continue with Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy.

Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy

This part of the procedure discusses how to associate the identity policy and SSL Decrypt - Resign rule with the access control policy you created earlier. After this, users can authenticate using the captive portal.

Before you begin

For an overview of the entire captive portal configuration, see How to Configure the Captive Portal for User Control.

Procedure


Step 1

Click Policies > Access Control > Access Control and edit the access control policy you created as discussed in Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule. If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 2

Either create a new access control policy or edit an existing policy.

Step 3

At the top of the page, click the link next to Identity Policy.

Step 4

From the list, choose the name of your identity policy and, at the top of the page, click Save.

Step 5

Repeat the preceding steps to associate your captive portal SSL policy with the access control policy.

Step 6

If you haven't done so already, target the policy at managed devices as discussed in Setting Target Devices for an Access Control Policy.


What to do next

Captive Portal Fields

Use the following fields to configure captive portal on the Active Authentication tab page of your identity policy. See also Identity Rule Fields and Exclude Applications from Captive Portal.

Server Certificate

The server certificate presented by the captive portal daemon.


Note


Captive portal does not support the use of Digital Signature Algorithm (DSA) or Elliptic Curve Digital Signature Algorithm (ECDSA) certificates.


Port

The port number to use for the captive portal connection. If you plan to use an ASA FirePOWER device for captive portal, the port number in this field must match the port number you configured on the ASA FirePOWER device using the captive-portal CLI command.

Maximum login attempts

The maximum allowed number of failed login attempts before the system denies a user's login request.

Active Authentication Response Page

The system-provided HTTP response page includes Username and Password fields, as well as a Login as guest button to allow users to access the network as guests. To display a single login method, configure a custom HTTP response page.

Choose the following options:

  • To use a generic response, click System-provided. You can click View (View button) to view the HTML code for this page.

  • To create a custom response, click Custom. A window with system-provided code is displayed that you can replace or modify. When you are done, save your changes. You can edit a custom page by clicking Edit (edit icon).

Exclude Applications from Captive Portal

You can select applications (identified by their HTTP User-Agent strings) and exempt them from captive portal active authentication. This allows traffic from the selected applications to pass through the identity policy without authenticating.


Note


Only applications with the User-Agent Exclusion Tag are displayed in this list.


Procedure


Step 1

If you haven't done so already, log in to the Firepower Management Center.

Step 2

Click Policies > Access Control > Identity .

Step 3

Edit the identity policy that contains the captive portal rule.

Step 4

On Realm & Settings tab page, expand HTTP User Agent Exclusions.

  • In the first column, select the check box next to each item to filter applications, then one or more applications, and click Add to Rule.

    Check boxes are ANDed together.

  • To narrow the filters that are displayed, type a search string in the Search by name field; this is especially useful for categories and tags. To clear the search, click Clear (clear icon).

  • To refresh the filters list and clear any selected filters, click Reload (reload icon).

Note

 

The list displays 100 applications at a time.

Step 5

Choose the applications that you want to add to the filter from the Available Applications list:

  • To narrow the individual applications that appear, enter a search string in the Search by name field. To clear the search, click Clear (clear icon).

  • Use paging at the bottom of the list to browse the list of individual available applications.

  • To refresh the applications list and clear any selected applications, click Reload (reload icon).

Step 6

Add the selected applications to exclude from external authentication. You can click and drag, or you can click Add to Rule. The result is the combination of the application filters you selected.


What to do next

Troubleshoot the Captive Portal Identity Source

For other related troubleshooting information, see Troubleshoot Realms and User Downloads and Troubleshoot User Control.

If you experience issues with captive portal, check the following:

  • The time on your captive portal server must be synchronized with the time on the Firepower Management Center.

  • If you have DNS resolution configured and you create an identity rule to perform Kerberos (or HTTP Negotiate, if you want Kerberos as an option) captive portal, you must configure your DNS server to resolve the fully qualified domain name (FQDN) of the captive portal device. The FQDN must match the hostname you provided when configuring DNS.

    For ASA with FirePOWER Services and Firepower Threat Defense devices, the FQDN must resolve to the IP address of the routed interface used for captive portal.

  • 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, testing the connection the AD connection fails. This limit applies in both directions and is discussed in RFC 6891 section-6.2.5.

  • If you select Kerberos (or HTTP Negotiate, if you want Kerberos as an option) as the Authentication Type in an identity rule, the Realm you select must be configured with an AD Join Username and AD Join Password to perform Kerberos captive portal active authentication.

  • If you select HTTP Basic as the Authentication Type in an identity rule, users on your network might not notice their sessions time out. Most web browsers cache the credentials from HTTP Basic logins and use the credentials to seamlessly begin a new session after an old session times out.

  • If the connection between your Firepower Management Center and a managed device fails, no captive portal logins reported by the device can be identified during the downtime, unless the users were previously seen and downloaded to the Firepower Management Center. The unidentified users are logged as Unknown users on the Firepower Management Center. After the downtime, the Unknown users are reidentified and processed according to the rules in your identity policy.

  • If the device you want to use for captive portal contains both inline and routed interfaces, you must configure a zone condition in your captive portal identity rules to target only the routed interfaces on the captive portal device.

  • The system does not validate the type of interface in ASA with FirePOWER devices. If you apply a captive portal policy to an inline (tap mode) interface on an ASA with FirePOWER device, the policy deployment succeeds but users in traffic matching those rules are identified as Unknown.

  • The host name of the managed device must be less than 15 characters for Kerberos authentication to succeed.

  • The only way to be sure a user logs out is 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.

  • Active FTP sessions are displayed as the Unknown user in events. This is normal because, in active FTP, the server (not the client) initiates the connection and the FTP server should not have an associated user name. For more information about active FTP, see RFC 959.

  • Captive portal authenticates any user in the associated realm, even if that user does not belong to a downloaded group. The system identifies users in non-downloaded groups as Unknown; Unknown users match no identity rules. To avoid that, configure the realm to download users in all groups you expect to authenticate with captive portal.

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

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

History for Captive Portal

Feature

Version

Details

Guest login.

6.1.0

Users can log in as guest using captive portal.

Captive portal.

6.0

Feature introduced. You can use the captive portal to require users to enter their credentials when prompted in a browser window. The mapping also allows policies to be based on a user or group of users.