• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Standard Disclaimers
  • Resume/Curriculum Vitae
  • Why Blog?
  • About
  • (Somewhat Recent) Publication List

packetqueue.net

Musings on computer stuff, and things... and other stuff.

802.1x

August 11, 2010 802.1x

802.1x for Wired Networks (Part 2)

Read­ing Time: 6 min­utes

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.

Share

July 29, 2010 802.1x

802.1x for Wired Networks (Part 1)

Read­ing Time: 3 min­utes

Most of you are prob­a­bly famil­iar with the IEEE 802.1x spec­i­fi­ca­tion, at least in gen­er­al terms, but are more than like­ly used to see­ing it applied in the con­text of wire­less net­works and ser­vices.  In this mul­ti-part series, I’m going to explore the use of 802.1x as it applies to wired net­works.  In part I we’ll begin with what 802.1x is and what it isn’t, fol­lowed by some basic con­fig­u­ra­tion adher­ing to Cisco’s cur­rent best prac­tices rec­om­men­da­tions.  Then, in part II we’ll fol­low-up with a more com­plex con­fig­u­ra­tion that you real­ly, real­ly don’t want to use but I put out as an aca­d­e­m­ic exam­ple of what can be done if you like the kind of com­plex­i­ty that will guar­an­tee you or your sup­port staff nev­er sleep again.  We’ll also talk about what hap­pens when you mix oth­er secu­ri­ty fea­tures with 802.1x.

Dot1x, as I’ll be refer­ring to it from now on, is at its most fun­da­men­tal lev­el sim­ply a method for ver­i­fy­ing that a device con­nect­ed to your net­work is who it appears to be.  If a com­pa­ny-owned com­put­er con­nects to the net­work, we let them have access to cer­tain resources.  If some­one con­nects an unau­tho­rized com­put­er (per­son­al lap­top, etc.) to the net­work, they have no access to any­thing.  This is the basic idea behind dot1x when we’re talk­ing about wired net­works.

Dot1x is not encryp­tion, and doesn’t pro­vide any kind of pri­va­cy or anti-replay pro­tec­tion like IPsec.  It isn’t intend­ed for that.  Think of dot1x as login secu­ri­ty for your switch ports.  If your switch ports are con­nect­ed through to wall jacks, with no authen­ti­ca­tion, then rogue machines have at least lim­it­ed (lay­er 1 and 2) access to, at min­i­mum, the VLAN or net­work that switch port is a part of.  Is that enough to cause dam­age to your net­work?  You’ll have to decide for your­self based on your own appetite for risk and inter­nal secu­ri­ty poli­cies.

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 cov­er the two that hap­pen on the Cis­co side:

(1)    Con­fig­ure your switch to act as an authen­ti­ca­tor

(2)    Con­fig­ure indi­vid­ual switch ports to use dot1x

(3)    Con­fig­ure your Radius Serv­er to pro­vide authen­ti­ca­tion and autho­riza­tion to clients

(4)    Turn on dot1x authen­ti­ca­tion on your clients (Win­dows, Mac, Lin­ux, etc.)

The first step is fair­ly straight for­ward, and that is to tell your switch you want to do dot1x authen­ti­ca­tion.  In order for this to work you have to have AAA enabled which is going to change your entire login method, so def­i­nite­ly play around with in a lab if you’re not famil­iar with it already.  So, the com­mands we want look like this, entered from Glob­al Con­fig mode:

! Turn on aaa authentication
aaa new-model
! 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
dot1x system-auth-control

 

Now that we have the switch set to authen­ti­cate clients to our Radius (Remote Authen­ti­ca­tion Dial-in User Serv­er) Serv­er, we have to make sure the Radius serv­er has some poli­cies defined.  This is beyond the scope of what I’m going to cov­er in this post, though if I get enough com­ments request­ing it I can cov­er that por­tion in anoth­er post.  Basi­cal­ly you’re just telling your Radius serv­er (typ­i­cal­ly IAS or NPS on some ver­sion of Win­dows Serv­er) that the switch will be con­tact­ing it for client authen­ti­ca­tion, and what that client can and can’t do once authen­ti­cat­ed (the autho­riza­tion piece.)

The next step is to con­fig­ure your clients to use dot1x authen­ti­ca­tion, and this is dif­fer­ent for each client OS you use.  Win­dows clients need to have a ser­vice turned on which is not on by default, where­as Mac­in­tosh has the ser­vice turned on but not con­fig­ured.  For Lin­ux and all man­ner of mobile devices, there are as many options as there are devices, so I’ll leave that as an exer­cise for the read­er.  As above with the Serv­er sec­tion, if I get enough com­ments I can cov­er the Win­dows and Mac­in­tosh con­fig­u­ra­tion piece in anoth­er post.  Mobile devices and Lin­ux I have lim­it­ed expe­ri­ence with as per­tains to dot1x set­up.

The last step in this whole busi­ness is to turn on dot1x authen­ti­ca­tion on a per port or port-range basis.  Keep in mind that you’ll want to test this before turn­ing on carte-blanche as I’ve seen a lot of mis­con­fig­u­ra­tion in the ini­tial set­up and the last thing you want is a horde of scream­ing users look­ing for your head on a stick.  There­fore, to turn on one port, pre­sum­ably for test­ing, we do like so from inter­face con­fig­u­ra­tion mode:

dot1x port-control auto
! kind of anti-climactic isn’t it

 

That is the basic con­fig­u­ra­tion of dot1x on a Cis­co switch.  In part II of this series, I’ll explore some more com­plex con­fig­u­ra­tions, as well as some less-than-ide­al ram­i­fi­ca­tions of com­bin­ing oth­er secu­ri­ty fea­tures with dot1x.  As with any­thing you con­fig­ure in the realm of secu­ri­ty in par­tic­u­lar, it is always a trade-off between secu­ri­ty and usabil­i­ty and dot1x is no excep­tion.  Test, test, and test some more.

Share

Copyright© 2023 · by Shay Bocks