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

---

RADIUS Authentication Troubleshooting Tool

The RADIUS Authentication Troubleshooting tool attempts to examine various aspects of a session and provide additional details that might not have been available in the detailed authentication report, as well as provide some suggestions for items to check next. Do the following:

Step 1. Navigate to Operations > Troubleshoot > Diagnostic Tools > General Tools > RADIUS Authentication Troubleshooting.

Step 2. From here you can select any number of specifics to limit your search, such as a specific username, failed or passed authentication status, and more. Click Search.

Step 3. Select one of the resulting authentications and click Troubleshoot, as shown in Figure 22-18.

Figure 22-18 Troubleshooting the selected authentication.

Step 4. The troubleshooting progress is displayed, as shown in Figure 22-19.

Figure 22-19 Troubleshooting progress.

Step 5. When the troubleshooting is complete, click Show Results Summary to see the diagnosis and suggested resolution, as displayed in Figure 22-20.

Figure 22-20 Diagnosis and resolution.

TCP Dump

One of the most valuable troubleshooting tools available to an ISE administrator is the ability to perform a packet analysis of the RADIUS packet. The packet analysis provides visibility into the raw RADIUS attributes of an authentication, so you can determine why a specific authentication rule was chosen or not chosen.

Cisco ISE provides the capability to perform a packet capture from any interface of any node in the entire ISE cube, download the resulting PCAP file, and perform that action from the central admin console. The downloaded file can then be viewed using your favorite packet analysis tool, such as Wireshark.

The TCPDump tool is located under Operations > Troubleshoot > Diagnostics Tools > General Tools > TCP Dump, as shown in Figure 22-21.

Figure 22-21 TCP Dump.

With the tool, you can select any node of the ISE deployment and any interface of that node. You are also able to select the resulting packet capture format to be either the raw PCAP format or in a human readable format.

To illustrate the value of this tool, this chapter walks through an example of checking an incoming wireless authentication. In Chapter 12, “Implement Wired and Wireless Authentication,” you created an authorization rule that examined the wireless SSID an endpoint connected to, which used the RADIUS attribute Called-Station-ID. This example uses TCPDump to examine the incoming RADIUS packet and look for the Called-Station-ID attribute:

Step 1. Navigate to Operations > Troubleshoot > Diagnostics Tools > General Tools > TCP Dump, as shown previously in Figure 22-21.

Step 2. The correct ISE node (a PSN) and the proper interface are selected (should be GigabitEthernet 0 for most installs).

Step 3. Click Start to begin the TCP Dump. The packet capture begins and the approximate file size updates, as shown in Figure 22-22.

Figure 22-22 TCP Dump in progress.

Step 4. From an endpoint, connect to the wireless network (the CiscoPress SSID is being used in this example).

Step 5. From ISE, click Stop when you are finished. The dump file information will be updated on the screen, and the Download and Delete buttons will be enabled, as shown in Figure 22-23.

Figure 22-23 TCP Dump finished.

Step 6. Click Download to retrieve the PCAP file.

Step 7. Open the resulting PCAP file with your favorite packet analysis tool. Wireshark is used in this example, and it helps to apply a filter, such as “radius” to only see RADIUS packets, as shown in Figure 22-24.

Figure 22-24 Opening the PCAP file in Wireshark.

Examining the RADIUS details in the packet, as shown in Figure 22-25, we see that the called-station-id did not contain the SSID; instead it contains the MAC address of the wireless access point. This is a configurable setting in the Wireless LAN Controller (WLC), and we will now change that setting beginning with Step 8.

Figure 22-25 Called-Station-ID is AP’s MAC address.

Step 8. Log in to the WLC Administrative GUI.

Step 9. Navigate to Security > AAA > RADIUS > Authentication.

Step 10. Set the Auth Call Station ID Type drop-down to AP MAC Address:SSID, as shown in Figure 22-26. This configures the RADIUS authentication requests to be sent with the SSID appended to the access point’s MAC address.

Figure 22-26 Auth call station ID type.

Step 11. Click Apply and Save Configuration.

Step 12. Repeat Steps 1-6 to generate a new packet capture.

Step 13. Open the PCAP file in a packet analyzer, and the called-station-id (RADIUS attribute 30) will be the MAC address of the AP, followed by a colon (:) and then the SSID Name (CiscoPress), as shown in Figure 22-27.

