Web Authentication - Implementing Secure Network Access - CCNP Security SISAS 300-208 Official Cert Guide (2015)

CCNP Security SISAS 300-208 Official Cert Guide (2015)

Part IV: Implementing Secure Network Access

Chapter 13. Web Authentication

This chapter covers the following exam topics:

Image Implement Wired/Wireless 802.1X

Image AV Pairs

Image Implement MAB

Image Implement Network Authorization Enforcement

Image Troubleshooting, Monitoring, and Reporting Tools

Image Implement Central Web Authentication (CWA)

Image Describe the Function of CoA to Support Web Authentication

Image Configure Authentication Policy to Facilitate CWA

Image URL Redirect Policy

Image Redirect ACL

Image Customize Web Portal

Image Verify Central Web Authentication Operation

As discussed in Chapter 5, “Non-802.1X Authentications,” just because there is no configured supplicant on an endpoint does not mean that the user of that endpoint does not need to authenticate. Consider the use cases of guests or visitors, or maybe just a misconfiguration or expired credential for the end user. Based on who the user is, they still might require network access and be granted access to the network.

Enter web authentication, commonly referred to as just WebAuth. An authenticator would be able to send a user to a locally hosted web page—in other words, a web page hosted on the local device itself: the switch, wireless controller, or even the firewall or VPN concentrator. It is a simple thing, really, just a very basic web page where a user can submit his username and password.

Chapter 5 also discussed the multiple types of WebAuth and that Centralized WebAuth (CWA) is the type used with Cisco Secure Access and ISE. CWA is the focus of the exam and therefore the main focus of this book.


Note

The content of this chapter is written with the assumption that the switches and wireless LAN controllers (WLCs) have been configured as defined in Chapter 12, “Implement Wired and Wireless Authentication.” If you have not already configured your network devices for authentication, none of the configuration in this chapter will work, and you should revisit Chapter 12.


“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 13-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Image

Table 13-1 “Do I Know This Already?” Section-to-Question Mapping


Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.


1. Before a Cisco switch will generate a self-signed certificate, which configuration is required?

a. The internal CA must be enabled.

b. An IPv6 address.

c. A Cisco switch cannot generate a self-signed certificate.

d. A domain name.

2. True or False? The URL redirection ACL can be downloaded from ISE to the NAD.

a. True

b. False

3. Which of the following settings is required for a WLAN to support CWA on the Cisco WLC?

a. SNMP NAC

b. Layer-3 Authentication

c. RADIUS NAC

d. Fast Transition

4. For wired and wireless MAB, which option must be configured for unknown identities?

a. Drop

b. Continue

c. Reject

d. Pass

5. Which of the following rule types need to be created for CWA? (Choose two.)

a. A WebAuth authentication rule must be created for the authentication through the web portal.

b. An authorization rule must be created that redirects the user to the CWA portal.

c. An authentication rule must be created that permits access to users who have successfully authorized through the CWA portal.

d. An authorization rule must be created that permits access to users who have successfully authenticated through the CWA portal.

e. A WebAuth authentication rule must be created that redirects the end user to the CWA portal.

6. Which of the following capabilities exists for MyDevices portals in ISE 1.2 but not the Device-Registration portal?

a. MyDevices provide a portal for the end user to manage his endpoints.

b. MyDevices provides the ability to automatically populate the MAC address of the endpoint.

c. MyDevices did not exist in ISE version 1.2.

d. MyDevices is linked to the MDM and has the knowledge of which device belongs to a user.

7. True or False? CWA and DRW are using the same RADIUS attributes; the difference is in the actual URL sent down to the NAD.

a. True

b. False

8. Which command on the NAD will display information about the URL-redirected session, including the MAC address, IP address, dACL, URL-redirect ACL, and the URL to which the end user is being redirected?

a. show epm redirection

b. show authentication sessions

c. show epm authentication | include redirection

d. show authentication session interface [interface-name]

9. Which of the following locations within the ISE GUI should you examine to validate that CWA is working? (Choose the best answer.)

a. Policy > Policy Elements > Results > Authorization

b. Operations > Authentications

c. Policy > Policy Elements > Results > Authentication

d. Operations > Results

10. Which of the following statements most accurately describes the use of change of authorization (CoA) in relation to CWA?

a. The CoA-Reauth causes the NAD to reauthenticate the endpoint within the same session, and ISE is then able to tie the MAB and CWA authentications together.

b. The CoA sends a packet of disconnect (PoD) to the NAD, which starts a new session based on the web credentials.

