UAG SP1 DirectAccess: Config Wizard, DirectAccess Server

Author by Shannon Fritz

This wizard has also been improved in SP1 and I find it more intuitive than in the RTM.  Here you'll be defining the network interfaces for UAG, the details about your earlier decisions around certificates and have a few more options about how to further secure the connections and apply policies to your servers. If you've got your IP addresses set right and you have ISATAP removed from the DNS Global Query Block List (here's how) then the first page of this wizard should look like the above screenshot.  If not, then the wizard is likely assuming that you are using native IPv6 or cannot find the ISATAP DNS record. The two dropdown lists should be populated with only one option in each.  In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear below the drop-down.  In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP.  Of course that’s a little ironic being that you needed to do that beforehand. This is where you select the certificate to be used for IP-HTTPS.  You should have generated this certificate already, but to recap, this can be issued from your internal CA or from a 3rd party, which ever you prefer, and you can read more about it here.  Remember, the "Common Name" that you've defined in this certificate must be the same as the External DNS name that resolves to the first public IP address on your UAG server. The last page is where you select the Certificate Authority that is issuing Computer Certificates to your DirectAccess Clients which should be listed as a Trusted Root Certificate for the Computer Account.  This is the CA that you should have already configured Auto-Enrollment for, which you can read more about here.

Optional Settings

There are a number of additional settings that you can configure for the DirectAccess Server, but you can typically leave these at their defaults. Configuring Two-Factor authentication will also require you to set up the DirectAccess Connectivity Assistant (which you should do anyway) but it will allow you to use either a Smart Card or OTP.  This is used in addition to the security measures already in place for DirectAccess such as needing a Computer Certificate and the user AD credentials.  If you want to set up Two-Factor Authentication, do it later, but you can read more about it at TechNet. You can use NAP to make sure the DirectAccess clients meet certain requirements prior to letting them on the corpnet.  For this guide we'll leave that disabled but you can read about UAG NAP on TechNet. Split tunneling vs Force Tunneling is really referring to the way you want to handle the traffic from your DirectAccess clients that is not destined for the corpnet.  For example, when a user on a DirectAccess enabled client is browsing the internet, Split Tunneling allows that traffic to traverse the client's "local" Internet connection.  If instead they are using Force tunneling, then that traffic must instead traverse the DirectAccess tunnel back to the corpnet and then out to the Internet from there. As the wizard indicates, this will impact network performance, but it is for two reasons.  One is because all network traffic from the client must flow through your UAG server, so there's a potential/likely bottle neck.  And Two, using Force Tunneling requires that the clients use IP-HTTPS which is the lowest performing of the three tunnels DirectAccess can use.  So unless you have a genuine need to do Force Tunneling, leave it Split. The last option lets you determine how you want to apply the DirectAccess GPO's to your UAG servers.  It's similar to the decision you made in the Clients wizard but this determines how the Server Group Policy is managed. Leaving the default "Server name" option will link the GPO at the domain level and then use a filter so the policy only applies to the computers listed (the list is auto-populated).  This should work fine for most deployments but will require that the UAG servers are in an OU that is not blocking inheritance (which you should not be doing anyway as a matter of best practice). The second option is to specify an OU that the Policy should be linked at.  This option does not use a filter and will apply to all computers in that OU so you will need to create an OU that contains only your UAG server(s). When you're all set click Finish.
Author

Shannon Fritz

Infrastructure Architect & Server Team Lead