Windows Server

SolutionBase: Configuring Network Access Protection for Windows Server 2008

In this installment of the TechRepublic series on Microsoft Network Access Protection, Rick Vanover takes a deep look at the server configuration for Windows Server 2008. All of the various roles and communication sequences for the MS-NAP implementation need plenty of planning and upfront understanding. This segment will give you a good grasp on these communication points and roles.

Unlike other Microsoft solutions, the MS-NAP implementation does not resemble other products like Exchange, SQL, or IIS, but exists more as a collection of roles, policies, and services. It's different in that in cannot be run as a single server solution. The roles are distributed across different systems. For example, a small Exchange implementation can consolidate the roles onto one computer.

MS-NAP generally requires at least two servers to fully implement all of the roles outlined by Microsoft. MS-NAP has a few basic elements that enable the implementation to succeed as designed. Further, there are four enforcement clients (ECs) or methods in which MS-NAP will function. These are DHCP enforcement, VPN enforcement, IPSec enforcement, and 802.1X enforcement. These four ECs allow you to choose an implementation that fits best for your needs and infrastructure. In this article, we'll take a look at what you have to have in place to make MS-NAP work properly.

MS-NAP server-side best practices

The MS-NAP back end depends heavily on your core components of your existing infrastructure, including the Active Directory (AD) domain. These components, if in an incorrect configuration, will give you nothing but headaches downstream. Below are details of some of the best server practices to ensure a MS-NAP implementation can start off correctly:

  • Software and network policies: While not a technology matter, it's important to first identify the functionality desired by the MS-NAP implementation, and then apply the technology to define the service pack levels, anti-virus criteria, IPSec policies, and other factors to permit access to a specified network. And then to define what happens in a non-compliant state: remediation network, denied access, or other way of handling non-compliant systems.
  • Active Directory domain: This part of the back-end infrastructure should be very organized so that users accessing it have clear access to specified resources. Don't fall into the over-permissions trap simply to make things work. MS-NAP functions in a mash of roles depending on your configuration, but it's required that it be at functionality level Windows Server 2003 or higher.
  • VPN access: If the VPN enforcement method is used, the VPN solution is critically important for an MS-NAP implementation. This external (Internet) connections is for internal VPN connections for higher level secure sites within your private network if used.
  • Network equipment: Ensure that your equipment supports 802.1X authentication, especially if using wireless clients or the 802.1X EC.
  • DHCP networking: The DHCP network in regard to the MS-NAP implementation is important, as there are scope options that designate a class for remediation should a system not be compliant with the MS-NAP policy.

Configuring MS-NAP on Windows Server 2008: DHCP server

Now we will dive into an actual configuration example for Windows Server 2008 Beta 3 (formerly known as Longhorn). We will set up a DHCP server to enforce the NAP policy. The enforcement policy will do one of the following actions based on compliance:

  • Totally allow network access by policy compliance
  • Direct non-compliant systems to a remediation network for limited access
  • Deny access for systems that are not able to gauge compliance at all

For this example, there won't be a full, drawn-out policy for scope of use and the requirements for entering onto a network. In live situations, however, give plenty of planning upfront to the desired functionality for the MS-NAP implementation. Here, I'll highlight that this example will provide an automatic remediation of client computers that need to match policy before access can be permitted. This is the sample network I've identified for this TechRepublic series on MS-NAP:

Computer name

Role

OS and configuration

WS2K3-DEV

Domain Controller

Windows Server 2003 Std.

WS2K8

Member Server, NAP roles server, DHCP Server (IPv4)

Windows Server 2008, Beta 3

Client1

DHCP Client

Windows Vista

Client2

DHCP Client

Windows XP Service Pack 2

The first part of configuring MS-NAP is to enable the Network Policy and Access Services (NPS) role on the WS2K8 server. This role will be the entry point for the MS-NAP implementation. From the Add Server Role wizard, select the NPS role as shown in Figure A, and press Continue.

Figure A

Select the Network Policy And Access Services Role.

Select the Network Policy Server, Health Registration Authority, and Host Credential Authorization Protocol elements. You may need to add IIS, as this is a requirement for these roles. Our example will have WS2K8 perform the certificate server roles in standalone configuration.

