Welcome back AskPerf Readers.  In my last post we covered the basics of Network Access Protection (NAP) – what it is, and what it can (and can’t!) do for you.  Today we’re going to go over the various components of NAP.  The diagram below from the NAP Architecture Whitepaper (the link to the Whitepaper is at the end of this post) shows the various components of a NAP-enabled infrastructure:

NAP_Components

The components are as follows:

 

  • NAP Clients: Client systems that support the NAP platform – Windows Server 2008, Windows Vista and Windows XP SP3
  • NAP Enforcement points: NAP enforcement points evaluate the health of NAP clients, determine whether network access or communication is allowed and what remediation actions (if any) a non-compliant NAP system must take.  Examples of NAP enforcement points include VPN Servers (Windows Server 2008 with RRAS), DHCP Servers (Windows Server 2008) and Network Access devices such as Ethernet or  Wireless Access Points that support IEEE 802.1x authentication
  • NAP Health Policy Servers: These are servers running Windows Server 2008 and the NPS Service that store the health requirement policies and provide health state validation
  • Health Requirement Servers: These systems provide current system health state for NAP health policy servers – for example the health requirement server for an anti-virus program might track the latest version of the signature file
  • Active Directory Domain Services: Your enterprise Active Directory.  AD is not required for health state validation, but it is required for IPSec, 802.1x authenticated connections and remote access VPN connections
  • Restricted Network: The restricted network is a separate logical or physical network.  Depending on how the NAP policies are configured, NAP systems that have not passed the health check may be placed into this network.  This network may also contain remediation servers that NAP clients can access to resolve issues preventing them from passing the health check – such as outdated AV, missing patches etc.  Systems that do not support NAP (for example Windows XP SP2 systems) may also be placed in this restricted network.

So how exactly does NAP work?  A couple of different components – the System Health Agents (SHA’s) which run on NAP clients and the System Health Validators (SHV’s) which run on the NAP Health policy servers – provide health state tracking.  Windows Vista and Windows XP SP3 include a SHV that monitors the settings for the Windows Security Center.  The SHA creates a statement of health (SOH) that contains the status information about the specific attributes that the SHA monitors.  As an example, an SHA could monitor the version of anti-virus program installed, whether the service is enabled and running, and what version of the definition files are loaded on the client.  When the SHA updates its status, a new SOH is created.  Each of these SOH’s are included in the System Statement of Health (SSOH).  The SSOH is sent to the NAP Health policy server for evaluation through an enforcement point.  The NAP Health policy server sends back a System Statement of Health Response (SSOHR), which contains individual Statement of Health Responses (SOHR’s).  The SSOHR indicates whether or not the NAP client is compliant or not.  If the system is not compliant, then the remediation steps within the SOHR are followed, a new SOH is created on the NAP Client and the process begins once more.

NAP is an extensible platform that provides an infrastructure and API set for adding components that verify and amend a computer’s health state and that enforce access restrictions.  For example, your anti-virus vendor can provide additional SHA’s and SHV’s to the NAP platform.

And with that, we’ve reached the end of this post.  As I mentioned in my last post, we’re far from being NAP experts on the Performance team, but knowing a bit about how NAP works will help you if you’re planning a Terminal Server Gateway implementation.  Until next time …

 

Additional Resources:

- CC Hameed

Share this post :