Web Authentication (Cisco Wireless LAN Controllers) Part 1

When a company provides a guest network for outside visitors, it allows those visitors access to the Internet using, usually, a segregated network subnet. This network segregation blocks internal network resources from the visitors but allows them to VPN to their own network, check their email, and so on.

Guest networking implies two things:

■ Web authentication

■ Centralized guest traffic flow

This topic covers the basics of web authentication including how it works, how to configure it, how to troubleshoot it, as well as some features you can implement to fine-tune your visitor network. This topic also discusses how you can centralize the traffic flow from your guest clients using auto-anchoring to help segregate that traffic from your internal wired corporate network.

Web authentication, or web auth, is a Layer 3 security method that allows a client to pass Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) traffic only until they have passed some form of authentication. What makes web auth a great solution for wireless guest access is that no client-side configuration is required for it to work. A guest client needs only to associate to the guest WLAN and get an IP from DHCP. When the client tries to access the Internet, the controller redirects the client to the web authentication page. Here the client will accept a user agreement and, if authentication is configured, enter the correct username and password before being allowed network access.


Web Authentication Policies

A wireless controller has four authentication policies:

■ Authentication

■ Passthrough

■ Conditional Web Redirect

■ Splash Page Web Redirect (added in Release 5.0)

Figure 14-1 shows the authentication polices on the Layer 3 Security tab of the Wireless LANs (WLAN) configuration page.

Web Authentication Policies

Figure 14-1 Web Authentication Policies

Note You can also provide an open guest network with no security. To do this, you simply don’t configure Layer 2 or Layer 3 security on the WLAN. Although this is easy to set up, it does allow any users, whether they are valid visitors or people out on the street, to use your wireless network and Internet access.

When you enable authentication, the controller presents a splash screen like the one in Figure 14-2 that you can configure to display a welcome message, terms of use agreement, or other legalese. The guest client has to enter a username and password to gain access to the guest network. Using authentication prevents someone off the street from using the wireless network of a company and taking up vital bandwidth that was intended for real guest users. The controller can authenticate the users using its local database, an external RADIUS, or Lightweight Directory Access Protocol (LDAP) server.

Generic Web Auth Splash Page

Figure 14-2 Generic Web Auth Splash Page

When using the passthrough policy, the guest client is presented with a splash screen just as with authentication. The difference between the two policies at this point is that clients need only to accept the agreement before gaining network access. Although the clients in this case are not authenticating with a username/password, the controller does not consider the clients authenticated to the network and blocks network access (except DHCP and DNS) until they click on the Submit/Accept button on the splash page. If desired, you can also use Layer 2 security methods in conjunction with web auth. This, of course, requires client-side configuration and can undermine the ease of guest access to visitors because they have to know what type of Layer 2 security to configure. Web auth supports open, open + WEP, and Wi-Fi Protected Access-Pre-Shared Key (WPA-PSK). It does not support 802.1x authentications like Lightweight Extensible Authentication Protocol (LEAP) and Protected Extensible Authentication Protocol (PEAP).

Controller code 4.2.61.0 introduced the Email Input option (see Figure 14-3). With Email Input selected, the guest user is prompted to enter an email address before proceeding. If you have Wireless Control System (WCS), you can run reports to see those email addresses. If you have configured RADIUS accounting on the guest WLAN, the email address entered is logged there as well. Administrators can then send emails to these users thanking them for visiting. You will only see the Email Input option when passthrough is selected.

Email Input Option with Passthrough Authentication

Figure 14-3 Email Input Option with Passthrough Authentication

Note Until controller Release 5.2.157.0, however, the format of the text entered was not verified. This meant a guest user could choose not to enter anything, enter gibberish, or enter colorful messages. Because the description of Email Input indicates that a user must enter an email address before proceeding, some administrators considered this a security violation.A user can still enter bogus information because there is no way to validate the address, but at least it will be in the form of an email address before access is granted.

Cisco added this feature starting in 4.0.206.0 code. Conditional Web Redirect is commonly used by businesses that are selling network access to users. There is now a Conditional Web Redirect policy. When users log into the wireless network from the splash page, a RADIUS server verifies their user credentials. Should certain conditions be met that necessitate another redirect, the client is redirected to a new page. The conditions that facilitate a redirect and the redirect URL are configured on the RADIUS server, not the controller. An example of this is if the user needs to pay a bill and is redirected to a site where it is possible to make that payment to continue having network access. The guest WLAN must have some form of Layer 2 802.1x or WPA and WPAZ security configured for Conditional Web Redirect to function. For more information on the Conditional Redirect feature, please refer to Cisco.com.

With code Release 5.0, another web authentication policy was added, Splash Page Web Redirect. With Splash Page Web Redirect, the user is redirected to a particular web page after successfully completing 802.1X authentication. Once the redirect is complete, the user has full access to the network. You can specify the redirect page on a RADIUS server. If the RADIUS server returns the Cisco AV-pair "url-redirect," then the user is redirected to the specified URL upon opening a browser. Even if the RADIUS server does not return a "url-redirect," the user is considered fully authorized at this point and is allowed to pass traffic. Just like the Conditional Web Redirect policy, Splash Page Web Redirect requires 802.1x or WPA + WPA2 Layer 2 security.

For more information on both Conditional Web Redirect and Splash Page Redirect, please refer to the wireless controller configuration guides at www.cisco.com.

Web Authentication Types