c. The CoA-Reauth causes the NAD to reauthenticate the endpoint, which starts a new session based on the web credentials.

d. The CoA sends a packet of disconnect (PoD) to the NAD. ISE is then able to tie the original MAB session to the new web-authenticated session by correlating the MAC addresses from both authentication sessions.

Foundation Topics

Web Authentication Scenarios

There are a number of reasons a company might choose to implement a WebAuth strategy. One of the most common reasons is to provide Internet access to visitors (also caled guests), which is detailed in Chapter 14, “Deploying Guest Services.” Additionally, as newer versions of ISE are released, many companies are looking to add an interactive login to capture a user’s username and password, as an additional credential to a certificate-based authentication. Think: two-factor authentication.

The end user is presented with a web portal to input his username and password. The credentials are then sent from the authenticator to ISE in a standard RADIUS Access-Request packet. So, in a similar fashion to what occurs with MAC address bypass (MAB), the switch is sending the request for the endpoint, because the endpoint itself is not participating in authentication. Figure 13-1 illustrates the WebAuth concept.

Image

Figure 13-1 Web authentication.

The credential that gets submitted through the WebAuth page could be Active Directory credentials of an employee. The credentials could be guest credentials for someone who is only temporarily allowed to have Internet access and no other access. The use of WebAuth is really not limited to any specific identity type.

Keep in mind that WebAuth is an effective authentication method only for a device that has an interactive user. In other words, it would not make sense to try to use WebAuth for a printer. There is no user to interact with the web portal, enter her credentials, and then click Submit.

As with MAB, WebAuth is not a standard either. There are multiple ways to perform WebAuth, with benefits and downsides to each one.

Local Web Authentication

Local web authentication (LWA) is the original WebAuth. The authenticator will redirect web browser traffic to a locally hosted web portal where a user can enter her username and password.

Image

The credentials are submitted through the switch, or the wireless controller sends the RADIUS Access-Request to the authentication server, using the username and password from the web portal’s form. It is key to remember that any time the switch is sending the credentials for the user, it is considered local web authentication.

On a Cisco switch, the locally hosted web pages are minimally customizable. Many companies require that the web portals be customized to match the corporate branding. For those companies, traditional LWA is not usually an acceptable solution—at least not for WebAuth with wired connections.

Additionally, when using LWA with Cisco switches, no native support exists for advanced services, including:

Image Acceptable Use Policy acceptance pages

Image Client provisioning

Image Password changing capabilities

Image Self-registration

Image Device registration

For those advanced capabilities, a company truly needs to consider using centralized web authentication (CWA). For more details on LWA, see Chapter 5.

Centralized Web Authentication

CWA is what Cisco ISE uses throughout the Secure Access solution. Although Cisco ISE is still capable of supporting LWA methods, those methods are typically reserved for non-Cisco network devices.

As with all web authentications, CWA is only for interactive users who have a web browser, where the user will manually enter the username and password.

Change of authorization (CoA) works fully with CWA, which leads to the support for all the authorization results, such as ACL and VLAN authorization. Keep in mind that any time you change virtual local area networks (VLANs) on an endpoint, the endpoint must be able to detect the VLAN change and trigger an IP address renewal. With 802.1X, the supplicant takes care of the VLAN change detection and address renewal. However, when using CWA there normally is no supplicant on the endpoint. Therefore, the DHCP scope length on the initial subnet must be set to renew the address quickly or the portal must use an ActiveX or Java applet to handle the renewal of the IP address after the VLAN assignment.

CWA also supports all the advanced services, such as these:

Image Client provisioning

Image Posture assessments

Image Acceptable use policies (AUPs)

Image Password changing

Image Self-registration

Image Device registration

Image

As described in Chapter 5, the switch or wireless controller sees only a MAB, and the rest is handled on the authentication server (ISE). Figure 13-2 shows the MAB occurring with a redirection to the centralized portal, and Figure 13-3 illustrates that the switch still sees only a MAB request while ISE is maintaining the user authentication.

Image

Figure 13-2 URL-redirected MAB.

Image

Figure 13-3 The credentials are never sent to the authenticator.

The following steps detail what is occurring in Figures 13-2 and 13-3:

Step 1. The endpoint entering the network does not have a supplicant.

Step 2. The authenticator performs a MAB, sending the RADIUS Access-Request to Cisco ISE (the authentication server).

Step 3. The authentication server (ISE) sends the RADIUS result including a URL-Redirection to the centralized portal on the ISE server itself.

