There are a number of reasons that a company may choose to implement a WebAuth strategy. In this sample chapter from CCNP Security Identity Management SISE 300-715 Official Cert Guide, you will learn how to configure Centralized Web Authentication, build CWA authorization rules, and verify Centralized Web Authentication.
This chapter covers the following topics:
Web Authentication scenarios
Configuring Centralized Web Authentication
Building CWA authorization rules
Verifying Centralized Web Authentication
As discussed in Chapter 4, “Non-802.1X Authentications,” just because there is no configured supplicant on an endpoint does not mean the user of that endpoint does not need to authenticate. Consider the use cases of guests or visitors, or maybe just a misconfiguration or an expired credential for an end user. The user may still require access to the network.
Enter Web Authentication, commonly referred to as just WebAuth. With WebAuth, an authenticator can send a user to a locally hosted web page—that is, a web page hosted on the local device itself (the switch, wireless controller, or even the firewall or VPN concentrator) where a user can submit a username and password.
As mentioned in Chapter 4, there are multiple types of WebAuth, and Centralized WebAuth (CWA) is the type used with Cisco Secure Access and ISE. CWA is the focus of the Implementing and Configuring Cisco Identity Services Engine SISE 300-715 exam and, therefore, the main focus of this book.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows 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 12-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 and Q&A Sections.”
Table 12-1 “Do I Know This Already?” Section-to-Question Mapping
Foundation Topics Section |
Questions |
|---|---|
Web Authentication Scenarios |
5 |
Configuring Centralized Web Authentication |
1, 3–6 |
Building CWA Authorization Policies |
3 |
Verifying Centralized Web Authentication |
2, 7–10 |
1. Before a Cisco switch can generate a self-signed certificate, what configuration is required?
a. The internal CA must be enabled.
b. An IPv6 address must be configured.
c. A Cisco switch cannot generate a self-signed certificate.
d. A domain name must be configured.
2. Which statement about URL-Redirect ACLs is true?
a. A URL redirection ACL can be downloaded from ISE to a NAD.
b. A URL redirection must be preconfigured locally on the NAD, and ISE applies it through the use of RADIUS attribute/value pairs (AV pairs).
c. There is no ACL needed for URL redirection.
d. A URL redirection ACL and its ACEs must be configured both in ISE and on the NAD.
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. ISE 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 to redirect the user to the CWA portal.
c. An authentication rule must be created to permit access to users who have successfully authorized through the CWA portal.
d. An authorization rule must be created to permit access to users who have successfully authenticated through the CWA portal.
e. A WebAuth authentication rule must be created to redirect the end user to the CWA portal.
6. Which statement is true regarding network segmentation and Web Authentication?
a. Network segmentation should never be used with Web Authentication; they are mutually exclusive technologies.
b. VLAN changes may be used, and TrustSec SGTs may be used, but VLAN changes and SGTs can never be used together.
c. Only TrustSec SGTs can be used with Web Authentication to provide segmentation.
d. VLAN changes should only be used with devices that can recognize a change and request a new DHCP address.
7. Which of the following statements about CWA is true?
a. CWA is configured exactly the same for both wired and wireless NADs.
b. CWA must leverage different policy sets when configured for wired and wireless.
c. With CWA, the switch isn’t aware of the Web Authentication and only identifies the session as using MAB.
d. CWA stands for Cisco Wide-area Authorization.
8. Which command on a NAD displays information about a URL-redirected session, including the MAC address, IP address, dACL, URL-Redirect ACL, and the URL the end user is being redirected to?
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 in the ISE GUI is the best one to examine to validate that CWA is working?
a. Policy > Policy Elements > Results > Authorization
b. Operations > RADIUS > Live Log
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 together the MAB and CWA authentications.
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 PoD to the NAD, and ISE is able to tie the original MAB session to the new Web Authentication session by correlating the MAC addresses from both authentication sessions.
Foundation Topics
Web Authentication Scenarios
There are a number of reasons that a company may choose to implement a WebAuth strategy. One of the most common reasons is to provide Internet access to visitors (also known as guests), as detailed in Chapter 13, “Guest Services.” In addition, as newer versions of ISE come out, many companies are looking to add interactive logins to capture usernames and passwords as additional credentials to certificate-based authentication (think two-factor authentication).
The end user is presented with a web portal to input a username and password. The credentials are then sent from the authenticator to ISE in a standard RADIUS Access-Request packet. So, in a very similar fashion to what occurs with MAC Authentication Bypass (MAB), the switch sends the request for the endpoint, and the endpoint itself does not participate in authentication. Figure 12-1 illustrates the WebAuth concept.
)
The credential that gets submitted through the WebAuth page could be the 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 type of user account.
Keep in mind that WebAuth is only an effective authentication method for a device that has an interactive user. In other words, it would not make sense to try to use WebAuth for a printer as there would be no user to interact with the web portal, enter credentials, and click Submit.
Like MAB, WebAuth is not a standard. There are multiple ways to perform WebAuth, with benefits and downsides to each one.
Local Web Authentication (LWA)
Local Web Authentication (LWA) is the original WebAuth. With LWA, the authenticator redirects web browser traffic to a locally hosted web portal where a user can enter a username and password.
The credentials are submitted through the switch or wireless controller, which 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 Catalyst switch, the locally hosted web pages are not very customizable. Many companies require that 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.
In addition, when using LWA with Cisco switches, there is no native support for advanced services such as the following:
▪ Acceptable use policy acceptance pages
▪ Client provisioning
▪ Password-changing capabilities
▪ Self-registration
▪ Device registration
▪ BYOD onboarding
For advanced capabilities like these, a company truly needs to consider using Centralized Web Authentication.
Centralized Web Authentication (CWA)
Cisco ISE uses Centralized Web Authentication (CWA) almost exclusively. While Cisco ISE is capable of supporting LWA methods, those methods are typically reserved for non-Cisco network devices.
Like other forms of Web Auth, CWA is only for interactive users with web browsers, who need to manually enter usernames and passwords.
Change of Authorization (CoA) works fully with CWA, which contributes to support for all the authorization results, such as ACL and VLAN authorization. Keep in mind that any time you change 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 WebAuth, a supplicant does not typically exist on the endpoint. Therefore, the DHCP scope length 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, which is not a popular option due to the security concerns related to using Java or ActiveX applets.
CWA also supports advanced services such as the following:
▪ Client provisioning
▪ Posture assessments
▪ Acceptable use policies (AUPs)
▪ Password changing
▪ Self-registration
▪ Device registration
▪ BYOD onboarding
As described in Chapter 4, a switch or wireless controller only sees MAB, and the rest is handled on the authentication server (ISE). Figure 12-2 shows the MAB occurring with a redirection to the centralized portal, and Figure 12-3 shows how the switch still sees only a MAB request, with ISE maintaining the user authentication.
)
)
The following steps detail what occurs in Figures 12-2 and 12-3:
Step 1. The endpoint entering the network does not have a supplicant.
Step 2. The authenticator performs 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.
Step 4. The end user enters credentials into the centralized portal. Unlike the LWA options, the credentials are never sent to the switch; instead, 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, and it 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 are the basis for many of the other solutions in ISE, including Device Registration WebAuth, BYOD onboarding, MDM onboarding, and posture assessment.
Configuring Centralized Web Authentication
Multiple devices need to be configured to enable CWA. The network access device (NAD) requires some special configuration, such as a redirection ACL; in addition, ISE needs authentication and authorization rules set up for CWA. The following sections look at these configurations.
Cisco Switch Configuration
With secure network access using ISE, the switch performs the URL redirection for Web Authentication and also redirects the discovery traffic from the posture agent to the ISE policy service node.
Performing URL redirection at the Layer 2 access (edge) device is a vast improvement over previous NAC solutions, which requires an appliance (such as the inline device) to capture web traffic and perform redirection to a Web Authentication page. URL redirection at the Layer 2 access device simplifies Web Authentication deployment, device onboarding, and the posture agent discovery process.
Configure Certificates on the Switch
In order to redirect HTTPS traffic, there is a prerequisite for the switch to have its own certificate. To configure a certificate, perform the following tasks in global configuration mode on a switch:
Step 1. To 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, and the keys can be generated.
Step 2. To generate keys to be used for HTTPS, type crypto key generate rsa general-keys mod 2048 at the global configuration prompt.
Enable the Switch HTTP/HTTPS Server
The embedded HTTP/HTTPS server in IOS is used to grab HTTP traffic from the user and redirect that user’s browser to the Centralized Web Authentication portal or to a device registration portal or even to the mobile device management onboarding portal. This same function is used for redirecting the posture agent’s traffic to the Policy Services node. Follow these steps to enable the switch HTTP/HTTPS server:
Step 1. Enable the HTTP server by entering the following command in global configuration mode:
C3850(config)# ip http server
Step 2. Enable the HTTP secure server by entering the following command:
C3850(config)# ip http secure-server
Many organizations need to ensure that this redirection process, which is using the switch’s internal HTTP server, is decoupled from the management of the switch itself. To disconnect the HTTP management process from the URL-redirection process, run the following two commands in global configuration mode:
C3850(config)# ip http active-session-modules none
C3850(config)# ip http secure-active-session-modules none
Verify the URL-Redirect ACL
In Chapter 11, you created an access list named ACL-WEBAUTH-REDIRECT, which is used to determine what traffic is redirected to the CWA portal with the permit statement. Any traffic that is denied is not redirected.
Contrary to the way a wireless LAN controller works, the URL-Redirect ACL on a switch is used only to determine what traffic is redirected and what traffic is not redirected. If network traffic is denied from redirection, it is not necessarily denied the ability to traverse the network. The traffic-filtering capability comes from the downloadable ACL (dACL) that is sent to the switch 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 later in this chapter.) Follow these steps to verify the URL-Redirect ACL:
Step 1. Validate whether the ACL-WEBAUTH-REDIRECT ACL is configured on the NAD by entering the following command:
C3850# 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, continue to step 2.
Step 2. Add the following ACL to be used for URL redirection with Web Authentication:
C3850(config)# ip access-list ext ACL-WEBAUTH-REDIRECT C3850(config-ext-nacl)# remark explicitly deny DNS from being redirected to address a bug C3850(config-ext-nacl)# deny udp any any eq 53 C3850(config-ext-nacl)# remark redirect all applicable traffic to the ISE Server C3850(config-ext-nacl)# permit tcp any any eq 80 C3850(config-ext-nacl)# permit tcp any any eq 443 C3850(config-ext-nacl)# remark all other traffic will be implicitly denied from the redirection
Cisco WLC Configuration
Cisco switches are responsible for redirecting web browser traffic to the centralized portal(s), and Cisco WLCs must do the same thing.
Validate That MAC Filtering Is Enabled on the WLAN
The MAC Filtering option for an open wireless network configures a WLAN for wireless MAB. This is necessary to ensure that an authentication is sent from the WLC to ISE, so ISE can return the URL redirection in the authorization result.
From the WLC’s GUI, navigate to the WLANs tab, examine the list of WLANs, and ensure that MAC Filtering is listed in the Security Policies column, as shown for the CiscoPress-Guest SSID in Figure 12-4.
)
Validate That ISE NAC Is Enabled on the WLAN
The ISE NAC feature is a very important setting. It is critical to allow for URL redirection, Centralized Web Authentication, posture assessment, native supplicant provisioning, and more.
From the WLC GUI, follow these steps:
Step 1. Navigate to WLANs > and select your open SSID.
Step 2. Click on the Advanced tab.
Step 3. Ensure that NAC State is forest to ISE NAC, as shown in Figure 12-5. In the same screen, ensure that Allow AAA Override is set to Enabled.
)
Validate That the URL-Redirection ACL Is Configured
The last critical item you need to ensure exists in the WLC configuration is an ACL to use for URL redirections. In Chapter 11, you created an ACL named ACL-WEBAUTH-REDIRECT, which is used to determine what traffic is redirected to the CWA portal with the deny statement. Any traffic that is permitted is not redirected.
Unlike IOS-based NADs, 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 a single ACL. Therefore, the logistics of which traffic is redirected are not the same as with IOS-based devices. With Cisco WLCs, a deny statement means that traffic should be redirected. A permit statement allows the traffic through the WLC and bypasses the redirection.
In the WLC GUI, follow these steps:
Step 1. Navigate to Security > Access-Control-Lists > Access-Control Lists. Ensure that the ACL-WEBAUTH-REDIRECT ACL is in the list, as shown in Figure 12-6.
Step 2. Click this access list and ensure that the entries for your environment are there, as shown in Figure 12-7.
)
)
Configure ISE for Centralized Web Authentication
When you’re sure the key elements of the network devices are configured correctly, it’s time to ensure that ISE is configured correctly, too. A key change must be made in the authentication policy: An identity source sequence that uses all the appropriate identity stores and the appropriate traffic-filtering dACLs need to be configured. In addition, you need to create the appropriate authorization rules for both before and after Web Authentication.
The sections that follow describe the key steps in configuring ISE for Centralized Web Authentication:
Step 1. Configure MAB Continue for the Authentication.
Step 2. Verify the Web Authentication identity source sequence.
Step 3. Configure a dACL for pre-WebAuth authorization.
Step 4. Configure an authorization profile.
Configure MAB Continue for the Authentication
WebAuth is often used for guest access, which means an endpoint is likely to be unknown to ISE when a guest attaches to the network. It is therefore critical to set the identity options to continue when the MAC address is unknown. This has been the default for MAB since ISE Version 2.0, but we examine it anyway to better understand the situation.
In the ISE GUI, follow these steps (see Figure 12-8):
)
Step 1. Navigate to Work Centers > Network Access > Policy Sets.
Step 2. Select the Default policy set.
Step 3. Expand the Authentication Policy section.
Step 4. In the MAB rule, click Options underneath Internal Endpoints.
Step 5. Ensure that If User Not Found is set to CONTINUE.
Verify the Web Authentication Identity Source Sequence
There is a preconfigured 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 Internal Users, Guest Users, and All_AD_Join_Points—in that order.
There is no configuration change required. This sequence, and all the preconfigured sequences since ISE Version 2.0, are ready to use as is. However, just to be sure it does what you need, in the ISE GUI, navigate to Work Centers > Network Access > Identities > Identity Source Sequence and select the Guest_Portal_Sequence, as shown in Figure 12-9.
)
Configure 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.
In the ISE GUI, follow these steps:
Step 1. Navigate to Work Centers > Network Access > Policy Elements > Results > Downloadable ACLs, as shown in Figure 12-10.
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 policy service nodes but deny access to the remainder of the internal network. Figure 12-11 shows what this might look like.
Step 6. Click Submit.
)
)
Configure an Authorization Profile
At this point, you are 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-Redirect ACL, and apply the dACL to limit network traffic.
In the ISE GUI, follow these steps:
Step 1. Navigate to Work Centers > Network Access > Policy Elements > Results > Authorization Profiles, as shown in Figure 12-12.
Step 2. Click Add.
Step 3. Name the new Authorization Profile CWA.
Step 4. Select the WebAuth dACL.
Step 5. Select the Web Redirection checkbox and choose Centralized Web Auth from the first dropdown. In the ACL text box, type ACL-WEBAUTH-REDIRECT. You are using a default WebAuth portal, so ensure that Sponsored Guest Portal (default) is selected from the Value dropdown.
)
Figure 12-13 is a composite image that shows all the key parts in one graphic, including the complete authorization profile.
)
Many organizations implement segmentation with ISE, as it is a security best practice. After all, this is a major use case for ISE and probably a big reason you are reading this book now. With segmentation, users and devices that have an 802.1X supplicant and perform strong authentication should be admitted to the network and kept separate (segmented) from users and devices that have not gone through strong authentication.
If you are going to use VLANs for segmentation, go for it. However, you don’t want to change VLANs on a device that is not using a supplicant unless you absolutely have no other choice.
A supplicant detects VLAN changes and renews its IP address in the new VLAN. Most devices that are not using a supplicant don’t detect that change of VLAN, and they therefore hold on to the wrong IP address, effectively ensuring that the device will be unable to communicate on the network at all.
Some tricks of the trade can be employed here. (Some in the industry like to call it network gymnastics.) Java and ActiveX applets can be used with WebAuth, and you can play tricks with the DHCP scope in the initial VLAN. The DHCP option is one of the better ones, as a lease can be issued for a very short time, such as 5 minutes. The rules of DHCP client behavior dictate that a client will try to renew its IP address at 50% of the lease time (in this case, 2.5 minutes). ISE has a built-in DHCP server for just such use cases.
However, the recommendation from most implementors is to change VLANs only on clients who use supplicants. Therefore, the default VLAN of your switch ports should remain in a common network segment for guest users and the like, while an authorization profile for employees who gain access via 802.1X should include the VLAN change, and an employee who gains access via CWA should land in the default VLAN of the switch.
Building CWA Authorization Policies
Configuring the authorization policy for centralized Web Authentication is ultimately a two-rule process. This section shows how to create two different authorization rules that will exist toward the end of your authorization policy. They appear at the end of the policy because of the top-down nature of ISE policies and to ensure that CWA is leveraged only when a more specific authorization rule does not apply. If an explicit authorization does not occur, ISE uses the CWA rule to redirect the user to the CWA portal.
The second rule must exist above the redirection rule because this rule is used to assign the right level of access to a user who successfully authenticates to the CWA portal. The second rule must exist above the first rule, or the user will end up in a CWA loop.
Cisco has included preconfigured authorization rules with ISE for wireless guest access Web Authentication. These rules, which are shown in Figure 12-14, are disabled by default.
)
You can leverage these prebuilt rules, but how would that help you learn and prepare for the SISE 300-715 exam? Instead of leveraging those prebuilt rules, which could shorten your configuration time dramatically, in the following sections you will see how to build your own rules.
Create the Rule to Redirect Users to the CWA Portal
The first rule to create is one that redirects unauthenticated users to the CWA portal, where they are required to authenticate interactively.
In the ISE GUI, follow these steps:
Step 1. Navigate to Work Centers > Network Access > Policy Sets.
Step 2. Drill down into your default policy set (or the policy set that is in use for your deployment at this time).
Step 3. Insert a new rule above the Basic_Authenticated_Access rule and name the new rule WebAuth, as shown in Figure 12-15.
Step 4. For the conditions, select two existing compound conditions from the library: Wired_MAB and Wireless_MAB. Ensure that the OR operator is used with the conditions, as shown in Figure 12-15.
Step 5. Use the CWA authorization profile you created previously for the result, as shown in Figure 12-15.
Step 6. Click Save.
)
Figure 12-15 shows the completed WebAuth authorization rule.
Create the Rules to Authorize Users Who Authenticate via CWA
The second rule needs to allow a user who authenticates via WebAuth to have specific access to the network. The number of rules created depends on the needs of your organization. For the purposes of this chapter, you will create only one rule, for employees. (Guest users are covered in Chapter 13.)
In this case, you need to construct a new authorization rule that will allow employees (users who are members of the Employees group in Active Directory) who have successfully authenticated through the web portal to have network access.
To accomplish this task, you can use a dictionary item named Guest Flow in your rule. ISE uses this dictionary item to identify when an authentication has occurred via an ISE web portal.
Technically, 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 should be specific and construct an authorization rule that allows 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.
In the ISE GUI, follow these steps:
Step 1. Navigate to Work Centers > Network Access > Policy Sets.
Step 2. Drill down into your default policy set (or the policy set that is in use for your deployment at this time).
Step 3. Insert a new rule above the WebAuth rule and name it Employee CWA.
Step 4. Use GuestFlow as the first condition for the rule.
Step 5. Add another condition with the AND operator.
Step 6. Select the Active Directory group named Employees as the second condition.
Step 7. Use the previously created authorization profile named Internet-Only.
Step 8. Select the Employees security group tag.
Step 9. Click Save.
Figure 12-16 shows the completed Employee_CWA rule.
)
Verifying Centralized Web Authentication
You’ve already gone through a fair bit of configuration in this chapter. Now that you’ve completed the CWA configurations, you’re ready to see it all in action.
There are a number of locations to verify the actions. You can examine the effect the user experiences on the client, check Live Log in ISE, run show commands on the wired switch, or even examine the client details on the WLC.
Check the Experience from the Client
A quick way to see if your configuration is working is to try opening a web browser on the client machine and see if the browser is redirected to a portal.
Figure 12-17 shows the client experience on a wired Windows client being redirected to the CWA portal and the user entering credentials in the login form.
)
Figure 12-18 displays the acceptable use policy that is shown to a user who submits valid authentication credentials. Figures 12-19 and 12-20 show the screens that follow, which indicate that it is now possible for the user to access the Internet. Finally, Figure 12-21 shows the successful connection to the Internet, as the user browses to http://www.cisco.com.
)
)
)
)
Verify CWA Through the ISE UI
A logical way to verify WebAuth configuration would be to look at the centralized policy server. ISE has a number of tools that can be used to verify WebAuth. The most common is Live Log, but many other tools can be used, including TCPDump (although this chapter covers only Live Log). For more on those other tools, see Chapter 21, “Troubleshooting Tools.”
Check Live Log
Cisco ISE has a phenomenally useful built-in tool called Live Log. Live Log provides a near-real-time view of all incoming authentications, Change of Authorization (CoA), and more. In this section, you will follow the client experience from the ISE management console.
Figure 12-22 highlights the process.
)
The following points correspond to the numbers in the figure:
1. The initial MAB has been assigned the CWA authorization result.
2. Immediately following the successful authorization, you see the successful download of the dACL.
3. After the end user enters credentials and clicks Submit, those credentials are recorded.
4. Immediately after the credentials are authenticated, a CoA-ReAuth is sent to the switch. The CoA is a key function that causes the switch to reauthenticate the endpoint without starting a new session.
5. That reauthentication means the switch sends another MAB request to ISE, where the Web Authentication from the centralized portal is bound to the MAB request from the switch.
6. Due to the correlation of the centralized Web 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.
7. Finally, a RADIUS accounting packet is sent from the switch to ISE, confirming the full session establishment.
Check the NAD
Checking the device that is performing the enforcement should be a good way to confirm that CWA is working. In this section, you will see how to 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 provides a lot of valuable information. Example 12-1 shows the command and its output for the endpoint as it was being redirected to the CWA portal.
Highlighted in this example are the MAC address, IP address, dACL (listed as an ACS ACL), URL-Redirect ACL, and the URL the end user is being redirected to. Notice that the username is the MAC address of the endpoint, which is a clear sign that the authentication performed was really a MAB. At the end of the screen output, you also see that MAB has the state Authc Success.
Example 12-1 show authentication session interface g1/0/3 Command Output
Example 12-2 shows the command and its output for the endpoint after the user has successfully completed the Web Authentication.
Example 12-2 show authentication session interface g1/0/3 Command Output
Notice the differences between Examples 12-1 and 12-2. Specifically, notice that in Example 12-2, the username is filled in (and no longer listed as the device’s MAC address), and there is no longer any redirection happening. However, the authentication method for mab is still listed as Authc Success. This is because a switch still considers CWA to be MAB rather than a separate authentication. ISE is responsible for binding the username to the MAB session.
Viewing the Client Details on the WLC
With the WLC, you can navigate to Monitor > Clients to see a list of all clients currently associated to that controller. Clicking the MAC address brings up the details about the client and its association, including authentication information such as the redirection and run state.
When you implement ISE, in addition to needing to know how ISE works, it is especially important to have a clear understanding of how the network devices work with ISE.
Figure 12-23 is a screenshot from the WLC GUI that shows the details for a client that is currently being redirected to a CWA portal, with a cropped focus on the Security Information section.
)
Figure 12-23 highlights the important sections:
▪ The RADIUS NAC state is set to CENTRAL_WEB_AUTH.
▪ The Security Policy Completed state is currently No.
▪ There is an AAA override ACL named ACL-WEBAUTH-REDIRECT.
▪ The redirect URL contains the dynamic URL of the active ISE PSN for this client’s session.
Figure 12-24 is a screenshot from the WLC GUI that shows the details for the same client after it has gone through a successful Web Authentication. The screenshot has a cropped focus on the Security Information section.
)
Figure 12-24 highlights the important sections:
▪ The RADIUS NAC state is now RUN. This is a key setting: The redirection will never work if the state is RUN since RUN is the final state.
▪ The Security Policy Completed state is currently Yes.
▪ There is no AAA override ACL in the RUN state.
▪ There is no redirect URL in the RUN state.
▪ There is an Internet-only ACL applied.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 27, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.
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 12-2 lists these key topics and the page number on which each is found.
Table 12-2 Key Topics
Key Topic Element |
Description |
Page |
|---|---|---|
Paragraph |
Local Web Authentication |
310 |
Paragraph |
Disconnecting management traffic from the web server in order to isolate and protect a switch |
311 |
Paragraph |
Using MAB with CWA |
314 |
Paragraph |
Traffic filtering and traffic matching |
314 |
Paragraph |
Traffic filtering and traffic matching combined with the WLC |
316 |
Paragraph |
Segmentation |
321 |
The steps involved with CWA |
327 |
|
Paragraph |
A switch recognizing CWA as a MAB flow |
329 |
Paragraph |
The steps involved with CWA on the WLC |
329 |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Web Authentication (WebAuth)
Local Web Authentication (LWA)
Centralized Web Authentication (CWA)
Guest Flow
Q&A
The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep software online.
1. What is the final state of a client connected to a Cisco wireless LAN controller?
2. What capability in a Cisco NAD enables the client to be sent to a Web Authentication portal?
3. What authentication method is displayed on a switch for a user who has successfully authenticated via CWA?
4. Where is the URL-Redirect ACL created?
5. What is different about URL redirection when comparing how a switch uses ACLs to how a WLC uses ACLs?