Using 802.

1x Port Authentication To Control Who Can Connect To Your Network

Author: Colin Weaver Company: ITdojo, Inc. Last Revision: 1/31/05 On more than one occasion I have been asked something along the lines of, How do I keep people from bringing their own personal equipment in to the office and connecting it to the network? Its a common problem and I hear it from a lot of admins from all walks of life. Since most of us live in a DHCP world its particularly difficult to keep rogue devices off our network. In the simplest scenario all a user has to do is bring in a hub or switch from home and connect it to the drop that normally goes to their PC. After that they can connect pretty much whatever they want and, since youre running DHCP in your shop, you happily (though unknowingly) give them an IP address. Despite having signed their understanding of the corporate security policy when they joined your company users could really care less whether or not the network is secure. All they really want is for the network to work without problem and in a way thats convenient for them, which includes being allowed to add their own devices to the network. Here are a few scenarios to illustrate the problem: Scenario #1: Normal network with a user PC connected to an Ethernet switch. The user PC obtains an IP address from the DHCP server when it enters the network. All is right in the world.

Scenario #2: User brings in his own switch or hub and connects it to the network in place of his company PC. The user then connects his personal laptop and the company PC to the hub. Both the company PC and the personal laptop obtain an IP address from the DHCP server. The users personal laptop is now on the network. Heres a list of some of the bad things that could happen: User could steal data from the network by copying it directly to his laptop User laptop could be infected with a virus/worm that could infect your network User could install software from network shares (software piracy and licensing issues) User could waste their day playing games o Dont get me wrong, games are important. I would, however, get pissed if I was paying someone $50/hr. to play them. User could make use of protocols and/or programs that are in direct violation of corporate security policy (yeah, like we all actually have those things written out) Blah, blah, blah and on and on and on. You get the point.

Scenario #3: Perhaps the worst possible scenario is when a user brings in his own wireless access point (AP) so he can have wireless connectivity with his personal laptop while at work. If you havent already experienced this in your own shop, you will. This is becoming increasingly common and the users usually put these in without any form of protection at all; no WEP, no TKIP, nothing. Just an open access point with no encryption required. This scenario makes not only the users laptop a DHCP client but it also makes every knucklehead within RF (radio frequency) range of the AP a potential DHCP client. The potential for something bad happening shouldnt have to be spelled out for you on this

one. If it does, drop me an email (colin(a)itdojo.com) and well chat. Heres a list of all the bad things that could happen: Everything from Scenario #2 but now it applies to anybody in the area who has wireless network card in their laptop, PDA, etc. At least your users actually work for you. Now youve got Laurie from the accounting firm next door connected to your network (and she probably doesnt even know it). It is very common for un-knowing users to associate with the wrong access point and not realize a problem. Youre severely screwed if someone comes by who knows what theyre doing and what theyre looking for. There are a variety of ways to prevent these situations from happening. It is likely that you will deploy multiple solutions to prevent a lapse in one from allowing something like this to happen (e.g. defense-in-depth). Some (no, not all) ideas that come quickly to mind on how to mitigate the likelihood of this happening are: Strong physical security o Physical inspection of user work area on a regular basis o RF inspection of the area on a regular basis (rogue access point detection). You should do this even if you dont have wireless connectivity as part of your normal network. A corporate security policy with some teeth. o If only we could say, Pull some shit like this and youre fired, to our employees. Alas, the old phrase, disciplinary action up to and including the possibility of termination, will have to suffice for most of us. It sucks that saying what you really mean isnt kosher. Port security using a maximum number of MAC addresses per port (one MAC per port for access layer switches, for example.) o By defining a maximum number of MAC addresses per physical port, especially on access layer switches, you can greatly reduce the likelihood that an uneducated user will be able to make use of your network in ways you dont see fit. Port security using 802.1x authentication o By requiring devices connected to ports to authenticate to an authentication server (RADIUS or TACACS+) before being allowed to transmit frames you can also greatly reduce the likelihood that a user will be able to insert a rogue device.

