Captive Portal (CP) Authentication for Wired Clients

Wired clients connected via port profile (tunnelled and bridged) will require CP authentication to pass external traffic. Wired Clients can have CP Authentication with Security Profile configured with L2 mode in Clear profile or L2 mode in 802.1X Clear profile.

Supported access points: AP122, AP822v2, AP822, OAP832, AP832, AP332 (only supports G1/G2 port in mesh configuration), AP433 (only supports G1 port in mesh configuration), FAPU421EV, and FAP-U423EV

To allow wired clients to pass external traffic, do the following:

1. Create a captive portal (CP)profile
2. In the security profile, map the CP profile to the security profile. In the security profile ensure that at least one of the (802.1x, WebAuth, Mac Authentication, or CP Bypass) security option is enabled.
3. In the port profile, map the security profile to port profile

NOTES

Captive Portal (CP) Authentication for Wired Clients

• CP authentication is available only when VLAN trunk is disabled.
• Dynamic VLAN is not supported.\
• Wired clients connected to a leaf AP should be in bridge mode port profile.
• Re-authentication will fail, If the Ethernet cable is disconnected and reconnected from the wired client’s port.

Station log for wired client

2015‐Dec‐2 14:31:55.075109 | 08:9e:01:28:64:25 | Station Assign | wired Assigned to <AP_ID=2>(v0)

Captive Portal With N+1

Captive Portal changes are propagated in an Nplus1 environment as follows. When a slave takes over a master, it uses the master’s Captive Portal pages. If changes are made on that active slave, that change is not automatically propagated to the master.

Troubleshooting Captive Portal

• The same subnet should not be entered for both CaptivePortal1 and CaptivePortal2. If you do this, only the CaptivePortal1 configured splash page will be displayed.

Captive Portal With N+1

• Custom pages have to imported properly before making use of this feature. See “Optionally Customize and Use Your Own HTML Pages” on page 282.
• To check if the pages and images have been properly imported into the controller use the command show web custom-area
• To check if the imported page is coming up properly use the CLI https://<controller ip>/vpn/ <page Name>
• To ensure that Captive Portal authentication is taking place, look at the access-accept message from the RADIUS server during Captive Portal authentication.
• Even when using custom CP pages, four default HTML files are used; only two are actually customized. The only way to change this is to alter the four default files which are used for both CP1 and CP2.

Captive Portal Profiles

Captive portal profiles feature that allows you to create individual captive portal profiles with distinct configuration settings. Such captive portal profiles can be mapped to security profiles for fine control over captive portal user access.

A captive portal profile is created from the Configuration > Security > Captive Portal page. The Captive Portal Profile tab is used to specify the captive portal profile settings. Once created, this captive profile can be enabled in a security profile. The following screen-shots illustrate the process to create and assign a captive profile.

Captive Portal Profiles

1. Creating a Captive Portal Profile
2. Assigning a Captive Portal Profile to a Security Profile

Captive Portal Profiles

Optionally Customize and Use Your Own HTML Pages

If you want to create custom Captive Portal login and success pages with your own logos and credentials, complete the directions in this section. You do not need to do this if you plan to use all of the default Captive Portal pages provided by Fortinet Networks (see login example in Figure 57 on page 282). If you do want to create custom HTML pages, you can create up to four sets of Captive Portal custom login pages; these are referred to as Captive Portal 1 through 4. Each set has 6 files, but you can only create customized pages for the main login page and the authentication successful page. The remaining four HTML pages are always the default pages. If you create multiple custom files, they must both use the same authentication

(RADIUS or Local) with up to 300 local users (the users can be different for each custom portal).

All Custom Portal pages (HTML, CSS, JS, and graphics) for the default pages and up to four sets of Custom Portal 2 pages that you create are all located in the same folder. This makes it imperative that you use unique names for all custom files. It also means that you can share a file such as a CSS file used for both CP1 and CP2 custom pages. This is also how and why any pages that you do not customize will use default HTML files. Here are the locations for the custom web portal files:

/opt/meru/etc/ws/html.vpn.custom

/opt/meru/etc/ws/Styles.vpn.custom

/opt/meru/etc/ws/Images.vpn.custom

 

Create Custom Pages

The easiest way to create your own set of custom pages is to download Fortinet default files and use the two customizable ones (Login page and Success page) as templates, giving the two altered HTML pages new names. To do this, follow these steps:

