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.
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.
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.