The purpose of this article is to explore the latter option: using 802.1x authentication. Ill save the other topics for a different day. 802.1x, for the uninitiated, is an IEEE standard that has been around since about 2001. The purpose of 802.1x is to provide some control for what devices can be physically connected (via cable or RF) to a network. In essence, it creates your ability to say, You can plug stuff into my switches all day long but if its not supposed to be here, it wont work. Not bad. Not bad at all. The devil, as always, is in the details. Getting it set up and working requires a fair amount of understanding and configuration. Each device in the 802.1x framework has a job and a name. They are: Supplicant this is a sexy term used to describe the user PC. Its the device that is being authenticated. This could be either the device or the user or both. Authenticator this is the switch. Its the device that prevents you from being able to get on the network until you have been proven worthy (e.g. authenticated & authorized) Authentication Server this is the server somewhere in your network that actually authenticates the supplicant. This is a RADIUS server or a TACACS+ server. Either one will work. In this article we will use RADIUS. This particular role can lead to some confusion because the authentication server may not actually do the authentication. It is possible (and probable) that the authentication server will send the authentication request to yet another device. In a Microsoft environment, for example, this other device could be and Active Directory Domain Controller.

Here is the general flow (note that this is a greatly simplified explanation): Step 1 PC (supplicant) tries to send frames in to the network (via RF or cable). Step 2 The switch (authenticator) receives the frame from the PC (supplicant) and, since 802.1x is enabled, doesnt allow it to pass. Step 3 The switch (authenticator) sends a message to the PC (supplicant) and says, Pack sand. Youve got to authenticate first. Step 4 The PC (supplicant) sends an authentication request to the authenticator (switch). o Note: In many situations the PC (supplicant) knows it is supposed to authenticate so it starts off the conversation by asking to authenticate rather than trying to send other types of frames. Thats more efficient when you think about it. Step 5 The switch (authenticator) receives the authentication request and forwards it back to the authentication server (RADIUS or TACACS+). Step 6 The PC (supplicant) and the authentication server have an authentication exchange. The switch (authenticator) simply passes the frames back and forth between them. o A couple of beautiful things are happening here: 1. The switch has no idea how the PC and the authentication server are actually authenticating to each other and it doesnt need to. All it needs is a SUCCESS or REJECT message from the authentication server when its over. This eliminates the need for the switch (authenticator) to have detailed knowledge about all the possible ways two devices might authenticate (e.g. its very flexible).

The switch does allow authentication frames but thats pretty much it. No other frames are allowed to pass until authentication has succeeded. Step 7 Assuming the PC can successfully authenticate to the authentication server, the authentication server sends the switch a SUCCESS message. Step 8 Having received a SUCCESS message from the authentication server, the switch allows the PC to begin sending other frames onto the network. Step 9 All is right in the universe.

2.

You can get all of the gory details on how the exchange works by doing a few Google searches. For today, weve got enough detail to move along. A pretty common graphic that youll see is similar to the one below. It illustrates the exchange outlined in the steps above.

My main area of focus for this article is on how to configure a Cisco switch to be an authenticator but Ive got to throw in a few details on how the Windows part of this all comes together. This document was written using the following equipment: PC running Windows XP Professional (member of the phatcat.com domain) Server running Windows Server 2003 with DHCP Services installed Server running Active Directory Server running Microsofts implementation of RADIUS (Internet Authentication Service) Cisco Catalyst 2950 Switch running C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA2 o Enhanced Image filename: c2950-i6q4l2-mz.121-22.EA2.bin

The network I am using is shown below. Its about as vanilla as you can get. Adding complexity to your network doesnt really change things much.

Well look at each of the three roles separately. Here is the order in which we will examine each of the configurations: 1. 802.1x Supplicant (Windows XP Pro PC) 2. 802.1x Authentication Server (Windows Server 2003) 3. 802.1x Authenticator (Cisco Catalyst 2950 Switch)

First: 802.1x supplicant (the user PC)

Follow all of these steps to make sure your client is configured correctly: Youll need to have some rights to set up the PC. Administrator rights will do nicely.