1. Get the template files. Click Maintenance > Captive Portal > Customization > Get Files. A zip file called zip.tar.gz is downloaded to your computer. When the zip.tar.gz file is unzipped, you see the folder html.vpn that contains these six default files: Login page can be customized (default filename is loginformWebAuth.html)
   • Successful login page can be customized (default filename is auth_web_ok.html)
   • Your login failed – try again page (default filename is loginformWebAuthRetry.html)
   • Web authentication succeeded; do you want to log off? (default filename is logoff User.html)
   • You are now logged off page (default filename is loggedoff.html)
   • Your logoff failed – try again page (default filename is logoffUserFailed.html)
2. You can only create two custom files per Captive Portal interface: a replacement for the Login page loginformWebAuth.html and a replacement for the Successful Login page auth_web_ok.html. Locate the two customizable HTML files on your computer and use them as templates to create your own custom HTML files. Use a program such as Notepad, make your changes, and then save the files with unique names.
   • CSS, JavaScript, and HTML are supported.
   • You can upload graphics up to 50K each in the formats .html .gif, .jpg, .png, .bmp .css,

.js.

To replace the first Fortinet logo graphic, look for the line that reads: src=”Images.vpn/img_merulogo.gif” width=133 border=0></A></TD>

Change the text “Images.vpn/img_merulogo.gif” to “Images.vpn.custom/your_image.gif” (Note that you are specifying a new directory for the .gif file, which is Images.vpn.custom).

To replace the second graphic (the mountain), look for the line that reads: src=”Images.vpn/img_aboutmeru.jpg” width=326 border=0></TD></TR>

Change the text “Images.vpn/img_aboutmeru.jpg” to “Images.vpn.custom/your_image2.gif” (Note that you are specifying a new directory for the .gif file, which is Images.vpn.custom).

Possible edits include changing logos, text, and formatting. The only lines that cannot be altered are the login communication process between the controller and the RADIUS server in the file loginformWebAuth.html.

3. Import all new Captive Portal files (HTML, CSS, JS, and graphics) to the controller one by one. Click Maintenance > Captive Portal > Import File > enter the location/file in the text box > Import File. Be sure that the files have unique names; they will all be placed in the same directory.

Tell the controller to use custom pages. Click Configuration > Captive Portal and select the radio button Customization.

The custom HTML, CSS, JS, and graphic files are now on the controller.

4. If you want to remove the word Fortinet or make any other changes in the four remaining files loginformWebAuthRetry.html, logoff User.html, loggedoff.html, or logoffUserFailed.html, alter the default files that you downloaded in Step 1 and import them as you did in Step 3. All five sets of Portal pages (default, CP1, CP2, CP3, and CP4) will then use the default files that you altered. These four files have only one version. See Figure 59.

Figure 59: Captive Portal HTML Pages (maximum)

Next, tell FortiWLC (SD) which custom files to use under what circumstances. Either Implement New Custom HTML Files Using the CLI or Implement New Custom HTML Files Using the GUI.

Implement New Custom HTML Files Using the CLI

Implement custom Captive Portal pages with the CLI by indicating which subset of users should see the new login and success pages; when a user logs in from this subnet, they will see the corresponding custom pages. You can implement up to two sets of Captive Portal pages at a time. For example, students in a library might see the Custom Captive Portal 1 login and success pages while visitors to the football stadium see the Custom Captive Portal 2 login and success pages. See Figure 59.

Determine who will see which pages. Point to two custom Captive Portal pages with the CLI command web custom CaptivePortal[1|2] landing-file-name <landing.html> success-file-name <success.html>. Then, point to the network or subnet for the custom captive portal pages with web custom CaptivePortal[1|2] subnet <x.x.x.x> mask <x.x.x.x>. For example:

MC3K‐1# configure terminal MC3K‐1(config)# web custom ?

CaptivePortal1         Custom configuration for captive portal 1

CaptivePortal2         (10) Custom configurations for captive portal2.

CaptivePortal3         (10) Custom configurations for captive portal3.

CaptivePortal4         (10) Custom configurations for captive portal4.MC3K‐

1(config)# web custom captiveportal2 ? landing‐file‐name subnet

MC3K‐1(config)# web custom CaptivePortal1 landing‐file‐name landing.html success‐file‐name success.html

MC3K‐1 (config) web custom CaptivePortal1 subnet 1.1.1.0 mask 255.255.255.0

MC3K‐1(config)# exit

MC3K‐1# show web ?

custom                 Displays IP range for captive portal custom mode. custom‐area            Lists the files in the custom area for web‐auth and captive portal.

login‐page             Displays the type of login page used for web‐auth and captive portal.

MC3K‐1# show web custom‐area

Html Files total 16

‐rw‐rw‐rw‐    1 root     root         2607 Jul 13 16:26 page2OK.html

