Remote Network Access: Health Validation

Welcome back to our series on Remote Network Access! Now on to part five, dealing with Remote Network Access and health validation. The Health Registration Authority (HRA) is the service which will communicate directly with the Issuing Certificate Authority to request on the behalf of the NPS Server and Client, our health certificates.

Need to catch up? Check out our first article in the series, in which we introduced the objectives and architecture of Remote Network Access. In part two, we began the process of installing and configuring the SSTP servers to support and implement our client’s VPN Connection. In part three, we guide you through the steps to manually configure an SSTP client, and in part four, we showed you how to create new health certificates and delegate the NPS Server Permission.

Installing Health Registration Authority (HRA)

In my environment, I have chosen to add the Health Registration Authority role to my existing NPS server, using the Server Manager wizard for Add Roles and Features.

  • During the installation on the Certification Authority page, you can select your Issuing CA, or choose to wait until the role is installed and configure the server to use at that point. I am going to select one of my CAs for now, so I can validate that the process is working correctly and add the others later.
  • On the Choose Authentication Requirements for the Health Registration Authority page, I am going to keep the default option of Yes, require requestors to be authenticated as members of a domain. This really means that our connecting computers must be part of our domain if they are to be issued a health certificate
  • On the Choose a Server Authentication Certificate for SSL Encryption page, I am going to Choose an existing certificate for SSL Encryption from the list of certificates already enrolled on the NPS server. The certificate that I selected will have the servers FQDN in the Subject Name or SAN field.
  • The rest of the installation wizard options are defaults. After a few moments, the new role will be added to the server.



Configuring Health Registration Authority (HRA)

At this stage we will inform the HRA service which CA we’d like to use to issue the Health Certificates, and of course, which certificate should be used. We also have the opportunity to determine the life of the issued certificate, which by default will be just four hours. Short periods like this are recommended, as anything can essentially happen on the client during the normal course of a day, and we really do want to know its health as regular as possible. It is worth remembering however, that the shorter the time period we set the more requests that our CA will need to process.

  • On the NPS server still, we will now launch the HRA console, but running HCSCFG.msc.
  • Select the Certification Authority branch.
  • In the main window, we should now see the CA we selected to use in the previous exercise, if desired you may add or remove the issuing CAs as necessary for your environment.
  • Right-click on the branch node Certification Authority and from the context menu select Properties.
  • On the Settings tab of the Certification Authority Properties dialog, select Use enterprise certification authority.
  • In the drop-down Authenticated Compliant certificate template select SystemHealthAuthentication.
  • In the drop-down Anonymous Compliant certificate template select AnonymousSystemHealthAuthentication
  • Click OK.

And that’s all there is to the HRA. Next, we are going to change our focus back to the NPS server, this time establishing a new NAP Policy which will leverage our HRA service.

Network Access Protection (NAP): System Health Validators

NAP is about checking and ensure that our clients measure up to a specific set of checks or validations. In the default installation we have a single health validator for Windows Security, which we can customize to our environmental requirements.

  • In the Network Policy Server console, expand Network Access Protection > System Health Validators > Windows Security Health > Settings.
  • Right-click on the Settings branch, and from the context menu select New.
  • In the Configuration Friendly Name dialog, enter Windows OS Validation, then click OK.
  • In the Windows Security Health Validator dialog, select the Windows 8/Windows7/Windows Vista node. From there, set the validations as applicable for your environment. For example: Enable the following choices: A firewall is enabled for all network connections, An antivirus application is on, Antivirus is up to date, An Antispyware application is on, Antispyware is up to date and Automatic Updating is enabled.
  • Select the Windows XP node. Again, please set the validations as applicable for your environment. For example: Enable the following choices A firewall is enabled for all network connections, An antivirus application is on, Antivirus is up to date, and Automatic Updating is enabled.
  • Click OK.

Network Policy Server (NPS): Configure Health Policies

Next we will create a policy relationship between our new System Health Validation policy called Windows OS Validation and the client’s ability to pass one or more of these checks. To implement this we will establish a pair of policies to define our health statement – one for healthy systems and a second for unhealthy systems.

  • Launch the Network Policy Server console.
  • Expand the Policies branch, and select Health Polices.
  • Right-click the Health Policies node and select New from the context Menu.
  • In the Create New Health Policy dialog type NAP Compliant Client in the Policy Name field.
  • In the Client SHV checks drop-down, select Client passes all SHV checks.
  • In the SHVs used in the health policy, you must check the option Windows Security Health Validation.
  • Set the Settings to Windows OS Validations. Click OK.
  • Right-click the Health Policies node and select New from the context Menu.
  • In the Create New Health Policy dialog, type NAP Non-Compliant Client in the Policy Name field.
  • In the Client SHV checks drop-down, select Client fails one or more SHV checks.
  • In the SHVs used in the health policy, you must check the option Windows Security Health Validation. Set the Settings to Windows OS Validations. Click OK

NPS: Configure Remediation Server Group

With the checks and polices now established, we also need to define what servers an unhealthy client should still be permitted to connect with so that it can attempt to remediate the problem situation the computer has been detected to be in. A simple example of this would be our Windows Software Update Server, which needs to be accessible if the client is to apply any missing updates

  • In the Network Policy Server console, expand the Network Access Protection branch, and its sub-branch System Health Validators, then select Remediation Server Group.
  • Right-click the Remediation Server Group node and select New from the context Menu.
  • The New Remediation Server Group dialog appears. In the Group Name field, type NAP Remediation Services.
  • On the Remediation Servers list, click Add to display the Add New Server dialog.
  • In the Friendly Name field, enter Windows Update Services.
  • In the IP address or DNS Name field, enter the name of your update server.
  • Finally, click Resolve to validate the IP Addresses for the service. Click OK.
  • Click OK.

You can continue to populate this list with any other server that you are comfortable with the unhealthy clients connecting to, so that they can resolve their health issues and return to compliant status.

At this point we have completed all the basic foundation work for our NAP services. Our next step will be to alter the NPS polices to require that the NAP services are utilized. We will also need to configure our clients so that they are enabled for NAP validation checks, and ensure they know where to communicate with.