This tutorial is excerpted with permission from the book, Implementing 802.1x Security Solutions (ISBN: 978-0-470-16860-8), written by Jim Geier.
Also consider our free Download: Chapter 2, Port-Based Authentication Concepts. This chapter provides essential background information on 802.1x protocols and will help you understand the underlying concepts of this tutorial.
The most common 802.1x problem you’ll likely need to troubleshoot is when you have a client device attached to the network that can’t authenticate. In most cases, these clients will be placed in the guest VLAN (if available) instead of the protected side of the network. You’ll often hear related complaints finding their way to the help desk. As a result, you must be ready to identify and resolve the underlying problems.
Start by gathering information about the problem by getting answers to the following questions:
1. Is there an active supplicant on the client devices? The user may be a visitor or a new hire who has not been set up for accessing the protected network. If this is the case, then the 802.1x system is doing the right thing by not allowing the client device on the network.
2. Is the client device on the guest network? If you can browse the Internet
but not reach protected corporate applications, then the device is likely on
the guest network. Check the RADIUS logs, however, to be sure.
2. Is the client device on the guest network? If you can browse the Internet but not reach protected corporate applications, then the device is likely on the guest network. Check the RADIUS logs, however, to be sure.
3. How long does it take for the client device to be placed onto the guest network or a protected VLAN? The user may be able to tell you this, but be sure to get realistic numbers. Some frustrated users may say “It took an hour to get connected!” although the actual time was only three minutes. As we’ll discuss later in this chapter, the unavailability of a primary authentication server often causes significant delays (several minutes) during authentication. A delay can also result from a network infrastructure having problems that slowed down packet delivery.
4. Was the client device able to access the guest network but then, without any changes to the client device, was not able to access anything? Sometimes, the addition of a hub can cause problems such as this, and we’ll look at this scenario in more detail later in this chapter.
5. How are the 802.1x port-based authentication protocols operating? View
the system logs and run some 802.1x debug processes to understand what,
when, and how packets are being sent. In addition, identify the state of
various components. In order to accomplish this, you might need to attempt
authenticating the client device to the network yourself.
5. How are the 802.1x port-based authentication protocols operating? View the system logs and run some 802.1x debug processes to understand what, when, and how packets are being sent. In addition, identify the state of various components. In order to accomplish this, you might need to attempt authenticating the client device to the network yourself.
6. In the case of mobile applications, where in the facility do the authentication issues occur? This could pinpoint where there might be signal coverage holes or strong RF interference that’s limiting or even blocking communications from occurring between the supplicant and the authenticator.
7. Were any changes made to the system or network prior to when the authentication problems began appearing? If so, consider whether these changes could have caused the problem, and correct them as appropriate. Spend some time getting answers to these questions and any others you feel are pertinent based on your experience. Try to avoid solving what appears to be the problem too early. You might go down the wrong path and leave underlying problems present before learning all of the issues.
Once you have sufficient data to work with, apply classic system troubleshooting principals: analyze information you know about the system and figure out where it broke. It’s often best to start from the beginning of the authentication process, such as when the client device first connects to the network, and then follow through the process to the end. You’ll find that it breaks somewhere.
Be certain to fully diagnose the system in order to find the root of the problem. For example, suppose a user is experiencing delays when authenticating with the primary server. As a fix, you might replace an old 10 Mbps Ethernet card in the server with a newer 100 Mbps card. The time to authenticate improves slightly, but the bigger problem is that the authentication process spans a wide area network that introduces significant delays. Often, difficulty solving a problem other than the root problem is caused by not having sufficient data regarding the issues you’re trying to resolve. That is why it’s so important to do some probing and collect as much data as possible (and practical).
Be aware that the root problem causing issues with authentication may not be associated with the 802.1x port-based authentication protocols. For example, significant delays during authentication over a wireless network may result from significant RF interference or a coverage hole.