‐rw‐rw‐rw‐    1 root     root         4412 Jul 13 16:26 page2LOGIN.html

‐rwx‐‐‐‐‐‐    1 root     root         2607 Jul 13 16:04 auth_web_ok.html

‐rw‐rw‐rw‐    1 root     root         4412 Jul 13 16:04 loginformWebAuth.html

‐rwx‐‐‐‐‐‐    1 root     root            0 Jun 30 00:31 empty.html

Image Files total 9

‐rwx‐‐‐‐‐‐    1 root     root            0 Jun 30 00:31 empty.gif

‐rw‐rw‐rw‐    1 root     root         8574 Oct 29  2008 Sample.jpg

MC3K‐1# show web login‐page custom

Implement New Custom HTML Files Using the GUI

Implement custom Captive Portal pages with Web UI by first directing Captive Portal to use custom HTML files; those HTML files will then reference the CSS, JS and graphic files you imported. Second, indicate which subset of users should see the new login and success pages by providing a subnet and a mask; when a user logs in from this subnet, they will see the corresponding custom pages. For example, students in a library might see the Custom Captive Portal 1 login page while visitors to the football stadium see the Custom Captive Portal 2 login page.

Direct Captive Portal to use custom HTML files by following these steps:

1. Click Maintenance > Customization > select a controller > Change Mode 2. Scroll down and select Customized.

indicate which subset of users should see the custom pages by following these steps:

1. Make sure that security logging is set to on by clicking Configuration > Security > Profile and then selecting a security profile from the list. The security logging setting is near the bottom of the Security Profile Table. This setting must be set to on for Captive Portal configuration to work.
2. Click Maintenance > Captive Portal > Custom CP. The Custom Captive Portal page is displayed.

Figure 60: Custom Captive Portal Page

3. Provide the names of the new HTML Login Page and Success Page for CP1. Since they are on the controller now, you do not have to indicate a location. Click Save Page Info.
4. Provide at least one subnet location by clicking Add, providing a Subnet IP and a Network Mask, then clicking OK. Users logging in from this subnet will see these custom pages.
5. Create a corresponding Security Profile for this portal by clicking Configuration > Security > Profile > Add. Be sure that the setting for Captive Portal is set to webauth in this profile, then save it.
6. Click Configuration > Security > Captive Portal. In this window, identify the RADIUS server, whether or not to adjust the session, and idle timeouts. Session timeout and idle timeout are indicated in minutes.

The L3 User Session Timeout field is used for specific clients that have issues in which they get deauthenticated upon entering sleep mode. This field specifies that the controller will retain these clients in memory for the specified number of minutes before the client is dropped from the captive portal authentication state.

7. Click OK.

The custom HTML files are now configured. You can configure up to four sets of custom files, Captive Portal 1, Captive Portal 2, Captive Portal 3, and Captive Portal 4; or, you can use the default files. See Figure 59.

Configure Captive Portal with the CLI

• radius-profile defines the primary and secondary Captive Portal authentication servers.
• accounting-radius-profile defines the primary and secondary Captive Portal accounting servers.
• captive-portal > activity-timeout determines one timeout value. If a client is idle for this many minutes, the client is asked to reauthenticate. captive-portal > session-timeout determines one timeout value. If a client session lasts this long (minutes), the client is asked to reauthenticate.
• change_mac_state
• ssl-server captive-portal-external-URL directs Captive Portal to use a third-party solution located at the named URL.
• captive-portal-auth-method sets authentication to internal (default for Fortinet) or external for third-party solutions.

Captive Portal CLI Examples

This example configures Captive Portal with the CLI by completing these tasks:

• Create a guest user ID (Guest) and password.
• Enter the service start time (01/01/2010 00:00:00).
• Enter the service end time (01/01/2011 00:00:00).
• Show the Captive Portal.

MC3K‐1(config)# guest‐user ?

<guestname> Enter the name of the guest user.

MC3K‐1(config)# guest‐user Guest ?

<password> Enter the password of the guest user.

MC3K‐1(config)# guest‐user Guest XXXXX ?

<start‐time> Enter the service start‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” ?

<end‐time> Enter service end‐time (mm/dd/yyyy hh:mm:ss) in double quotes. MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011 00:00:00” ?

<CR>

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011

00:00:00″

MC3K‐1(config)# exit

MC3K‐1#

MC3K‐1# show guest‐user

Guest User  Name Service Start Time              Service End Time               

Guest 01/01/2010 00:00:00             01/01/2011 00:00:00            

        Guest User Table(1 entry)

