Troubleshooting 802.1x Missing Supplicant Problems (Part I)
June 20, 2008
A common problem with 802.1x port-based authentication systems is when the supplicant is missing or inoperative. Here, we offer tips on how to diagnose and solve these problems.
Download Chapter 2, Port-Based Authentication Concepts, free of charge. This chapter provides essential background information on 802.1x protocols that will help you understand the underlying concepts of this tutorial.
With an 802.1x system that has been up and running successfully for some time, a common source of authentication problems are issues related to the supplicant. After ruling out network access and infrastructure issues, a good place to start within the realm of 802.1x is the supplicant.
The supplicant is missing
If a user complains that he or she cant access a particular server on the corporate network, determine whether the user has a valid supplicant. The user may have brought in a laptop from home for use on the corporate network, unaware that an 802.1x supplicant is required. In this case, the user may be granted access to the public network, including access to the Internet, but without access to the rest of the corporate systems. Of course, with these situations, you need to equip the user with a valid supplicant if they are authorized.
Note: The most frequent reason for placing a client device in a guest VLAN is lack of supplicant software or a supplicant that is not functioning correctly.
Missing supplicant behavior
The following steps describe the flow of packets and tasks that occur in a debug routine when there is a missing or disabled supplicant (see Figure 9-6):
1. The port on the authenticator is made active with an unauthorized state.
2. The authenticator sends an EAP Failure packet.
3. The authenticator sends an EAP Request Identity packet.
4. After 30 seconds (the default timeout), the authenticator sends a second EAP Request Identity packet
5. After another 30 seconds, the authenticator gives up because the maximum number of attempts (the default of 2) has been exceeded.
6. The authenticator determines whether a guest VLAN has been configured.
7. If a guest VLAN is available, then the authenticator authorizes the port for the guest VLAN number configured in the authenticator (if implemented), and the client device has access to services available on the VLAN. This is generally only Internet connectivity outside the firewall of the company. Figure 9-7 illustrates this conclusion.
8. If a guest VLAN is not configured, then the authenticator leaves the port status in the unauthorized state, and the client device has no access to anything beyond the authenticator.
With this process, there is no need for the authenticator to communicate with the authentication server. Thus, the authenticator is the decision-maker when it comes to supplicants that are either missing or not enabled. The process is fairly automatic from the perspective of users. They dont have to input a username and password, but they will experience a connection time that often exceeds 60 seconds. Of course, this will be annoying to most users, prompting them to contact the help desk. Therefore, if you receive trouble calls indicating delays of a minute or so when user devices are authenticating, ensure that the supplicant is present and enabled on the client device. That is often the reason for this problem.
Note: Sometimes in the case of a missing or disabled supplicant, when an authentication is not successful, debugging might indicate that the port is assigned to a correct VLAN, but the port is not active. This can be confusing when found, but keep in mind that the client still doesnt have access to the protected side of the network.
Jim Geier provides independent consulting services and training to companies developing and deploying wireless networks for enterprises and municipalities. He is the author of a dozen books on wireless topics. He is a frequent and long-time contributor to Wi-FiPlanet.