Well hello. I’m Gavin Carius, an Architect in Microsoft Australia. Jeff has been “inviting” me for some time to write about this cool thing in NAP we call “HRA Discovery” – so here goes my first NAP blog post!
A great feature with NAP IPSec enforcement is the ability for clients to automatically discover the most appropriate Health Registration Authority (HRA – aka the NAP Health Certificate Server) based on DNS SRV records. With auto-discovery enabled, the NAP client will discover a suitable HRA at start-up using the following sequence:
1. Query SRV records for HRAs in the Active Directory site of the client (eg, _hra._tcp.<sitename>._sites.<domainname>)
2. Query SRV records for HRAs in the Active Directory domain of the client (eg, _hra._tcp.<domainname>)
3. Query SRV records for HRAs in the DNS domain of the client (eg, _hra._tcp.<DNSname>)
Once a HRA has been discovered, the URL(s) will be plumbed into the client registry for future reference. The registry location is:
URL(s) will be sorted based on SRV “priority” details. Clients will use the SRV record with the lowest priority value first, and only fall back to other records if the connection with this HRA fails. For example, if a client request for _hra._tcp.acme.com results in the following DNS SRV records being returned:
· _hra._tcp.acme.com. IN SRV 0 100 443 hraserver03.acme.com
· _hra._tcp.acme.com. IN SRV 0 10 443 hraserver02.acme.com
· _hra._tcp.acme.com. IN SRV 0 0 443 hraserver01.acme.com
the client will use the HRAs in the following order:
To enable automatic HRA discovery, the following registry keys must be defined on the client. If using group policy:
· HKLM\SOFTWARE\Policies\Microsoft\NetworkAccessProtection\ClientConfig\Enroll\HcsGroups\EnableDiscovery (DWORD): 0x1
If using local NAP client configuration:
· HKLM\SYSTEM\CurrentControlSet\Services\napagent\LocalConfig\Enroll\HcsGroups\EnableDiscovery (DWORD): 0x1
Communication with the HRA will always be performed using SSL when HRA auto-discovery is used.
HRA auto-discovery will work with domain joined or workgroup NAP clients. Additional certificate validate checks are performed requiring the certificate of the Certificate Authority that issued the SSL certificate to the HRA to be published in the client enterprise NTAuth store before communication will be established. Enterprise Certificate Authorities in an Active Directory environment are automatically added to a clients NTAuth store.
For workgroup clients, the certificate can be added using the following command:
· certutil -addstore -enterprise NTAuth certificate.cer
As a side note, for workgroup clients, a default IPsec rule can be automatically plumbed onto the machine by the IPsec enforcement client once a health certificate has been obtained. To make the IPsec QEC enforcement client the IPSec policy, the following client registry key is required:
· HKLM\SYSTEM\CurrentControlSet\Services\NapAgent\LocalConfig\PlumbIpsecPolicy (REG_DWORD): 0x1
If the value is set, the IPSec policy will be applied as soon as a health certificate is retrieved from a HRA. The policy will be removed after the certificate expires or is deleted from the machine store.
The IPsec rule defined will be in the form:
· Me-to-Any, all traffic, request outbound/require inbound, Credential=Health Certificate; ESP 3DES/SHA1 and ESP Null/MD5
· Me-to-Any, ICMP, permit
So to summarise, HRA auto-discovery is a great way to allow your NAP clients to automatically locate your HRA servers and obtain a health certificate.
Even if you do not initially apply IPSec policies and restrict access of unhealthy clients, issuing health certificates will enable you to monitor how many of your clients are adhering to your health policy. Using a NAP infrastructure to issue health certificates throughout your organisation provides a quick and risk free way to continually validate the health of all of your clients.
HRA auto-discovery is only supported with IPSec enforcement running on Windows Vista SP1 and Windows XP SP3 clients.
** May 15th 11:25AM GMT-8 ** Small correction to the URLs to HTTPS