
close
close
Upcoming FREE Conference on Identity Management and Privileged Access Management
We’re back with our series on Remote Network Access! Now, assuming that your basic SSTP RRAS Service is now online and working, we can extend the functionality of the service, by enabling the Network Access Protection (NAP) functionality.
Network access protection depends on a special certificate to be issued from your internal certificate authority (CA) to indicate to the Network Policy Server (NPS) system that the workstation is healthy and trustworthy. Unsurprisingly, this certificate is called a “health certificate,” which is issued by the CA upon the request of the Health Registration Authority. This service works in conjunction with the NPS server; clients have these certificates issued when appropriate to signal the state on the Network Access protection.
I am using a central private CA for issuing my certificates, but I do need to enable the CA to issue new health certificates.
First thing first! We need to prepare a certificate, which will be issued from our Enterprise CA infrastructure to our clients for their statement of health. We will also be restricting this template so that a computer cannot manually enroll this certificate, essentially allowing a computer to “lie” about its true health.
We will begin by connecting to our Enterprise Root CA or a Sub-Ordinate Enterprise CA and opening the Certificate Templates console, by running certtmpl.msc.
As we are using an Enterprise-based CA we are actually required to also create a second System Health Certificate Template, this time for non-domain joined machines. This is despite the fact that when we will deploy the HRA service, we will choose to not issue health certificates for these non-domain joined systems.
Remaining in the console, we will repeat part of the process above again, this time for our second template.
That completes the work necessary to create both of the templates we will require for successfully issuing health certificates.
Next, we just need to make these available for publishing from our issuing CAs. Go ahead and close the Certificate Template Console.
We will begin by connecting to our Enterprise Root CA or a Sub-Ordinate Enterprise CA and opening the Certificate Management console, by running certsrv.msc.
This procedure will need to be repeated on each issuing CA with which we will be linking up the HRA.
Once the certificate management console is displayed, expand the tree and select the node Certificate Templates.
Our new certificate templates should now be presented in the listing of templates which are available for publishing from our selected Certification Authority.
Staying on our Enterprise Root CA or a Sub-Ordinate Enterprise CA, we will next provide permissions to permit our HRA server to actually request the certificates we just enabled for issuance.
Finally, we have one additional configuration change that we really should implement on the Issuing CA Server. This setting allows a request for the CA change the expiry date at the time of issue, so that it is different from that which is defined in the template. As this setting is pretty sensitive, this is one of the reasons why it is recommended that the CA responsible for issuing your health certificates is a dedicated server for health certificates only.
This configuration setting must be defined using the CERTUTIL.exe command tool, we will need an Administrative prompt to execute this command sequence
Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTEENDDATE net stop certsvc net start certsvc
Great, now we are all set with the certificate work!
More in Networking
What Are the Best Hyperconverged Infrastructure (HCI) Solutions on the Market?
Jan 9, 2023 | Sukesh Mudrakola
Most popular on petri