Technical Tip: FortiAuthenticator self-service portal and captive portal – purpose and differences

Description

This article explains two portals that FortiAuthenticator offers, captive portal and self-service portal, their purpose, and differences, and the issue that occurs on Guest Wifi users.

Scope

FortiAuthenticator.

Solution

FortiAuthenticator can provide a number of portal services, including captive portal and self-service portal.

These two in particular are sometimes confused; the goal of this Knowledge Base article is to detail the purpose of each one.

1. Self-service portal.

This is an option to allow users to access FortiAuthenticator directly for specific purposes such as:

• Registering.
• Requesting a FortiToken.
• Reporting a lost FortiToken.
• Editing user information in FortiAuthenticator (updating email address/mobile number, etc).

2. Captive Portal.

This is an option to allow users to authenticate; the user will be redirected from the host asking for authentication (such as a FortiGate or Wireless Controller) to FortiAuthenticator, which handles the authentication and upon a successful one sends the user back to the original host.

3. Using Captive Portal vs Self-Service Portal.

Self-service portal is ONLY to be used for users to access FortiAuthenticator directly, to create and edit their accounts. The self-service portal does not handle user authentication for other hosts.

Captive portal handles authenticating users for other hosts, not the self-service portal.

In some instances, a captive portal authentication WITH registration is desired (to allow guests to connect and create their own account, for example).

However, this is not done via the self-service portal.

The Captive Portal also allows for user registration; what options a portal allows (registration, etc) are defined in the actual portal used in a portal policy.

Captive Portal policy:

And the portal:

Self-service policy:

And the portal:

Captive portal workflow steps:

The typical captive portal workflow for an end-user with a FortiGate/FortiWiFi goes as follows:

• The end-user browser attempts to go through the FortiGate/FortiWiFi to access a website.
• (Optional step) FortiGate/FortiWiFi sends a MAC Authentication Bypass (MAB) RADIUS authentication request using the end-user's MAC address to the FortiAuthenticator.
• (Optional step) FortiAuthenticator processes the MAB request. It return an Access-Accept response and authorized group name RADIUS attributes if the MAC address is authorized, or an Access-Accept response without the authorized group name RADIUS attribute otherwise.
• (Optional step) Upon an Access-Accept response and correct group membership, the end-user browser bypasses the captive portal and is allowed through to the requested website. Workflow stops here.
  FortiGate/FortiWiFi intercepts the request and redirects the browser to the FortiAuthenticator's captive portal. The redirect takes the form of an HTTPS request including parameters containing information unique to this particular authentication session. Here is a FortiGate/FortiWiFi redirect sample:

https://192.168.30.47/portal/?post=http://192.168.30.1:1000/fgtauth&magic=040d028c9aaae999&usermac=60:03:08:8f:5e:b6&apmac=08:5b:0e:08:d4:ee&apip=192.168.30.41&ssid=test&apname=FWF60D4613003326&bssid=00:00:00:00:00:00

• FortiAuthenticator successfully authenticates the end-user.
• FortiAuthenticator redirects the end-user browser to the FortiGate/FortiWiFi's captive portal API specified in the 'post' parameter of the original captive portal redirect, e.g. http://192.168.30.1:1000/fgtauth in the above sample. The API call also contains the 'magic' parameter (also from the original redirect), in addition to a username and password.
• FortiGate/FortiWiFi uses the 'magic' parameter to associate the API request to the firewall session that triggered the original redirect and triggers a RADIUS authentication request to the FortiAuthenticator using the username and password from the API request.
• FortiAuthenticator verifies the credentials from the RADIUS authentication request. If valid, it returns a RADIUS Access-Accept response containing the appropriate RADIUS attributes.
• FortiGate/FortiWiFi redirects the end-user browser to a website. The specific website depends on the FortiGate/FortiWiFi configuration.

Troubleshooting steps for after authentication, if the internet is not working. Follow the steps below:

On the Guest Wifi SSID, configured a Captive Portal on FortiGate:

•  Verify the Policies, user-groups on both FortiGate/FortiAuthentication. If the configuration seems fine.
•  Check for any URL mismatch issues.
• Verify the URLs from both FortiGate and FortiAuthenticator.
• The URLs should be the same as the following example: https://fac.forti.com/portal/
• On FortiGate, verify the URLs are for the portal, not a self-service portal.
• Once it is connected with the Guest-Wifi, it redirects to the same URLs, and after entering the username/Password, it will redirect to the Original Page of the SSID IP address e.g. 192.168.10.0:1000.
  
  

The browser will receive an error. The page does not connect, which is the expected behavior.

Instead of the Original Page, choose a specific URL like https://www.google.com or Customer Domain URLs.

Once it is connected, internet connectivity will start working as expected.