Rolling Review: Microsoft NAP
Can Microsoft's Network Access Protection challenge Cisco's network access control dominance? Yes--and not just because it's free.
July 30, 2008
Nearly 80% of respondents to our third annual InformationWeek Analytics NAC poll are evaluating or deploying network access control technology, but IT still has a big beef with its lack of interoperability. So it's to Microsoft's credit that early on the company moved away from trying to develop a proprietary system. Instead, it built a framework; developed a set of APIs for third-party integration; and, most important, aligned itself with the most widely accepted standards body in the NAC space, the Trusted Computing Group.
Of course, the fact that Microsoft is offering its Network Access Protection technology free with a Windows Server 2008 license can only help drive adoption. In fact, according to our poll, NAP already is pulling equal with Cisco Network Admission Control in terms of framework familiarity.
Near term, the fruit of Microsoft's collaboration with the Trusted Computing Group is a new interoperability standard based on Microsoft's NAP and TCG's Trusted Network Connect. The spec defines a NAC industry-standard protocol, dubbed Statement of Health, or SoH, for reporting on the security profile of a given endpoint. SoH is a win-win for IT and vendors alike because it ensures that third-party clients can report and enforce system health with a Microsoft Network Policy Server (NPS). Conversely, the Microsoft NAP client built into Vista and Windows XP SP3 will, theoretically, seamlessly interoperate with third-party enforcement points.
DIG DEEPER
2008 NAC SURVEY
Find out what peers and vendors think about the future of the NAC market.
Download this
InformationWeek Report
>> See all our Reports <<
We didn't test NAP head-to-head with Cisco NAC because it's just not an apples-to-apples comparison ... not yet, at least. If you're considering Cisco NAC vs. Microsoft NAP now, be aware of the functions that NAP does less well, if at all; these include enabling robust guest access enforcement, captive portals, and support for Mac OS. Additionally, the Cisco NAC agent provides the administrator with the ability to scan for specific registry keys or other system values, and make policy decisions based on those values. The NAP agent does not.
Still, for the price, Network Access Protection is sure to take a bite out of Cisco's bottom line.
GET READY ...
As we unboxed NAP in our Boston Real-World Labs and studied Microsoft's implementation of the technology, it became clear that there are three design decisions that must be made before jumping in.
First, what type of enforcement do you want to employ in your NAP system? Microsoft NAP attempts to secure the network at five distinct points of entry: DHCP, IPsec, Remote Access/VPN, Terminal Services Gateway, and 802.1X. Methods can be used individually or in tandem, and each has advantages and disadvantages. For example, using DHCP as an exclusive enforcement point is easy and works well ... as long as your end users lack the sophistication to set static IP addresses for their systems as a means of circumventing the NAP health check. In the DHCP enforcement method, clients that pass the health check are given DHCP data that's valid for access to the production network. Clients that fail a health check are provided with an IP address and subnet mask, but no default gateway. However, these clients are provided with host routes to remediation servers, where updates can be downloaded and installed automatically or manually.
The IPsec enforcement method works by employing health certificates, which are issued by a Network Policy Server to clients upon login, after a successful health check. If a system that lacks a valid health certificate tries to connect to a network that requires one for access, the connection will be dropped.
VPN enforcement is most easily achieved through the use of Microsoft's Routing and Remote Access server, but third-party VPNs can be made to work with NAP. In much the same way that DHCP enforcement works, a failed health check results in packet filters that allow clients to connect to remediation servers only being applied to the VPN connection.
In Detail
Featured Element: Microsoft Server 2008 Network Access Protection
About This Rolling Review: In this new breed of Rolling Review, we're analyzing the most intriguing new features of Windows Server 2008. Where competition exists, we'll run bake-offs in our Boston Real-World Labs. When a capability is unique, we'll put it through its paces and tell you what we find.
Previously tested: Terminal Services, PowerShell, Server Core
Next Up: Hyper-V
Other Vendors Invited:
Rolling Reviews present a comprehensive look at a hot technology category. See our kickoff and other reviews at
informationweek.com/rollingreviews/
The functionality of the Terminal Services Gateway enforcement method is still somewhat limited because auto-remediation is not supported through Terminal Services. Despite that drawback, it's possible to at least conduct health checks on clients trying to access your Microsoft Terminal Servers. The primary option for administrators who want to enforce system health though Terminal Services is to place the connection into quarantine for manual remediation.
Finally, Network Access Protection supports the use of dynamic virtual LAN steering via the 802.1X standard. This enforcement method is the most popular and versatile because it's effective both on the wire and wirelessly. NAP and 802.1X work like this: When a system attempts to log on, the NAP client packages its Statement of Health and logon credentials into an EAP authentication request. The 802.1X-capable switch accepts the client SoH/authentication request using a method called EAP over LAN, and forwards it to the NPS via the Radius protocol. If the NPS is not also your Radius server, then the NPS can act as a Radius client and direct the SoH/authentication request to the Radius server you specify. The authentication portion of a request is forwarded to the domain controller, but the SoH part of the request is vetted by the NPS to determine system health. If a client fails the health check but passes authentication, 802.1X dynamically switches VLAN membership to a DMZ, where the device can be auto-remediated and recertified to log back on to the production network.
The second design choice you'll need to make when implementing NAP is a policy decision: What factors will you use to determine system health?
Out of the box, you can check for the status of Windows firewall and antivirus/anti-spyware software, as well as Windows Updates and the update policy. Windows Updates themselves can be automatically installed from a dedicated server or via the Web or an intranet that you make available.
The final major architectural decision relates to how strictly you'll enforce policies. Microsoft recommends a phased implementation where NAP is initially deployed in a reporting-only mode. Once you're comfortable that enforcing health standards won't grind business to a halt, you can move gradually to an auto-remediated enforcement policy. Of course, shops with high security standards can implement immediate enforcement.
OUT FOR A SPIN
To get a hands-on read of Network Access Protection, we deployed DHCP enforcement in our lab environment and quickly hit our first snag: To use DHCP enforcement with NAP, you need to be running a Windows 2008-based DHCP server. That's because DHCP in Windows 2008 is NAP-aware and includes the additional user classes and scope options necessary to dynamically black-hole clients that fail health checks. Thankfully, your domain controller and DNS server do not need to be running Windows 2008 to perform DHCP enforcement.
The second gotcha: Only Windows XP SP3 and Vista have built-in NAP clients, and Microsoft has no plans to support additional operating systems. Fortunately, third parties are working on clients for Linux and Mac OS devices; in fact, Avenda Systems already offers a beta version of a Linux-based NAP client.
As we configured our DHCP scopes and NAP policies, we discovered a third gotcha: The NAP client is installed as a service on XP SP3 and Vista machines out of the box, but by default, the service is unconfigured and not running, so we had to configure a group policy to get clients to start up the service automatically and participate in DHCP enforcement. Sure, we could have taken the easy road and configured the client manually for testing purposes, but how good would this review be if we didn't subject ourselves to the same pain that you'll feel in the real world?
Once our group policies were built and tested, we unleashed them on our domain. We were curious to see what would happen with our XP SP2 clients. To our surprise, these non-NAP-capable PCs were quarantined, as though they had failed a health check. The good news: You can force users to upgrade to SP3 immediately. The bad news: Employees might not take kindly to having to wait half an hour for their systems to be remediated up to SP3. Luckily, you can configure policies to allow non-NAP clients onto the production network, or you can do delayed enforcement and let end users decide when to remediate themselves.
We also were curious to see how the auto-remediation feature worked. To test it, we modified the Windows Security Health Validator to require all clients to have their Windows firewalls turned on. We then turned off the firewall on our Vista client, logged out, and popped back in. To our delight and slight surprise, the policy worked as advertised. The NAP client greeted us with a yellow balloon saying that the client failed a health check, and about 60 seconds later, our Windows firewall was turned back on and all of our routes to production network resources were restored.
Although auto-remediation worked well, we had to twiddle our thumbs for a minute until the NAP client let us back onto the network. Just for fun, we tried to turn off the Windows firewall again while logged in. The NAP client didn't even bark at us--it just immediately turned the firewall back on.
Bottom line, NAP is a great value for organizations that have yet to invest in NAC. For now, it's all about the price; if you're buying a Windows 2008 license, you're getting the functionality for free. In addition, as more vendors develop the System Health Validators needed to expand on present policy enforcement capabilities, we expect Microsoft NAP to mature to the point where it will pose a significant threat to established NAC players.
If our reader survey yielded one truth, it's that IT wants an industry-standard NAC framework.
On the other hand, Microsoft Network Access Protection is difficult to configure, even for simple enforcement methods. We'd like to see a more intuitive auto-install process for an antivirus or anti-spyware client as part of the auto-remediation process, for example, and we wish Redmond had added captive portal functionality for guest access in this first cut of NAP. Microsoft says that functionality is coming via Forefront Universal Access Gateway, due next year. In addition, it's an open question how aggressively Microsoft will seek to dominate the NAC market. In much the same way that Citrix and Terminal Services coexist, we don't see the company wanting to alienate its partners over what is, after all, a free feature of Windows 2008 Server. Expect Microsoft to instead concentrate its top talent on the features that will most quickly drive licensing revenue growth--like Hyper-V, which we'll evaluate in the next installment of our Windows Server Rolling Review.
About the Author
You May Also Like