Step 4. The end user enters his credentials into the centralized portal. Unlike the LWA options, the credentials are never sent to the switch; they are stored within the ISE session directory and tied together with the MAB coming from the switch.

Step 5. ISE sends a reauthentication change of authorization (CoA-reauth) to the switch. This causes the switch to send a new MAB request with the same SessionID to ISE, which is processed.

Step 6. ISE sends the final authorization result to the switch for the end user.

CWA and the URL-Redirection capability in the switches and wireless devices is the basis for many of the other solutions within ISE, including device registration WebAuth, BYOD onboarding, MDM onboarding, posture assessments, and much more.

Device Registration WebAuth

Device registration WebAuth (DRW) is a special form of WebAuth. Beginning with ISE 1.0 and continuing until ISE 1.2.x (which this exam is focused on), this special WebAuth was used to allow an interactive user to add her MAC address to an Endpoint Identity Group. An authorization rule that permits members of that Endpoint Identity Group to have network access (hopefully limited network access because this is not a strong method of authentication) is required.

Image

It is important as both an implementer of ISE and a taker of this exam to understand the difference between DRW and the BYOD portal known as MyDevices. Both portals allow an interactive user to add her MAC address to the system. However, a device that is authorized via the DRW portal uses a base license, whereas a MyDevices endpoint uses an advanced license.

License consumption is not the only difference between the two processes. Table 13-2 displays a comparison of the DRW and MyDevices functions.

Image

Table 13-2 Comparison of DRW and MyDevices

The MyDevices portal and BYOD processes are covered in much more detail in Chapter 17, “Bring Your Own Device.”

Configuring Centralized Web Authentication

Multiple devices will require configuration to enable CWA. The network access device (NAD) requires some special configuration, such as a redirection ACL, and ISE will need authentication and authorization rules set up for CWA as well.

Let’s start with the NADs.

Cisco Switch Configuration

Within Cisco’s Secure Access system, the switch performs the URL redirection for web authentication as well as redirecting the discovery traffic from the posture agent to the ISE policy service node (PSN).

Performing URL redirection at the Layer-2 access (edge) device is a vast improvement over previous NAC solutions that required an appliance (such as the inline posture node) to capture web traffic and perform redirection to a web authentication page, simplifying the deployment for both web authentication and the posture agent discovery process.

Configuring Certificates on the Switch

To redirect HTTPS traffic, the switch must already have its own certificate.

Cisco IOS does not enable certificates, or even self-generated keys, to be created and installed without first defining a DNS domain name on the device.

From Global Configuration mode on the switch, do the following:

Step 1. Set the DNS domain name on the switch; type ip domain-name domain-name at the global configuration prompt. Now that the domain name is configured, the keys can be generated.

Step 2. Generate keys to be used for HTTPS; type crypto key generate rsa general-keys mod 2048 at the Global Configuration prompt.

Enabling the Switch HTTP/HTTPS Server

The embedded HTTP/S server in IOS will be used to grab HTTP traffic from the user and redirect that user’s browser to the CWA portal, a device registration portal, or even the Mobile Device Management onboarding portal. This same function is used for redirecting the posture agent’s traffic to the PSN:

Step 1. Enable the HTTP server in Global Configuration mode:

C3560X(config)# ip http server

Step 2. Enable the HTTP secure server:

C3560X(config)# ip http secure-server

Many organizations will want to ensure this redirection process that is using the switch’s internal HTTP server is decoupled from the management of the switch itself. This can be accomplished by running the commands listed in Step 3, from Global Configuration mode:

Step 3. Disconnect the HTTP management process from the URL-Redirection process:

C3560X(config)# ip http active-session-modules none
C3560X(config)# ip http secure-active-session-modules none

Verifying the URL-Redirection ACL

In Chapter 12, you created an Access List named ACL-WEBAUTH-REDIRECT. This list is used to determine what traffic is redirected to the CWA portal with the permit statement. Any traffic that is denied will not be redirected.

Image

Contrary to the way a WLC works, the URL-redirection ACL on a switch is used only to determine which traffic is redirected and which is not. If network traffic is denied from redirection, that does not deny it from traversing the network. The traffic-filtering capability will come from the downloadable ACL (dACL) that is sent down from ISE as part of the authorization result.

The use of dual ACLs is limited to IOS-based wired and wireless devices. The AirespaceOS wireless controllers behave differently and are covered in the WLC configuration within this chapter:

Step 1. Validate whether the ACL-WEBAUTH-REDIRECT ACL is configured on the NAD:

