Understanding the NAP Architecture

Let’s dig into the NAP architecture a bit so that we can understand these enforcement mechanisms better. So it’s time for a couple of diagrams and some explanation. Let’s start with the big picture (shown in Figure 10-1).

Figure 10-1: Overall architecture of NAP showing various components

On the left of this figure are the clients trying to get onto your network and the remediation servers that can provide updates to them to move the health status of these clients from unhealthy (noncompliant) to healthy (compliant). These remediation servers can be Microsoft products such as System Center Configuration Manager 2007 (currently in beta) or Windows Server Update Services (WSUS), or they can be third-party server products from AV vendors, patch management solution providers, and so on.

Now for a client machine to participate in a NAP infrastructure, the machine must include a NAP client. This NAP client comes built into Windows Vista and Windows Server 2008, and Microsoft is currently working on a NAP client for Windows XP that is planned for release around the time Windows Server 2008 RTM’s.

This NAP client has several layers as follows:

• System Health Agents (SHAs) These are components that verify whether the client machine satisfies given health requirements. For instance, one SHA might determine whether the client has AV software installed and whether the sig file is up to date. Another SHA might determine whether the client has the latest software updates installed for some enterprise LOB application. By default, Windows Vista includes its own Microsoft SHA (MS SHA) that can do things like check whether Windows Firewall is turned on, verify whether Automatic Updates is enabled, and determine whether the system has AV or spyware protection software installed and enabled on it. This built-in SHA basically interacts with Security Center on the machine to verify this information. Other SHAs are typically provided by third-party ISVs to support their AV, patch management, firewall and other security products.

• Quarantine Agent (QA) Also called the NAP Agent, this is basically a broker layer that takes health status information collected by SHAs and packages them into a list that is then handed to the Enforcement Clients to handle accordingly.

• Enforcement Clients (ECs) These are the client-side components that are involved in helping enforce whether the client is granted full (or partial, or no) network access based upon compliance with your predefined health policy. In Windows Vista and Windows Server 2008, there are built-in ECs for each of the different NAP enforcement mechanisms described previously in this chapter. And because the platform is extensible, third-party ISVs and IHVs are also being encouraged to develop ECs for their own network access and security products.

In the middle of Figure 10-1 are your network access devices that control access to the network. These devices need to be able to interoperate with the NAP infrastructure to pass the statements of health (SOHs) to the NPS servers for health evaluation. In some cases, this will require that the server be enabled for NAP, which is why you need to use Windows Server 2008 DHCP and VPN servers if you are going to use those NAP enforcement methods. However, some existing network access devices (such as 802.1X authenticating switches) are already able to integrate with NAP using their built-in RADIUS capabilities. These network access devices, if running Windows Server 2008 (for example, DHCP or VPN servers) must include a component called an Enforcement Server (ES) that corresponds to an EC on the clients. For example, Windows Server 2008 has a DHCP NAP ES that corresponds to the DHCP NAP EC in the NAP client for Windows Vista, and an ES on the server works together with its corresponding EC on the client to make the enforcement mechanism work. We’ll walk through how that happens in a moment.

Finally, on the right of the figure is your Network Policy Server (NPS) and your system health servers. The health servers (also called policy servers) provide NAP health policy information to the NPS upon request. The heart and soul of the NAP platform, however, is the NPS server, which is a RADIUS server that is basically the replacement for the Internet Authentication Service (IAS) found in previous versions of the Windows Server operating system. The NPS server is a key component of Windows Server 2008 and is installed by adding the Network Policy Server role service from the Network Policy And Access Services role using the Add Roles Wizard. (See Chapter 5.)

The NPS also has a layered architecture as follows:

• System Health Validators (SHVs) These are the server-side components on the NPS that correspond to the SHAs on the client. Again, this includes both a Microsoft SHV (MS SHV) that ensures the different security components managed by Security Center are enabled on the client, and third-party SHVs developed by ISVs that are enhancing their security products to support the NAP platform. We’ll see how the SHAs and SHVs communicate in a moment.

• Quarantine Server (QS) This is basically a broker between the SHVs running on the NPS and the ESs running on the NAP servers. Note that in a large enterprise deployment of NAP, the NPS servers and NAP servers are typically running on different boxes. It’s possible, however, to implement NPS and NAP server functionality on a single machine- for example, by installing the DHCP Server role on an NPS server. However, this actually makes managing NAP more complicated instead of simplifying things because if you do this, each NAP server must be separately configured with its own network access and health policy. In most scenarios, however, the NPS and NAP servers will be running on different machines and the QS on the NPS server will use the RADIUS protocol to send and receive messages with the NAP servers.