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.