Question on 802.1x

Its my understanding that once the command:

Switch(config)#dot1x system-auth-control

...and the appropriate aaa new-model and radius server(s) are defined, that all ports are placed into the "force-unauthorized" state by default. This basically turns the ports off, and is just a good default security measure. By going into port config mode and selecting auto you are allowing people to authenticate on a port (those that CAN authenticate properly through the radius server). And then then force-authorize is like an explicit permit for the switchport. We did this for users that were using one of the public access computers within the facility (because if you leave the switchport blank...without the
"dot1x port-control auto" command it is going to deny access by default). Hopes this helps, and is accurate. Most of it is based on the theory I have from reading, and the past configs/advice from previous engineers. I should lab it up and see if the ports are indeed blocked after the dot1x system-auth-control command.

From the BCMSN Official Exam Guide 4th Edition:

Step 4 Enable 802.1x on the switch:

Switch(config)#dot1x system-auth-control

Step 5 Configure each switch port that will use 802.1x:

Switch(config)# interface type mod/num

Switch(config-if)#dot1x port-control {force-authorized | forceunauthorized

| auto}

Here, the 802.1x state is one of the following:
• force-authorized—The port is forced to always authorize any
connected client. No authentication is necessary. This is the default state
for all switch ports when 802.1x is enabled.

394 Chapter 15: Securing Switch Access

• force-unauthorized—The port is forced to never authorize any
connected client. As a result, the port cannot move to the authorized state
to pass traffic to a connected client.
• auto—The port uses an 802.1x exchange to move from the unauthorized
to the authorized state, if successful. This requires an 802.1x-capable

application on the client PC.

Under Force-authorized, it states it is the default port state once dot1x is enabled. On the other hand, Cisco.com Catalyst 2950 Desktop Switch Software Configuration Guide, 12.1(9)EA1 section for configuring 802.1x says that unathorized is the default. Which confirms your post.

There lies my confusion, is the default authorized or unauthorized and if it's authorized, what point is there to unauthorized? Why ever use it over auto? I've labbed it but wasnt really looking for this particular issue. Maybe i'll run through the setup again and see for myself, but does anyone else have any experience with this? Thanks for your input by the way.

SysAdmin,
Did an interesting little lab on this tonight on one of my 3550's. Ran the commands:
aaa new-model
radius-server host xxx.xxx.xxx.xxx
aaa authentication dot1x default group radius
dot1x system-auth-contol

I then did a show dot1x all and received the usual output. The show dot1x interface [type/num] revealed nothing however. I added the command dot1x port-control auto on fa0/1 and ran the show dot1x interface fa0/1 command again to verify that I got some output...and I did. However, when I hooked a laptop up to port fa0/2 (which I had ran no interface commands on yet), the port stayed up and up, and I was able to ping throughout the network (hmmm...). Just to play a bit I ran the port through the different states (auto, force-auth, force-unauth), and they reacted as expected.

So I guess your question has some genuine validity that I would now like to know the answer to as well. Why have force-auth, or force-unauth as command choices if
1) Auto forces you to authenticate, and if you cant it puts the line protocol in the down state, and
2) by default you are allowed access through the switchport (with no switchport config)

I can see why you would not want the switch to automatically default to a force-unauthorized state though. Think about a case where you are implementing dot1x on a live switch....if it defaulted to unauthorized and you had users working they would immediately be dropped and forced to re authenticate. Would probably piss some people off. But it seems like the more secure choice. Ya, why go through the trouble of typing dot1x port-control force-unauthorize when you can type shutdown?

Good topic!

See, See!!!! Confusion lol. I didnt get a chance to lab it last night, but I have labbed it before and my memory is getting a bit sharper on the subject. I do remember it NOT defaulting to force-unauth. It defaulted to nothing, and all traffic was allowed to flow. Anyone know why you would ever use anything but no configuration or auto on an interface? Why is force-auth or force-unauth necessary? Thanks Jason for the curiousity with me, when do you take the BCMSN?

I am looking at early September. Good luck on yours Saturday. Let us know.

Most def, i'm looking forward to it. Then it's on to the ISCW, then finishing up with the ONT. A short break, maybe a month, then on to the CCIE written.

mikej412

jason_lunde wrote: »

Why have force-auth, or force-unauth

While printers may be getting smarter, most network printers still probably wouldn't have a clue about how to log into the network.

And for forced-unauth, while you should have physical security and people shouldn't have access to plug anything they want into unused switchports, it's sort of the same reason people who get home alarm systems also put sensors on windows -- while no one should be entering the house through the window, some buglers "didn't get the memo" or don't have manners and don't follow the rules.

If you read the posts, you would understand why we are asking these questions. It isnt necessarily as cut and dry as you state, which was a little insulting. I understand the need for security. Your post is common sense.

For printers, dont set any dot1x statement on that port. The default behavior in practice seems to be nothing, always open. For secure ports, set an auto state. It requires authentication and if none is received, you cant access the port. So why would you use force-unauth when you could just use Auto or no config? I'm going to lab it again tonight and make sure that is what's happening, but I am fairly sure that is the default behavior after dot1x system-auth-control is run. All ports are placed into an open state. Why would you lock down a port with force-unauth, a state that allows for no traffic to pass and cannot be authenticated ever?

Has ANYONE used this feature extensively, and if so, what was the context? Can anyone give any real insight as to why you would use the above mentioned option?

networker050184

Like Mike said its just another layer of security. Force auth would be used on ports that plug into something that doesn't authenticate like a printer as he stated. I think you are just looking way too deep into it.

Well I have been in a environment with 802.1x but never had the switch side setup (I did setup FreeRadius and OpenSSL as a test for some WPA enterprise for wireless). I want to say that the net admins used force-authorized for anything that didn't support 802.1x (or anything they didn't want to support). Just a guess but in this environment they had VoIP phones and would disable any computer account and do a force-unauthorized on the port when a computer was out off compliance. The phones did not take part in the authentication process. With shutdown it would cut out the phone but with force-unauthorized it would still work. I don't have the ability to lab this up right now but you may want to look at something along those lines.

I haven't had a chance to lab this up and try it so I do not know for sure.

Turning on complicated services to enable the same level of security that could be gained by simply shutting down a port is a bad security solution. I cant believe that the IEEE would have designed the command for that purpose. But maybe you're right. Doesnt make sense which is why in my head there's got to be a deeper level that i'm just not aware of.

Force-auth essentially works like a shutdown command Wastedtime, so the phones would not work. That wouldnt work, but thanks for your weigh in. What a purplexing question. I guess it doesnt matter for the exam, just really curious as far as the theory is concerned.

networker050184 wrote: »

Like Mike said its just another layer of security. Force auth would be used on ports that plug into something that doesn't authenticate like a printer as he stated. I think you are just looking way too deep into it.

For some odd reason I got everything to lab this up but Cat V cables and power for a few 7941 phones. Later this week I plan on getting this up to try it out.

Good deal Wasted, let me know how that works out. I dont have any phones, so I cant lab that portion of it. What types of switches do you have?

If I get a chance to do it tomorrow it will be 3550 SMI (no PWR), 1760 with CME, some 7941s, and windows 2k3 for Radius/certificate server. I should have 2 power cubes in the mail tomorrow.

Well I went through and set it up. Like usual I had some issues with the certificate authentication and I don't have time to work it out. I did however get a chance to look at the dot1x config and a bit of how Cisco works around the voice vlan with 802.1x. Regardless of the host mode or dot1x status the phone will work (with voice vlan/CDP enabled). From the debugs it look like it makes a automatic host access entry for the mac of the phone. One thing I did notice is even with force-authorized the switch will still send EAPOL start, but right after that it sends a EAP Success.

cisco_trooper

wastedtime wrote: »

Well I have been in a environment with 802.1x but never had the switch side setup (I did setup FreeRadius and OpenSSL as a test for some WPA enterprise for wireless). I want to say that the net admins used force-authorized for anything that didn't support 802.1x (or anything they didn't want to support). Just a guess but in this environment they had VoIP phones and would disable any computer account and do a force-unauthorized on the port when a computer was out off compliance. The phones did not take part in the authentication process. With shutdown it would cut out the phone but with force-unauthorized it would still work. I don't have the ability to lab this up right now but you may want to look at something along those lines.

I haven't had a chance to lab this up and try it so I do not know for sure.

Did you happen to run dynamic vlans? This topic always catches my attention. I never got dynamic vlans to work in an environment with roaming profiles. Local profiles worked fine if I remember correctly.

How did the exam go SysAdmin? Hope it went well...I am going to take a swing in 2-3 weeks!