This is the second article in a three-part series on Microsoft's Network Access Protection.
Microsoft's Network Access Protection is a complex security solution and not a simple "Next, next, finish" IT project. It requires the integration of several components, and having an understanding of these components -- and how and why they connect -- will prepare you to design a system that best fits your business.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
There are many articles available detailing simple Network Access Protection (NAP) installations, including "Implementing simple Network Access Protection for Windows Server 2008," which I wrote last year. Microsoft has its own set of documents on creating a NAP-enabled infrastructure using any of its enforcement mechanisms. However, a big-picture view of NAP's components is more important than a step-by-step installation guide.
There's great power in how the individual components work with one another. By separating out different elements of functionality, Microsoft has created an offering that scales from the smallest IT shop to the needs of the largest enterprises.
What are NAP's components?
The central functionality of a NAP implementation arrives as part of the Network Policy and Access Services (NPAS) role, which is installed to a Windows Server 2008 computer.
NPAS can be used to accomplish multiple functions, which can cause confusion. NPAS has the capability to handle NAP enforcement as a function of its Network Policy Server (NPS) role service, but it can also handle Routing and Remote Access Services (RRAS).
To further add to the confusion, the NPS role service can be used for NAP as well as traditional Remote Authentication Dial In User Service (RADIUS) services. In fact, many NAP implementations use RADIUS as a point of authentication -- a tangled web, indeed.
Therefore, let's focus exclusively on what is needed for NAP functionality.
External NAP components
The first step in any NAP planning process is determining the location of a network's point of enforcing a security policy.
As I mentioned in part one of this series ("The role of NAP in your security infrastructure"), that point of enforcement can come as:
- The Dynamic Host Configuration Protocol (DHCP) server hands out IP addresses through DHCP enforcement.
- The switch infrastructure enables ports through 802.1x enforcement.
- Computers attempt to communicate with resources in a domain through IPsec enforcement.
- External computers attempt to connect to internal resources through VPN enforcement.
- External computers attempt to connect to an internal Remote Desktop Services infrastructure through RD Gateway enforcement.
Depending on a network's needs, one or more of these points of enforcement can be selected (points of enforcement can be also added via third parties, which will be discussed in part three of this series).
Different enforcement mechanisms work differently, with some being dramatically more complex than others.
- DHCP enforcement requires a NAP-enabled DHCP server, which hands out different IP addresses to special networks when noncompliant clients are found.
- 802.1x enforcement requires the use of switches that support 802.1x authentication, redirecting clients to different network locations when they are found to not comply with security settings.
- IPSec enforcement requires an in-place certificate infrastructure along with the NPAS Health Registration Authority role service because it uses server and domain isolation to isolate noncompliant computers.
- For external clients, VPN authentication requires the RRAS role service to handle inbound client requests.
- RD Gateway authentication requires a Remote Desktop infrastructure protected behind a RD Gateway server, which is the point of enforcement for clients coming in. RD Gateway enforcement has been significantly improved in Windows Server 2008 R2's management tools.
A fully-realized NAP infrastructure needs a place for clients to go when they've been deemed noncompliant. This network location is usually a separate virtual LAN or subnet that includes special protections.
In this remediation location, noncompliant clients are positioned so they can be reconfigured to meet security policies, which is the task of one or more remediation servers -- domain controllers, antivirus servers, third-party servers, etc.
These components represent the technologies external to the core NAP role service. While external requirements can be complex to implement, remember that NAP's componentization is what makes it so easily scalable for enterprises. Without this level of componentization, for example, NAP could not enforce a particular network's custom requirements.
Internal NAP components
The NAP components internal to the NPS role service are also divided into multiple elements that can be combined in different ways to create desired policies.
First up are the policies themselves, which are broken into the following three parts:
- Connection request policies designate which servers handle inbound authentication for every type of connecting client.
- Network policies determine which clients can connect to the network as well as the circumstances in which they are allowed to connect, are denied access or are forced into remediation.
- Health policies determine the client configurations required for a client to be considered compliant.
These three policies work hand in hand to identify the full path of approval from "Who gets in?" to "Why do they get in?" to "Who makes the call?"
However, note that the individual conditions associated with identifying why clients get into a network have not been documented.
Defining compliance is accomplished through the use of one or more System Health Validators (SHV). The compliance status can be based on firewall settings, antivirus and antimalware settings, and/or the level of installed patches (as discussed in part one of this series). Third parties can also create their own SHVs to validate other custom settings.
If the separation between the "rules" in SHV and the "policies" available in Health Policies is confusing, consider Microsoft's Group Policy as a metaphor: Individual settings are configured within the Group Policy Management Editor and bundled into a Group Policy Object. That Group Policy Object is then linked to an Organizational Unit in the Group Policy Management Console. By separating policy settings from policies, you have greater flexibility to determine which clients ultimately get which settings.
The final pieces in this puzzle are the client components themselves.
The elements discussed thus far relate only to the server and network infrastructure that deal with clients as they come on the network. Each client also needs components that verify compliance and report findings to the NAP infrastructure.
First, there is the NAP enforcement client, which facilitates enforcement responsibilities at the client. Multiple enforcement clients exist, with one matched to each type of enforcement enabled in the NAP server infrastructure.
System Health Agents (SHA) are also installed to clients. These SHAs are responsible for scanning the client to verify that compliant configurations are present. SHAs are often related to elements that need to be managed such as antivirus-versus-firewall settings.
Microsoft provides a default SHA. Third parties can build their own for deployment to clients when custom configurations must also be verified.
The glue that holds these two pieces together is the NAP Agent. This agent facilitates communication between individual SHAs and their associated enforcement clients. By separating the NAP Agent from the other two components, Microsoft creates an extensible architecture that allows for large levels of customization by third parties.
Client-side components for NAP are most commonly enabled through Group Policy, which means that clients typically will need some period of on-network connectivity to be initially configured.
Thankfully, for environments that are always in a high state of flux, NAP policies can be defined for non-NAP-capable clients as well as for clients depending on their compliance status. This third-state setting ensures that clients that haven't been configured -- or those that can't participate in NAP (like other operating systems) --won't be left out in the cold.
Microsoft's documentation on NAP is exceptional and is a first stop for any organization looking to implement the technology. However, NAP components that come from Microsoft are only one piece. Most enterprises use security software developed by other companies. Ensuring their compliant configuration is an important part of a holistic approach.
The final article in this series will discuss where third parties can connect and third-party products that are already NAP-capable.
About the author
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.