Network Access Protection in Windows Server 2008

In considering LAN security, we mostly think about preventing an attacker from accessing network resources. The reason for this focus is simple: Most attacks are initiated from the Internet and are directed at breaking into private networks.

However, an equally large security issue that administrators must address is preventing regular (i.e., authenticated and authorized) network users from using computers with weak security configurations to access network resources. For example, a traveling employee might have a laptop that only occasionally uses the VPN to connect to the corporate LAN—but this laptop still needs all the current security fixes, antispyware, and antivirus definitions installed. Otherwise, such a computer is a likely source to spread viruses or worms on the network. If a computer doesn’t have a firewall enabled and becomes infected with Trojan-like software, the computer can provide unauthorized persons with easy access to local network resources. Employees’ home computers that use the VPN to access the corporate LAN and that aren’t managed properly provide a similar risk. Finally, letting visitors connect their computers to your local network, even just to provide them with Internet access, can put other hosts on the network at risk for infection with viruses or other kinds of malicious code.

The question is: How do you check a computer’s security configuration before you allow it to access network resources? In addition, how do you determine whether to grant full or limited access? Network administrators need a mechanism to ensure that any computer connecting to the corporate network meets the organization’s health policy requirements and has all the necessary software, patches, and hotfixes installed.

Network Access Protection
Windows Server 2003 SP1 includes a technology called Network Access Quarantine (NAQ) that helps administrators limit or deny connections to computers that don’t comply with a company’s security policies. However, NAQ has many disadvantages. First, it’s limited to VPN-based connections only, which means you can’t protect your network from unsecured wireless users, or even from users who have a physical connection to the network (e.g., via employees’ personal laptops). Second, NAQ is based on manually created scripts (implemented via Connection Manager) that must be run on the client side before VPN access is granted. These scripts check such things as the firewall state, antivirus state, presence of a password-protected screen saver, and status of Internet Connection Sharing. Besides the fact that writing the scripts can be difficult and time consuming, the various types of protection software on the client side can also cause problems. For example, if VPN clients have various antivirus programs, you must write a specific script for each program and use a different Connection Manager package for each. In the end, this solution is static. After the client passes all the checks and the main script reports the state of the client’s health to the server, the user can safely disable the firewall, antivirus software, and all other security features. These actions won’t be detected, and the level of access to resources will remain unchanged.

Windows Server 2008 solves most of NAQ’s disadvantages with Network Access Protection (NAP) technology. Using NAP, an administrator can enforce specific compliance policies that must be met before a client computer can access network resources. If a client computer doesn’t meet the defined health requirements, it’s either placed in quarantine (with access limited to specific hosts) or simply not allowed access.

In addition, NAP can automatically remediate unhealthy clients, updating systems when possible to make them comply with corporate policy. The administrator configures NAP’s method of enforcement, depending on the type of client connection. NAP enforces health requirements for the following types of connections:

In this article, I focus on NAP implementation for DHCP-managed connections. Using NAP with DHCP lets you protect your network from all potentially unsecured clients that are managed via DHCP (i.e., clients that receive IP addresses from DHCP), including resident desktop computers that are NAP capable.

NAP-capable OSs include Windows Vista (by default) and Windows XP SP2 with NAP client software (currently in Beta 3). XP SP3 will include the NAP client by default. No older OSs are supported, because NAP relies on information from Windows Security Center (WSC), which exists only in Vista and XP SP2.

A benefit of NAP is that it’s not limited to Microsoft technologies. Any system that can provide the NAP server with its health state can also use NAP. Microsoft is working with many hardware and software vendors and other partner companies to help them create NAP-compatible devices and software. To use NAP for DHCP-managed connections, you must prepare the environment, configure health policies, create network policies for NAP, configure DHCP for NAP, and enforce NAP on the client side.

Prepare the Environment
First, you must have an existing Active Directory (AD) infrastructure available, with one or more Windows 2003-based (or Server 2008-based) DCs. DHCP must be installed on a Server 2008 machine, because previous versions of the DHCP service (such as the version on Windows 2003) aren’t aware of NAP. You need at least one static IP address for this host.

