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.