Most of you are probably familiar with the IEEE 802.1x specification, at least in general terms, but are more than likely used to seeing it applied in the context of wireless networks and services. In this multi-part series, I’m going to explore the use of 802.1x as it applies to wired networks. In part I we’ll begin with what 802.1x is and what it isn’t, followed by some basic configuration adhering to Cisco’s current best practices recommendations. Then, in part II we’ll follow-up with a more complex configuration that you really, really don’t want to use but I put out as an academic example of what can be done if you like the kind of complexity that will guarantee you or your support staff never sleep again. We’ll also talk about what happens when you mix other security features with 802.1x.
Dot1x, as I’ll be referring to it from now on, is at its most fundamental level simply a method for verifying that a device connected to your network is who it appears to be. If a company-owned computer connects to the network, we let them have access to certain resources. If someone connects an unauthorized computer (personal laptop, etc.) to the network, they have no access to anything. This is the basic idea behind dot1x when we’re talking about wired networks.
Dot1x is not encryption, and doesn’t provide any kind of privacy or anti-replay protection like IPsec. It isn’t intended for that. Think of dot1x as login security for your switch ports. If your switch ports are connected through to wall jacks, with no authentication, then rogue machines have at least limited (layer 1 and 2) access to, at minimum, the VLAN or network that switch port is a part of. Is that enough to cause damage to your network? You’ll have to decide for yourself based on your own appetite for risk and internal security policies.
So, what do we do to make it all work? I’m glad you asked. You’ll need to do four things, of which I’ll cover the two that happen on the Cisco side:
(1) Configure your switch to act as an authenticator
(2) Configure individual switch ports to use dot1x
(3) Configure your Radius Server to provide authentication and authorization to clients
(4) Turn on dot1x authentication on your clients (Windows, Mac, Linux, etc.)
The first step is fairly straight forward, and that is to tell your switch you want to do dot1x authentication. In order for this to work you have to have AAA enabled which is going to change your entire login method, so definitely play around with in a lab if you’re not familiar with it already. So, the commands we want look like this, entered from Global Config mode:
! Turn on aaa authentication
! Define our Radius server, port, and shared secret (must match
! with our server setup)
radius-server host 10.0.0.1 auth-port 1812 key abc123
! Here we tell the switch that our default authentication method is to
! use the Radius host we defined above
aaa authentication dot1x default group radius
! Enable dot1x on the switch
Now that we have the switch set to authenticate clients to our Radius (Remote Authentication Dial-in User Server) Server, we have to make sure the Radius server has some policies defined. This is beyond the scope of what I’m going to cover in this post, though if I get enough comments requesting it I can cover that portion in another post. Basically you’re just telling your Radius server (typically IAS or NPS on some version of Windows Server) that the switch will be contacting it for client authentication, and what that client can and can’t do once authenticated (the authorization piece.)
The next step is to configure your clients to use dot1x authentication, and this is different for each client OS you use. Windows clients need to have a service turned on which is not on by default, whereas Macintosh has the service turned on but not configured. For Linux and all manner of mobile devices, there are as many options as there are devices, so I’ll leave that as an exercise for the reader. As above with the Server section, if I get enough comments I can cover the Windows and Macintosh configuration piece in another post. Mobile devices and Linux I have limited experience with as pertains to dot1x setup.
The last step in this whole business is to turn on dot1x authentication on a per port or port-range basis. Keep in mind that you’ll want to test this before turning on carte-blanche as I’ve seen a lot of misconfiguration in the initial setup and the last thing you want is a horde of screaming users looking for your head on a stick. Therefore, to turn on one port, presumably for testing, we do like so from interface configuration mode:
dot1x port-control auto
! kind of anti-climactic isn’t it
That is the basic configuration of dot1x on a Cisco switch. In part II of this series, I’ll explore some more complex configurations, as well as some less-than-ideal ramifications of combining other security features with dot1x. As with anything you configure in the realm of security in particular, it is always a trade-off between security and usability and dot1x is no exception. Test, test, and test some more.