Greetings, Guardians of NAPness!
Here is an interesting question about NAP client behavior that was posed by a fellow NAP fan:
How does a NAP client communicate a change in health state and get reevaluated and what sort of ongoing traffic is there between the NAP client and the NAP health policy server?
If you have seen a typical demonstration of NAP autoremediation, the demonstrator intentionally turns off the Windows Firewall on a compliant NAP client. Within seconds, a Network Access Protection message appears in the notification area of the desktop indicating that the computer no longer meets the system health requirements of the network, and then another message appears stating that the computer now meets the system health requirements of the network.
The natural questions that arise from seeing this demo are the following:
1. How does the NAP client know that the firewall was turned off?
2. How does the NAP client indicate its new health state to the rest of the NAP infrastructure, get re-evaluated, and receive remediation instructions to turn on the firewall?
3. After turning on the firewall, how does the NAP client get re-evaluated and gain full access to the network?
4. Does the demonstrator realize that he has a tuft of hair towards the back of his head that is sticking straight out, acting for all intents and purposes like a rooftop radio antenna?
I will answer questions 1 through 3 below. As for question 4, I am afraid this issue is beyond the capabilities of the NAP platform at this time and can only suggest a stiff hair gel for a short-term workaround, scissors for a longer term solution, or laser-based hair removal for a permanent solution (or, in my case, a laser is not required; only a few more years are needed!). :>
The summary answer to questions 1 through 3 is that System Health Agents (SHAs) monitor the configuration state of their associated components and system services for changes that affect system health. When a change occurs, the SHA indicates an updated Statement of Health (SoH) to the NAP Client service, which creates a new System SoH (SSoH) and uses its NAP enforcement clients (ECs) to send the new SSoH to their corresponding NAP enforcement points. The NAP enforcement points then send the SSoH to the NAP health policy server for evaluation. At this point, the process for remediation and reevaluation occurs in the same way as if a noncompliant NAP client started up on the network.
Note that the NAP client sends the new SSoH to the NAP health policy server when the configuration change occurs. There is no ongoing, interval-based polling or connection-based data flowing between the NAP client and the NAP health policy server. When indicating a change in health state, the amount of traffic on the wire is the same as the NAP-based traffic when the computer starts up on the network. The traffic on the wire between the NAP enforcement point and the NAP health policy server is typically a handful of RADIUS messages; two messages for each round trip to the NAP health policy server.
Let’s apply this explanation to the demonstration: When the Windows Firewall is turned off, the Windows Security Health Agent (WSHA) notices the configuration change, creates a new SoH (with the Windows Firewall state set to disabled), and indicates it to the NAP Client service. The NAP Client service creates and sends a new SSoH containing the updated WSHA SoH to its enforcement point, who forwards it on the NAP health policy server.
The next question that arises from this explanation is the following: OK, smart guy, how exactly does the NAP client indicate the new SSoH to the NAP enforcement point, who forwards it to the NAP health policy server?
I am glad that you asked…
The exact method of indicating the new SSoH depends on the NAP enforcement method. Here is how it is done:
· For IPsec enforcement, the NAP client computer deletes its current health certificate and contacts its HRA to obtain a new health certificate. In the ensuing process, the NAP client sends the SSoH to the HRA over HTTP or HTTPS.
· For 802.1X enforcement, the NAP client computer initiates 802.1X reauthentication on its existing wired or wireless connection. In the ensuing authentication process, the NAP client sends the SSoH in a PEAP-TLV message.
· For VPN enforcement, the NAP client computer restarts PPP-based authentication on its existing remote access VPN connection. In the ensuing authentication process, the NAP client sends the SSoH in a PEAP-TLV message.
· For DHCP enforcement, the NAP client computer attempts to renew its current DHCP-based IPv4 address configuration. The NAP client sends the SSoH in the DHCPRequest message.
Are there any more questions? It’s Friday. Can I go home now? :>
Senior Program Manager
This posting is provided “AS IS” with no warranties, and confers no rights.