Using Group Policy Filtering to Create a NAP DHCP Enforcement Policy (Part 3)

If you would like to read other parts to this article please go to:

If you would like to be notified when Tom Shinder releases Using Group Policy Filtering to Create a NAP DHCP Enforcement Policy (Part 4) please sign up to the WindowSecurity.com Real TIme Article Update Newsletter.

In part 2 of this series on configuration NAP for DHCP enforcement, we went over the NAP configuration wizard in the NPS console. The NAP configuration wizard created a number of policies, including connection request policies, health policies and network policies. In this, part 3 of the article series, we’ll look more closely at these policies and see what they do in the NAP DHCP enforcement solution.

Connection Request Policy

A connection request policy allows you to designate whether connection requests are processed locally or forwarded to remote RADIUS servers. In the figure below you can see that the wizard created a NAP DHCP connection request policy that has specific conditions and settings. As you can see in the figure below, the single condition applied to this policy is that it is applied at all times for all days of the week, and that the only Setting is that the Authentication provider is the Local Computer (the machine that is running the NPS service).

Let’s double click on this policy and see what shows up.


Figure 1

On the Overview tab, you can see that the policy is enabled and that the network connection method is DHCP. This means that the DHCP server is the network access server for this network and the DHCP network access server communicates with the RADIUS (NPS) server to determine whether or not to allow access to the network, and what type of access the computer should be allowed to the network based on the client health state.


Figure 2

On the Conditions tab you can see the conditions that appeared in the NPS console earlier. The only conditions applied to this rule is that it is applied at all hours for all days of the week.


Figure 3

On the Settings page, click the Authentication link in the left pane of the page. Here you can see that the Authentication settings are set to Authenticate requests on this server. This RADIUS (NPS) server is the server that performs the authentication. In some cases you might want to put the DHCP server on a machine separate from the NPS server that is doing the authentication. In that case, you would still need to install NPS on the DHCP server machine, but then you would configure that NPS server to forward authentication requests to a remote RADIUS (NPS) server by using the Forward requests to the following remote RADIUS server group for authentication as seen in the figure below.

Click OK in the NAP DHCP Properties dialog box.


Figure 4

As you can see, the connection request policy sets conditions and authentication settings for the overall NAP policy. Now let’s take a look at the NAP Network Policies.

Network Policies

NAP Network Policies allow you to designate who is authorized to connect to the network and the circumstances under which they can or cannot connect. You can see that the NAP wizard has created three Network Policies for our overall NAP policy:

  • NAP DHCP Compliant This Network Rule applies to machines that are NAP compliant
  • NAP DHCP Noncompliant This Network Rule applies to machines that are not NAP compliant
  • NAT DHCP Non NAP-Capable This Network Rule applies to machines that aren’t able to process NAP policies

In the following three figures, you can see the Conditions and Settings for each of these rules. The main difference between these three rules is the level of access each of these rules provides clients to the network. For fully compliant DHCP clients, full access is allowed to the network. For non-compliant or unable to apply NAP machines, then they are allowed limited network access with the hope that they will be able to use that limited network access to remediate and then meet compliance requirements.


Figure 5


Figure 6


Figure 7

Let’s double click on one of these rules and see what lies beneath. When you double click on the NAP DHCP Noncompliant Properties rule, the first tab you see is the Overview tab. Here we can see that the policy is enabled, that the Access Permission is to Grant access and that the users dial-in properties should be ignored (since DHCP clients aren’t dialing into the network). Finally, you can see that the Network connection method is DHCP server.


Figure 8

On the Conditions tab, you can see that the NAP DHCP Noncompliant Health Policy will be applied when the NAP DHCP Noncompliant Properties Network Rule is applied. We’ll look at the Health Policies in more details in a little bit.


Figure 9

On the Constraints page, the wizard has configured the constraints on the Network Policy. The only constraint is that only a health check should be applied and that there are no other authentication requirements.


Figure 10

Click on the Settings tab and then click on the NAP Enforcement link in the left pane of the dialog box. In the right pane you can see that the wizard has configured the level of access allowed for this Network Policy. In this case the wizard has configured the policy to Allow limited access. Limited access is defined as access only to IP addresses, network IDs, and servers that are required for basic network services and to enable remediation. You can add more of these by clicking the Configure button in the Remediation Server Group and Troubleshooting URL frame.