C3560X# show ip access-list ACL-WEBAUTH-REDIRECT
Extended IP access list ACL-WEBAUTH-REDIRECT
10 deny udp any any eq domain
20 permit tcp any any eq www
30 permit tcp any any eq 443

If the ACL is not there or needs to be modified, follow Step 2.

Step 2. Add the following ACL to be used for URL redirection with web authentication:

C3560X(config)#ip access-list ext ACL-WEBAUTH-REDIRECT
C3560X(config-ext-nacl)#remark explicitly deny DNS from being
redirected to address a bug
C3560X(config-ext-nacl)#deny udp any any eq 53
C3560X(config-ext-nacl)#remark redirect all applicable traffic to the
ISE Server
C3560X(config-ext-nacl)#permit tcp any any eq 80
C3560X(config-ext-nacl)#permit tcp any any eq 443
C3560X(config-ext-nacl)#remark all other traffic will be implicitly
denied from the redirection

Cisco WLC Configuration

Just as the Cisco switches are responsible for redirecting the web browser traffic to the centralized portal(s), the Cisco WLC must do the same thing. As stated in the introduction to this chapter, you are expected to have already configured the WLC as per Chapter 12.

In Chapter 12, you created an open WLAN with MAC filtering enabled and the NAC state configured for Radius NAC. Additionally, you created an Access List named ACL-WEBAUTH-REDIRECT.


Note

At the time of writing this book, the latest version of the Cisco WLC was 7.6 MR3. As of that version, the Cisco WLC could redirect only HTTP traffic. HTTPS redirections were not possible but were expected in a future release.


Validating That MAC Filtering Is Enabled on the WLAN

The MAC Filtering option for the open wireless network is configuring the WLAN for wireless MAB. This is necessary to ensure an authentication is sent from the WLC to the ISE, so ISE can return the URL-Redirection in the authorization result.

From the WLC GUI, do the following:

Step 1. Navigate to WLANs.

Step 2. Examine the list of WLANs, ensuring that MAC Filtering is listed under the Security Policies column, as shown for the CiscoPress-Guest SSID in Figure 13-4.

Image

Figure 13-4 MAC Filtering on an open SSID.

Validating That Radius NAC Is Enabled on the WLAN

Even though the Radius NAC feature is mislabeled with the wrong capitalization of the acronym RADIUS, it is still a valid and important setting. This setting is critical to allow for URL redirection, CWA, posture assessment, native supplicant provisioning, and more.

From the WLC GUI, do the following:

Step 1. Navigate to WLANs > and select your open SSID.

Step 2. Click the Advanced tab.

Step 3. Examine the setting for the NAC state and ensure it is configured for Radius NAC, as shown in Figure 13-5. While at this configuration screen, also ensure that Allow AAA Override is enabled, which is also depicted in Figure 13-5.

Image

Figure 13-5 Radius NAC setting.

Validate That the URL-Redirection ACL Is Configured

The last critical item to ensure exists in the WLC configuration is an ACL to use for UR -redirections. In Chapter 12, you created an ACL named ACL-WEBAUTH-REDIRECT. This list is used to determine which traffic is redirected to the CWA portal with the deny statement. Any traffic that is permitted will not be redirected.

Image

Unlike IOS-based NADs, the AireSpaceOS-based wireless controllers use a single ACL to determine which traffic to redirect and which traffic to permit through. In other words, both redirection and traffic filtering are handled by the single ACL. Therefore, the logistics of which traffic is redirected are not the same as with IOS-based devices. With these WLCs, a deny statement means that traffic should be redirected. A permit statement allows the traffic through the WLC and bypasses the redirection.

From the WLC GUI, do the following:

Step 1. Navigate to Security > Access-Control-Lists > Access-Control Lists. Ensure the ACL-WEBAUTH-REDIRECT ACL is in the list, as shown in Figure 13-6.

Image

Figure 13-6 ACLs.

Step 2. Click the ACL, and ensure the entries for your environment are there.

Figure 13-7 shows the ACL as it is defined in the WLC.

Image

Figure 13-7 ACL-WEBAUTH-REDIRECT contents.

Captive Portal Bypass

One more local configuration is required for the WLC. You need to enable a feature called captive portal bypass. Apple iOS devices have a feature to help facilitate network access when their end users are on public hotspot-type networks. When joining an open wireless network, the iOS device attempts to reach a few web pages hosted on apple.com, and it attempts this in the background so the end user is not aware of the attempted communication.