The commands in this section show how to configure Captive Portal. The RADIUS server user configuration is performed separately, and is vendor-specific. (Check the Customer Service website for applicable Application Notes.) The Microsoft Internet Explorer and Netscape 7 browsers are both supported for the client application.

1. Create the Security Profile for the WebAuth Captive Portal:

default# configure terminal default(config)# security-profile web_auth default(config‐security)# captive‐portal webauth default(config‐security)# exit default(config)# exit

2. Bind the web_auth Security Profile to an ESSID:

default# configure terminal default(config)# essid WebAuth-meru-WIFI default(config‐essid)# security-profile web_auth default(config‐essid)# exit

3. Set the SSL server to use the primary RADIUS authentication server profile:

default(config)# ssl-server radius-profile primary main-auth default(config)# end

4. Save the configuration:

default(config)# copy running‐config startup‐config

When users are authenticated, they can be moved into a corporate VLAN, and can have QosRules applied to their session. Each user will have a supplied default session timeout, which if nothing is supplied, will be the default of 33 minutes. If a user disconnects and connects back to same SSID on the same controller within 60 seconds, no re-authentication will be required.The session time returned from the RADIUS server takes priority. If the RADIUS server doesn’t return the session time, configured values are used.

Create Captive Portal Guest User IDs Locally

For authentication purposes, you can set up guest user IDs instead of using RADIUS authentication. (This is also a backup for RADIUS authentication; if RADIUS fails, this list is then used.) Releases 3.6 and later support user IDs. Be sure that the field Captive Portal Authentication is set as Local when using Guest IDs (click Configuration > Security > Captive Portal).

The guest user features of both releases are as follows.

Guest User Feature	Supported
Number of users	300
Add/delete users	yes
Change user’s password	yes
Time of day login	yes
Day of month login	yes
Assigned to local administrators	yes

CLI Example – Create Guest User ID

This CLI example creates the guest user named Guest:

MC3K‐1 configure terminal

MC3K‐1(config)# guest‐user ?

<guestname>            Enter the name of the guest user.

MC3K‐1(config)# guest‐user Guest ?

<password>             Enter the password of the guest user.

MC3K‐1(config)# guest‐user Guest XXXXX ?

<start‐time>           Enter the service start‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” ?

<end‐time>             Enter service end‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011 00:00:00” ?

<CR>

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011

00:00:00″

MC3K‐1(config)# exit

MC3K‐1#

MC3K‐1# show guest‐user

Guest User Name Service Start TimeService End Time         

Guest 01/01/2010 00:00:00 01/01/2011 00:00:00            

        Guest User Table(1 entry) MC3K‐1#

There is an additional option for Local Authentication so that when local authentication for a

Captive Portal user fails, RADIUS authentication is automatically checked; this option is called Local and RADIUS. From the Web UI, configure this by clicking Configuration > Security > Captive Portal.

Figure 61: Local Captive Portal Authentication Has Two Options

The corresponding CLI command ssl-server captive-portal authentication-type configures the controller to use both local and RADIUS authentication.

Controller(config)# ssl‐server captive‐portal authentication‐type ? local                  Set Authentication Type to local. local‐radius           Set Authentication Type to Local and RADIUS. radius                 Set Authentication Type to RADIUS.

Optionally Configure Pre-Authentication Captive Portal Bypass

Not all users or traffic types need to be authorized and authenticated by Captive Portal; users of VPN software can pass through the portal without authentication. To enable this passthrough firewall filter ID, follow these steps:

1. Click Configuration > Security > Profile.
2. Enter the name of the Passthrough Firewall Filter ID.
3. Click Configuration > QoS > System Settings to see the QosRule section of the Configuration menu (a license for PPF is required to enter the passthrough rules).
4. Add a rule. Remember that rules are stored in the order they are entered and can not be modified once they are entered.
5. At the bottom of the screen enter the QoS Filter ID.

The last entry in the filter should be a rule that drops all other traffic, so that traffic other than the passthrough will not be allowed to transverse the Captive Portal without authentication.

Bypass Apple Captive Network Assistant (CNA)

You can bypass or disable the CNA. When enabled, the auto-login pop-up is not displayed in a captive portal authentication (in tunneled mode) using an Apple device or Android devices running Android 5.0 or later.

Using GUI

To enable CNA bypass, Go to Configuration > Captive Portal > Advanced Settings section and select ON for Bypass Apple CNA.

Using CLI

Use the cna‐bypass option in the ssl‐server command to enable or disable CNA bypass.

mc3200(15)# configure terminal master(15)(config)# ssl‐server cna‐bypass on master(15)(config)# exit master(15)# sh ssl‐server

Captive Portal

Name                                         : Captive Portal

 

Server Port                                  : 10101

User Authentication Protocol                 : None

Server Lifetime                              : 100

Server IP                                    : 172.18.34.177

Certificate                                  :

Authentication Type                          : radius

Primary Profile                              :

Secondary Profile                            :

Primary Profile                              :

Secondary Profile                            :

Accounting Interim Interval (seconds)        : 60

CaptivePortalSessionTimeout                  : 0

CaptivePortalActivityTimeout                 : 0 Protocol                                     : https

Portal URL                                   : CaptivePortal External URL                   :

CaptivePortal External IP                    : 172.18.34.177

L3 User Session Timeout(mins)                : 1

Apple Captive Network Assistant (CNA) Bypass : on

802.1X Authentication

Authentication in the 802.11 standard is focused more on wireless LAN connectivity than on verifying user or station identity. For enterprise wireless security to scale to hundreds or thousands of users, an authentication framework that supports centralized user authentication must be used in addition to the WEP type specified by 802.11, or by using WPA/WPA2, which incorporates TKIP/CCMP-AES and 802.1X authentication.

The use of IEEE 802.1X offers an effective framework for authenticating and controlling user traffic to a protected network, as well as dynamically varying encryption keys if WPA/WPA2 is configured. 802.1X ties a protocol called EAP (Extensible Authentication Protocol) to both the wired and wireless LAN media and supports multiple authentication methods, such as token cards, Kerberos, one-time passwords, certificates, and public key authentication.

802.1X Components

There are three basic pieces to 802.1X authentication:

1. Supplicant—a software client running on the wireless station
2. Authenticator—the access point and the controller
3. Authentication Server—an authentication database, traditionally a RADIUS server such as Cisco ACS, Steel Belt RADIUS server (Juniper), or Microsoft IAS.

Extensible Authentication Protocol (EAP) is used to pass the authentication information between the supplicant (the wireless station) and the authentication server (RADIUS, MS IAS, or other). The actual authentication is defined and handled by the EAP type. The access point (and the controller in the configuration) acts as the authenticator. The authenticator is a client of the server that allows the supplicant and the authentication server to communicate.

802.1X Authentication

About the EAP Types

The EAP type you choose, and whether you choose to implement authentication in your organization, depends on the level of security you require. Some of the most commonly deployed EAP authentication types include the following, all of which are supported by the controller:

• EAP-TLS
• EAP-PEAP
• EAP-TTLS
• Cisco LEAP

EAP-TLS

EAP-TLS (Transport Layer Security) provides certificate-based mutual authentication between the client and the network. It relies on client and server certificates to provide authentication and can be used to dynamically generate user-based and session-based encryption keys to secure subsequent communications between the WLAN client and the access point. This type of authentication mechanism requires the administrator install a Certificate Server to store and distribute user and computer certificates. Each client will need the certificate to be downloaded and installed on the wireless client before attempting to use the WLAN. For a large WLAN installation, this can be a cumbersome task.

EAP-TTLS (Tunneled Transport Layer Security)

EAP-TTLS (Tunneled Transport Layer Security) was developed by Funk Software and Certicom, as an extension of EAP-TLS. This security method provides for certificate-based, mutual authentication of the client and network through an encrypted channel (or tunnel), as well as a means to derive dynamic, per-user, per-session encryption keys. Unlike EAP-TLS, EAP-TTLS requires only server-side certificates.

LEAP (Lightweight Extensible Authentication Protocol)

LEAP (Lightweight Extensible Authentication Protocol), is an EAP authentication type used primarily in Cisco Aironet WLANs. It encrypts data transmissions using dynamically generated WEP keys, and supports mutual authentication. Cisco has recently licensed LEAP to a variety of other manufacturers enabling the usage of other than Cisco adapters with LEAP.

PEAP (Protected Extensible Authentication Protocol)

PEAP (Protected Extensible Authentication Protocol) provides a method to securely transport authentication data, including legacy password-based protocols, via 802.11 wireless networks. PEAP accomplishes this by using tunneling between PEAP clients and an authentication server. Like the competing standard Tunneled Transport Layer Security (TTLS), PEAP authenticates wireless LAN clients using only server-side certificates, thus simplifying the implementation and administration of a secure wireless LAN. Microsoft, Cisco and RSA Secu-

802.1X Authentication

rity developed PEAP. Note that Cisco’s LEAP authentication server, ACS, recently added support for PEAP.