If you click the Configure button, you’ll see that the Network Services group that we created appears as the remediation server group that applies to this network policy.

Note that based on our selections in the wizard, the Network Policy is also configured to enable Auto remediation, as there is a checkmark in the Enable auto-remediation of client computers checkbox.


Figure 11

Health Policies

Health Policies are used with NAP to allow you to designate the configuration required to NAP-capable client computers to access the network. In essence, the Health Policies are used to determine if the machine meets that definition of a compliant computer. As you can see in the figure below, the wizard has created two Health Policies:

  • NAP DHCP Compliant
  • NAP DHCP Noncompliant

The purpose of each one should be clear. The compliant policy defines computers who are compliant with out network health policies and the non-compliant policy defines what it is to be non-compliant with our network health policy.

In the figure below you can see that I have double clicked on the NAP DHCP Noncompliant entry to bring up the NAP DHCP Noncompliant Properties dialog box. Here you can see that in order to meet the requirements of this policy, the client must fail one or more SHV checks using the Windows Security Health Validator. That all there is to it! Guess what the definition of the DHCP compliant policy is? You guessed it. The client passes all of the SHV checks for the Windows Security Health Validator.


Figure 12

When you expand the Network Access Protection node in the left pane of the Network Policy Server console, you’ll see that there are two nodes: the System Health Validator node and the Remediation Server Group node. Click on the System Health Validator node.

Here you can see in the right pane of the console a list of System Health Validators that are used to determine the Health Policy we saw earlier. By default, there’s only a single SHV, which is the Windows Security Health Validator. When you click on this SHV, you can see in the bottom pane under the SHV a list of error code configurations. You can see that the wizard has set for each of these error codes that the client should be deemed non-compliant.

Let’s take a closer look by double clicking on the Windows Security Health Validator entry.


Figure 13

This brings up the Windows Security Health Validator Properties dialog box. Here you can see the Error code resolution settings. These error code resolution settings are used to determine how to handle situations where various error codes are encountered during the NAP enforcement process. The defaults configured by the wizard are the most secure and I recommend that you keep them as they are.

Click the Configure button to configure the settings for this SHV.


Figure 14

This brings up the Windows Security Health Validator dialog box, which has two tabs: a Windows Vista tab and a Windows XP tab. In this example we’ll focus on the Windows Vista tab since that’s the only client we’ll be testing when we complete the configuration.

The Windows Security Health Validator allows you to configure the following:

  • Firewall You can force a firewall to be enabled on the Vista client in order to be compliant with health policy
  • Virus Protection You can force that virus protection be enabled in order to be complaint. In addition, you can require that the virus protection be up to date in order to be compliant.
  • Spyware Protection You can force that an antispyware application be enabled to be compliant. In addition, you can force that the antispyware application be up to date in order to be compliant.
  • Automatic Updating When automatic updating is enabled, the NAP agent on the client will try to fix the problem. For example, if the user disables the Windows Firewall, the NAP agent on the client machine will try to turn the firewall back on
  • Security Update Protection When this option is enabled, you can choose to restrict clients from accessing the network based on their current state of security updates. You can use the drop down list seen in the figure below to set what type of security updates are required. You also have the option to set the minimum number of hours allowed since the client has checked for new security updates and whether you want to allow the clients to use Windows Server Update Servers or Windows Update (Microsoft Update is allowed by default).


Figure 15

The figure below shows the SHV settings for the Windows Security Health Validator for the Windows XP client. Notice that the anti-malware options aren’t included here.


Figure 16

Summary

In this, part 3 of our article series on NAP DHCP enforcement, we looked at the details of the Health, Network and Connection Request policies created by the NAP wizard. In addition, we took a detailed look at the of the Windows Security Health Validator. In the next and last part of the series, we’ll examine the DHCP server setup and then test our NAP policies. See you then! -Tom.

If you would like to read other parts to this article please go to:

If you would like to be notified when Tom Shinder releases Using Group Policy Filtering to Create a NAP DHCP Enforcement Policy (Part 4) please sign up to the WindowSecurity.com Real TIme Article Update Newsletter.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top