If the communication is successful, nothing happens because (obviously) the end user must be on the Internet if that was successful. If the connection is not successful, iOS launches a pseudo-browser to facilitate the end user in entering credentials or accepting the public hotspot’s acceptable use policy (or whatever other reason the redirection can be happening).

The pseudo-browser is not fully functioning and has problems with many types of redirections, including the ones to ISE’s secure portals. Therefore, the pseudo-browser doesn’t work for most CWA types or other onboarding. The icing on the cake is that if the end user closes that full-screen pseudo-browser, iOS will drop the connection to the network. That’s right—instead of allowing the end user to launch a real browser, it actually disconnects him from the network. This causes a denial of service (DoS) against iOS-based endpoints with CWA or BYOD onboarding, and so on.

To get around that DoS, Cisco and other vendors have all created different ways to “spoof” a success message to the iOS endpoint. The following command needs to be run on all your Cisco WLCs, which will also require a reboot before it is active:

> config network web-auth captive-bypass enable

Configuring ISE for Centralized Web Authentication

Now that you’re sure the key elements of the network devices are configured correctly, it’s time to ensure ISE is configured correctly, too. A key change must be made in the authentication policy: an identity source sequence that will use all the appropriate identity stores and the configuration of the appropriate traffic filtering dACLS. Additionally, you must create the appropriate authorization rules for both pre- and post-web authentication.

Configuring MAB for the Authentication

WebAuth is often used for guest access, which means the endpoint will most likely be unknown to ISE when the guest is attached to the network. As such, it is critical to set the identity options to continue when the MAC address is unknown.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Authentication.

Step 2. Edit the MAB rule, and click the plus (+) sign next to Internal Endpoints.

Step 3. Ensure the If User Not Found setting is set to Continue, as shown in Figure 13-8.

Image

Figure 13-8 MAB, continued.

Step 4. Click Done and then click Save.

Configuring the Web Authentication Identity Source Sequence

There is a pre-onfigured identity source sequence (ISS) named Guest_Portal_Sequence. The default web authentication portal is configured to use this ISS. It is configured by default to check both the Internal Users and the Guest Users identity stores. Web authentication is not only used for guest access, so in this case we add Active Directory to the list of identity sources to query.

From the ISE GUI, follow these steps:

Step 1. Navigate to Administration > Identity Management > Identity Source Sequences, as shown in Figure 13-9.

Image

Figure 13-9 Identity source sequences.

Step 2. Click the ISS named Guest_Portal_Sequence.

Step 3. Add the Active Directory identity store to the sequence, as shown in Figure 13-10.

Image

Figure 13-10 Guest_Portal_Sequence.

Step 4. Click Save.

Configuring a dACL for Pre-WebAuth Authorization

Before a device can reach the CWA portal, it first has to be permitted onto the network. Full network access is not desirable in most cases. For IOS-based devices, a dACL can and should be used to limit the network access.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs, as shown in Figure 13-11.

Image

Figure 13-11 Downloadable ACLs.

Step 2. Click Add.

Step 3. Name the new dACL WebAuth.

Step 4. Add a description.

Step 5. Configure the ACL to permit traffic to the ISE PSNs, but deny access to the remainder of the internal network, similar to what is shown in Figure 13-12.

Image

Figure 13-12 Sample WebAuth dACL.

Step 6. Click Save.

Configuring an Authorization Profile

At this point, everything is ready to build the authorization profile to allow the end user onto the network, apply the URL redirection to the default CWA portal with the correct URL-redirection ACL, and apply the dACL to limit network traffic.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.

Step 2. Click Add.

Step 3. Name the new authorization profile CWA.

Step 4. Select the WebAuth dACL.

Step 5. Select the check box for Web Redirection, choosing Centralized Web Auth from the first drop-down list. In the ACL text box, type ACL-WEBAUTH-REDIRECT. This ACL name must be typed exactly with proper capitalization. You are using the default WebAuth portal, so ensure that Default is selected for the redirect drop-down menu.

Figure 13-13 is a composite image, created to show all the key parts in one graphic, and it shows the complete authorization profile.

Image

Figure 13-13 The complete CWA authorization profile.

Building CWA Authorization Policies

Two different authorization rule types must be created. The first rule should match if no more specific authorization rule is used and should redirect the user to the CWA portal. The second rule type should exist above the redirection rule and allow access to the user after she has successfully authenticated to the CWA portal.

Creating the Rule to Redirect to CWA

The first rule to create is one that will redirect to the CWA portal when no more specific rules are matched.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Authorization.

Step 2. Add a new rule above the default rule at the bottom, as shown in Figure 13-14.