You will be prompted to determine if authenticated network access requires domain membership. This is more important from the policy perspective than the technology perspective. In this example, we will require requestors to be Active Directory domain members. Adding the base MS-NAP role is pretty straightforward; and, when complete, the Network Policy Server (NPS.MSC) console is installed. An empty console looks like the one shown in Figure B.

Figure B

You start with an empty console.

The MS-NAP configuration elements are determined by the System Health Validator configuration element of the snap-in. For our example, we'll configure a server-side validator that requires an antivirus application to be running and up to date for the system to be determined to be a compliant system. You can see what this looks like in Figure C.

Figure C

Select the elements of the policy you want to enforce.

The System Health Validator configuration here will determine the behavior of the MS-NAP policy. For the non-compliant systems, they will need to connect to the WS2K3-DEV server to pull down the antivirus application. This will be the remediation server. In the NPS console, we'll add the WS2K3-DEV server as a server for the group "RG-NonCompliant-NoAV", as shown in Figure D.

Figure D

Create the name of the group.

The remediation network is important for the effectiveness and scope of the MS-NAP implementation. The remediation network will allow for the non-compliant system to access the specified hosts (in this example, WS2K3-DEV) explicitly. All other computer systems in Active Directory would be prohibited. However, if this segment shares access to non-Windows system; an out of compliance MS-NAP client may still be able to access those systems from TCP/IP, depending on the entire configuration. Thorough testing is required for the pilot implementation to avoid issues in a live environment.

We will then need to tell Windows how to handle compliant or non-compliant systems from the system health perspective. We will configure Windows to use the Security Health Validator policy we defined earlier for systems that pass or fail the defined criteria of having the anti-virus program installed on the system, as shown in Figure E.

Figure E

Here you tell Windows how to handle systems that pass or fail validation.

Once that we've addressed what to do with the compliant or non-compliant systems, we can now go about the steps involved with assigning the two policies created earlier (PASS and FAIL) to the network. Here we will assign for the PASS policy that the systems are granted full access, and for the FAIL policy, they are granted access to the remediation network to install the anti-virus. The wizards to add the policies in the MS-NAP implementation are straightforward. Figure F shows where we allow full access as part of the PASS policy being assigned as a network policy.

Figure F

Here you tell Windows to Allow Full Network Access if the workstation passes the tests.

Once the policies are set up within the core components of NPS for the MS-NAP implementation, we need to configure the DHCP server to enable MS-NAP on all activated scopes. This is done within the DHCP server, as shown in Figure G.

Figure G

Here you tell DHCP to assign addresses to workstations that MS-NAP accepts.

We also need to add a user class within DHCP for the users who are not compliant systems, and will be on the remediation network. This class adds a DNS server and a DNS name of remeditation.ws2k3dev.local for the remediation network. The DHCP service for Windows Server 2008 will provide a user class called "Default Network Access Protection Class" so that the MS-NAP policies can be implemented from the different networks through the DHCP services. Figure H shows the classes.

Figure H

You can configure other network services based on MS-NAP.

At this point, the DHCP server on the WS2K8 server is set to use the MS-NAP implementation, and any client that tries to receive an address will not do so unless the following configuration elements are met (these are not enabled by default installations of Windows Vista Enterprise):

  1. Security Center is enabled on Windows Vista
  2. Enable the DHCP enforcement client
  3. Have the Network Access Protection Agent service started
  4. Disable IPv6 in the Network and Sharing Center if it's not used on your network

Windows XP clients will be able to be MS-NAP aware when Service Pack 3 is released. All other clients -- including Windows 2000, NT, and non-Windows systems -- will not be able to retrieve an address from this scope using the MS-NAP configuration.

After this configuration has been made, a Vista client is able to receive an address from the MS-NAP enabled DHCP server. From the client, the MS-NAP policies will be enforced from the DHCP process.

Author's warning

Be sure to not do the above mentioned steps in a live environment; this will render most DHCP clients unable to receive an IP address (regardless of the PASS or FAIL policy determination). Devices that do not have NAP enabled components will not get an address.

Additional resources for MS-NAP

This example is a quick overview of the MS-NAP implementation from the Windows Server 2008 perspective. While still in beta form, Windows Server 2008 has a large number of resources available, including additional examples for MS-NAP configurations, as well as detailed technical information on the underlying authentication and network traffic requirements.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

0 comments

Editor's Picks