NAC/NAP: A House of Cards?
Is the new Cisco NAC/Microsoft NAP Interoperability Architecture partnership a harbinger of things to come? Is this the situation that NAC vendors have feared (or welcomed, depending on your point of view)? It certainly is an ambitious partnership and if...
September 6, 2006
Is the new Cisco NAC/Microsoft NAP Interoperability Architecture partnership a harbinger of things to come? Is this the situation that NAC vendors have feared (or welcomed, depending on your point of view)? It certainly is an ambitious partnership and if successful, will change the shape of the NAC market and, more importantly, your deployment options. The NAC/NAP Interoperability Architecture(they need a better name. My editors will tell you I am terrible at coming up with names, so I have no suggestions), tightly couples Microsoft???s NAP in Longhorn and Vista with Cisco???s NAC, which is available today. Microsoft role is to provide the client side component and the API for third party integration. Cisco provides the network enforcement and desktop support for Non-Windows Longhorn and Vista OS???s via the freely available Cisco Trust Agent.
Both Microsoft and Cisco have stated that they will be supporting their own partner programs as well as the NAC/NAP initiative. Cynics might say that they are hedging their bets against the possible failure of this partnership to materialize in the market. But practically speaking there are benefits for both sides.
Microsoft benefits by having a partner with market dominance in the network infrastructure and having the OS tightly integrated with the network. At the spring 2006 Interop event, John Chambers spoke at length of moving traditional OS services into the network. This might be one manifestation. While Microsoft will still be supporting it???s own partner program, the clear indication from talks with Mark Ashida, General Manager, Enterprise Networking at Microsoft, is that the NAP API will be the integration point going forward and Microsoft is transitioning it???s partners to that API. It make sense for them to do so. Microsoft???s success will depend on 1) their ability to execute a partner program that doesn???t inhibit Independent Software Vendors (ISV) from participating and 2) their ability to build in the management framework for policy definition, agent updating, etc, into Vista and Longhorn.
Cisco benefits because they get access to the most dominant operating system on the planet while maintaining compatibility with non Microsoft OS???s, notably MacOS X. The partnership also gives Cisco leverage as the infrastructure choice. Unifying the hardware and maintaining integration points with Microsoft is a compelling selling point. Bear in mind as well, that the Cisco/Microsoft arrangement is not limited to NAC/NAP. Both Cisco and Microsoft are making noise about Unified communications which is another technology that benefits from tight integration with OS services and the network. Cisco???s success depends on 1) defining a smooth migration path from an appliance based NAC to a network based one and 2) having a policy definition solution that offers the features and functionality customers want. Truth be told, however, for those NAC vendors that integrate with Cisco, they are already doing so using mechanisms like CLI, SNMP, and 802.1X.
ISV???s benefit because a Cisco partner that integrates with the NAC automatically gets entrance into a Microsoft shop and vice versa. At risk are vendors that make NAC products that directly compete with Cisco such as ConSentry and Nevis because the switch hardware selling point pales in comparison with the promised integration between Cisco and Microsoft. Same holds true for Microsoft and patch management, AV, etc.The success of the NAC/NAP partnership is not a forgone conclusion. Hell, the success of NAC in general is not a forgone conclusion. But this does signal a pretty big change in the NAC market place that will effect you, dear reader, whether you???re a company, an integrator, or an ISV.
About the Author
You May Also Like