Upgrading Your Skills to MCSA Windows Server 2012 R2: Configure a Network Policy Server Infrastructure

Network Access Protection (NAP), as you know, is a Windows Server technology that enforces health requirements on client computers as they attempt to connect to a company network. These health requirements can relate to the status of software updates, of anti-virus protection, of host firewall status, or of spyware protection. NAP was first introduced in Windows Server 2008.

In a move that surprised many, Microsoft announced with the release of Windows Server 2012 R2 that NAP has been officially deprecated (set on a path to obsolescence). Some improved alternative to NAP might very well appear in a future version of Windows Server, but for now, you still have to deal with NAP on the 70-417 exam. Questions about NAP are not being phased out.

Although NAP doesn’t include any significant new features in Windows Server 2012 or Windows Server 2012 R2, one important new feature, System Health Validator (SHV) Multi-configuration, did appear in Windows Server 2008 R2. This new feature falls within “Configure Network Access Protection,” the one NAP objective listed for the 70-417 exam.

Objectives in this chapter:

• Objective 7.1: Configure Network Access Protection (NAP)

Objective 7.1: Configure Network Access Protection

NAP can be deployed in many different configurations, depending on whether it is enforced through DHCP, virtual private networks (VPNs), IPSec, Remote Desktop Services Gateway, or 802.1x. It’s important to review how NAP enforcement is configured.

Most of NAP has remained the same since Windows Server 2008, but there is one new feature in NAP that falls within the Configure Network Access Protection objective: SHV Multi-configuration.

How NAP works

First, let’s review some basic NAP concepts. When a client computer first attempts to connect to a network, its first point of contact could be a DHCP server, a VPN server, or another type of device. In a NAP infrastructure, this first point of contact is configured as a NAP enforcement point, and the NAP client is configured to report its system status (called a statement of health or SoH) to this NAP enforcement point.

The NAP enforcement point uses the RADIUS protocol to forward the SoH and connection request to a Network Policy Server (NPS). The NPS server uses connection request policies to determine whether the client connection request will be processed by NAP. If evaluated by NAP, the client request is next processed by network policies, which provide potential instructions about whether to allow the connection, block the connection, or allow restricted access only to a remediation server or set of servers. Of all the instructions defined in various network policies, only one set is applied to a connection: that of the first network policy whose conditions match the connection request.

Figure 7-1 shows an example of a simple NAP infrastructure.

Network policies usually include health policies as matching conditions. Health policies, for their part, determine whether a NAP client matches an indicated state of failing or passing a health check according to an SHV. Windows Server includes one built-in SHV, Windows Security Health Validator.

Besides the network policies that assess the health compliance of NAP clients, an additional network policy is normally also included to match clients that are not NAP-capable. These network policies include a condition named “NAP-Capable” (meaning “NAP capability status”) whose value is configured as “Computer is non NAP-capable.” (NAP-capable computers are ones that send an SoH.) Network policies created to match non-NAP-capable clients may be configured either to allow or block the connection request.

The following list further describes these components involved in NAP processing:

• Connection request policies Rules that determine whether a connection request will be processed by network policies.
• Network policies Rules that compare the health of connection requests to health policy statements and accordingly allow access, block access, or allow remediated access to those requests. Network policies include conditions and condition values configured to match different types of clients. The Health Policy condition uses a health policy check to match a client. The NAP-Capable condition matches clients based on whether they have sent an SoH. The MS-Service class condition is used to match particular DHCP scopes.
• Health policies A statement of health compliance or noncompliance according to a particular SHV.
• SHVs A software component that performs a particular set of tests about the safety of a client connection.
• Windows SHVs The default SHV and only SHV built into Windows Server.

Figure 7-2 illustrates how these components could work together in a particular example of NAP processing.

Configuring NAP

The procedures for configuring the various NAP enforcement types all differ from each other, but they do share common steps. In general, you first configure the NAP server by using the Configure NAP Wizard. You start this wizard by clicking Configure NAP in the details pane when the NPS (Local) node is selected in the console, as shown in Figure 7-3.

