And for the last post of this series, the DirectAccess Configuration. Let start with a minimal checklist in order to avoid headache.
First step is to check activation status of each node. If one ore more node is not operational, solve this problem first.
Second step is to check NLB status and synchronization status of each node. If necessary wait for the NLB feature to be fully operational before continuing.
Because I have an internal VIP for my UAG farm, the DNS ISATAP record need to point to the VIP. At this point also check that all your UAG network interface cards DNS suffix are properly configured if you don’t want to have activation issue with ISATAP.
Each of our node should have a properly configured certificate but also our IP-HTTPS certificate, with the private key.
For more UAG DirectAccess check-list, see “Basic troubleshooting steps for UAG DirectAccess” from the UAG blog team.
Just like Windows DirectAccess or standalone UAG DirectAccess deployment, the first operation is to select one or more Windows security groups that will be used for filtering purpose on the DirectAccess client GPO.
Because UAG was configured in an array and the required KB977342 was installed. The load balancing checklist was successful (in Windows Network Load balancing).
The tricky screen. if everything is properly configured, you should have correct content for both internet and internal network cards.
By default and by design, i keep NAT64 and DNS64. My LAN is IPV4 based, no need to change this.
The certificates headache. First, you select our internal PKI infrastructure. UAG will check clients certificates status to this PKI. If you have imported the IP-HTTPS certificate with a friendly name, you should have no problem to select the good certificate.
At this point, you can activate Smart Card support for IPSEC Tunnels and also support for an optional but highly recommended Network Access Protection infrastructure. The next screen deal with the Network Location server witch is a simple web server that properly responds to HTTPS request with a content when clients are connected to the LAN.
As illustrated bellow, our Network Location Server is also declared as an exclusion for the Name Resolution Policy Table. Why? Because if it’s possible to reach it from the internet, clients will consider they are located on the LAN.
By Default, the UAG wizard will reference all domain controllers in the NRPT (it is considered that each domain controller is also a DNS server). You can add or remove domain controllers, but don’t forget about high availability.
If you setup a Network Access Protection infrastructure and select the checkbox, don’t forget to add the HRA. This might be useful if you want to see NAP working with DirectAccess.
And the last configuration screen to select the deployment mode. Enabling the end-to-end authentication mode will configure an additional group policy that will be applied to application servers included in one or more security groups. This group policy will configure IPSEC endpoint for these servers.
And now Powershell time (drum roll).
As told in a previous post of this series, UAG is not UAG without his activation process. Note that this activation process includes group policy deployment. For this reason, check that each UAG node applied this GPO with a “GPUPDATE /FORCE” command.
Activation is successful, but just like NLB, this do not mean the end.
This is the end
Let start with a last UAG activation monitoring.
As each node is activated with configuration data from the central location, we can consider our DirectAccess UAG farm ready.
This UAG/DirectAccess deployment scenario might be long and complex to setup but if you follow the rules and checklists this will work.
BenoîtS – Simple and Secure by Design (I emphasize on “Secure”)