Image

Figure 13-14 Creating the WebAuth authorization rule.

Step 3. Name the new rule WebAuth.

Step 4. For the conditions, select two existing compound conditions from the library: Wired_MAB and Wireless MAB. Ensure the OR operator is used with the conditions, as shown in Figure 13-14.

Figure 13-14 shows the compound conditions being added to the authorization rule.

Step 5. Use the CWA authorization profile you created previously for the result, as shown in Figure 13-15.

Image

Figure 13-15 Completed WebAuth authorization rule.

Step 6. Click Done and then click Save.

Figure 13-15 shows the completed WebAuth authorization rule.

Creating the Rules to Authorize Users Who Authenticate via CWA

The second rule type is one that will allow the user(s) who authenticates via WebAuth to have her specific access to the network. The number of rules created will greatly depend on the needs of your organization. For the purposes of this chapter, you will create two authorization rules: one for employees and another for guests.

Creating the Guest Rule

You are constructing a new authorization rule that will allow guest users (users who belong to the User Identity Group named Guest) who have successfully authenticated through the web portal to have Internet-only network access. You will also use a dictionary item, called Guest Flow, in your rule. This dictionary object is used by ISE to identify when an authentication has occurred via an ISE web portal. Chapter 14 discusses guest access in much more detail.

From the ISE GUI, follow these steps:

Step 1. Navigate to Policy > Authorization.

Step 2. Add a new rule above the first employee rule, as shown in Figure 13-16.

Image

Figure 13-16 Creating the guest authorization rule.

Step 3. Name the new rule Guest.

Step 4. Select the Guest Internal User Identity Group, as shown in Figure 13-16.

Step 5. Create a new condition for Network Access > Use Case EQUALS Guest Flow, as shown in Figure 13-16.

Step 6. Save the condition as GuestFlow for reuse in other rules.

Figure 13-16 shows the guest authorization rule being constructed.

Step 7. Select the Internet-Only authorization profile you created earlier as the result.

Step 8. Click Done and then click Save.

Figure 13-17 shows the completed guest rule.

Image

Figure 13-17 The completed guest rule.

Creating the Employee Rule

Technically, you already have a rule that will work. You are not required to use the Guest Flow attribute in your conditions, and an employee logging in through CWA will still land on any rule that matches your Employee condition.

However, for good security practice, you are constructing a new authorization rule that will allow employees (users who belong to the Active Directory group named Employees) who have successfully authenticated through the web portal to have Internet-only network access.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Authorization.

Step 2. Add a new rule below the guest rule, as shown in Figure 13-18.

Image

Figure 13-18 The completed employee CWA rule.

Step 3. Name the new rule Employee CWA.

Step 4. Create a new condition that uses the new Guest Flow condition from the library and the saved simple condition named Employees with the AND operator, as shown in Figure 13-18.

Step 5. Select the Internet-Only authorization profile you created earlier as the result.

Step 6. Click Done and then click Save.

Figure 13-18 shows the completed employee CWA rule.

Configuring Device Registration Web Authentication

In this section you will create a new DRW portal. DRW is used to allow an interactive user to add his MAC address to an Endpoint Identity Group, so that endpoint will be permitted back on the network repeatedly without having to go through another interactive authentication.

Creating the Endpoint Identity Group

The first procedure is to create an Identity Group for all the devices your users register. There is a preexisting endpoint identity group called Registered-Devices, but the best practice is to reserve that group for the BYOD devices that have been registered through MyDevices. You will create a new endpoint identity group named DRW-Endpoints to help differentiate them.

From the ISE GUI, follow these steps:

Step 1. Navigate to Administration > Identity Management > Groups > Endpoint Identity Groups.

Step 2. Click Add.

Step 3. Name the new group DRW-Endpoints.

Step 4. Click Submit.

Figure 13-19 shows the completed Endpoint Identity Group.

Image

Figure 13-19 The completed DRW-Endpoints Group.

Creating the DRW Portal

The next procedure is for you to create the actual DRW portal to which to redirect the end user. Because you used the default portal for the CWA procedures, this will be a new experience for you. The portal configuration is pretty well buried in a location that has proven itself difficult to find.

From the ISE GUI, follow these steps:

Step 1. Navigate to Administration > Web Portal Management > Settings.

Step 2. On the left side, select Guest > Multi-Portal Configurations.

Step 3. Click Add.

Step 4. Name the new portal DRW.

Step 5. Select Device Web Authorization Portal.

Step 6. Select DRW-Endpoints for the Endpoint Identity Group.

Step 7. Click Submit.

Figure 13-20 shows the completed DRW multi-portal.

Image

Figure 13-20 The completed DRW multi-portal.

Creating the Authorization Profile

Now that you have a DRW portal created, you need to create an authorization result that will redirect users to that portal.

From the ISE GUI, follow these steps:

Step 1. Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.

Step 2. Click Add.

Step 3. Name the new authorization profile DRW.

Step 4. Select the WebAuth dACL.

Step 5. Select the check box for Web Redirection, choosing Device Registration Web Auth from the first drop-down list. In the ACL text box, type ACL-WEBAUTH-REDIRECT.

Step 6. Select DRW from the Value drop-down list.

Figure 13-21 is a composite image, created to show all the key parts in one graphic, and it shows the complete authorization profile.

Image

Figure 13-21 The complete DRW authorization profile.

This should have felt a lot like the procedure for creating a CWA authorization profile. Pay attention to how the Web Redirection field in the authorization profile is used for many different actions. When you select Device Registration Web Auth from the first drop-down list, it automatically grayed out the redirect drop-down menu and populated the Value drop-down list with all the DRW-type portals that had been created.

Figure 13-22 illustrates the difference in the raw RADIUS being used for both CWA and DRW. Notice the differences in the URL.

Image

Figure 13-22 Comparing the CWA and DRW RADIUS details.

Creating the Rule to Redirect to DRW

Much like the process for CWA, the DRW redirection rule will need some parameters on when to redirect a session to the DRW portal. For the purposes of this example, you will create a rule that redirects all MAB authenticated sourced from the CiscoPress-Guest SSID only. One major difference between CWA and DRW is that a user must only accept the AUP to register her device. No username or password is required.

From the ISE GUI, follow these steps:

Step 1. Navigate to Policy > Authorization.

Step 2. Add a new rule above the WebAuth rule, as shown in Figure 13-23.

Image

Figure 13-23 Creating the DRW authorization rule.

Step 3. Name the new rule DRW.

Step 4. For the first condition, select the existing compound conditions from the library: Wireless MAB.

Step 5. For the second condition, create a new one with Airespace > Airespace-Wlan-Id EQUALS 2.

In Step 5 you are leveraging a Cisco Airespace attribute to identify the WLAN. In our example, we used an Airespace-Wlan-Id of 2, but this can vary depending on your WLC configuration.

Step 6. Optionally save that condition for use again in other rules.

Step 7. Ensure the AND operator is used with the conditions, as shown in Figure 13-23.

Figure 13-23 shows the compound conditions being added to the authorization rule.

Step 8. Use the DRW authorization profile you created previously for the result, as shown in Figure 13-23.

Step 9. Click Done and then click Save.

Figure 13-24 shows the completed DRW authorization rule.

Image

Figure 13-24 The completed DRW authorization rule.

Creating the Rule to Authorize DRW-Registered Endpoints

Much like what you completed in the guest authorization rule, you will leverage the Identity Group field. Here you are creating a new authorization rule, above the DRW redirection rule that will allow any devices that are part of the DRW-Endpoints group to have Internet-only access.

From the ISE GUI, follow these steps:

Step 1. Navigate to Policy > Authorization.

Step 2. Add a new rule above the guest rule, as shown in Figure 13-25.

Image

Figure 13-25 The completed DRW-Endpoints rule.

Step 3. Name the new rule DRW Endpoints.

Step 4. Select the DRW-Endpoints Internal Endpoint Identity Group, as shown in Figure 13-25.

Step 5. Select the Internet-Only authorization profile you created earlier as the result.

Step 6. Click Done and then click Save.

Figure 13-25 shows the completed DRW-Endpoints rule.

Verifying Centralized Web Authentication

Congratulations! You’ve gone through a lot of configuration this chapter. Now that you’ve gotten the CWA and the DRW configurations complete, it helps to see them in action. There are a number of locations to verify the action. You can examine the effect of the user experience on the client, check the Live Log in ISE, run show commands on the wired switch, or even examine the client details on the WLC.

Checking the Experience from the Client

Obviously, a quick way to see whether it’s working is to try opening a web browser on the client machine and see if the browser is redirected to a portal.

Figure 13-26 shows the client experience on a wired Windows client being redirected to the CWA portal and the user entering his credentials in the login form.

Image

Figure 13-26 Browser redirected to CWA portal.

Figure 13-27 displays the client experience after the authentication was submitted. As the figure shows, the test client was able to connect to the Internet.

