Click here to Download PDF Version of this Article
 

Using 802.1x Port Authentication To Control Who Can Connect To Your Network

Author: Colin Weaver Company: ITdojo, Inc. Last Revision: 1/31/05

  
 
802.1x, for the uninitiated, is an IEEE standard that has been around since about 2001. The purpose of 802.1x is to provide some control for what devices can be physically connected (via cable or RF) to a network. In essence, it creates your ability to say, “You can plug stuff into my switches all day long but if it’s not supposed to be here, it won’t work.” Not bad. Not bad at all. The devil, as always, is in the details. Getting it set up and working requires a fair amount of understanding and configuration.

Each device in the 802.1x framework has a job and a name. They are:
  • Supplicant – this is a sexy term used to describe the user PC. It’s the device that is being authenticated. This could be either the device or the user… or both.
  • Authenticator – this is the switch. It’s the device that prevents you from being able to get on the network until you have been proven worthy (e.g. authenticated & authorized)
  • Authentication Server – this is the server somewhere in your network that actually authenticates the supplicant. This is a RADIUS server or a TACACS+ server. Either one will work. In this article we will use RADIUS. This particular role can lead to some confusion because the authentication server may not actually do the authentication. It is possible (and probable) that the authentication server will send the authentication request to yet another device. In a Microsoft environment, for example, this other device could be and Active Directory Domain Controller.

Here is the general flow (note that this is a greatly simplified explanation):
  • Step 1 – PC (supplicant) tries to send frames in to the network (via RF or cable).
  • Step 2 – The switch (authenticator) receives the frame from the PC (supplicant) and, since 802.1x is enabled, doesn’t allow it to pass.
  • Step 3 – The switch (authenticator) sends a message to the PC (supplicant) and says, “Pack sand. You’ve got to authenticate first”.
  • Step 4 – The PC (supplicant) sends an authentication request to the authenticator (switch).
    • Note: In many situations the PC (supplicant) knows it is supposed to authenticate so it starts off the conversation by asking to authenticate rather than trying to send other types of frames. That’s more efficient when you think about it.
  • Step 5 – The switch (authenticator) receives the authentication request and forwards it back to the authentication server (RADIUS or TACACS+).
  • Step 6 – The PC (supplicant) and the authentication server have an authentication exchange. The switch (authenticator) simply passes the frames back and forth between them.
    • A couple of beautiful things are happening here:
      1. The switch has no idea how the PC and the authentication server are actually authenticating to each other… and it doesn’t need to. All it needs is a “SUCCESS” or “REJECT” message from the authentication server when it’s over. This eliminates the need for the switch (authenticator) to have detailed knowledge about all the possible ways two devices might authenticate (e.g. it’s very flexible).
      2. The switch does allow authentication frames… but that’s pretty much it. No other frames are allowed to pass until authentication has succeeded.
  • Step 7 – Assuming the PC can successfully authenticate to the authentication server, the authentication server sends the switch a SUCCESS message.
  • Step 8 – Having received a SUCCESS message from the authentication server, the switch allows the PC to begin sending other frames onto the network.
  • Step 9 – All is right in the universe.

You can get all of the gory details on how the exchange works by doing a few Google searches. For today, we’ve got enough detail to move along.

A pretty common graphic that you’ll see is similar to the one below. It illustrates the exchange outlined in the steps above.

  
 

My main area of focus for this article is on how to configure a Cisco switch to be an authenticator but I’ve got to throw in a few details on how the Windows part of this all comes together. This document was written using the following equipment:

  • PC running Windows XP Professional (member of the phatcat.com domain)
  • Server running Windows Server 2003 with DHCP Services installed
  • Server running Active Directory
  • Server running Microsoft’s implementation of RADIUS (Internet Authentication Service)
  • Cisco Catalyst 2950 Switch running C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA2
  • Enhanced Image filename: c2950-i6q4l2-mz.121-22.EA2.bin

The network I am using is shown below. It’s about as vanilla as you can get. Adding complexity to your network doesn’t really change things much.

In the rest of this article we will look at each of the three roles separately. Here is the order in which we will examine each of the configurations:

  1. 802.1x Supplicant (Windows XP Pro PC)
  2. 802.1x Authentication Server (Windows Server 2003)
  3. 802.1x Authenticator (Cisco Catalyst 2950 Switch)
 
 
HOME     -    CONTACT  US