You use the Configure NAP Wizard to specify the NAP enforcement type you want to implement and to create the required connection request policies, network policies, and health policies. After running the wizard, you create security groups for NAP and configure Group Policy. You can also modify the policies created by the wizard, for example, by adding an MS-Service class condition to match the profile name you have assigned a DHCP scope on your DHCP server. This condition would accompany the Health Policy condition automatically added by the Configure NAP Wizard, as shown in Figure 7-4.

SHV multi-configuration

Windows Server 2008 allowed you to configure just one set of health tests for each SHV. As a result, an NPS server couldn’t normally adjust its health checks to suit different NAP client types.

This limitation could sometimes present a problem. In some scenarios, you might prefer to apply different health checks to different enforcement methods, computers, or users. For example, you might want to require all VPN-connected computers to have their antivirus software both enabled and up-to-date but require local DHCP-based connections to have their antivirus software only enabled. To meet such a requirement in Windows Server 2008, you normally needed to use two NPS servers.

In Windows Server 2008 R2 and later, however, you can now create multiple configurations for each SHV. After you create additional configurations beyond the default configuration, you can specify which SHV configuration you want to use for a particular health policy. Figure 7-5 shows an example of multiple configurations created for the built-in SHV, Windows Security Health Validator.

Default configuration

Since Windows Server 2008 R2, a Settings node now appears in the Network Policy Server console beneath the default Windows Security Health Validator (and beneath any additional SHVs you have installed that are also compatible with multiple configurations). When you select the Settings node, only the Default Configuration appears by default. This configuration can’t be deleted or renamed.

Creating additional SHV configurations

To create an additional configuration for an SHV, perform the following steps. (These steps demonstrate the procedure using the built-in Windows Security Health Validator as the SHV.)

1. In the Network Policy Server console tree, navigate to Network Access Protection\System Health Validators\Windows Security Health Validator\Settings.

2. Right-click Settings and then click New, as shown in Figure 7-6.

   

   FIGURE 7-6 Creating an additional SHV configuration

3. In the Configuration Friendly Name dialog box, type a name for the new configuration and then click OK.

4. In the Windows Security Health Validator window, shown in Figure 7-7, specify the desired system health requirements for the configuration.

   

   FIGURE 7-7 Specifying settings for a new SHV configuration

You can enable any of the following health checks:

• A Firewall Is Enabled For All Network Connections If this check box is selected, the client computer must have a firewall that is registered with Windows Security Center and that is enabled for all network connections.
• An Antivirus Application Is On If this check box is selected, the client computer must have an antivirus application installed, registered with Windows Security Center, and turned on.
• Antivirus Is Up To Date If this check box is selected, the client computer can also be checked to ensure that the antivirus signature file is up-to-date.
• An Antispyware Application Is On If this check box is selected, the client computer must have an antispyware application installed, registered with Windows Security Center, and turned on. (Not available for Windows XP.)
• Antispyware Is Up To Date If this check box is selected, the client computer can also be checked to ensure that the antispyware signature file is up-to-date. (Not available for Windows XP.)
• Automatic Updating Is Enabled If this check box is selected, the client computer must be configured to check for updates from Windows Update. You can choose whether to download and install them.
• Security Update Settings Use this section to define health checks related to security updates. If you select the option to restrict access for clients that do not have all available security updates installed, clients will be designated as noncompliant if they do not meet this requirement according to the criteria you specify. You can specify the minimum severity level required for the updates and the minimum number of hours allowed since the client has checked for security updates. You can also choose require clients to use Windows Server Update Services (WSUS), Windows Update, or both sources.

Assigning an SHV configuration to a health policy

To assign different health checks to different NAP client types, you can assign different SHV configurations to the health policies created for these different client types. For example, you might want to assign one SHV configuration to your VPN client health policies and another to your DHCP client health policies.

