Introduction

This month, I'd like to take a look at what goes into actually implementing Identity-Based Access Controls. I'm currently involved in two college/university network design projects for which 802.1x is of interest. So I'm definitely practicing what I preach here!

Basic Orientation

For Identity, Cisco's answer is the product, CiscoSecure ACS. This RADIUS and TACACS+ server software comes  in Windows and UNIX variants, including a Service Provider product. It can use back-end user databases such as  Novell, Windows NT, Active Directory, and LDAP.

For Identity-Based Network Services, IBNS, that's where a collection of products allow us to authenticate users via 802.1x and EAP, against CiscoSecure ACS and back-end user databases. RADIUS attributes allow us to then configure the network devices with per-user or per-user-group settings. The recent emphasis appears to be on dynamically-assigned VLAN's. For enterprises, think "employees", "on-campus-consultants#1", "guest", etc. For colleges, think "faculty and admin", "student", "server", "guest", etc. The idea is to issue VLAN's and corresponding addresses, perhaps from different address blocks. These may then provide the basis for all sorts of nifty policy actions, including access lists, routing, QoS, policy-based routing, etc.

I see some interesting design challenges lurking here, which we may get into in future articles. This definitely is venturing into new territory. What will scale and  remain manageable is one of the big questions. The  challenge is tying such user communities together across a Layer 3 core without getting seduced into large-scale Layer 2 VLAN's.  MPLS VPN or VRF-Lite is one way to do that, a way that may be equally repulsive to some. L3 tunnels in general seem to what's currently under consideration to solve this.

Identity-Based Access Control

If you haven't guessed by now, this article fits firmly into the IBNS space. I want to give you an idea of what's entailed in getting IBNS working on a real network. Subsequent articles may drill down in more detail.

The ultimate good reference on all this right now appears to be titled Network Infrastructure Identity-Based
Network Access Control and Policy Enforcement Implementation Guide (June, 2003). Yes, that's a mouthful! It can be found at http://www.cisco.com/application/pdf/en/us/guest/netsol/ns178/c649/ccmigration_09186a0080160229.pdf

There are three areas requiring setup to get IBNS working. Plus arguably some follow-on activities.

The following diagram shows the main activities required for  IBNS. You've got to install and configure client supplicant software on the desktop. The switches and WAP's have to be set up to require 802.1x authentication on appropriate ports. They also have to be set up to work with the ACS  RADIUS server. The intervening network devices do have to provide connectivity between edge switches or WAP's and ACS. Then ACS needs to have the edge devices added as clients, to allow them to query it. ACS also needs to be set up with users and passwords, or set up to relay unknown user authentication actions to the appropriate back-end database. It is also helpful to set up ACS to handle groups of  users, so you don't have to do a lot of repetitive work. If the back-end database uses user groups, they have to be mapped to ACS user groups.

There's also follow-up work. If you are doing dynamic VLAN's, they need to be created in the switches, and other switch configuration may need minor adjustment. They would also have to be setup in ACS via the appropriate optional RADIUS attributres. If these VLAN's are new subnets, you need to route them, you'll need DHCP scopes, you may need to adjust access lists, etc.  We won't go into these latter details as (a) they'll vary from network to network, (b) this article would get too long, and (c) you'd probably find it boring anyway.

I hope I haven't scared anybody. This is mostly doing a little bit here, a little bit there, and getting it all right. ACS may take the most work, nothing that hard, but just a bunch of getting it set up to work with your devices if you haven't already done that.

Let's now take a brief look at what's involved for each of the above 3 areas: supplicant, client edge device, and ACS.

Supplicant

The Microsoft Knowledge database did help me solve  the first of the above gotchas. Some head-scratching did ensue, since the article helpfully never mentioned the name of the service to start. It's not named anything obvious, like dot1x or 802.1x Service. In fact, see the below figure, it's named "Wireless Configuration". Since I already had 802.1x working on my wireless side without enabling this (via the Dell driver), I didn't catch on until I expanded the description column as shown and saw "wired". Ok, maybe that was obvious to you. It wasn't for me!

Aside from the technical details, the main issues with 802.1 supplicant seem to be (a) obtaining one, and (b) user policy. Neither is necessarily particularly hard.

If one has a wireless card, up-to-date drivers probably take care of authentication support. Windows XP has 802.1x support. Windows 2000 SP3 or later includes 802.1x support, as noted. I understand free client support is available for Linux and  MacOS. That leaves out legacy devices (printers, other UNIX variants, etc.). It also leaves out older versions of Windows. But Funk and Meetinghouse both have driver support available for older Windows PC's. One can download it from their websites for around $40-50 per PC.

The policy issue arises with colleges because of hesitancy, either on cost or support. Both can be complex issues.

Re cost, it costs money to upgrade Windows, or to buy the Funk or Meetinghouse driver. I've got two kids in college, I understand how sensitive parents are about cost. Colleges are very hesitant to dictate more cost for their students. Part of that goes with being an open environment. Part of it may also relate to staying competitive. Operating systems upgrades may not be feasible, since they may require the cost of a new PC. That's a show-stopper for many families. Concerning purchasing drivers for older Windows variants, one could argue that $40 per student is cheap, compared to the support costs of worm containment. That's where policy becomes a problem.Some colleges feel they cannot afford to support the wide variety of desktops or the sheer number of PC's their students have. And installing drivers or requiring installation of drivers means you own any support problems the student subsequently encounters. So do you provide "legacy support" (see below)? Is  a component of it lesser connectivity as an incentive for students to opt for the buy-and-install-drivers solution?

One counter-argument is that students who get virii do impose very real costs on the college. If they get a worm that creates traffic, it may adversely affect other users or even knock out the network.

Colleges often try to provide anti-viral software to their students. Who then ignore it, don't install it, turn it off, etc. The necessary teeth might then be access control (NAC? web-based?), or it  might be a hefty fine if your PC gets infected and starts trashing the network. I personally think stringent standards up front ("you must have one of the following anti-viral products installed") with fee for non-compliance may be where we all end up. But even there, how does one induce the unwilling to periodically update their virus signatures and  refrain from turning the protection off? That's where NAC will be of intense interest to colleges.

This is also why 802.1x arises in college environments right now. Student PC's are a very scary unknown right now, not  under any anti-viral control. So  it is highly desirable to identify student machines and isolate them (quarantine them?) in student VLAN's. Then run traffic from those VLAN's through firewalls or IDS's. That at least addresses damage containment now.
Having a  focal IDS allows identification and treatment of infected PC's. Down the road, NAC may provide more enforcement without major labor burden. At that point, maybe student PC's become trusted again, and the policy split becomes "NAC-approved" versus "guest and non-NAC-approved  PC's".

To sum that up, what's messy with clients right now is figuring out what is technically feasible, and what the policy ought to be. The interaction with culture and expectations of the surrounding environment make this particularly sensitive for colleges.

In a few years, most people will be running OS variants that support 802.1x. No doubt we'll all have some other hot issue then.  In the meantime, we do have the challenge of transition and "legacy support". Either users have to have OS upgraded, have to have supplicants installed, or there  has to be some way to support legacy non-802.1x devices. The latter is another potential article. I've got two techniques that you may find useful, ones that work right now. Which to use depends on your policy and needs.

Client Edge Device

CiscoSecure ACS

There are a good many more options to configuring ACS, but it feels now that they properly belong in an article about just ACS. So I'll save those for another time.

Troubleshooting 802.1x

I also found the ACS reports on passed and failed authentications very useful. The failures often told what the problem was and how to fix it!

Summary

There was also a good Networkers 2003 presentation on this topic, complete with many ACS screen captures. See http://www.cisco.com/networkers/nw03/presos/docs/SEC-2005.pdf.

I've decided to go ahead and post the ACS screen captures I have, pending writing an article on ACS. They are intended more as a visual tour of ACS than as showing the specifics of how to set up for 802.1x, PEAP, dynamic VLAN's, etc. See http://www.netcraftsmen.net/welcher/papers/acs-3.2-cap.pdf.

Let me know what  you think of those topics!

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eight CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net.