Understanding and Configuring Network Policy and Access Services in Server 2012 - Part 1

You can Download this article as Word and PDF

Word Document: Understanding and Configuring Network Policy and Access Services in Server 2012

PDF: Understanding and Configuring Network Policy and Access Services in Server 2012

 

Introduction

An important part of a network security strategy is the protection of the network from threats that can be introduced via the client computers that connect to that network. This becomes particularly vital in the case of remote clients, such as laptops that workers take off site and home computers that employees use to access their work during off-work time or even full-time as telecommuters. Windows Server 2012 based networks have many mechanisms aimed at giving administrators more control over who connects to the corporate network and over the computers they use to connect.

DirectAccess is one such technology, and I’ve discussed it in previous articles. But not all clients are able to use DirectAccess; those that run legacy operating systems (pre-Windows 7) and those that are not domain members will need to use a different connection method, such as virtual private networking (VPN). Windows Server operating systems provide features that help to protect the network when VPN clients connect, as well.

Network Access Protection (NAP) has been around for quite some time. It was introduced with Windows Server 2008 to provide a built-in policy-based technology similar to Cisco’s Network Access Control (NAC). Windows Server 2008 R2 added functionality and features.

Remote Authentication Dial In User Service (RADIUS) server support in Windows Server has been around even longer. If you’re coming to Windows Server 2012 from Windows Server 2003, when you think of RADIUS in Windows, you probably think of Internet Authentication Service (IAS). In Windows Server 2008, IAS was replaced by NPS – the Network Policy Server. The NPS is part of a larger framework: Microsoft’s Network Policy and Access Services (NPAS).

[ads1]

Understanding NPAS: What it includes

The Network Policy and Access Services include the following role services:

• Network Policy Server (NPS)


• Health Registration Authority (HRA)


• Host Credential Authorization Protocol (HCAP)


• RADIUS server and proxy

This is the server role through which you deploy Network Access Protection (NAP) in Windows Server 2012, and that’s what we’re going to be talking about in the first part of this series of articles.

A new feature in Windows Server 2012 is the ability to use PowerShell to install and configure the Network Policy Server.

NAP enforces health policies on a number of connection types, including IPsec-protected communications, IEEE 802.1X-authenticated communications, and terminal services gateway connections. In this article, we’ll be looking at NAP primarily as an enforcement mechanism for remote clients connecting via a VPN.

Understanding NAP: What it does

NAP utilizes a number of components on the server and client to allow administrators much greater control over which computers are allowed to connect to the network, and specifically to prevent systems that may be at risk – such as those that do not have up-to-date security patches, aren’t running antivirus software and antimalware software with current definitions, don’t have an active host firewall, etc. – from connecting to the network and potentially putting other systems at risk as well.

NAP can be used with client computers running Windows XP SP3 and above; these operating systems support the NAP Agent that is the component on the client that collects and manages health information. When the NAP Agent service is installed and running, the client can communicate its health status to the NAP servers.

The health status information is based on the state of the client’s configuration and can include such factors as:

• The firewall status


• Antivirus signature status


• Status of service packs and security updates.

Understanding NAP: How it works

NAP is Microsoft’s implementation of a “health” enforcement solution. In the context of protecting remote clients and protecting the network from health “issues” that those remote clients may bring to the network, it checks the identity of each remote client and determines whether it is in compliance with the organization’s health policies. The health information that each client sends to the NAP server is called a statement of health or SoH.

The server evaluates this information based on the policies and settings that have been configured. It uses this information, along with group membership, to determine whether and at what level of access the client will be allowed to connect to the corporate network. Clients that are out of compliance with the policies can be brought into compliance through NAP’s mechanisms.

NAP does this by performing a network health analysis, verifying the effectiveness of existing security policies, and helping administrators to identify risks by creating a health profile for the network. This improves the overall health of the network by enforcing compliance with your network health policies and restricting the access of remote client computers that are not in compliance.

Understanding NAP: The parts and pieces

The Network Policy Server is the core component of a NAP deployment. It is used to manage network access through the VPN server, RADIUS servers and other points of access to the network. Depending on your network environment, you may deploy multiple NPS servers.

An NPS can be a RADIUS server, a RADIUS proxy or a NAP policy server. The NAP server is where you configure the NAP policies and settings such as health policies, SHVs, and remediation server groups. Remediation servers are the servers to which non-compliant clients are allowed to connect in order to update their configurations so as to become compliant, after which they can be re-evaluated and allowed to connect to other network resources.

The NPS works in conjunction with other components, including the System Health Agents (SHAs) and System Health Validators (SHVs). The SHA that is built into Windows Vista and Windows 7 operating systems is called the Windows Security Health Agent (WSHA), which works with the Windows Security Center on the client computer and the Windows Security Health Validator (WSHV).

You can configure the WSHV settings to report on the host firewall, virus protection, spyware protection, automatic updating status, and security updates installed. Third party vendors can use the NAP API to create SHAs and SHVs for their software products (for example, third party antivirus programs).

The Health Registration Authority (HRA) is another server component of NAP that is used in IPsec enforcement and is installed on a computer that is running NPS and IIS. These services must be installed on the HRA computer. When you install the Network Policy and Access Services server role on a Windows Server 2012 server, the HRA administrative tool will be installed on the NPS server. Likewise, if you install HRA, NPS is automatically installed.

The HRA approves the issuance of health certificates to NAP clients. These health certificates are X.509 certificates that are issued by an Active Directory certification authority (CA). A CA that issues health certificates is known as a NAP CA. To get a health certificate from the NAP CA, the client must submit a SoH to the HRA. IIS is used to provide the interface by which the clients contact the HRA to request a health certificate.

Understanding NPS policies

The NPS can apply and enforce three different types of policies:

• Connection request policies


• Network policies


• Health policies

In Part 2, when we start configuring policies, we’ll go into more detail about what each of these policy types does.

NPS also supports templates for health policies, that you can use to make it quicker and easier to configure NPS on the server. These are available in the Templates Management section of the NPS console (which you’ll see in Part 2). You can easily create new templates.

Planning for NAP

Before you undertake the deployment of NAP on your network, there are a number of planning tasks that you should complete. The following checklist can serve as a guideline for planning your NAP deployment:

• Determine the NAP enforcement method (in this case, we are focusing on VPN enforcement)


• Plan the appropriate placement of your NAP server(s) on the network so it can communicate with other NAP components and so it will have a connection to Active Directory Domain Services (AD DS) for authentication of domain users connecting through the VPN.


• Determine whether you need multiple NAP servers for load balancing and failover.


• Determine which health requirements you want to enforce (for example, firewall, virus protection, antivirus software updates, spyware protection and updates, automatic updating enabled, security updates installed via WSUS      and/or Windows Update).


•  Determine how you will deal with those computers that will be exempt from health checks (e.g., domain controllers and most other servers, devices that are not NAP-capable, and users who must have access at all times. This is your exception management strategy.


• Consider your NAP reporting strategy.


• Create a pilot program to help you evaluate your NAP deployment decisions.


• Document the NAP deployment design.

Deploying NAP: A preview

To deploy NAP on Windows Server 2012, you will need to install the Network Policy and Access Services role with the Network Policy Server role service. You can do this in one of two ways: by using Server Manager to install NPS via the graphical user interface, or by using PowerShell to install NPS via the command line. In Part 2 of this article series, we’ll dig down into how to install NPAS using both of these methods, and then we’ll look at the steps that you need to complete in order to your VPN servers to work with the Network Policy Server (NPS) so they can use NAP to validate the health of VPN clients that attempt to connect to your corporate network.