It’s best to use the Configure NAP Wizard to generate your health policies automatically. The health policies created by the Configure NAP Wizard will be assigned appropriate names and be set as conditions in new, correctly configured network policies. Normally there will be two health policies for each client type, one compliant and one noncompliant. For example, if you run the Configure NAP Wizard twice and specify first VPN and then DHCP as the network connection methods, the wizard will generate the four health policies shown in Figure 7-8. For each client type, the noncompliant health policy serves as a matching condition for clients that do not pass one of the health checks.

If you want to assign a custom SHV configuration to a certain type of client, the only thing you have to do after running the Configure NAP Wizard is to modify the properties of the newly created health policies. You want to specify the same SHV configuration for both the compliant and noncompliant versions of the same NAP client type (for example, VPN or DHCP).

By default, when a new health policy is created, the Default Configuration of the SHV is used to define the health checks for that health policy. To assign a nondefault SHV configuration instead, perform the following steps:

1. In the Network Policy Server console, navigate to Policies\Health Policies and then double-click the name of the health policy that you want to modify.

2. On the Settings tab, in the SHVs Used In This Health Policy list, click the drop-down arrow in the Setting column for the Windows Security Health Validator SHV to see a list of available configurations. (Figure 7-9 shows an example.)

   

   FIGURE 7-9 Assigning an SHV configuration to a health policy

3. Select the desired configuration in the Setting drop-down list and then click OK.

Objective summary

• NAP is a technology that enforces health requirements on client computers as they attempt to connect to a network.
• The NAP feature most likely to be tested is SHV Multi-configuration. This feature first appeared in Windows Server 2008 R2. With SHV Multi-configuration, you can define different sets of health checks for a single SHV. You might use this feature to assign a higher health standard for certain types of NAP clients, such as VPN clients.
• After you create a new configuration for an SHV, you can assign that configuration to health policies. The configuration is applied to a particular NAP client type if you modify the health policies created for that client type.
• NAP has not changed much since Windows Server 2008, so you should be prepared to answer some of the same types of questions about this feature that you saw when you last earned your certification.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of the chapter.

1. You have deployed NAP in your network with VPN enforcement. You have deployed a single NPS on a computer running Windows Server 2012 R2 and are using Windows Security Health Validator as the only SHV.

   Through your NAP policies, VPN clients that are evaluated as noncompliant are allowed access only to a set of remediation servers.

   You now want to implement NAP with DHCP enforcement. However, you only want to log noncompliant DHCP clients. You don’t want to block noncompliant DHCP clients from accessing any part of the network.

   What should you do?

   1. Create a new configuration for the SHV for the DHCP clients.
   2. Install an additional SHV and configure it for the DHCP clients.
   3. Modify the default NAP DHCP connection request policy.
   4. Modify the default NAP DHCP Noncompliant network policy.

2. You have deployed NAP in your network with VPN enforcement. You have deployed a single NPS on a computer running Windows Server 2012 R2 and are using Windows Security Health Validator as the only SHV. Your VPN clients are allowed only restricted access to the network if either security updates or virus definitions are not up-to-date.

   You now want to implement NAP with DHCP enforcement. However, you want to use NAP to ensure only that automatic updates and antivirus software are enabled on the DHCP client.

   What should you do?

   1. Create a new configuration for the SHV for the DHCP clients.
   2. Install an additional SHV and configure it for the DHCP clients.
   3. Modify the default NAP DHCP connection request policy.
   4. Modify the default NAP DHCP Noncompliant network policy.

3. You have been testing a new deployment of NAP in your network. NAP is currently configured so that VPN clients with antivirus software that is not up-to-date log their status with the NPS. These clients are currently not blocked from network access.

   You now want to change your NAP configuration so that the access of the same VPN clients is now restricted to a set of remediation servers on the company network.

   How can you achieve this goal?

   1. Modify the NAP VPN Compliant network policy.
   2. Modify the NAP VPN Noncompliant network policy.
   3. Modify the NAP VPN Compliant health policy.
   4. Modify the NAP VPN Noncompliant health policy.