According to Microsoft, Network Access Protection (NAP) is the single most popular new feature in Windows Server 2008. NAP is designed to help organisations manage client devices that connect to their networks. Its basic function is to check that PCs are configured according to IT policies and take appropriate action if they are not. For example, NAP can check that a client PC is running Windows Firewall, that its anti-virus signatures are up to date and that specific patches are installed.
Should a PC fail to pass muster, NAP can be configured to warn the user, or reprogram a switch supporting RADIUS VLAN assignments so that the client is refused access to the LAN.
However, NAP simply asks the client operating system various questions, and it's up to the client to respond honestly. Should the client be infected with malware, it's likely to provide misleading responses to NAP's enquiries. Therefore, NAP is not so much a security enforcement system as a tool to help IT managers ensure that the bulk of their client devices are patched and configured correctly.
In lab tests by ZDNet.com.au's sister site ZDNet UK, NAP was intalled using the Add Roles Wizard to add Network Policy and Access Services to one of our test systems. As we wanted to put the full NPS suite onto a single server we ticked the option box for Health Registration Authority (HRA), so the wizard told us we also needed to install Internet Information Services (IIS) and many of its management tools. HRA can be configured to issue certificates only to clients that are authenticated to a domain, or can work with all clients. Network Policy and Access Services is compatible with domains running Windows 2000 or later modes. For our tests we took the option to work with all clients. As we clicked through the dialogue boxes to complete the installation, the wizard told us it needed to install Active Directory Certificate Services and the Windows Process Activation Service in order to make a working NPS system, and warned us that once the software was installed we would not be able to change the name of the server.
The Network Policy Server tool allows client-access policies -- in this case for devices connected over a VPN -- to be configured for a network.
With the software installed, we used a wizard in the Network Policy Server (NPS) management tool to set up policies for our environment. For our test, we configured a policy for clients connected using a VPN. We could also create policies for clients connecting via DHCP, Terminal Services Gateway, 802.1x wired and wireless, and IPsec with HRA. The wizard gave us the option to specify RADIUS access servers, and then the option of groups of machines and users to which the policy would apply. Each policy can be set up to allow clients to authenticate to NPS using passwords or certificates, and NPS can work with certificates stored either in smartcards or certificate stores. You can also specify a remediation server, to which clients that fail the NAP checks can be restricted, and from which from which any required patches can be downloaded before trying the NAP checks again.
Security Health Validators compare the status of devices wishing to connect to the LAN, and either grant access, deny access or direct it to a remediation server.
Options are also available for clients to automatically remediate themselves against the remediation server; you can then choose whether to allow full access to NAP-ineligible clients.
Before testing our NAP setup, we needed to enable Routing and Remote Access using the appropriate tool from the Administrative Tools program group. For example, our XP SP2 system was not able to perform the NAP checks, but was allowed full network access because our VPN Non NAP Capable policy was configured to allow this. NAP will be supported by systems running XP SP3 and Vista SP1. Third-party vendors are expected to producte NAP clients for Linux and Mac OS X desktops in the near future.
The facility to force compatible clients to automatically remediate themselves if they don't pass the NAP health checks is clearly extremely useful. However, some organisations may wish to use NAP in either its reporting or deferred enforcement modes. Both of these modes can be used to improve the health of client systems before the policy enforcement mode is activated. Also impressive are NAP's reporting capabilities, which can show how many systems are compliant with an IT department's patching and configuration regimes.
6%
2%
Be very careful of building applications based on M$ servers... Server 2003 dropped support for earlier API calls, and our application failed to work... The problem was that with M$ you can't really stay on older versions, as support is dropped etc, yet there is no corporate commitment to retain reverse compatibility. It would not have hurt M$ to retain the API support... but M$ just thought everyone should be migrated onto the newer M$ ways of doing things (.NET etc further lock-in). Our problem was that we were not yet ready to re-write that functionality.. and the programers who did write the earlier stuff were no longer around. To this day, for adding new users to an M$ Access application, we need to copy the database off the 2003 server back to the prior server (NT server) and make the changes, then re-copy the database files back onto the 2003 server. Clearly the application still works, but what changed was M$' support for functions done within their own complementary products (eg Access).
The good: Can't think of any... Presumably some of the security problems of the earlier product are addressed... but at a cost of greater lock-in.
The bad: Our experience with non-compatibility in 'upgrading' from one M$ product to its replacement has meant that we are seriously looking to standardise on only Linux servers, knowing that Linux retains strict reverse-computability and adherence to true standards.