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.