One of the nice things about working with Cisco equipment, as opposed to many other brands, is that you truly do get a smorgasbord of features and capabilities. On the flip side of that coin, however, the bad thing about working with Cisco equipment is that you can really paint yourself into a corner with features, even when you know what you’re doing. Many features and capabilities that you have access to on a multilayer switch (or bridge, layer-2 router, forwarder, other nom-de-jour) conflict with one another, are just not nearly as useful as they might seem at first glance, or bring a number of gotchas to the proverbial ball-game, often far outweighing any benefits inherent therein. Dynamic VLAN assignment with 802.1x is one of those features.
If you’ve read the first part in this series on dot1x, or are generally familiar with the technology, you know that dot1x on a wired network allows a supplicant (software on your PC) to communicate with an intermediary (the switch) in order to facilitate hardware level authentication of assets on the corporate network. In other words, the switch acts as a traffic-cop and only allows known systems to gain even layer-2 access to the network. This happens in many cases prior to other types of authentication and authorization and can be part of an overall security strategy on your network.
When you try to do more with wired dot1x is where things get a little more fun. And by fun I mean gouging your eyes out with dull implements, or randomly beating the nearest co-worker with the weighted end of a console cable. Doing more in this case referring to assigning computers on your network to specific VLANs based on whatever policies you use to do these things.
For argument’s sake, and because we’ve already established that you’re probably a masochist for doing things this way, let’s just assume that you are using VTP (VLAN Trunking Protocol) to keep your VLANs consistent across all switches in a given campus or building. Let’s also assume that you have a couple of VTP Servers, and all other switches are in client mode. This would also be a good time to mention VTP Passwords, domains, and careful planning, but I think we’ve established that you might be a bit of a renegade. So we’ll move on.
If you’ve already gotten through the first part of this series, then you already have your switches talking to a backend access and authorization server; most likely this is NPS on Windows 2008 Server or some other RADIUS server tied into your user database. The main thing you have to do on the RADIUS side that is different for this configuration is to determine what user groups, or computer groups, etc. are going to be assigned to what VLAN.
So your main switch configuration, assuming NPS, could look something like this and would be defined under the Radius Clients section of Network Policy and Access Services:
All this does is establish a connection profile which allows your switch (or whatever device) to speak to the NPS server. For network policies we’ll have two defined for our example:
One of these is for the IT group, as you might have guessed. The other is for a Guest access group that we’ll talk about soon. These policies, by the way, are very flexible and can be written in a myriad of different ways. The examples here are just one particular way of implementing this type of control.
If we break open one of our policies to look at it, you’ll see something like so:
We actually have a lot more in this section that we’re not showing, including many dialog boxes and configuration tabs. The summary above, however, is enough to give you a general sense of what’s going on. While the whole breakdown is beyond the scope of what I’m writing here, a couple of the key things you’ll want to take note of are:
-
Tunnel-Pvt-Group-ID: This is the VLAN you want to assign to this group. This had better match what exists in your VTP domain, on the switch or switches in question.
-
Tunnel-Type: This is pretty self-explanatory, but I’ve seen it overlooked.
-
Tunnel-Medium-Type: The 802 here refers to, you guessed it, 802.1x
This is all fairly standard server-side NPS or IAS configuration for Windows. Other systems will, of course different and have their own idiosyncrasies to deal with. I assume that you or someone you work with is familiar with this on some level, as almost all major enterprise networks these days use a central database like Active Directory to not only control user access to the network generally, but also to authenticate and authorize all manner of connections from wireless dot1x to SSL VPN.
On the Cisco side, things are actually considerably cleaner as you might expect. Since you should already have dot1x working from our first part in this series, only a few changes are necessary:
-
Define a guest VLAN (in our example we’re using this but it is far from necessary)
-
Define a quarantine, or authentication failure VLAN (again, our example, etc.)
-
Define configuration for individual switch ports, or more likely for ranges.
Steps one and two above shouldn’t need explaining if you’ve come this far: just make the VLANs and be done with it. For step three, we’re going to use the following configuration:
dot1x pae authenticatordot1x port-control autodot1x timeout quiet-period 5dot1x timeout server-timeout 10dot1x max-reauth-req 1dot1x guest-vlan 405dot1x auth-fail vlan 404dot1x auth-fail max-attempts 1
Note that we are using a few extra options here that aren’t, strictly speaking, needed (the timeouts, quiet periods, etc.) Don’t let those distract you from the core elements. The dot1x guest-vlan and auth-fail vlan statements in particular are interesting. What we’re basically doing here are a couple of things:
- When the switch port receives an EAPoL from the supplicant (PC) indicating dot1x capability, the credentials are tested. If they are good, the device is automatically put into the appropriate VLAN as prescribed by our RADIUS server.
- If failure occurs during authentication (ie; EAPoL capable, but wrong credentials, etc.) then the device is put into the auth-fail VLAN (404 in this case.)
- If the device in question has no dot1x capability or the capability is turned off (no EAPoL seen) then the device is put into the guest VLAN (405 in this case.)
Note that if you have voice VLANs set up, these are unaffected by the dot1x configuration. Also, you have options to force a port into a permanent authorized or unauthorized state (using the dot1x port-control force-authorized or force-unauthorized command) if you need this functionality.
So when all put together, what does this configuration get you besides a headache? Seamless and dynamic control of clients, as well as some pretty good security. You have the clients you know being put into their assigned VLANs regardless of where in the network they are. This can be good if you rely heavily on VLAN access control lists (VACLs) for security. Clients who fail authorization are immediately dumped into what can be set up as a black-hole VLAN and then dealt with as needed. Everyone else—those we don’t know or are older clients—can be put into a guest VLAN where maybe we just give them access out to the Internet at large and possibly a printer. This is a handy feature for auditors or customers who may set up in a conference room and need some access, but very limited. Another use for this might be in conjunction with a Network Access Control (NAC) system. In this case you could test for appropriate patch levels of clients, appropriate firewall settings, unauthorized software or whatever, then dump the client into a quarantine VLAN for remediation.
In the next part of this series I’ll explore some switch port security features that are arguably more useful than dot1x, but conflict in some way forcing you to make a choice. We’ll also talk about the things that can break in some way when running dot1x. Ultimately security policy will be determined by business needs—in my case we have a pretty heavy security burden due to the business we’re in. You, however, may find the headache of dot1x is too much to deal with when compared with the administrative overhead to manage it. You may also decide that the things you give up to run it just aren’t worth the cost. Hopefully, when we’re all done you’ll have enough information to make that choice intelligently.