Image

Figure 13-27 Successfully browsing the Internet.

Next, we will try the DRW experience from a wireless client. Figure 13-28 shows an iPad that has successfully associated to the CiscoPress-Guest wireless SSID and is redirected to the DRW portal.

Image

Figure 13-28 DRW’s acceptable use policy.

After the user accepts the AUP, the MAC address is automatically added to the DRW-Endpoints identity group. A success message is displayed to the end user, as shown in Figure 13-29.

Image

Figure 13-29 Success message.

Now that the device has been successfully registered, the end user is authorized for Internet-only access and is able to reach the Internet, as shown in Figure 13-30.

Image

Figure 13-30 Internet access achieved.

Checking on ISE

The next most logical place to look is at the centralized policy server itself. ISE has a number of tools that can be used to verify the WebAuth. The most common is the Live Log. But in the case of DRW, you can also check the Identity Group itself. Many other tools can be used, such as TCPDump, but those tools are not covered in this chapter. For more on those other tools, see Chapter 22, “Troubleshooting Tools.”

Checking the Live Log

Cisco ISE has a phenomenally useful tool built in to it, commonly called Live Log. Live Log provides a near real-time view of all incoming authentications, CoA, and more. In this section, you will follow the client experience from the perspective of the ISE management console.

Figure 13-31 is highlighting the initial MAB, which has been assigned the CWA authorization result. Immediately following the successful authorization, you see the successful download of the dACL, which is also highlighted in Figure 13-31.

Image

Figure 13-31 Live Log.

Image

After the end user enters her credentials and clicks Submit, a guest authentication is recorded, followed by a CoA (displayed as a dynamic authorization). The CoA is a key function. Specifically, it is a CoA-Reauth and causes the switch to reauthentciate the endpoint without starting a new session. The switch sends another MAB request to ISE, which is able to tie the guest authentication from the centralized portal to the MAB request from the switch.

Due to the correlation of the centralized guest authentication to the MAB authentication request, the employee is assigned the Internet_Only authorization profile, which is followed immediately by the successful download of the Internet_Only dACL. All these steps are shown inFigure 13-32.

Image

Figure 13-32 Live Log part 2.

Checking the Endpoint Identity Group

With DRW, the endpoint is added to the configured Endpoint Identity Group. So, to ensure the redirection to the AUP occurred and the user accepted the AUP, you can check the membership of the Endpoint Identity Group, as shown in Figure 13-33.

Image

Figure 13-33 DRW-Endpoints Group membership.

Checking the NAD

Certainly, checking the device that is performing the enforcement should be a good way to validate that the CWA is working. In this section you will examine the authorization result on a Cisco switch and a Cisco WLC.

show Commands on the Wired Switch

The go-to command on a Cisco switch is show authentication session interface [interface-name]. This command is like a Swiss Army knife with all the valuable information it provides. Example 13-1 displays the command and its output for the endpoint as it was being redirected to the CWA portal.

Highlighted in the example are the MAC address, IP address, dACL (listed as an ACS ACL), URL-redirect ACL, and URL to which the end user is being redirected.

Example 13-1 show authentication session interface g1/0/2


C3560X# sho authen session int g1/0/2
Interface: GigabitEthernet1/0/2
MAC Address: 0050.5687.0004
IP Address: 10.1.10.50
User-Name: 00-50-56-87-00-04
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
URL Redirect ACL: ACL-WEBAUTH-REDIRECT
URL Redirect: https://atw-cp-ise02.ise.local:8443/guestportal/gateway?sess
ionId=C0A8FE01000000270B2CAA43&action=cwa

Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A8FE01000000270B2CAA43
Acct Session ID: 0x0000002D
Handle: 0x68000028

Runnable methods list:
Method State
mab Authc Success
dot1x Not run


Viewing the Client Details on the WLC

With the WLC, navigating to Monitor > Clients will show you a list of all clients currently associated to that controller. Clicking the MAC address will bring up the details about the client and its association, including the authentication information such as the redirection and run state.

Figure 13-34 shows the details for that client, with a focus on the Security Information section. Pay attention to the RADIUS NAC state, which is set for CENTRAL_WEB_AUTH.

Image

Figure 13-34 Security Information section of client details.

Figure 13-35 shows the same client details after the endpoint was registered. Notice the RADIUS NAC state is now RUN. This is a key setting; the redirection will never work if the state is RUN because this is the final state.

Image

Figure 13-35 Security Information section of client details—run state.

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 13-3 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 13-3 Key Topics for Chapter 13