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:
The components are as follows:
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 …
|Share this post :|
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.