Three types of web authentication exist:

■ Internal: Default web page from the internal web server of the controller.

■ Custom: Customized web page using the internal web server of the controller.

■ External: Uses an external web server to provide a customized splash page.

You can make your selection from the WLC graphical user interface (GUI) under SECURITY > Web Auth > Configuration, as illustrated in Figure 14-4.

Web Authentication Type Configuration

Figure 14-4 Web Authentication Type Configuration

If you want to use the most basic type, choose Internal web auth. Using Internal web auth allows you to hide the Cisco logo, enter a heading up to 127 characters, and enter up to 2047 characters of message text. If you want guest users to be redirected to a particular page after authentication, such as the company website, they can enter that address in the Redirect URL after login section.

Note Keep in mind that the redirect URL applies to all types of web authentication. In older code prior to 4.1.181.0, if you configured External or Custom web auth, the Redirect URL was not visible; the controller would still use that URL if configured.

Custom web auth allows you a lot more flexibility in the web auth splash page appearance. Using a web auth template login.html file, an HTML expert can modify the web auth splash page to include corporate logos, backgrounds, legalese, links to other pages, and so on within the custom web auth bundle. The web auth bundle is a GNU tar file that contains the HTML and GIF files. Custom web auth will be covered in more detail in the "Custom Web Auth Splash Pages" section later in this topic.

If you want to use a network web server instead of the internal web server on the controller to service the web auth splash pages, select External web authentication and enter the address for the external web page. The use of the sample login.html file is required here as well to build the custom page that the network web server will use. Keep in mind that the external web server only provides the web page. The controller is still responsible for authenticating the guest user. The 2000, 2100, and WLCM series controllers have a hardware limitation and require the use of a pre-auth access control list (ACL) for the clients to gain access to the external web server. You would create an ACL on the controller allowing HTTP/HTTPs access to the external web server IP address and then apply that ACL under the Layer 3 Security under the WLAN configuration. Figure 14-3 shows the screen where you can access the Preauthentication ACL configuration drop-down list.

Web Authentication Process

Because web auth takes place at Layer 3, it only occurs after clients complete all Layer 2 authentications (WPA-PSK, static Wired Equivalent Privacy [WEP]), if any.This means that it happens after Layer 2 authentication and after DHCP-Required, but before clients enter the RUN state.

When clients associate to a web auth WLAN, they get an IP address, default gateway, and DNS server from DHCP. Web auth is the only security method on the controller that allows clients to obtain an IP before authentication. After association, if clients open a web browser and try to access a web page, they are redirected to the web auth splash page.

For this process to work, DNS resolution must be allowed on the guest VLAN. When a client browser opens a web page, that page has a friendly name, such as www.cisco.com. To the computer, however, it is really going to IP address 198.133.219.25. The client sends a DNS request and receives the DNS response telling it what IP to use. Without DNS, the client computer has no idea what IP address to send the HTTP GET to in order to pull up the www.cisco.com website. When the web server responds, the controller intercepts that packet and adds a URL redirect to either its own virtual interface IP address or that of the configured external web server so the guest client is presented with the web auth splash page.

The web authentication process is as follows:

Step 1. The client enters the START machine state, completing any Layer 2 security if necessary.

Step 2. After Layer 2 authentication state is complete, the client moves to DHCP-Required (DHCP_REQD).

Step 3. The client receives IP, DNS, and so on from the DHCP server. The client opens the web browser and the PC sends a DNS query. In Figure 14-5 the client queries for webserver.leesdesk.com.

Client DNS Query

Figure 14-5 Client DNS Query

Step 4. The controller forwards the DNS request.

Step 5. The DNS server resolves webserver.leesdesk.com to 192.168.1.10 (see Figure 14-6).

Step 6. The controller forwards the DNS reply.

Step 7. The client sends HTTP GET to the web server, the destination host (see Figure 14-7). The client and the web server in this example are in the same domain, leesdesk.com.

DNS Response

Figure 14-6 DNS Response

Client HTTP GET

Figure 14-7 Client HTTP GET

Step 8. The controller intercepts the returned web page from the destination web server and sends a redirect to its own internal web server address https://VIRTUAL-IP/login.html?redirect to the client. See Figure 14-8.

 Controller Redirect to Virtual IPAdress 1.1.1.1

Figure 14-8 Controller Redirect to Virtual IPAdress 1.1.1.1

Step 9. The client goes to the login page, passes web authentication, and enters the RUN state on the controller.

Step 10. The controller forwards the client browser to the original web page— 192.168.1.10/login.html.

Note In this example the DNS server and the web host happen to be the same server. That is why you see the same IP for both. Under non-lab conditions, these will typically not be the same.

Before 4.0.206.0, a client associated to a web auth-enabled WLAN could sit indefinitely without ever trying to authenticate. Knowing this, an attacker could initiate a denial-of-service (DoS) attack on the guest network by using all the IP addresses in the DHCP scope. To help mitigate this form of attack, Cisco added a web auth timeout. Should a client associate and not authenticate after a 5-minute period, the controller will remove the client. The output of debug client mac-addr indicates when this time is reached:

tmp195-74_thumb

The web auth timeout value is not configurable, and until the 5.0 code release, you could not turn it off. In 5.0 and higher code, you can turn it off, but you must do that from the controller command-line interface (CLI) using the following command:

tmp195-75_thumb

Next post:

Previous post: