Configuring Web-based (Captive Portal) Authentication

[#1]

Hardware and Software Requirements

Must be using vWLAN software 2.4 or later.

Deployment Concerns and Considerations

For the purposes of this document, it is assumed you have already licensed APs and they are online, locations are ACTIVE, and Roles are configured accordingly.   Please see for help getting started with vWLAN.

Introduction

Web-based authentication (captive portal) is an authentication process in which clients typically connect to an open system SSID and are then redirected to a login page or captive portal (after opening a browser). This authentication process requires no client-side configuration, although it can also be used with WPAPSK/WPA2PSK SSIDs, which requires the client to configure the preshared key. This authentication process typically occurs as described in Figure 1 below.

Figure 1.  Client Authentication Process

In the authentication process, clients in the un-registered role are redirected to the secure vWLAN login page (captive portal). The client initially receives an authentication (NAC) IP address (10.254.0.0/14 or whatever the administrator has assigned) with a short lease time from the AP, and then the HTTP request is redirected to https://vWLAN-ip/login.pl. The credentials entered by the client are sent to vWLAN and authenticated against a local user database, external Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, external RADIUS server, or SIP2 library server.  The client is then placed into the proper authenticated role and will receive an IP address on their target location/network and begin to pass traffic.

Web-authenticated traffic is secured using HTTPS, however, subsequent over-the-air traffic is secured based on the SSID configuration. For example, if the SSID is configured for open system, there is no over-the-air encryption. If the SSID is configured for WPAPSK/TKIP, WPA2PSK/AES, WPAPSK+WPA2PSK/TKIP or AES, there is over-the-air encryption. Please note, you cannot achieve 802.11n data rates while using TKIP, but will be limited to legacy data rates only up to 54 Mbps.  This guide will serve as an aid for configuring a basic web-based (Captive Portal) authentication.

NOTE:

The un-registered role is the only role that will allow web redirection. The local database is checked first, then the authentication servers are checked in the order specified by the administrator (set when creating or editing the external server). Some client devices do not transfer automatically to a finalized IP address, but rather keep their assigned NAC IP address, which keeps them from passing traffic. Prior to vWLAN 2.6 release, these devices had to be manually disconnected and reconnected to the vWLAN network. With the included support of Layer 7 Device Fingerprinting in vWLAN 2.6, the BSAPs automatically detect devices that keep their NAC IP address and quickly deauthorize them so that they will automatically reconnect to vWLAN, transition to the final IP address, and begin transmitting data without the need for manual vWLAN administrator intervention.

Step 1. Configuring an SSID

To allow wireless clients to connect to the vWLAN network, each AP domain must have at least one SSID. To configure an SSID, connect to the GUI and follow these steps:

1. Navigate to the Configuration tab, and select Wireless > SSIDs. Here any previously configured SSIDs are listed, and the name, role, broadcast, authentication method, accounting server, and cipher type for each SSID is displayed. You can edit an already configured SSID by selecting the SSID from the list. To create a new SSID, select Create SSID from the bottom of the menu or select Domain SSID from the Create drop-down menu (at the top of the menu).

   

2. Enter a name for the SSID. SSID names can be up to 31 characters in length.

   

3. Next, enable SSID broadcasting by selecting the Broadcast SSID check box.  This is selected be default.

   
   

4. Specify whether the SSID will convert multicast or broadcast network traffic to unicast traffic by selecting the appropriate option from the Convert drop-down menu. You can select to Disable this feature, Convert broadcast to unicast, Convert multicast to unicast, or to Convert broadcast and multicast to unicast.  By default, Convert multicast to unicast is enabled. Multicast transmissions are typically sent from one source to several destinations or to all destinations. From a security standpoint, it is difficult to configure the firewall properly for multicast transmissions between different client types. Converting multicast to unicast allows you to police traffic more efficiently to IP addresses or specific users. In addition, when multicast and broadcast transmissions are sent wirelessly, they use the lowest data rate available, resulting in lower performance than unicast transmissions. If traffic is converted from broadcast or multicast to unicast, it is sent using a higher data rate which improves performance, using less air time. Broadcast traffic must be sent to all clients, and therefore it is sent at the rate of the slowest client. Unicast traffic is sent to a single client, therefore it can be sent at the speed of each client rather than that of the slowest client.  For the purposes of the document, we will illustrate using the default setting.

   NOTE:

   If you do not choose to convert multicast network traffic to unicast traffic, you must allow multicast traffic in the default role of the SSID.  Please see: Enabling Multicast Support for . The default role of an 802.1x SSID is Un-registered. If you do not allow multicast traffic in the SSID’s default role, and you do not choose to convert multicast traffic to unicast traffic in the SSID, then multicast traffic from a unified access host or wireless client on another AP will not be seen.

5. Then specify the authentication method for connecting to the SSID by selecting an option from the Authentication drop-down menu. Authentication choices include: Open System, Shared Key, WPA, WPA-PSK, WPA2, WPA2-PSK, WPA+WPA2, WPA-PSK-WPA2-PSK. For the purposes of this document, we will only focus on Open System.

6. Open System authentication means that there is no client verification when a client attempts to connect to the SSID. With open system, you can choose not to use a cipher for data protection, or you can use wired equivalent privacy (WEP) as your cipher. To select open system as the authentication method for this SSID, without a cipher, select Open System from the Authentication drop-down menu.

7. Once you have selected the authentication, cipher, and preshared key (if necessary) information for the SSID, specify the login form to be associated with the SSID by selecting the appropriate form from the Login Form drop-down menu. By default, each SSID will use the default login form. If you have not created another login form, this will be the only option. You can select another login form if one has been created, or you can choose to use the default form from the AP template.  Next, select the role for clients that connect to this SSID. By default, two roles exist from which to choose: Un-registered and Guest.  You must choose Un-registered to allow clients to authenticate with web-based authentication. If you choose another role, note you will bypass web authentication entirely.

8. Select Create SSID. A confirmation will be displayed indicating the SSID was successfully created.

9. The SSID is now available for editing or deletion, and should be applied to the APs through AP templates.  Once you add the SSID to the AP Template, you will see a Domain Task.  Select Domain Tasks at the top of the GUI to apply the changes to the vWLAN system. This will take you to the Administration tab, Admin Tasks menu, and the Domain tab. Select the play icon next to to Must apply configuration to APs to push the SSID to the AP.
   

Step 2. Configuring External Server Authentication

You can now configure an external RADIUS web-based authentication, LDAP or AD, or Session Initiation Protocol 2 (SIP2) web-based library authentication server for vWLAN authentication. To configure an authentication server for the specified domain, follow the steps for each server type as outlined in the following sections.  Again, the credentials entered by the client are sent to vWLAN and authenticated against a local user database, external Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, external RADIUS server, or SIP2 library server.  The local database is checked first, then the authentication servers are checked in the order specified by the administrator (set when creating or editing the external server).

Configuring Domain Accounting (optional)

RADIUS accounting can be used to notify external systems about user’s usage of the vWLAN system. When a client is authenticated, and joins the vWLAN system, a start request is sent to the accounting server. After a timeout period (when the client leaves the vWLAN system), a stop request is sent to the accounting server. Interim records can also be sent in periodic intervals, so that the external system can track vWLAN users at intervals. This can be helpful in tracking users that stay logged into the system for extended periods of time. To use accounting servers with vWLAN, you must configure the accounting server and then associate the server with one of the methods of authentication; RADIUS 802.1X, RADIUS web, LDAP, or SIP2 authentication servers, or local or MAC authentication. Accounting can also be used for a client that is assigned a default role using an SSID or unified access group by selecting the server in the SSID or unified access group configuration.

When configuring a RADIUS accounting server to use with vWLAN, note that the standard RADIUS accounting attributes apply, as well a vendor-specific attribute under the vendor code (9967).

To configure a RADIUS accounting server in vWLAN, follow these steps:

1. Navigate to the Configuration tab, and select External Authentication > Accounting. Any previously configured accounting servers will be listed in the menu. If you want to edit a previously created accounting server, select the server name from the list. To create a new accounting server, either select Create Accounting Server at the bottom of this menu, or select Domain Accounting Server from the Create drop-down menu (at the top of the menu).
   
2. Enter the name of the server, the server’s IP address, and the port used by the server (1813 by default) in the appropriate fields. Enable the server by selecting the Enabled check box.
3. Enter the shared secret for the accounting server, and the shared secret confirmation, in the appropriate fields.
4. Specify the server timeout value (in seconds), and the number of times vWLAN will attempt to reconnect to the server in the appropriate fields. By default, the timeout value is set to 5 seconds, and the number of retries is set to 5.
5. Enable interim reporting updates by selecting the Interim updates enabled check box. Additionally, specify the interim update interval (in seconds) by entering a value in the appropriate field. By default, the interim update interval is set to 300 seconds.
6. Select Create Accounting Server to create the server. A confirmation is displayed indicating that the server has been created. The server will now appear in the accounting server list (Configuration tab, External Authentication > Accounting), where you can display, edit, or delete the server.

Configuring Local User Authentication

Local user authentication in vWLAN takes precedence over external server authentication and can be used for web-based authentication. Each local user authentication database record consists of the following:

• User status (disabled, enabled)
• User name
• Role
• Number of active sessions
• User password
• Whether and how the user expires

By default, no local users exist in the vWLAN system.

To configure local user authentication for the specified domain, follow these steps:

1. Navigate to the Configuration tab, and select Internal Authentication > Users. Any previously configured internal users will be listed in the menu. If you want to edit a previously created internal user, select the user name from the list. To create a new internal user, either select Create Internal User at the bottom of this menu, or select Domain Internal User from the Create drop-down menu (at the top of the menu).
2. Specify the user’s name and password in the appropriate field, and enable the user by checking the Enabled box. Then specify the user’s role by selecting the appropriate role from the Role drop-down menu. Optionally, select an accounting server to associate with this user from the Accounting Server drop-down menu. Next, specify how many users of the same name can be logged in simultaneously by entering a value in the appropriate field. If you specify 0, there is no limit to how many users with the same name can be logged in simultaneously. Lastly, you can specify that the user account does not expire by selecting the Never expire check box.
3. Select Create Internal User. A confirmation is displayed indicating that the user has been created. The user will now appear in the internal user list (Configuration tab, Internal Authentication > Users), where you can display, edit, or delete the user.
4. Once users have been created, the local user database will be used as the primary web-based authentication method for connecting to vWLAN.

External RADIUS Web-based Authentication Server

To configure a RADIUS web-based authentication server for use with vWLAN, follow the steps outlined below.  For more on configuring a Windows Server for Authentication, see: vWLAN External RADIUS-802.1X Authentication.

1. Navigate to the Configuration tab, and select External Authentication > Servers. Any previously configured web-based authentication servers will be listed in the menu. If you want to edit a previously created web-based authentication server, select the server name from the list. To create a new authentication server, either select Create Authentication Server at the bottom of this menu, or select Domain Authentication Server from the Create drop-down menu (at the top of the menu).
2. Select RadiusWebAuthServer from the Type drop-down menu.
3. Next, enter the name of the server and its IP address in the appropriate fields. Optionally, specify if this authentication server will be associated with an accounting server by selecting the accounting server from the Accounting Server drop-down menu.
4. Next, specify the port to be used by the server. If you are using a RADIUS server, the port is generally either 1645 or 1812.
5. Next, enter the shared secret or password for the authentication server.  Specify the timeout weight, maximum number of simultaneous user authentications, and the precedence of the server.
6. The timeout weight value is relative to the timeout weight of other authentication servers. The total time allocated to authenticate is defined for the entire vWLAN system. Each server’s timeout is computed as a percentage of the total weight of all authentication servers on this domain. If you leave the maximum number of simultaneous authentications field blank, or enter a 0, that indicates there is no limit. You can specify the precedence level of the server as Highest, Lowest, or Fixed. If you select Fixed, you can manually order the authentication servers in order of precedence.
7. Next, you must specify the authentication rules for the server and the role given to a user who does not meet the authentication rules. Select the role from the Role drop-down menu. This is the Role in which all authenticated clients will be placed if successfully authenticated and DO NOT match any of the configured attributes (next step).  If you choose Un-registered from the drop-down menu, clients will never transition out of the Un-registered Role unless their successful authentication matches an attribute configured in the next step.
8. Next, select the appropriate attribute from the Authentication Rules drop-down menu and then specify the logic type used for authentication mapping from the drop-down menu. You can select from equal to, not equal to, starts with, ends with, and contains. Then, fill in the appropriate value in the next field, and select the appropriate role from the drop-down menu. In the example below, a RADIUS 1x server is configured to use a User Name attribute, that contains the value ann jenkins, which assigns the user the role of Guest.  Attributes are searched in a top-down order. You can move these attributes in any order you want or add additional rules by selecting Append Auth Rules. You can also remove an attribute by using the Trash Can icon.
9. Lastly, select Create Auth Server. A confirmation is displayed indicating that the server has been created. The server will now appear in the server list (Configuration tab, External Authentication > Servers), where you can display, edit, or delete the server.

NOTE
External RADIUS web-based authentication uses PAP and requires a RADIUS client to be configured in the RADIUS server for the vWLAN instance.

External LDAP Web-based Authentication Server

To configure an LDAP authentication server for use with vWLAN, follow these steps:

1. Navigate to the Configuration tab, and select External Authentication > Servers. Any previously configured LDAP authentication servers will be listed in the menu. If you want to edit a previously created LDAP authentication server, select the server name from the list. To create a new authentication server, either select Create Authentication Server at the bottom of this menu, or select Domain Authentication Server from the Create drop-down menu (at the top of the menu).
2. In the New Authentication Server menu, select LdapAuthServer from the Type drop-down menu.
3. Enter the name of the server and its IP address in the appropriate fields. Optionally, specify if this authentication server will be associated with an accounting server by selecting the account server from the Accounting Server drop-down menu.
4. Specify the port to be used by the server. If you are using an LDAP server, the port is generally 389, unless Secure Socket Layer (SSL) is used, in which case the port is generally 636.
5. Specify the name of the administrator user to which to bind the LDAP server. Enter the administrator’s FQDN in the LDAP Bind User field.
   

   NOTE
   It is not recommended to use an administrative account. Using a standard account is sufficient. The entered account must match the user account configured in LDAP or AD.

   1. The LDAP user field should be populated with the full name of the user, not the login name in AD. For example, use Bob Smith, not BSmith. All the name parts are used and added to each other to compose the full name. The resulting user name when using Bob and Smith as the first and last names respectively in AD is Bob Smith. Unless the LDAP user is in the root of AD, and the base entry specifies the root, you must specify where it is. This is referred to as the distinguished name. For example, if Bob Smith is in the users container, you would enter CN=Bob Smith,CN=Users,DC=Bluesocket,DC=com in the LDAP user field, where the first CN refers to common name, and the second CN refers to container.
   2. If Bob Smith was in the root of AD, and the base entry specified the root, you could simply enter Bob Smith.  Make sure you do not confuse CNs (containers) with OUs (organizational units). OUs have an icon in AD that could be described as a folder in a folder, while CNs have an icon in AD that could be described as a folder. Built-in folders in AD are typically CNs, while folders you add are typically OUs. Right-click the folder in AD, select properties, select the object tab, and refer to the object class to be certain you are using CN or OU. For example, if Bob Smith is in the Engineers OU, enter the following in the LDAP user field: CN=BobSmith,OU=Engineers,DC=Bluesocket,DC=com. CN refers to Common Name, and OU refers to Organizational Unit. Work from the bottom of the AD tree upwards. For example, if Bob Smith is in the Tech Support OU, which is in the Engineers OU, enter the following into the LDAP User field: CN=Bob Smith,OU=Techsupport,OU=Engineers,DC=Bluesocket,DC=com. CN refers to Common Name, and OU refers to Organizational Unit.
6. Enter the shared secret or password for the previously created bind user.
   
   
7. Configure the LDAP base entry, unique ID attribute, and any LDAP filters. The LDAP Base Entry field specifies the starting point for LDAP database queries, and the LDAP Unique ID attribute field specifies the unique identifier used to distinguish each user record within the database. LDAP filters are additional filters used when looking up LDAP unique ID attributes.  Next, you can configure the system to bind all queries with the LDAP Bind User’s credentials by checking the box next to Bind all Queries as LDAP Bind User. If this option is not selected, then Anonymous Authentication will be used and the external LDAP/AD server must be configured to allow anonymous binding.
   
   
   1. The LDAP Base Entry should be populated with the location with which vWLAN should start to search for users in the LDAP or AD tree. For example, if all the users are in the Users container, then the base entry should be populated with CN=Users,DC=Bluesocket,DC=com. If the users are scattered about AD in different containers or organizational units, you can simply specify the root by entering DC=Bluesocket,DC=com.
   2. The LDAP Unique ID attribute field specifies the unique ID attribute that identifies and distinguishes each user record in LDAP or AD. The unique ID attribute for AD is sAMAccountName.
8. Configure the timeout weight, maximum number of simultaneous user authentications, server precedence, and whether SSL is used. The timeout weight is the value relative to the timeout weight of other authentication servers. The total time allocated to authenticate is defined for the entire vWLAN system. Each server’s timeout is computed as a percentage of the total weight of all authentication servers on this domain. Leaving the maximum number of simultaneous authentications field blank, or entering a 0, indicates there is no limit. You can specify the precedence level of the server as Highest, Lowest, or Fixed. If you select Fixed, you can manually order the authentication servers in order of precedence. If required, enable SSL by selecting the Require SSL check box.
9. Next, you must specify the authentication rules for the server and the role given to a user who does not meet the authentication rules. Select the role from the Role drop-down menu. This is the Role in which all authenticated clients will be placed if successfully authenticated and DO NOT match any of the configured attributes (next step).  If you choose Un-registered from the drop-down menu, clients will never transition out of the Un-registered Role unless their successful authentication matches an attribute configured in the next step.
10. The authentication rules specify to which role users are assigned when they are authenticated. Manually enter the type of attribute to use in the authentication rules (for example, distinguishedname).  Next, specify the logic type used for authentication mapping from the drop-down menu (this applies to all servers). You can select from equal to, not equal to, starts with, ends with, and contains. Then fill in the appropriate value in the next field, and select the appropriate role from the drop-down menu. In the example below, an LDAP server is configured to use a distinguishedname attribute, that contains the value Faculty, which assigns the user the role of Guest. 
11. Attributes are searched in a top-down order. You can move these attributes in any order you want or add additional rules by selecting Append New Auth Rule. You can also remove an attribute by using the trash can icon.
12. Lastly, select Create Authentication Server. A confirmation is displayed indicating that the server has been created. The server will now appear in the server list (Configuration tab, External Authentication > Servers), where you can display, edit, or delete the server.

External SIP2 Web-based Library Authentication Server

To configure a SIP2 authentication server (typically used in libraries) for user authentication, follow these steps:

1. Navigate to the Configuration tab, and select External Authentication > Servers. Any previously configured SIP2 authentication servers will be listed in the menu. If you want to edit a previously created SIP2 authentication server, select the server name from the list. To create a new authentication server, either select Create Authentication Server at the bottom of this menu, or select Domain Authentication Server from the Create drop-down menu (at the top of the menu).
2. Select SIP2AuthServer from the Type drop-down menu.
3. Enter the name of the server and its IP address in the appropriate fields. Optionally, specify if this authentication server will be associated with an accounting server by selecting the account server from the Accounting Server drop-down menu.
4. Specify the port to be used by the server. If you are using a SIP2 server, the port is generally 6001.
5. Optionally, specify the name of the administrator user to which to bind the SIP2 server. Enter the administrator’s FQDN in the SIP2 Admin Name field.

   NOTE
   The administrator and password for the SIP2 server are optional. If no administrator or password is set, then the SIP2 authentication occurs without them. However, if an administrator is specified, a password must also be specified for authentication to occur.

6. Optionally, enter the shared secret or password for the authentication server.
7. Specify the timeout weight for the server. This value is relative to the timeout weight of other authentication servers. The total time allocated to authenticate is defined for the entire vWLAN system. Each server’s timeout is computed as a percentage of the total weight of all authentication servers in this domain (the platform setting of Timeout Value for Web Server determines the total timeout that is divided based on weight).
8. Specify whether the user’s PIN or password will be validated by selecting the SIP2 Validate PIN/Password check box.
9. Specify whether an empty AO institution ID is specified when communicating with the server by selecting the SIP2 Specify an empty AO Institution ID check box.
10. Specify whether a CP location code is sent to the server, and what CP location code is sent, by entering the code in the SIP2 CP Location Code field. Leave this field blank if you do not want a CP location code in the login message.
11. Configure the maximum number of simultaneous users allowed to authenticate and the server precedence. Leaving the maximum number of simultaneous authentications field blank, or entering a 0, indicates there is no limit. You can then specify the precedence level of the server as Highest, Lowest, or Fixed. If you select Fixed, you can manually order the authentication servers in order of precedence.
12. Next, you must specify the authentication rules for the server and the role given to a user who does not meet the authentication rules. Specify a role by selecting the appropriate option from the Role drop-down menu. T This is the Role in which all authenticated clients will be placed if successfully authenticated and DO NOT match any of the configured attributes (next step).  If you choose Un-registered from the drop-down menu, clients will never transition out of the Un-registered Role unless their successful authentication matches an attribute configured in the next step.
13. Next, manually enter the type of attribute to use in the authentication rules (for example, attribute=PC: profile, logic=contains, value=Adult, and role=Adult).  Specify the logic type used for authentication mapping from the drop-down menu (this applies to all servers). You can select from equal to, not equal to, starts with, ends with, and contains. Then, fill in the appropriate value in the next field, and select the appropriate role from the drop-down menu. In the example below, a SIP2 server is configured to use a PC:profile attribute, that contains the value Adult, which assigns the user the role of Architecture Faculty. Attributes are searched in order. You can move these attributes in any order you want or add additional rules by selecting Append New Auth Rule. You can also remove an attribute by using the trash can icon.
14. Lastly, select Create Auth Server. A confirmation is displayed indicating that the server has been created. The server will now appear in the server list (Configuration tab, External Authentication > Servers), where you can display, edit, or delete the server.

Step 3. Enabling Redirect to Hostname and CNA Support (optional)

The Redirect to hostname option requires both a forward (A record) and a reverse pointer (PTR record) in your organization’s DNS server for the public network interface and the fully qualified domain name (FQDN) of the vWLAN. The vWLAN and APs query the PTR record and redirect traffic based on the response. If there is no PTR record, clients are redirected to an IP address (rather than a host name). This action can result in the receipt of a web browser security warning indicating a domain name mismatch. Clients use the A record to resolve the host name of vWLAN to an IP address.

To enable Redirect to hostname:

1. In vWLAN, navigate to the Configuration tab, select System > Settings, and select Platform. In this menu, scroll to and select the Redirect to hostname setting. This will allow you to enable host name redirection.  Select Enabled from the drop-down menu. This will redirect users to the host name (rather than the public network interface IP address). Select Update Platform Settings. 
2. After updating the settings, you will see a Platform Task.  Select Platform Tasks at the top of the GUI to apply the changes to the vWLAN system. This will take you to the Administration tab, Admin Tasks menu, and the Platform tab. Select the play icon next to Must restart User Web Server to restart the web server. Clients will not be able to access captive portal momentarily, but clients who are already connected will not be disconnected.
   
   
3. By default, an AP looks up the vWLAN name using a DNS pointer record (PTR) when redirecting clients to a host name for authentication. This setting must be enabled when Redirect to a hostname is enabled.  To disable this setting, navigate to the Configuration tab, select System > Settings, and select Domain. In this menu, select Allow the AP to look up the vWLAN name using a DNS PTR record from the list and select Disabled from the drop-down menu. Select Update Domain Setting to apply the change.
   1. If you change this setting you will see a Domain Task.  Select Domain Tasks at the top of the GUI to apply the changes to the vWLAN system. This will take you to the Administration tab, Admin Tasks menu, and the Domain tab. Select the play icon next to to Must apply configuration to APs to push the change to the AP.
      
      
      
4. By default, vWLAN uses a preinstalled self-signed SSL certificate to encrypt web-based login transactions. The vWLAN uses the SSL certificate when clients connect to the captive portal (which uses HTTPS), or when administrators connect to the vWLAN GUI (which also uses HTTPS). In both cases, when using the default Bluesocket self-signed SSL certificate, users can receive a certificate error from the web browser indicating the certificate was not issued by a trusted CA. This happens because the Bluesocket self-signed certificate is not in the browser’s list of trusted root certificate authorities and Bluesocket is not a CA. These errors can be avoided by either installing the self-signed certificate on each client in the browser’s list of trusted root CAs, or by installing an SSL certificate (provided by a CA, such as VeriSign that matches the FQDN created on your organization's DNS server) on vWLAN that is already in the client’s list of trusted root CAs.  To install SSL certificates on vWLAN, follow these steps: Install and Renew SSL Cert .

As part of the AP template (Configuration tab, Wireless > AP Templates), the administrator can optionally choose to enable or disable Captive Network Assistant (CNA). This option allows remote devices to store the credentials to networks requiring captive portal authentication so they do no have to be entered in manually every time they authenticate or re-authenticate to the network. By default, CNA is enabled on the AP template.  When CNA is enabled, vWLAN responds to the device’s CNA request with a redirection request to the vWLAN captive portal. The CNA device receives the redirection and detects that there is a captive portal in place. It then presents the CNA automatically and prompts the user to enter their credentials in the vWLAN login page. If CNA is disabled, the device will connect using a web request which redirects to vWLAN captive portal. For Microsoft NCSI, an information popup appears at the bottom right corner of the computer suggesting the user open a web browser to authenticate.  For CNA to function properly, however, there are additional configuration steps that are necessary. A custom certificate must be loaded on vWLAN because CNA has no method to allow the user that is accessing the network to accept the certificate. In addition, vWLAN must be configured to redirect to a host name, and a DNS server and hostname may need to be configured.

Step 4. HTTPS redirection (optional)

vWLAN supports redirection of HTTP and HTTPS traffic for webpage authentication. HTTPS redirection is optional and must be enabled on the vWLAN,  when needed to resource consumption.  By default, un-registered clients’ HTTPS traffic is not redirected. For example, a user with the home page set to a secure HTTPS banking page will not be redirected when this feature is disabled. To enable the redirection of HTTPS traffic for un-registered users, navigate to the Configuration tab, select System > Settings, and Domain.  In the menu, select Redirect HTTPS traffic for Unregistered clients from the list, and select Enable from the drop-down menu. Enabling this feature redirects HTTPS traffic to the captive portal. Select Update Domain setting to apply the change.  If you change this setting you will see a Domain Task.  Select Domain Tasks at the top of the GUI to apply the changes to the vWLAN system. This will take you to the Administration tab, Admin Tasks menu, and the Domain tab. Select the play icon next to to Must apply configuration to APs to push the change to the AP.

Testing

1. You should now be able to associate a client to your previously created SSID.  The client should receive an authentication (NAC) IP address (10.254.0.0/14 by default).
2. Open a web browser on the client and try to browse to an HTTP site (not in cache).  The client should query DNS, and then make an HTTP Get.  The AP will be monitoring for HTTP traffic and will intercept the client's HTTP Get and will redirect the client to the vWLAN: https://vWLAN-ip/login.pl.  The client should then be presented with the web page to log into the network (You may be presented with an SSL certificate warning before being presented with the web page depending on how you configured vWLAN in the steps above.)  The client should be presented with something similar to the following:
3. The client should now be able to login with the username and password which is authenticated against a local user database, external Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, external RADIUS server, or SIP2 library server. The local database is checked first, then the authentication servers are checked in the order specified by the administrator. (The Guests box in yellow illustrated above only requires an email address for log in.  This box can be removed from the Captive Portal Form by unchecking Allow Guest Logins).

Common Problems

1. Logs
   1. The vWLAN log includes the service it is associated with, the function monitored by the log, the type of log message, the message itself, the level associated with the log, and the time the log was created.  To view logs, navigate to the Status tab, Logs menu.  A failed login will look as follows:

      Created Time	Service	Function	Operation	Message	Level
      2016-05-18 09:32:27	user	login	failed	Login user Bsmith at [e8:50:8b:e1:26:90]/10.253.143.2 has failed.	ERRORS
      2016-05-18 09:31:55	defaultssid	auth	successful	User e8:50:8b:e1:26:90 successfully authenticated to SSID OpenSSID	INFORMATION
2. Client is not redirected:
   1. The client must be able to resolve DNS in order to be redirected to the login page. From a cmd prompt of a client try pinging or performing an nslookup for www.adtran.com  to see if the fully qualified domain name resolves to an IP address.  If redirecting to hostname, make sure the client is able to resolve DNS both the forward (A record) and a reverse pointer (PTR record).  By default the vWLAN allows DNS in the un-registered role to the DNS servers that the client is given. Also by default, (while in the un-registered role), clients are given whatever DNS servers are assigned to the AP.  Check to make sure DNS servers are assigned to the AP. Alternatively, you can configure DNS servers under Configuration > Wireless > AP Templates which will take precedence for the client, meaning the client will obtain the DNS server in the AP template and not the DNS server the AP has itself.  You should also be able to see this in an AP Traffic Capture taken from the NAC interface (the interface responsible for Un-registered users). If you are using the apdiscovery hostname for AP discovery, only an A record is required (delete the PTR record).
   2. Check to see if client is trying to go to an HTTP web page rather than HTTPS page.
      1. By default the AP only monitors HTTP requests from clients in the un-registered role. If the client's home page is set to an HTTPS page, it will not be redirect by default.  Have the client browse to an HTTP page or alternatively, enable Redirect HTTPS traffic for Unregistered under Configuration > System > Settings > Domain.  This should only be enabled when needed due to extra resource consumption.
   3. Ensure the "Allow the AP to look up the vWLAN name using a DNS PTR record" and the "Redirect to hostname" options are either both enabled (for redirect to hostname), or both disabled (redirect to IP).
3. Client receives an SSL warning:
   1. Allow HTTP access to the OCSP and CRL URLs of your SSL certificate in the Un-registered role as demonstrated here: Install and Renew SSL Cert .
4. Cannot login to the splash page:
   1. All web authentication requests are sent directly from the vWLAN (public interface) to the authentication server.  Taking a vWLAN Traffic Capture (on the Public interface) filtered on the port used for authentication will show the authentication processes.  For example, if using LDAP, you should see the bind user establish a connection with the server, complete the lookup for the user, and grant them access if found.  You should be able to see that in the vWLAN traffic capture (if not using SSL-LDAP) vWLAN and BSAP Traffic Capture Guide.
   2. If using LDAP or AD, ensure the LDAP Bind user is checked in the external server.

Useful Links

• Install and Renew SSL Cert .
• HTML Differences in
• ‌
• vWLAN External RADIUS-802.1X Authentication