Install Server 2008 as a member server in your domain. After installation, you must add the Server 2008 roles called Network Policy Server and DHCP Server. You can easily accomplish this task through the Server Manager console, which is available on the Welcome page or under Administrative Tools. Open Server Manager, go to Roles Summary, and click Add Roles. Server 2008’s Network Policy Server role replaces Windows 2003’s Internet Authentication Service (IAS). Thus, Network Policy Server (NPS) lets you create various types of policies, not just those related to NAP.

Configure Health Policies
To configure your health policies, go to Administrative Tools and click the Network Policy Server role you added. In the NPS console that opens, you must configure the System Health Validator and Health Policy options to create an appropriate network policy. The System Health Validator component defines your security requirements for clients that are accessing the network, whereas Health Policy defines different configurations for NAPcapable clients.

Double-click the Network Access Protection node on the left side of the console, and click System Health Validator. The Windows Security Health Validator item will appear on the right side of the console. Double- click this item to open the configuration window that Figure 1 shows. In this window, click Configure to see options for security requirements. As Figure 2 shows, you can simply select the appropriate check boxes to indicate what you require from clients. In Vista, you can require the firewall to be enabled, antivirus and antispyware applications to be present and current, the automatic update feature to be enabled, and current hotfixes to be installed. Similar requirements are available in XP SP2, other than the antispyware option, which isn’t part of XP. For testing purposes, let’s select only the firewall check box for both Vista and XP. Click OK twice to finish configuring the System Health Validator option.

To configure the Health Policy option, double- click the Policies node in the NPS console, right-click Health Policies, and select New. In the window that Figure 3 shows, enter the policy name and select what the System Health Validator (SHV) component will check.

First, let’s create a policy for compliant clients. Enter compliant for the policy name, and select Client passes all SHV checks from the drop-down menu. Selecting this option means that, for a client to be considered healthy, it must pass all the requirements you configured in SHV (which in the example was only the firewall requirement). Next, select the Windows Security Health Validator check box and click OK. Your first policy is now configured.

Next, let’s create a policy for noncompliant computers. Follow the same steps to create a new health policy, perhaps called noncompliant. In the drop-down menu, select Client fails one or more SHV checks, which means that if a client fails to correctly report one or more required components from SHV, it will be considered unhealthy. Finally, select the Windows Security Health Validator check box and click OK.

Create Network Policies for NAP
After you configure the SHV and Health Policy options, you can configure network policies. In the NPS console’s Policies node, click Network Policies and disable the default policies. By default, the two default policies are Connections to Microsoft Routing and Remote Access Server and Connections to other access servers. Right-click each policy and select Disable from the drop-down menu. Then, right-click the Network Policies folder and select New. A wizard for creating a new policy will start. Enter a policy name (e.g., “noncompliant- restricted” for a policy for unhealthy clients). Then, select from the drop-down list the type of network access server that will apply the policy to clients. The default is Unspecified; for our purposes, select DHCP Server.

Click Next to proceed to the Conditions page, and click Add to select conditions for the policy. From the list of available conditions that displays, select Health Policies from the Network Access Protection group. In the window that opens, select the “noncompliant” health policy that you created earlier.

Follow the same procedure to add the NAPCapable condition, which Figure 4 shows, to the policy. This condition limits application of the policy only to computers that are NAP capable.

Click Next to launch the Specify Access Permission window. In this window, you must specify what to do with clients that meet the policy. Although denying access to unhealthy clients might seem logical, you don’t want to completely deny access to those clients. Instead, you should provide them with limited access only to hosts that can help them improve their security state (i.e., remediation servers). Select Access Granted and click Next.

In the Configure Authentication Methods window, select the Perform machine health check only option, and clear the other check boxes, as Figure 5 shows. Because you’re configuring a policy for checking clients’ security health state via DHCP and because DHCP clients don’t authenticate to the DHCP server, you don’t need to configure authentication methods. Just click Next in the Configure Constraints window—none of the options apply to our example.

In the Configure Settings window, select NAP Enforcement in the Network Access Protection section, as Figure 6 shows. For this policy, you should select the Allow limited access NAP enforcement method. This setting will put clients in quarantine and give them access only to remediation servers. You can also configure those servers from this window: Simply click Configure to create a Remediation Server Group, and enter IP addresses for the hosts. Also select the Enable auto-remediation of client computers check box. Enabling both these settings causes the NAP Enforcement client component to automatically attempt to update the computer security state (e.g., if you turn the firewall off, it will be turned on automatically).