802.1X EAP Types Feature/Benefit	MD5	TLS	TTLS	PEAP	LEAP
Client certificate required	no	yes	no	no	no
Server certificate required	no	yes	yes	yes	no
WEP key management	no	yes	yes	yes	yes
Provider	Microsoft	Microsoft	Funk	MS	Cisco
Authentication Attributes	One way	Mutual	Mutual	Mutual	Mutual
Deployment Difficulty	Easy	Difficult	Moderate	Moderate	Moderate
Wireless Security	Poorest	Highest	High	High	High

The following notes apply to the authentication mechanisms above:

1. MD5 is not typically used as it only provides one-way authentication. MD5 does not support automatic distribution and rotation of WEP keys and therefore does nothing to relieve the administrative burden of manual WEP key maintenance.
2. TLS, although very secure, requires the administrator to install client certificates on each wireless station. Maintaining a PKI infrastructure adds additional time and effort for the network administrator.
3. TTLS addresses the certificate issue by tunneling TLS, and thus eliminates the need for a certificate on the client side. This often makes TTLS the preferred option. Funk Software primarily promotes TTLS and there is a charge for supplicant and authentication server software.
4. LEAP has the longest history. Although previously proprietary to Cisco, Cisco now licenses the software. Other vendors are now beginning to support LEAP in their wireless LAN adapters.
5. The more recent PEAP works similar to EAP-TTLS in that it does not require a certificate on the client side. PEAP is backed by Cisco and Microsoft and is available at no additional cost from Microsoft. If you want to transition from LEAP to PEAP, Cisco’s ACS authentication server runs both.

Local Admin Authentication

Local admin authentication takes place on the controller and uses the same three privilege levels as RADIUS and TACACS+, 15 (superuser), 10 (admin), and 1 (user). If administrators are using Local authentication, they cannot use RADIUS or TACACS+.

Configure an Admin for Local Authentication Mode With the CLI

Use these commands, new in release 4.1, to configure local administrators with the CLI:

• authentication-mode global
• authentication-type local
• local-admin
• password
• privilege-level
• show local admins

For command details, see the FortiWLC (SD) Command Reference.

Local Admin Authentication

CLI Example for Configuring a Local Admin

ramcntrl(0)# configure terminal ramcntrl(0)(config)# authentication‐mode global ramcntrl(0)(config‐auth‐mode)# authentication‐type local ramcntrl(0)(config‐auth‐mode)# exit ramcntrl(0)(config)# exit

ramcntrl(0)# sh authentication‐mode Administrative User Management

AuthenticationType           : local

Primary RADIUS IP Address    : 0.0.0.0

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 0.0.0.0

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 0.0.0.0

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 0.0.0.0

Secondary TACACS+ Port       : 49 Secondary TACACS+ Secret Key : ***** ramcntrl(0)#

ramcntrl(0)(config)# local‐admin LocalUser ramcntrl(0)(config‐local‐admin)# privilege‐level 15 ramcntrl(0)(config‐local‐admin)# password LocalUser ramcntrl(0)(config‐local‐admin)# exit ramcntrl(0)(config)# exit ramcntrl(0)

Configure Local Authentication and Add an Admin with the Web UI

To configure Local authentication for admins and optionally add a local administrator, follow these steps:

1. Click Configuration > User Management.
2. Select the Local radio button at the top of the screen.

To actually add a local administrator, continue with Step 3.

3. There are three tabs for admin authentication (see Figure 55), RADIUS, Tacacs+ and Local Admins. Click the Local Admin tab.
4. Click Add. The Local Admins – Add window displays – see Figure 56.

Local Admin Authentication

Figure 56: Setting Local Authentication for Admins

5. Provide the user name for a local administrator.
6. Provide a password for that local administrator.
7. Enter a privilege level, 15 (Superuser), 10 (Admin), or 1 (Operator); see the descriptions for each level below.
8. Click OK.

TACACS+ Authentication

Terminal Access Controller Access-Control System Plus (TACACS+) is a remote authentication protocol that runs on a TACACS+ server on the network and is similar to RADIUS authentication. There are some differences between the two, however. RADIUS combines authentication and authorization in one user profile, while TACACS+ separates the two operations. Another difference is that TACACS+ uses TCP port 49 while RADIUS uses UDP port 1812. FortiWLC (SD) supports TACACS+ authentication but not accounting; FortiWLC (SD) supports both RADIUS authentication and accounting. Only the Cisco ACS server is supported for Tacacs+ authentication.

The TACACS+ level required, 15 (superuser), 10 – 14 (admin), and 1 – 9 (user), for the activity on the current GUI window is listed in the Help. Click Help on any GUI window of FortiWLC (SD). In the CLI, all command lists also include the required authentication level, which is also now used for both RADIUS and local admin authentication in Release 5.1. TACACS+ actually provides eight levels, but Fortinet only uses the three authentication levels described here. The three levels used are described below:

1	Operator is the lowest authentication level and also the default. Operators can see statistics and results but cannot make any configuration changes.

TACACS+ Authentication

10

Administrators can also do general configuration changes, but cannot upgrade APs or controllers, nor can they upgrade FortiWLC (SD) versions using Telnet. The cannot configure an NMS server, NTP server, change the system password, date or time (all CLI). They cannot create admin accounts nor can they set the authentication mode for a controller (GUI and CLI). Administrators cannot add or remove licensing.

15

SuperUser administrators can perform all configurations on the controller. They are the only ones who can upgrade APs or controllers and they can upgrade FortiWLC (SD) versions using Telnet. The can configure an NMS server, NTP server, system password, date and time (all CLI). They can also create admins and set the authentication mode for a controller (GUI and CLI). Superusers can add and remove licensing.

Configure TACACS+ Authentication Mode with the CLI

New commands to configure TACACS+ authentication mode for all administrators on a Cisco ACS server were introduced in FortiWLC (SD) 4.1:

• authentication mode global
• primary-tacacs-ip
• primary-tacacs-port
• primary-tacacs-secret
• authentication type tacacs+
• secondary-tacacs-ip
• secondary-tacacs-port
• secondary-tacacs-secret

For command details, see the FortiWLC (SD) Command Reference.

CLI Example for Setting Authentication Mode to TACACS+

ramcntrl(0)# configure terminal ramcntrl(0)(config)# authentication‐mode global ramcntrl(0)(config‐auth‐mode)# authentication‐type tacacs+ ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐

primary‐tacacs‐ip      primary‐tacacs‐port    primary‐tacacs‐secret  ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐ip 172.18.1.5 ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐secret TacacsP ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐

secondary‐tacacs‐ip      secondary‐tacacs‐port    secondary‐tacacs‐secret  ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐ip 172.18.1.10 ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐secret TacacsS ramcntrl(0)(config‐auth‐mode)# exit

TACACS+ Authentication

ramcntrl(0)(config)# exit

ramcntrl(0)# sh authentication‐mode Administrative User Management

AuthenticationType           : tacacs+

Primary RADIUS IP Address    : 172.18.1.3

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 172.18.1.7

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 172.18.1.5

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 172.18.1.10

Secondary TACACS+ Port       : 49 Secondary TACACS+ Secret Key : ***** ramcntrl(0)#

For command details, see the FortiWLC (SD) Command Reference.

Configure TACACS+ Authentication Mode with the Web UI

To configure TACACS+ authentication on a Cisco ACS server for all admins, follow these steps:

1. Click Configuration > User Management.
2. Select the Authentication Type Tacacs+ at the top of the screen.
3. There are three tabs for admin authentication (see Figure 55), RADIUS, Tacacs+ and Local Admins. Click the Tacacs+ tab.

Figure 55: Setting Authentication for Admins

4. Provide the IP address of the primary TACACS+ server.

TACACS+ Authentication

5. Provide a primary TACACS+ port number; the default is 49.
6. Provide the secret key for TACACS+ server access.
7. Optionally repeat steps 4, 5 and 6 for a secondary TACACS+ server.
8. Click OK.
9. Add administrators on the TACACS+ server using these three levels.

1	Operator is the lowest  authentication level and also the default. Operators can see statistics and results but cannot make any configuration changes.
10	Administrators can also do general configuration changes, but cannot upgrade APs or controllers, nor can they upgrade FortiWLC (SD) versions using Telnet. The cannot configure an NMS server, NTP server, change the system password, date or time (all CLI). They cannot create admins nor can they set the authentication mode for a controller (GUI and CLI). Administrators cannot add or remove licensing.
15	SuperUser administrators can perform all configurations on the controller. They are the only ones who can upgrade APs or controllers and they can upgrade FortiWLC (SD) versions using Telnet. The can configure an NMS server, NTP server, system password, date and time (all CLI). They can also create admins and set the authentication mode for a controller (GUI and CLI). Superusers can add and remove licensing.

Remote RADIUS Server

Network deployments with remote sites that are physically away from their head-quarter (or master data center -DC) can use remote RADIUS server in each of the remote sites for local authentication purposes.

In a typical scenario, a RADIUS server is usually co-located in the DC. Remote sites that required AAA services to authenticate their local clients use the RADIUS server in the DC. This in most cases introduces among other issues high latency between the remote site and its DC. Deploying a RADIUS server within a remote site alleviates this problem and allows remotes sites or branches to use their local AAA services (RADIUS) and not rely on the DC.

Remote RADIUS Server

Before you Begin

Points to note before you begin deploying a remote RADIUS server:

1. Ensure that the Controller and site AP communication time is less than RADIUS timeout.
2. Provision for at least one AP that can be configured as a relay AP.
3. Only Fortinet 11ac APs (AP122, AP822, AP832, and OAP832) in L3-mode can be configured as a relay AP.
4. In case of WAN survivability, no new 802.1x radius clients will be able to join, until relay AP rediscovers the controller.

How It Works

This feature provides local authentication (.1x, Captive Profile, and mac-filtering) services using a RADIUS server set up in the remote site. In addition to the RADIUS server, the remote site must also configure a Fortinet 11ac AP as a relay AP.  The remote RADIUS profile can be created per ESS profile using the controller’s WebUI (Configuration > RADIUS) or CLI. A remote RADIUS profile works like a regular profile and can be used as primary and secondary RADIUS auth and accounting servers.

About Relay AP

• The relay AP primarily is used for communicating between the RADIUS server (in the remote site) and the controller in the head-quarters.
• An AP is set as a relay AP only when it is assigned in the RAIDUS profile. Once an AP is assigned as a relay AP It is recommended that you do not overload the relay AP with client WLAN services. This can result in communication issues between the relay AP and DC. For regular client WLAN services, we recommend the use of a different Fortinet access point. For a remote RAIDUS profile, you cannot configure a secondary relay AP. However, for resilience purposes, we recommend configuring an alternate (backup) RADIUS profile and assigning another AP as a relay AP to this backup RAIDUS profile. In the security profile, set this RADIUS profile as the secondary RADIUS server.

Remote RADIUS Server

The following figure illustrates a simple scenario with local RADIUS deployment.

To configure remote RADIUS via WebUI,

In the Configuration > RADIUS > RADIUS Configuration Table – ADD page, set Remote Radius Server to ON (see 1 in Figure 2).

Select the AP (Remote Radius Relay ApId) to be used as the relay AP (see 2 in Figure 2).

Remote RADIUS Server

Configuring Using CLI

# configure terminal

(config)# radius‐profile RemoteRadius

(config‐radius)# remote‐radius‐server on

(config‐radius)# radius‐relay‐apid XXX

XXX is the AP ID of the relay AP in the remote site.

# configure terminal

(config)# radius‐profile RemoteRadius

(config‐radius)# no remote‐radius‐server

# show radius‐profile <remoteRadius‐profile‐name>

EXAMPLE

# show radius‐profile site‐a   

RADIUS Configuration Table                                                       

RADIUS Profile Name      : site‐a          

Description              : Remote radius profile for Site‐A          

RADIUS IP                : 172.18.1.8     RADIUS Secret            : *****         

RADIUS Port              : 1812          

Remote RADIUS Server

Remote Radius Server     : on            

Remote Radius Relay ApId : 2             

MAC Address Delimiter    : hyphen         Password Type            : shared‐secret  

Called‐Station‐ID Type   : default       

Owner                    : controller    

COA                      : on

RADIUS-Based ESS Profile Restriction

This feature gives a controller the capability to restrict wireless clients attempting connection through RADIUS based ESS profiles; the clients can connect only to certain SSIDs as returned in a RADIUS Accept message.

 

With this system, there is one RADIUS server and multiple ESS profiles with 802.1X security using this RADIUS Server. In absence of the RSSID feature, all wireless clients provisioned in the RADIUS Server have access to all ESS profiles and hence all associated VLANS. With SSID restriction, the RADIUS server can be further configured for each of these wireless clients specifying the SSIDs they can connect with.

You can use a RADIUS server to restrict SSID connection using VSA in the RADIUS Accept message. There are three possible conditions for an SSID:

RADIUS Server Sends	Results in:
No list of acceptable SSIDs	Connection is accepted
A list of acceptable SSIDs that includes the ID	Connection is accepted
A list of acceptable SSIDs that does not include the ID	Connection is not accepted

The RADIUS server should return the allowed SSID(s) in a Vendor-specific attribute (VSA) with Vendor code 9 and attribute number 1 in the Access-Accept message. The attribute value should be string format.

The string should say ssid=<ssid-string> where <ssid-string> is replaced by the actual SSID (also known as the ESSID).

If a list of multiple allowed SSIDs is used, put each SSID in a separate instance of the attribute. The order of the attributes does not matter. If the SSID to which the station is trying to connect is not among the SSIDs returned by the RADIUS server, the station will be denied access.This feature has no CLI or Web UI commands associated with it. If the RADIUS responds with a list of allowed SSIDs, the list is used to process and limit the user.