Make sure you have at least SP1 installed (XP Pro). o If youre using Windows 2000 pre-SP3 youll need to go here (http://support.microsoft.com/kb/313664/EN-US/) and do some reading. Make sure your PC is a member of the domain. Open Network Connections and access the properties of your network card. o Select the Authentication tab from the NIC Properties o Verify that the Enable IEEE 802.1x authentication for this network check box is selected. o From the EAP type: drop-down, select Protected EAP (PEAP). o Verify that the Authenticate as computer when computer information is available is selected. o Leave the Authenticate as guest when user or computer information is unavailable unselected.

Complete the following tasks while still on the Authentication tab of the Network Card properties: Underneath the EAP type: drop-down, click on the Properties button. In the Protected EAP Properties dialog window choose the following: o Validate server certificate Selected o Connect to these servers: Not Selected o Trusted Root Certification Authorities Scroll down the list and look for the name of the Certificate Authority that supports your domain name space. This assumes that you have a root CA in your domain or that you have made arrangements with a third-part CA. For many environments this is provided via Certificate Services on the Windows Server operating system. o From the Select Authentication Method drop-down choose Secured Password (EAP-MSCHAP-v2). This is the simplest method for the client as it does not require each client to have a certificate installed. We could get into a big long discussion about this but we wont. o Leave the Enable Fast Reconnect check box cleared. The Fast Reconnect options applies to roaming wireless users and their ability to not have to re-authenticate when they roam from one AP to another (as long as both APs use the same RADIUS or TACACS+ server for authentication). Well talk about it another day. o Click the Configure button right next to the Select Authentication Method: drop-down. In the window that opens verify that the Automatically use my Windows logon name and password (and domain if any) check box is selected. Click OK. o Keep clicking OK until all the windows go away.

That should do it. The client (supplicant) is configured. Are there other ways? Yup! But not today

Second: 802.1x authentication server (the Windows domain controller)

There is a pretty big laundry list of things that you need to do in order to have your back-end set up to support this scenario. In this article I am going to set up the network to authenticate the computer account as it exists in an Active Directory domain. This means that a computer will only be able to get on to the network if it belongs to the domain. Rogue computers wont work. Here is what I will assume you have up and running: A functioning Active Directory domain (Windows 2000 or Windows Server 2003) A DHCP server with a valid scope for the network(s) on which you are working Certificate Services with auto-enrollment for servers configured o Domain controllers enroll automatically. If your RADIUS server is also a domain controller, youre cool. If not, youve either got to enable auto-enrollment in Group Policy or youve got to manually enroll the server for a certificate. You need a computer certificate with Server Authentication as a listed purpose. Internet Authentication Services (IAS) (Microsofts version of RADIUS). Just make sure its installed at this point. Well configure it in a little bit. A Global or Universal group that contains the computer account(s) you wish to authenticate. o For this article I created a Global group name Global Authorized PCs and added the computer account(s) in my domain to the group. o Notice that I didnt do anything with user accounts, just the computer account. Im just interested in keeping rogue devices off the network. We can worry about users later.

To summarize: o The computer account (Futomaki, in this article) is a member of the Global group named Global Authorized PCs o The user account (Colin Weaver) is a member of Domain Users (a default membership for all domain accounts). o This is important because you will see in a moment that we set up authentication based on group membership (Global Authorized PCs), not on user group membership.

Next we need to configure IAS (RADIUS) for authentication. The tasks are as follows: 1. Set up the RADIUS client The RADIUS client is the switch (authenticator). Sometimes people get the terminology confused and think that the RADIUS client is the user or computer being authenticated. Its not so dont. To set up the RADIUS client, follow these steps: o Open Internet Authentication Service o Right-click on RADIUS Clients and select New RADIUS Client o In the New RADIUS Client window, enter a Friendly Name and appropriate IP address for the client. Click Next. The Friendly Name is just to help you know who the client is. Call it whatever you want. The Client address (IP or DNS) is the actual IP address configured on the switch. For this article I am using Catalyst2950 as the friendly name and 172.16.44.140 as the IP address. o From the Client-Vendor drop-down, choose the correct vendor. If your vendor isnt listed, leave the setting as the default (RADIUS Standard) o In the Shared Secret field enter a secret value (this is just a unique password that will be shared between the RADIUS server and the switch). Enter it again in the Confirm Shared Secret field. Remember it. Youll need it when you configure the switch. Click Finish. o The RADIUS Client is now configured. You should see the RADIUS client listed in the detail window (see screen shots below).

d 2. Configure a Remote Access Policy using IAS. The policy is what defines the AAA rules (Authentication, Authorization & Accounting). We want to create a rule that reads something like this, If you are a computer that is a member of the Global Authorized PCs global group in the phatcat.com domain and you are connected to an Ethernet port, you are allowed on to the network. If you are anything else, youre denied access to the network.

To set up the Remote Access Policy, follow these steps: o From the Internet Authentication Service MMC snap-in, right-click on Remote Access Policies and select New Remote Access Policy. The New Remote Access Policy Wizard will begin. Click Next. o Since Im using Windows Server 2003 I have the option of using a wizard to set up the policy. This simplifies the process a bit. If you have the wizard option, select it and then enter a name in the field below it. The name needs to be something meaningful to you. For this article I am using Authenticate Domain PCs as my Policy Name. If you dont have the wizard option (Windows 2000 IAS) all you need to do is select: NAS-Port-Type matches Ethernet and; Windows-Group matches Phatcat\Global Authorized PCs (or whatever your group name is) o Wizard users, click Next and select the Ethernet radio button. Click Next. o On the Users or Group page, click the Group radio button and then click Add . Enter the name of your group(s) and then click OK. o On the Authentication page, choose Protected EAP (PEAP) and then click the Configure button. o In the certificate selection drop-down choose the certificate you want to use. If you dont see a certificate here it means your RADIUS server doesnt have a certificate enabled for Server Authentication installed. Youll need to remedy this before moving on. o In the EAP Types window make sure Secured Password (EAP-MSCHAP v2) is listed. Leave the Enable Fast Reconnect check box cleared. Click OK. o Click Finish. o The Remote Access Policy is now configured. It should be at the top of the list on the detail pane. Order is important on this list. More than anything be sure the policy you just created is not the last one on the list. It wont work if it is. The safest bet is for it to be on the top of the list. You need to sort any other policies you have in order to make sure you get the desired behavior (if you have others, that is).

I To verify your policy settings double-click on the policy in the detail pane of IAS. You should see a settings tab. Make sure it contains the following Policy Conditions: o NAS-Port-Type matches Ethernet and; o Windows-Group matches Phatcat\Global Authorized PCs (or whatever your group name is) At the bottom of the settings page make sure the Grand remote access permission is selected. Click OK.

That should do it. The authentication server is configured. Are there other options and things to consider? Yup! But not today

Third: 802.1x authenticator (the Cisco Catalyst 2950 switch)

Damn! The only reason I started to write this article was to take about configuring a Cisco switch to do 802.1x authentication; I had to go through all that other crap just to get to this point. Now, some cool stuff: A Cisco switch configured for 802.1x authentication doesn't allow anything through until you authenticate. "Anything" (e.g. it's allowed even without authentication) includes: Spanning-Tree Protocol (STP) traffic o Switches talking to each other about how to avoid loops Cisco Discovery Protocol (CDP) traffic o Cisco devices talking to each other about who they are EAP over LAN (EAPOL) traffic o EAPOL traffic is the authentication traffic related to 802.1x and authentication The one thing we can say for sure about all three of those message types: they are all Layer 2 messages. Nothing thats Layer 3 is going anywhere until youve authenticated. 802.1x isnt enabled by default. Youve got to turn it on and youve got to configure AAA on the switch. The basic steps you have to take are: 1. 2. 3. Enable 802.1x authentication Configure the switch & RADIUS server to communicate Tweak the configuration to your liking

From the switch Command-Line Interface (CLI) there are a few interface configuration commands that you can use to control 802.1x. One of the most often used is the dot1x port-control command. There are three modifiers to the command. They are: auto force-authorized force-unauthorized
Cat2950(config-if)#dot1x port-control ? auto PortState will be set to AUTO force-authorized PortState set to Authorized force-unauthorized PortState will be set to UnAuthorized

If you set the port to force-authorized it will allow traffic, effectively disabling the need for authentication. This is the same as having no 802.1x port-authentication at all. If you set the port to force-unauthorized it will NOT allow traffic, effectively disabling the port. Even legitimate hosts will not be able to authenticate

If you set the port to auto it will cause the port to start its day in an unauthorized state. This is the mode you want to use if youre going to do 802.1x port-authentication. As soon as a device connects to the port the authentication process starts. Depending on the client that is connected it may be the client (the PC) that begins the authentication process or it may be the switch. If the switch is set to auto it will send an authentication request when it detects the link state change (e.g. the link has come up). It is also possible that the link is already up and the client sends the authentication request. While who starts it is important it doesn't change the end result; the client has got to authenticate because the switch isn't letting anything through otherwise.

Keep in mind that the switch doesn't actually do the authentication. It's just a pass-through. He's the gatekeeper but he doesn't decide if the device is allowed. That's the authentication server's job (RADIUS or TACACS+). If the RADIUS server says SUCCESS the port becomes authorized. If the RADIUS server says FAILURE the port stays in an unauthorized state (e.g. no frames are passed). The dot1x port-control auto command by itself isnt enough. Check out this debugging taken after the dot1x port-control auto command is entered on an interface (no other dot1x configuration has been done):
Cat2950(config)#int fa0/24 Cat2950(config-if)#dot1x port-control auto Cat2950(config-if)#end Cat2950#debug dot1x all Cat2950# 2w0d: dot1x-registry:** dot1x_vp_statechange: 2w0d: dot1x-registry:dot1x_port_modechange invoked on interface FastEthernet0/24 2w0d: dot1x-registry:dot1x_port_linkchange invoked on interface FastEthernet0/24 2w0d: dot1x-ev:dot1x_port_cleanup_author: cleanup author on interface FastEthernet0/24 2w0d: dot1x-err:Unable to send a message to the Dot1x Authenticator process. 2w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down 2w0d: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down 2w0d: dot1x-registry:dot1x_port_linkchange invoked on interface FastEthernet0/24 2w0d: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up 2w0d: dot1x-registry:** dot1x_vp_statechange: 2w0d: dot1x-registry:dot1x_port_modechange invoked on interface FastEthernet0/24 2w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to up

The error message about half-way through shows that the switch isnt able to communicate with the Authenticator process so it fails, allowing the port to transition into an authorized state. There is a bunch of configuration commands missing to make this work. Lets look at them. In order to configure the switch for AAA and 802.1x, I configure the following:
Cat2950(config)# aaa new-model Cat2950(config)# aaa authentication dot1x default group radius Cat2950(config)# interface fa0/24 Cat2950(config-if)# switchport mode access Cat2950(config-if)# exit Cat2950(config)# dot1x system-auth-control Cat2950(config)# radius-server host 172.16.44.200 auth-port 1812 key 1Td0j0Rawkz! Cat2950(config)# interface fa0/24 Cat2950(config-if)# dot1x port-control auto Cat2950(config-if)# end

Thats it! Lets look at each of these commands in a little detail and check out what theyre doing. aaa new-model Enables AAA on the switch. This command is a must if youre going to do anything other than local passwords on the switch aaa authentication dot1x default group radius This command creates something called a method list for 802.1x authentication. A method list is little more than a list of stuff to try in order to authenticate. The default keyword specifies that this is the list to use for all situations not otherwise specified. The group radius keyword specifies the order in which authentication methods should be tried. First, try all the RADIUS servers. If they return an error (different from a FAILURE messages), use whatever is listed next. In this case, there is nothing after RADIUS so its important that its available and functioning. Interestingly enough, if you were to enter aaa authentication dot1x default group radius none you might expect the switch to try RADIUS and then, if no response was received, to accept none as the authentication method. My personal tests of this have not shown this to be true. The documentation on Ciscos site specifically says, if an error is returned, the next authentication method is attempted. I guess getting no response and getting an error message are two different things to Cisco. switchport mode access the port has to be an access port for 802.1x to work. It cant be anything else. Anything else includes a trunk port, a dynamic port, a SPAN port, etc. If you say, Hey Colin, what about if its configured as a , No! The port needs to be an access port and it needs to have one PC connected to it. No hubs, no other switches, no access points just one PC plugged into one switch port. There is a multi-host option but its not likely that youll want to use it. Trust me on this. If you dont, look it up on Ciscos site. dot1x system-auth-control this command enables 802.1x globally on the switch

radius-server host 172.16.44.200 auth-port 1812 key 1Td0j0Rawkz! this is what points the switch to the radius server. The IP address is that of the RADIUS server. The auth-port is UDP port 1812, which is a default for RADIUS. 1813 is the default accounting port. You may also see ports 1645 & 1646 used by some apps. The key keyword is followed by the secret key the switch shares with the RADIUS server. This is the same key you configured earlier when setting up the switch as a RADIUS client on the Windows Server box. dot1x port-control auto I already talked about this one. This command enables 802.1x on an interface.

Now that we have it all set up, lets test it and capture the packets on the RADIUS server to see what we get. Guess what, it works like a champ. Heres a screen shot of the RADIUS capture:

If you want to see the capture in ethereal, you can download it here http://www.itdojo.com/synner/images/synner2images/radiussnag.cap

Summary
Controlling what computers are allowed on your network is seriously cool functionality. 802.1x brings a lot of things to the table that we just didnt have an easy way to accomplish a few years ago. By designing the security of your network to allow only authorized devices you have the ability to produce an environment that is more stable, more secure and more efficient. In a future article Im going to take you a bit further with 802.1x and show you how you can assign users to VLAN using it. Imagine the ability to have users and/or computers assigned to VLANs simply based on group membership in Active Directory (or something else). With 802.1x and RADIUS its very easy to do. No need for static VLAN assignments (though you can still use them) and no need for VMPS (VLAN Membership Policy Servers). You can even assign PCs that cant authenticate to a guest VLAN and give that VLAN limited access to network resources or you can give them nothing at all. Its up to you. Colin Weaver ITdojo, Inc. Colin(a)itdojo.com