When NAC meets NAP

Complete and seamless integration across Cisco NAC, Microsoft NAP, and other network access control solutions remains a distant dream, but signs of progress emerge

It is the rare environment that has only one vendor's product. The dream of integrated network access control (NAC) is that network managers will be able to pick and choose best-of-breed components from different vendors to make a complete solution. It's a dream that started with Cisco and Microsoft, and now rests on standards from the Trusted Computing Group. Today, most NAC solutions are interoperable with Cisco or Microsoft technology.

A very large percentage of environments have some combination of Microsoft software and Cisco network devices. This was recognized early on when Microsoft and Cisco were starting to develop their NAC solutions, and the two companies pledged to support each other's efforts. Microsoft and Cisco also promised that their products would be interoperable with the Trusted Computing Group's Trusted Network Connect (TNC) standards.

[ See the Test Center reviews of Microsoft NAP, the NAP-based Napera NAC appliance for SMBs, and NAC solutions from Enterasys, McAfee, Symantec, Trend Micro, Sophos, and ConSentry. ]

Two years ago, it seemed those pledged efforts might be mostly marketing hype, as neither delivered solutions that followed up on the agreed-upon integration. I'm happy to report that there is a moderate level of integration today, though mixing and matching components from Microsoft Network Access Protection (NAP) and Cisco Network Admission Control (Cisco NAC) to form a complete solution still has a way to go, and it is questionable if integration efforts will ever reach the level sought by users. But there is a lot you can do and a variety of ways you can juggle components.

Open industry standards
First, how compatible are Microsoft's and Cisco's products with the TNC standard? According to Steve Hanna, Distinguished Engineer at Juniper Networks, co-chair of the Trusted Network Connect working group at the Trusted Computing Group (TCG), and co-chair of the Network Endpoint Assessment (NEA) working group in the Internet Engineering Task Force, Microsoft's NAP client is fully compliant.

After working with the TCG to conform to the TNC standard, Microsoft turned over its internal Statement of Health (SoH) format and protocol to the TCG; SoH is integral to checking and reporting a computer's health status to participating management devices. Microsoft's SoH is an implementation of the IF-TNCCS-SOH standard, which describes how a TNC-compliant client and server exchange messages.

Cisco aimed to comply with TNC standards as well, but didn't feel as comfortable working directly with the TCG. Cisco normally works with open standards defined by the Internet Engineering Task Force (IETF), so both Cisco and TCG agreed to push the TNC standards through the IETF. TCG's Steve Hanna and Cisco's Susan Thompson co-chair the IETF NEA working group heading up the IETF standard. According to both TCG and Cisco, the new standard is near completion, which should lead to improved future integration between all NAC vendors, as all can move ahead with future products and features without worrying about a technical tower of Babel.

As usual, tomorrow will be a better day. But what if you want to integrate Cisco NAC and Microsoft NAP today? Here the story is more mixed. For instance, Cisco's NAC client does not work directly with Microsoft's Network Policy Server (NPS), and it doesn't appear that it will anytime soon. Microsoft Windows' built-in NAP client doesn't talk directly to Cisco's NAC servers either. However, that doesn't mean all is lost.

Microsoft's NAP client can collect an SoH and send it to the NPS, which in turn determines whether the endpoint should be allowed on the network. The NPS can instruct Cisco's version of RADIUS, called Access Control Server (ACS), to enable or disable ports on participating 802.1X-compliant network devices. See Cisco's NAC and NAP integration guide for more details.

Most NAC manufacturers require that customers install a vendor-specific NAC client on each participating endpoint. Some NAC clients work with only the vendor's corresponding NAC compliance server. A large portion of NAC vendors and products make up this group.

For example, to use Symantec's Network Access Control product, you must install Symantec's NAC or Endpoint Protection client (the latter incorporates the Symantec NAC agent) and talk to participating Symantec NAC-compliant services (anti-virus, host-based firewall, and so on) or 802.1x network devices. You define access rules in the Symantec Policy Management console or the Symantec Endpoint Protection Manager console, and then enforce network access by turning on various host-based firewall rules. (See the Test Center review.)

But more and more, NAC vendors are supporting Microsoft's NAP or TCG's TNC standard, or they're facilitating enforcement via 802.1X network devices using RADIUS. For example, Symantec's NAC products have the ability to communicate with Cisco's 802.1X network routers and switches. The Symantec NAC client can also integrate with Microsoft's NAP by installing itself as a System Health Validator (SHV) extension, which essentially makes it a part of the NAP client. As an SHV extension, the Symantec client can assess and control everything NAP normally does. And of course, any product can use Microsoft's Network Policy Server as a RADIUS service to talk to any 802.1X-compliant network device.

Alas, without a little planning, integration between Microsoft NAP and Cisco NAC isn't as simple as picking and choosing your favorites. But there is a moderate amount of interoperability, and that benefits us all.


Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform