NAC authentication with XP clients is a snap

Complications arise when dealing with agentless devices and guest access

Since it’s the first step in the NAC process, we began our testing with authentication: how will users identify themselves to the network?

We start with a simple test case: one enforcement point using 802.1X for authentication, virtual LAN (VLAN) assignment for access control, one policy server, no end-point security and a Windows XP client.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Since it’s the first step in the NAC process, we began our testing with authentication: how will users identify themselves to the network?

We start with a simple test case: one enforcement point using 802.1X for authentication, virtual LAN (VLAN) assignment for access control, one policy server, no end-point security and a Windows XP client.

Click to see: How we set up Cisco NAC

For a CNAC enforcement point, we used the Cisco Catalyst 3750 switch at the edge of the network, a workhorse and solid performer. (Cisco offered to send us an enterprise-sized Cisco Catalyst 6509 switch, but because we weren’t testing performance, we used the 3750 as a smaller and more environmentally friendly test case.)

CNAC’s policy server, running on our management network and accessible to the Catalyst switch, was Cisco Secure Access Control Server v4.1, the only choice for CNAC. End-point authentication was handled by Cisco’s Cisco Secure Services Client (CSSC) as an 802.1X supplicant, with the Cisco Trust Agent (CTA) layered on top, both running on top of Windows XP on Dell and IBM/Lenovo laptops.

On the TCG/TNC side, we had more choice in some areas, and less choice in others. Our initial enforcement point was an Enterasys Matrix C2-series switch. For a policy server, we started with Juniper’s Unified Access Control server, the IC-4000, the strongest contender supporting the TCG/TNC NAC framework. For the end-point, we installed Juniper’s UAC Agent, which included both the 802.1X supplicant and posture checking capabilities.

Click to see: How we set up TCG-TNC NAC

We expected this to be a slam dunk test, and it was. If an enterprise IT shop wanted something that simple for its NAC deployment, life would be great.

We then complicated the test network. We added a Cisco access point to the CNAC side of things, and an Aruba mobility controller onto the TCG/TNC side. We also threw three more switches into the TCG/TNC, an HP ProCurve Switch 5406zl, a Cisco Catalyst 3750, and an Extreme Networks Summit X450a. All of the new gear, wired and wireless, worked flawlessly in our simple Windows XP-based test.

Because we were using VLAN assignment for our enforcement of access control, there wasn’t any reason not to try the HP, Enterasys and Extreme switches on the CNAC network as well — so we did, and they also worked. However, the standardized RADIUS protocol doesn’t support every function you might want in a NAC environment. In particular, RADIUS has no way for the NAC server to tell a switch to boot someone off or make them re-authenticate. This means that semi-proprietary extensions to RADIUS will start showing up in NAC policy servers, and we can expect “better” results, especially with edge cases and some end-point security scenarios, when you match a Cisco ACS server with Cisco-branded switches.

We couldn’t get anything to fail the authentication tests. That is, until we switched user machine platforms.

NAC on Mac

Our first real complication came when we moved from our employees-on-Windows-XP scenario to an employees-on-Mac-OS-X scenario. Neither Cisco, nor the TCG/TNC, has an immediate answer for Mac desktops or laptops. On the Cisco side, we got away with the native 802.1X client built into the Mac operating system. Because we weren’t looking for end-point assessment yet, that fix sufficed.