Microsoft shows up for the NAC party

Server-side access control works as advertized, but only with the latest Windows clients

Microsoft's server-side support for network-access control has finally seen the light of day.

The security scheme – Microsoft calls it Network Access Protection (NAP) -- is an ambitious attempt to admit clients to a network based upon adherence to Microsoft's group policies, specifically relating to the client system's health. In our testing, NAP worked, but it required a significant degree of configuration.

NAP employs a three-tier network system, comprising a secure network, a resource-limited "boundary" network, and the public network. To gain admittance to the secure network, the client makes a request to join the network. The client is then checked for conditions imposed by pre-defined group policies, such as it running the latest antivirus updates and all critical Windows updates. These group policy objects have a degree of flexibility in terms of what passes or fails.

This scenario is not much different from what you would see in any 802.1X-driven NAC scenario.

Three different services are required to make the NAP scheme effective: a boundary health checker, the client-side Microsoft System Health Agents (currently only available for Vista and Windows XP SP3 machines), and a NAP enforcement point also included in the new server package.

The boundary health checker is presented with the System State of Health (SSoH) information by the agent software, and passes this to the admittance controller. The admittance controller may tap into a DHCP server or use 802.1X proxy authentication via a network boundary device such as a Wi-Fi access point that 802.1X authentication enabled.

In our test, we used Vista clients that had the Windows Firewall installed and we configured server-side policies to include an antivirus application. We enabled the IPSec enforcement client, which mandates secure, IPSec (key-based and encrypted) communications between the client and the server. We enabled the NAP agent service as a daemon on the client, after its configuration, which included registering the network location of system health services and authenticators residing in the Windows Server 2008 server.

With server-side policies constructed, and client-side network access information registers and the NAP client installed, we attempted a logon and it correctly failed, as we didn't have the Windows Firewall turned on in the client, and didn't have current antivirus files installed. We were pointed to the remediation server, which contained the necessary antivirus files.

A subsequent logon attempt prevented us from obtaining an IPSec logon because we hadn't turned on the Windows Firewall. We enabled the firewall and a third attempt correctly linked us to the 'secure network' represented by our test server, which contained the services needed to check our credentials and also serve as a reference checker for needed policy compliance.

So NAP works. But it still could fail to be adopted for several reasons. It's complex and requires quite a bit of configuration and ongoing management. It also requires that the health validation servers and remediation servers always be available, else client logons will fail. Microsoft's NAP also has allowances for exceptions to the NAP process for both 'friendly' servers and those that have no client agents, but these unvetted client logons could thwart the integrity of the entire NAP system — just as one bad/weak/absent password allowance compromises an entire system. And finally, Macintosh, Linux, and other clients can't participate in the NAP scheme until client-side health agents are offered (and hopefully maintained).

< Return to main test

Learn more about this topic

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.