Deploying Identity-Based Access Control

Enterprise Networks & Servers, Jun 2004 by Welcher, Peter J

Last month's article discussed technology, the 802.1x and EAP protocols, which can be used to authenticate users and grant or deny access to users of both wired and wifeless networks.

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!

This whole area is undergoing a lot of rapid change, so I'd like to start by covering the Big Picture. Cisco's top-level links tell the story. This whole area can be found under the title Cisco Trust and Identity Management Solutions, at www.cisco.com/en/US/netsol/ns463/networking_solutions_package.html.

That URL breaks this topic down into three areas, which I list below, along with the relevant links.

Identity (CiscoSecure ACS)

www.cisco.com/en/US/products/sw/secursw/ps5338/index.html

Identity-Based Network Services (IBNS)

www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns75/networking_solutions_sub_solution_home.html

Network Access Control

www.cisco.com/en/US/netsol/ns466/networking_solutions_sub_solution_home.html

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 IBNS, that's where a collection of products allows 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 VLANs. For enterprises, think "employees." "on-campus-consultants#l," "guest," etc. For colleges, think "faculty and admin," "student," "serve,r" "guest," etc.

The idea is to issue VLANs 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 VLANs. 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.

Cisco lately has been talking a lot about Network Access Control (NAC). This definitely should be the subject of a future article, perhaps my next one. NAC gives or will give the ability to deny access to the network not just based on user id but also based on whether the virus scanner or personal firewall software is running, how current the virus signatures are, etc. NAC is still evolving, with the first phases due to appear shortly.

It's sounding to me like you may want to have not just a site license on the desktop virus software but also your vendor's central management software. NAC is founded on network equipment interacting with not only the client (as far as current state of a particular desktop) but also with security desktop management software, to verify that the client meets current security policy.

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 www.cisco.com/application/pdf/en/us/guest/netsol/nsl78/c649/ccmigration_09186a0080160229.pdf

Take Your Time

I'm a big fan of doing lab work incrementally. Get something working, improve on it, gradually work your way toward what you want. That simplifies troubleshooting, since you're not trying to get 50 bazillion things working at the same time. For IBNS, my suggestion is to work with MD5 authentication first, even though that won't make use of a back-end database. After that, if you want to do PEAP, go for it. Tip: when installing MS certificate service, make sure you have MS US Web server installed first. Otherwise you may have some head-scratching concerning the certificate services Web interface and why it isn't working.

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

Figure 1 shows the main activities required for IBNS. You've got to install and configure client supplicant software on the desktop. The switches and WAPs 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 WAPs and ACS. Then ACS needs to have the edge devices added as clients, to allow them to query it.