After you create a policy for incompliant clients, you must create a policy for compliant clients. Follow the same steps to create another new network policy, this time naming the policy “compliant full.” On the Conditions page, select the “compliant” health policy. Then, select the Allow full network access check box on the NAP Enforcement Settings tab. All other settings are the same as for the incompliant client policy.

Finally, you can configure a policy for NAP non-capable clients, to provide them with or deny them network access. This policy should grant or deny access to clients that aren’t NAP capable, by implementing only the NAPCapable condition, with the Only computers that are not NAP-capable option selected. (Note that this policy isn’t necessary in a test environment.)

Figure 7 shows the NPS console after you’ve created the necessary policies. Next, you need to configure DHCP.

Configure DHCP for NAP
You need to configure DHCP, so that DHCP can use NPS and the policies you created. First, you must create a scope on the DHCP server. Our intention is to configure the DHCP server to distribute a different group of scope options to compliant and incompliant NAP clients. After you create a scope, right-click it in the DHCP console. Select Properties, and go to the Network Access Protection tab. Then, select the Enable for this scope check box, as Figure 8 shows, and use the default NAP profile.

Another thing you can configure from the Network Access Protection tab in IPv4’s properties is DHCP behavior, in case DHCP can’t contact the network policy server. The default setting is to give clients full access, but you can also select the Restricted Access or Drop Client Packet options. In addition, you can enable and disable NAP on the server level.

Finally, you must configure additional options for NAP-capable clients. Right-click Scope Options, and select Configure Options. In the Configure Scope Options dialog box, select the Advanced tab. Select Default Network Access Protection Class as a User class, and define specific DHCP options for this class of clients (e.g., different DNS domain name, different gateway).

Enforce NAP on the Client Side
The last step is to configure the client to work with NAP. In fact, you must enforce the use of NAP on clients. You can accomplish this task through the NAP Client console, Group Policy, or Netsh (which has the new context for NAP configuration). Because you can’t configure domain or OU Group Policy Objects (GPOs) to include NAP settings from Windows 2003, using Group Policy requires you to edit GPOs from Vista or Server 2008’s Group Policy Management Console (GPMC). Use the Administrative Tools’ Services console to start the Network Access Protection Agent service, changing this service’s startup type to Automatic (which you can also use Group Policy to accomplish).

On Vista, start the Microsoft Management Console (MMC) and add the NAP Client Configuration snap-in. Alternatively, select Run from the Start menu, and enter

napclcfg.msc

Select the Enforcement Clients node in the left task pane, double-click DHCP Quarantine Enforcement client on the right side, select Enable this enforcement client, and click OK. From now on, the client should be able to use NAP.

To use Netsh to configure NAP on a client, go to the command line and enter

Netsh nap client set enforcement ID = 79617

If you want to use XP SP2, you must install the NAP client software for XP Beta 3, which makes the OS NAP capable.

Run a NAP Test
To test NAP on a client, configure a Vista client and join it to your domain. Obtain an IP address from the DHCP server, with the firewall in the default active state. Ensure that you have a regular IP address, from the scope that you created in earlier steps, with regular scope options. To verify that you have all the necessary DHCP information (e.g., DNS servers, gateway, WINS servers), go to the command line and enter

ipconfig /all

Figure 9 shows the output.

Next, manually disable the Vista firewall. In a few seconds, the DHCP enforcement client will perform autoremediation to correct the client’s system state, thus reenabling the firewall. To demonstrate a quarantined client, go to Server 2008’s NAP console and configure Windows Security Health Validator to require an antivirus application to be installed and updated. If you don’t have an antivirus solution on the Vista client, run ipconfig /release followed by ipconfig /renew to quarantine your client and receive a taskbar quarantine notification message. Run ipconfig /all again, and note that your computer is configured with the options you specified in DHCP’s Network Access Protection class. As Figure 10 shows, all you have is an IP address and subnet mask—no Internet access, and no access to other hosts on the network.

An Effective Solution
Maintaining computers’ health is one of the most time-consuming challenges that any network administrator faces. This complex task is made even more difficult if you must maintain system health for users who connect from home systems, partner computers and laptops that aren’t under control of administrators, or computers that aren’t managed through a corporate patching system (e.g., Windows Server Update Services—WSUS, Microsoft Systems Management Server—SMS). NAP is an effective solution for controlling network computers’ security health.