|
Executive Summary: Microsoft Windows Server 2008 uses Network Access Protection (NAP) technology to ensure network security by enforcing compliance policies before client computers can access network resources. If a client computer doesn’t meet security requirements, NAP places the computer in quarantine or denies the computer network access. |
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:
- IPsec-protected communications
- IEEE 802.1x-authenticated connections
- VPN connections
- DHCP-managed connections
- Terminal Services Gateway 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.