NAC authentication with XP clients is a snap

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

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.

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.

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.

On the TCG/TNC side, we had a larger gap to cross. The UAC v2.0 IC-4000 controller Juniper sent works great with the Juniper client, but is only designed for TCG/TNC deployments. Without a TCG/TNC client on our Mac laptops, we couldn’t authenticate to the UAC controller. Juniper explains the reason we ran into this problem was because the company had just started integrating the Steel-Belted RADIUS server it acquired with Funk Software into the UAC with Version 2.0, but had not exposed all of the power of the RADIUS server on the inside of the UAC appliance.

With a new version of the UAC (Version 2.1 is expected to ship later this summer), everything needed to do both TCG/TNC-style authentication as well as simpler 802.1X authentication. The solution we came up with for the shipping product was ugly, but workable. We installed a primary RADIUS server in front of the UAC controller, and then told the new RADIUS server to send only the TCG/TNC-compatible client authentication and authorization requests onto the UAC controller.

Being hospitable to NAC guests

Moving from employees to guests was a real exploration into the difference between a single-vendor NAC product like those Network World is currently testing separately (see related on those testing details) and a NAC framework. With single-vendor NAC, there would be a simple pat answer: “do it this way, and that’s how we handle guests.”

Neither Cisco nor our TCG/TNC teams were willing to be so strict in terms of how guest access is permitted. To make guests work on the same switch ports as employees, the switch had to have a “guest VLAN” mode so that when 802.1X authentication didn’t work, the client machines would be sent off to a guests-only VLAN. We were able to successfully configure our Cisco, Enterasys, Extreme and HP switches to do this very easily. On the wireless side, we simply created an additional wireless Service Set Identifier for guests to use, separate from employees.

The most obvious solution to handling guest authentication was a captive portal, especially because guest users are accustomed to this type of browser-based authentication system. Cisco offered us our choice of products from their line, including the Cisco Clean Access (CCA) appliance. The difficulty with the Cisco solution was that policy management was now going to be split between two different systems: CCA for guest users and ACS for employees.

Juniper brought in a NetScreen 5GT firewall and developed a more elegant solution for guest users based on the standard tools built-in to ScreenOS and the UAC appliance. Because the ScreenOS operating system inside of the firewall is tied closely to the Juniper UAC appliance, the firewall was able to cooperate with the UAC appliance and create a captive portal environment that was closely tied to the policy tools within the UAC.

Authenticating the unauthenticatable

The biggest hurdle to authentication was agentless clients, devices that had neither Web browsers nor 802.1X clients. We picked out an HP printer, wireless devices including a Palm PDA and a Nokia E61 smart phone and two wired Session Initiation Protocol telephones as examples.

With this scenario we stretched the concept of what NAC was all about.

For example, we had to bring our printer into the network. One option might be to simply say “NAC doesn’t apply” since you’re not really authenticating a user nor checking end-point security status. The network manager could find the port the printer is connected to and configure it to be on a static VLAN. The problem with that approach is that you don’t know if that thing claiming to be a printer is really a printer, or a hacker pretending to be a printer to get on the network.

Because we wanted to integrate our printers with the highest level of security possible, we opted to look for a better approach. What we discovered was that it was now suddenly more about testing switches and wireless gear than faults or features in the CNAC and TCG/TNC frameworks. For example, our Catalyst 3750 switch has a feature called “MAC Authentication Bypass”. A switch port set for MAC authentication bypass will try 802.1X authentication, but if that fails it will also try authenticating a user based on his MAC address directly to a RADIUS server.

The idea is that you pre-load the MAC address (or perhaps just the MAC address prefixes) of your printers and VoIP phones into your authentication database and use that for authentication. Both the Cisco and Enterasys switches in the test bed can do MAC authentication bypass. The switch Extreme sent couldn’t do MAC bypass using its “Network Login” facilities, and we couldn’t successfully make the HP switch handle 802.1X, guests, and printers all on the same ports (HP’s documentation is ambiguous on whether this is even supposed to work).

Of course, using a MAC address for authentication has its own risks. Printers usually have a label containing their MAC address somewhere easy to see, and if not, determining the MAC address would only take a few seconds of an attacker’s time. If the MAC-authenticated printer was put on a VLAN specifically for printers, firewalled to only allow “printing” traffic and isolated from the rest of the network that might be an acceptable compromise. On the other hand, many network managers might want to simply place printers on the same VLAN as end user systems. In that case, using MAC addresses for authentication or statically mapping a port would represent a gaping hole in the security of any type of NAC strategy.

Even if printers could be firewalled off, the variety of agentless devices in a network might preclude having a firewall for every device type. Printers and VoIP phones are easy to put into special bins because they have predictable traffic patterns and destinations. But what about badge readers and security cameras and temperature sensors and UPSs and all other manner of device plugged into the network? Both Cisco and the TCG/TNC team had ideas on how to cope with this diversity.

Diversifying agentless access

Cisco brought in partners Qualys and Great Bay Software each with its own strategy for handling guests and unauthenticated devices.

Qualys provides a small appliance, part of its QualysGuard service, which is normally used for vulnerability scanning across a corporate network. In the CNAC scenario, our Qualys appliance talked directly to the Cisco ACS server. When a new system requested access, the ACS server sent a message using a Cisco-defined protocol to the QualysGuard appliance detailing the IP address of the requester. The QualysGuard appliance would run a quick scan, and return a status report with a pass/fail result on the new system.

The integration was quick and elegant, but the actual deployment was very limiting. In this initial incarnation of the QualysGuard NAC integration, we didn’t have a lot of options for configuring the difference between good systems and bad systems because the report didn’t seem to give us a lot of information on what was going on. As more guest users come with firewalls running on their laptops, it’s likely that this approach will offer less useful information. Because QualysGuard has to have an IP address of a system to scan it, this approach also didn’t work for 802.1X users or MAC-authenticated devices such as printers — neither of which has an IP address when the scan has to occur.

To complement the auditing capabilities of QualysGuard, Great Bay Software brought in its Beacon appliance to integrate with Cisco ACS and help with the problem of devices such as VoIP phones and printers. Beacon is a multi-purpose device, but one of its primary tasks is a network device discovery tool. Using a variety of techniques, such as packet sniffing and SNMP discovery, Beacon tries to associate a profile with each device on the network. With Beacon, we wouldn’t have to catalog the MAC address for every agentless device on our network and we would have some “checking” to help reduce the risk of MAC address spoofing by an intruder who wanted to pose as a printer. We used Beacon to identify our VoIP phones and printers based on how they behaved on the network.

The link between Beacon and Cisco ACS is made using an LDAP connection. When an agentless device tries to connect, the MAC address of the device is sent to Cisco ACS for authentication, which then looks it up using LDAP in the Beacon server. If Beacon has built a profile for that device, the profile is sent back to ACS, which can use it to decide what access control settings are appropriate. In the case of our VoIP phones and printers, we were able to put them on the correct VLANs without having to know ahead of time what their MAC addresses were.

Of course, because Beacon talked to Cisco ACS using a standardized protocol (LDAP) rather than a proprietary protocol (as QualysGuard needs to), we were able to sneak the Beacon Appliance onto our TCG/TNC network as well, with the same functionality. We did have to cope with the clumsiness of having two RADIUS servers on the TCG/TNC side, but were able to authenticate printers and VoIP phones using this technique.

One important development we learned about from vendors passing through our lab is that a new TCG/TNC protocol is currently under development. The specification, called IF-MAP, is specifically designed to allow tools such as intrusion-detection systems and Security Information Managers (SIM) to feed information back into the NAC deployment. This kind of linkage would be perfect for tackling the problems of MAC authentication. Currently there is no public information available on IF-MAP.