Figure 22-27 Called-Station-ID now contains the wireless SSID.

In the previous example, you have just seen what occurs when you configure a rule on ISE and then troubleshoot when that rule is not being matched by looking at the raw RADIUS packets. The root cause for the rule not being matched is identified as a misconfigured setting on the WLC, and the change was made.

Another common use for the TCP Dump tool is to verify that traffic from a NAD is actually reaching the ISE node and not relying solely on the Live Log.

Ensuring Live Log Displays All Events (Bypassing Suppression)

As networks continued to change and the bring your own device (BYOD) evolution continued to take hold, the number and types of endpoints grew and authentication traffic grew exponentially. Along with that shift in authentication traffic was a shift in the number of anomalous authentications, failures, and more.

To allow ISE to scale to larger environments, ISE 1.2 added new functionality to de-duplicate logs sent from the PSNs to the MNT. By default, repeated authentications with the same code are filtered out (de-duplicated) and not sent to the MnT node. Instead a summary is sent every 15 minutes with a count of the number of de-duplicated log entries.

Although this does wonders for the scalability of the solution, it also makes troubleshooting a tad more difficult because Live Log is not being updated with those suppressed events. There are two common ways to disable the suppression and enable you to troubleshoot more effectively. The first is to use a collection filter to bypass suppression. The last resort is to disable the suppression all together.

Collection Filters

Collection filters were created to prevent certain events from being logged to the MnT. For example, they can be used to prevent the logging of load balancer health probes or the proactive test probes from switches.

For troubleshooting purposes, the filters can be used to bypass suppression. To configure a collection filter, do the following:

Step 1. From the ISE GUI, navigate to Administration > Logging > Collection Filters. Any existing filters will be displayed in the right pane.

Step 2. Click Add to create a new filter.

Step 3. Select an attribute to uniquely identify which traffic should bypass suppression.

The options are User Name, Policy Set Name, NAS IP Address, Device IP Address, and MAC Address, as shown in Figure 22-28. The MAC address is the most common attribute to use when troubleshooting.

Figure 22-28 Choosing an attribute on which to filter.

Step 4. Enter the attribute value, such as the MAC address, as shown in Figure 22-29.

Figure 22-29 Enter an attribute value and select Disable Suppression.

Step 5. Select the Disable Suppression option from the Filter Type drop-down list, as shown in Figure 22-29.

Step 6. Click Submit.

Disabling Suppression

Bypassing suppression for a specific user or endpoint is a useful troubleshooting tool. However, that is not enough sometimes. Sometimes you must disable the suppression all together, like so:

Step 1. From the ISE GUI, navigate to Administration > System > Settings > Protocols > RADIUS, as shown in Figure 22-30.

Figure 22-30 RADIUS settings.

Step 2. To disable suppression, uncheck the Suppress Anomalous Clients check box. Be sure to save afterwards.

Troubleshooting Outside of ISE

As described throughout this chapter and this book, ISE provides numerous tools that provide visibility to the authentication as it pertains to ISE’s view of the network. Tools such as Live Log, Live Sessions Log, and TCP Dump very valuable when troubleshooting, but they cannot give a complete picture of all the parts of an authentication.

Think back to the basics of network authentication. There are three “actors” or participants in any authentication scenario: the endpoint, NAD, and authentication server. ISE is the authentication server and is world-class when it comes to providing troubleshooting details. However, there are still the other two participants in the authentication that you might need to look at: the endpoint and network device.

Endpoint Diagnostics

There are multiple aspects to troubleshooting from the endpoint. Naturally, there is the supplicant that is authenticating via 802.1X, but there are also other aspects that require visibility from time to time. DNS resolution is a critical aspect and might need to be validated from the client; however, activities such as BYOD onboarding with the Network Setup Assistant apps or the posture agent (NAC Agent) also require validation.

AnyConnect Diagnostics and Reporting Tool

When troubleshooting 802.1X, it can often come down to seeing exactly what is happening at the client side, not only the server side. Unlike many of the supplicants out in the world, the AnyConnect Network Access Manager (NAM) performs detailed logging and includes an optional module called the Diagnostics and Reporting Tool (DART).

