802.1x

One of the nice things about work­ing with Cis­co equip­ment, as opposed to many oth­er brands, is that you tru­ly do get a smor­gas­bord of fea­tures and capa­bil­i­ties.  On the flip side of that coin, how­ev­er, the bad thing about work­ing with Cis­co equip­ment is that you can real­ly paint your­self into a cor­ner with fea­tures, even when you know what you’re doing.  Many fea­tures and capa­bil­i­ties that you have access to on a mul­ti­lay­er switch (or bridge, layer‑2 router, for­warder, oth­er nom-de-jour) con­flict with one anoth­er, are just not near­ly as use­ful as they might seem at first glance, or bring a num­ber of gotchas to the prover­bial ball-game, often far out­weigh­ing any ben­e­fits inher­ent there­in.  Dynam­ic VLAN assign­ment with 802.1x is one of those fea­tures.

If you’ve read the first part in this series on dot1x, or are gen­er­al­ly famil­iar with the tech­nol­o­gy, you know that dot1x on a wired net­work allows a sup­pli­cant (soft­ware on your PC) to com­mu­ni­cate with an inter­me­di­ary (the switch) in order to facil­i­tate hard­ware lev­el authen­ti­ca­tion of assets on the cor­po­rate net­work.  In oth­er words, the switch acts as a traf­fic-cop and only allows known sys­tems to gain even layer‑2 access to the net­work.  This hap­pens in many cas­es pri­or to oth­er types of authen­ti­ca­tion and autho­riza­tion and can be part of an over­all secu­ri­ty strat­e­gy on your net­work.

When you try to do more with wired dot1x is where things get a lit­tle more fun.  And by fun I mean goug­ing your eyes out with dull imple­ments, or ran­dom­ly beat­ing the near­est co-work­er with the weight­ed end of a con­sole cable.  Doing more in this case refer­ring to assign­ing com­put­ers on your net­work to spe­cif­ic VLANs based on what­ev­er poli­cies you use to do these things.

For argument’s sake, and because we’ve already estab­lished that you’re prob­a­bly a masochist for doing things this way, let’s just assume that you are using VTP (VLAN Trunk­ing Pro­to­col) to keep your VLANs con­sis­tent across all switch­es in a giv­en cam­pus or build­ing.  Let’s also assume that you have  a cou­ple of VTP Servers, and all oth­er switch­es are in client mode.  This would also be a good time to men­tion VTP Pass­words, domains, and care­ful plan­ning, but I think we’ve estab­lished that you might be a bit of a rene­gade.  So we’ll move on.

If you’ve already got­ten through the first part of this series, then you already have your switch­es talk­ing to a back­end access and autho­riza­tion serv­er; most like­ly this is NPS on Win­dows 2008 Serv­er or some oth­er RADIUS serv­er tied into your user data­base.  The main thing you have to do on the RADIUS side that is dif­fer­ent for this con­fig­u­ra­tion is to deter­mine what user groups, or com­put­er groups, etc. are going to be assigned to what VLAN.

So your main switch con­fig­u­ra­tion, assum­ing NPS, could look some­thing like this and would be defined under the Radius Clients sec­tion of Net­work Pol­i­cy and Access Ser­vices:

All this does is estab­lish a con­nec­tion pro­file which allows your switch (or what­ev­er device) to speak to the NPS serv­er.  For net­work poli­cies we’ll have two defined for our exam­ple:

One of these is for the IT group, as you might have guessed.  The oth­er is for a Guest access group that we’ll talk about soon.  These poli­cies, by the way, are very flex­i­ble and can be writ­ten in a myr­i­ad of dif­fer­ent ways.  The exam­ples here are just one par­tic­u­lar way of imple­ment­ing this type of con­trol.

If we break open one of our poli­cies to look at it, you’ll see some­thing like so:

We actu­al­ly have a lot more in this sec­tion that we’re not show­ing, includ­ing many dia­log box­es and con­fig­u­ra­tion tabs.  The sum­ma­ry above, how­ev­er, is enough to give you a gen­er­al sense of what’s going on.  While the whole break­down is beyond the scope of what I’m writ­ing here, a cou­ple of the key things you’ll want to take note of are:

1. Tun­nel-Pvt-Group-ID: This is the VLAN you want to assign to this group.  This had bet­ter match what exists in your VTP domain, on the switch or switch­es in ques­tion.
2. Tun­nel-Type: This is pret­ty self-explana­to­ry, but I’ve seen it over­looked.
3. Tun­nel-Medi­um-Type: The 802 here refers to, you guessed it, 802.1x

This is all fair­ly stan­dard serv­er-side NPS or IAS con­fig­u­ra­tion for Win­dows.  Oth­er sys­tems will, of course dif­fer­ent and have their own idio­syn­crasies to deal with.  I assume that you or some­one you work with is famil­iar with this on some lev­el, as almost all major enter­prise net­works these days use a cen­tral data­base like Active Direc­to­ry to not only con­trol user access to the net­work gen­er­al­ly, but also to authen­ti­cate and autho­rize all man­ner of con­nec­tions from wire­less dot1x to SSL VPN.

On the Cis­co side, things are actu­al­ly con­sid­er­ably clean­er as you might expect.  Since you should already have dot1x work­ing from our first part in this series, only a few changes are nec­es­sary:

1. Define a guest VLAN (in our exam­ple we’re using this but it is far from nec­es­sary)
2. Define a quar­an­tine, or authen­ti­ca­tion fail­ure VLAN (again, our exam­ple, etc.)
3. Define con­fig­u­ra­tion for indi­vid­ual switch ports, or more like­ly for ranges.

Steps one and two above shouldn’t need explain­ing if you’ve come this far: just make the VLANs and be done with it.  For step three, we’re going to use the fol­low­ing con­fig­u­ra­tion:

dot1x pae authenticator

dot1x port-control auto

dot1x timeout quiet-period 5

dot1x timeout server-timeout 10

dot1x max-reauth-req 1

dot1x guest-vlan 405

dot1x auth-fail vlan 404

dot1x auth-fail max-attempts 1

Note that we are using a few extra options here that aren’t, strict­ly speak­ing, need­ed (the time­outs, qui­et peri­ods, etc.)  Don’t let those dis­tract you from the core ele­ments.  The dot1x guest-vlan and auth-fail vlan state­ments in par­tic­u­lar are inter­est­ing.  What we’re basi­cal­ly doing here are a cou­ple of things:

1. When the switch port receives an EAPoL from the sup­pli­cant (PC) indi­cat­ing dot1x capa­bil­i­ty, the cre­den­tials are test­ed.  If they are good, the device is auto­mat­i­cal­ly put into the appro­pri­ate VLAN as pre­scribed by our RADIUS serv­er.
2. If fail­ure occurs dur­ing authen­ti­ca­tion (ie; EAPoL capa­ble, but wrong cre­den­tials, etc.) then the device is put into the auth-fail VLAN (404 in this case.)
3. If the device in ques­tion has no dot1x capa­bil­i­ty or the capa­bil­i­ty 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 unaf­fect­ed by the dot1x con­fig­u­ra­tion.  Also, you have options to force a port into a per­ma­nent autho­rized or unau­tho­rized state (using the dot1x port-con­trol force-autho­rized or force-unau­tho­rized com­mand) if you need this func­tion­al­i­ty.

So when all put togeth­er, what does this con­fig­u­ra­tion get you besides a headache?  Seam­less and dynam­ic con­trol of clients, as well as some pret­ty good secu­ri­ty.  You have the clients you know being put into their assigned VLANs regard­less of where in the net­work they are.  This can be good if you rely heav­i­ly on VLAN access con­trol lists (VACLs) for secu­ri­ty.  Clients who fail autho­riza­tion are imme­di­ate­ly dumped into what can be set up as a black-hole VLAN and then dealt with as need­ed.  Every­one else—those we don’t know or are old­er clients—can be put into a guest VLAN where maybe we just give them access out to the Inter­net at large and pos­si­bly a print­er.  This is a handy fea­ture for audi­tors or cus­tomers who may set up in a con­fer­ence room and need some access, but very lim­it­ed.  Anoth­er use for this might be in con­junc­tion with a Net­work Access Con­trol (NAC) sys­tem.  In this case you could test for appro­pri­ate patch lev­els of clients, appro­pri­ate fire­wall set­tings, unau­tho­rized soft­ware or what­ev­er, then dump the client into a quar­an­tine VLAN for reme­di­a­tion.

In the next part of this series I’ll explore some switch port secu­ri­ty fea­tures that are arguably more use­ful than dot1x, but con­flict in some way forc­ing you to make a choice.  We’ll also talk about the things that can break in some way when run­ning dot1x.  Ulti­mate­ly secu­ri­ty pol­i­cy will be deter­mined by busi­ness needs—in my case we have a pret­ty heavy secu­ri­ty bur­den due to the busi­ness we’re in.  You, how­ev­er, may find the headache of dot1x is too much to deal with when com­pared with the admin­is­tra­tive over­head to man­age it.  You may also decide that the things you give up to run it just aren’t worth the cost.  Hope­ful­ly, when we’re all done you’ll have enough infor­ma­tion to make that choice intel­li­gent­ly.