Service provider takeaway: This part of the tutorial focuses on dealing with peripheral devices and hubs that don't have 802.1x supplicants.
Download chapter 2, Port-Based Authentication Concepts,
from Implementing 802.1x Security Solutions by Jim Geier. This chapter provides essential background information on 802.1x protocols and will help you understand the underlying concepts of this tutorial.
Many peripheral devices, such as printers, do not have supplicants. This poses a major problem when you need to include them in an 802.1x port-based authentication system. If you simply plug a printer without a valid supplicant into an existing 802.1x network, for example, the communications among the supplicant, authenticator, and the authentication server will be similar to that described for the missing supplicant. If guest access is available, then the printer will be placed into the guest VLAN. The problem now, however, is that none of the client devices on the protected side of the network can access the printer (see Figure 9-8).
In this case, you may be able to set up access lists
Ideally, choose printers and other peripherals that implement a supplicant with the appropriate EAP-Method for your system. This requires some planning during the design and rollout of the system. You likely won't be able to utilize existing printers in this manner, though, because they probably won't have the capability to support supplicants.
Note: In order to connect printers to an 802.1x port-based authentication system, consider using a print server that implements 802.1x, such as the HP Jetdirect print servers. Include the print server as a user in the authentication server.
Hubs don't work very well with 802.1x systems. Most hubs do not implement supplicants, resulting in the hub being unauthenticated and placed in the guest VLAN. Client devices attaching to the hub also have access to the guest VLAN and can communicate with each other through the hub. If guest access is not supported, then a hub will not be authorized to connect to the network.
Note: By default, 802.1x allows only a single MAC address to be active on a given port.
A hub does not have a MAC address, so the authenticator will not associate any MAC address with the applicable port to which the hub is connecting. This shows up in the statistics of the applicable port as a last received MAC address of "0000.0000.0000." Client devices connecting to the hub have access to the guest network, as shown in Figure 9-9.
Because no MAC address is associated with the port, another client device attaching to the hub can restart the authentication process. This is where problems arise. If this authentication is successful, then the authenticator assigns the port to the applicable VLAN, which may be something other than the guest VLAN. In fact, as soon as the authenticator sends the EAPOL-Start to the supplicant to start the authentication process, the port is switched to an unauthorized state. As a result, any communications taking place between other client devices connecting to the hub with applications on the network will halt, as shown in Figure 9-10.
To avoid this situation, you could enable the port to operate with multiple MAC addresses, such as four MAC addresses if the hub allows four connections. This will keep other client devices (due to different MAC addresses) from communicating on the network even if the other client devices have valid supplicants. In other words, adding hubs without proper planning will result in problems that are often difficult to diagnose Therefore, identify any hubs attached in this manner and redesign the architecture accordingly.
Read part 1 of how to troubleshoot 802.1x missing supplicant problems.
About the author
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.
This was first published in June 2008