3 Structure Examples
In the following example, an administrator sets up a new domain and attempts to enable NAP DHCP enforcement on the computers in the domain. The client computers run operating systems that contain NAP client processes initialized at startup and terminated at shutdown.
First, the administrator installs and configures an operating system on a computer that is intended to function as the domain controller (DC). After taking the necessary steps to designate the computer as a DC and creating a user account over the new domain, the administrator restarts the machine and logs on as the newly created user.
Next, the administrator launches the user interface for the administrative plug-in and sets the DHCP enforcement to Enabled. This causes the following entry to be written to the machine-specific Registry Policy file of the relevant GPO.
Size: Equal to the size of the Data field.
The administrator then adds client computers to this domain. When a client computer is restarted for the first time after being added to the domain, it contacts the domain controller and reads Group Policy information, as specified in [MS-GPOL]. As part of this process, a machine-specific registry policy file containing the following items is also downloaded:
A set of values under the registry key Software\Policies\Microsoft\NetworkAccessProtection\ClientConfig\Qecs\79617 that indicates that the NAP client will instruct the DHCP client on the system to send an SoH when requesting the IP address for the machine, as specified in section 2.3.1.
The Group Policy: Registry Extension Encoding on the client parses this file and adds the configuration information to the machine's registry.
The NAP client process polls the registry and determines that its Group Policy settings have changed. The NAP process then reads the enforcement values and sets the system DHCP client to send an SoH.
When a user logs on to the computer, the DHCP client requests the NAP agent for an SoH. NAP invokes the SHA to collect health information and to generate an SoH. The SoH is then sent by the DHCP client to the policy server.
The following figure represents such a transaction.
Figure 3: DHCP new lease acquisition process
When the SoH is sent, the client requests access to a service and, as a precondition for that access, is required to prove that it is in good health. When the SoH is received, it is forwarded to an infrastructure server that evaluates the SoH and returns the response (the SoHR) to the client by means of the original receiver of the SoH.
Generally, the receipt of an SoHR by the client allows access to the service being requested. When the health of the client is not good, the SoHR is likely to contain sufficient instructions to allow the client to seek and receive remedy. After the client is restored to good health, the client can initiate the protocol again.