DART creates a support bundle that can be sent to Cisco TAC that includes all relevant system log files, as well as detailed communication from the supplicant. This is incredibly valuable when troubleshooting 802.1X authentications.

To create a DART bundle on a Windows endpoint, do the following:

Step 1. Launch the DART tool from Start > Cisco > Cisco AnyConnect Secure Mobility Client > Cisco AnyConnect Diagnostics and Reporting Tool, as shown in Figure 22-31.

Figure 22-31 Launch DART from the Start menu.

Step 2. Click Next to begin the bundle creation, as shown in Figure 22-32.

Figure 22-32 Click Next.

Step 3. Select the bundle creation option (default is normally used) and click Next, as shown in Figure 22-33. The DART tool will gather all necessary system and application logs, as shown in Figure 22-34.

Figure 22-33 The Bundle Creation option.

Figure 22-34 The Bundle Creation option.

Step 4. When the bundle creation is complete, the resulting Zip file will be saved on the desktop, as shown in Figure 22-35.

Figure 22-35 Resulting bundle Zip file on the desktop.

AnyConnect NAM Extended Logging

Even though AnyConnect NAM does have detailed logging capabilities enabled by default, it also has a special debug mode as well, known as extended logging. This mode can even provide packet captures from the client side for analysis, with a maximum file size of 10MB.

To enable extended logging, follow these steps:

Step 1. Type ALT + SHIFT + L at the desktop.

Step 2. Then right-click the AnyConnect icon in the system tray.

Step 3. Select Extended Logging from the context menu, as shown in Figure 22-36.

Figure 22-36 Enabling extended logging.

Microsoft Native Supplicant

There are many reasons that an organization might choose to deploy the supplicant that is native to the Windows OS, especially given the terrific centralized control offered by Active Directory. However, Cisco TAC has accumulated a list of eight hotfixes that an organization should ensure are installed if it is going to use the native supplicant:

KB 976373—Windows 7 connected behind IP phones will not authenticate after waking up from sleep or hibernation.

KB 980295—Windows 7 stops responding to 802.1X after first authentication fails.

KB 2481614—Windows 7 selects a protocol different from what the GPO states.

KB 2491809—Windows 7 does not prompt for 802.1X credentials to some users on a shared PC.

KB 2835595—Windows 7 does not prompt for 802.1X credentials.

KB 2494172—Windows 7 cannot authenticate if a valid certificate and an invalid certificate are present.

KB 2769121—Windows 7 selects the wrong certificate for a machine migrated across two forests.

KB 2736878—Windows 7 authentication fails intermittently.

Vivek Santuka, CCIE #17621 maintains a blog entry on the Cisco Support Forums with details on the subject. That blog is located at https://supportforums.cisco.com/blog/12256681/getting-past-intermittentunexplained-8021x-problems-windows-7.

Supplicant Provisioning Logs

If an endpoint attempts a BYOD onboarding flow but is not able to complete the native supplicant provisioning (NSP) process, examining the local endpoint logs might be the only way to find the root cause. Each operating system stores the logs in a different location, and some may even require special software to examine the logs.

Here is a list of useful techniques that are used to troubleshoot client-side logging issues:

Microsoft Windows—Enter the Log %temp%\spwProfileLog.txt command to view the client-side logs.

Android—Enter the /sdcards/downloads/spw.log command to view the client-side logs.

Mac OSX—Use the Console application, and look for the SPW process.

Apple iOS—Use the iPhone Configuration Utility (iPCU) to view messages. It can be downloaded from: http://support.apple.com/downloads/.

Network Device Troubleshooting

Seeing the authentication attempts and the authorization results from the point of view of the NAD (the enforcement device) is invaluable when troubleshooting.

The Go-To: show authentication session interface

The command every ISE admin should have in her back pocket is the show authentication interface command. As described in Chapter 12, this command output shows the current state of the authentication and the results sent back from ISE. As shown in the bold text withinExample 22-5, this command is used to show that the WebAuth downloadable ACL (dACL) is applied to the session, the ACL-WEBAUTH-REDIRECT redirection ACL is applied, the session is being redirected to a CWA portal on the ISE node, it was assigned an SGT value of 8, and it is the result of a MAB.

Example 22-5 show authentication session interface