What Changed with Windows Server 2012?
With Windows Server 2008 R2, yon can configure NAP enforcement. NAP deployment is under your responsibility. With Forefront UAG 2010, Network Access Protection configuration can be performed by the UAG wizard and host the Health Registration Authority on the server. But with Windows Server 2012, there is a small change documented here :
It’s no longer supported to host the Health Registration Authority with the (URA) Unified Remote Access role. This means we have two solutions. Having the HRA published on Internet or using an internal HRA. For the first solution have a look at this post from the cable Guy (aka Joseph Davies author of the Understanding IPV6 book series). For the second solution, let’s go deeper into NAP.
Back to the NAP roots
Technically speaking, its not a problem to combine DirectAccess with NAP. URL corresponding to the HRA must be reachable through the first IPSEC infrastructure tunnel. First, we must enable Network Access Protection at DirectAccess Level :
In Picture above, we see that enabling Network Access Protection is just a checkbox, but this checkbox is available only if you are using computer certificates for tunnel authentication. Deploying DirectAccess without certificate is a cool feature for quick deployment but if you want extra-cool feature, don’t forget to select an internal CA that will be providing certificate to be used for tunnel authentication .
If you want to know, the “Enforce corporate compliance for DirectAccess clients with NAP” status just run a Get-DAServer Powershell as illustrated bellow :
When Network Access Protection is enabled, some small “changes” are performed into the DirectAccess Policy-DaServerToCorp connection Security Rule (on server-side). Let’s have a look in with an “old–school” way based on NETSH.EXE.
A specific certificate delivered by the Health registration Authority is required for user-tunnel establishment. This means that HRA URL must be reachable from the first IPSEC tunnel. For this reason, we must add this URL to the infrastructure server list.
Is is possible to use a single internal HRA?
Technically speaking it’s not a problem. You can have a single HRA but remember one thing. URL will be reachable from DirectAccess clients located on Internet but also DirectAccess clients connected on Intranet. That’s a big (bug?) change. In a DirectAccess project, you expect to have computer compliance checking for External clients, but you may not expect to apply the same compliance criteria for all computers. Unless you are engaged in a global computer compliance enforcement project, you have a problem. It would be great to have different NAP policy based on your location (Internet/intranet). Let’s have a look at NAP filtering capabilities.
Network Access Protection filtering capabilities
Let’s have a look at some Network Access Protection Design considerations :
The only way we have to filter a DirectAccess client from another from the NAP Point of view is the RADIUS client option. This means, that DirectAccess clients will use a dedicated HRA and internal clients will use another HRA. These two HRA will be considered as Radius clients from a central Network Policy Server that will use the Access Client IPv4/6 address condition. Technically speaking, that might be a solution but :
How can we be sure that a computer connected on Intranet will not use HRA dedicated to DirectAccess clients connected on Internet?
And more important, how can we be sure that a DirectAccess client connected on Internet will not use HRA dedicated to internal clients?
The Multiple NAP Challenge made simple
Specialize Health Registration authorities based on computer security level is a good option. Scenario explained before is technically possible, just complex to setup in a small DirectAccess deployment. The real challenge is how to be sure that NAP enabled client will always use the good HRA. DirectAccess have a solution for that. It’s always a question of name resolution capabilities.
In my scenario, I will dedicate a NPS/HRA to intranet clients and another one to Internet clients. Each NPS will have it’s own configuration (I said simple ). NAP enabled computers (DirectAccess or Not) will be able to use a HRA based on their location (Intranet/Internet).
First we need to be sure that DirectAccess clients connected on Internet cannot reach HRA dedicated to Intranet clients. With DirectAccess, we have built-in host resolution blocker capabilities : Name Resolution Policy Table :
If I block name resolution for my internal HRA URL (HRALAN), I’m sure that DirectAccess clients will never be able to use it when connected on Internet. Great thing. But we also need that internal clients cannot resolve DNS host name for the DirectAccess Dedicated HRA (HRADA).
That’s more tricky. In my scenario, I consider that my DirectAccess infrastructure is located on a specific network in DMZ. For security reason, servers in this network can only use Read-Only domain Controllers located in the same network. So internal clients use different DNS servers. In this case, I will use another host resolution blocker capability : DNS GlobalQueryBlockList. In illustration bellow, you can see the content of the GlobalQueryBlockList I configured on all DNS servers located on Intranet :
We can see the standard WPAD and ISATAP host blocked for DNS resolution. The HRADA host is my HRA dedicated to DirectAccess clients. If I add it to the GlobalQueryBlockList, I’m sure that clients connected on Intranet will never be able to reach it.
And last NAP client configuration. All my NAP clients will share the same Trusted Server group List including all HRA available in my environment (simple by design ).
DirectAccess clients connected on Internet will only be able to resolve “HRADA” hostname. Internal clients (DirectAccess enabled on not) will be able to resolve “HRALAN” only.
How fast is it to switch from an HRA to another?
Good question, after some tests on my lab and performing some research, I found the solution here : http://technet.microsoft.com/en-us/library/dd125359(v=ws.10).aspx
Since Windows Server 2008 R2 the initial timeout for HRA response is four seconds. If you add DirectAccess tunnel negotiation and network latency, I would be up to forty seconds when a DirectAccess clients connected on Intranet network switch to Internet network.
BenoîtS – Simple and secure by Design but Business compliant