My guide for Configuring DirectAccess with UAG Service Pack 1 has been released! Read it here
There are a few topics that I want to briefly touch on more as an overview or theory than a step-by-step how-to.
First, while DirectAccess functions by using IPv6 tunnels, the traffic and connectivity is secured and encrypted by using certificates. Second, endpoints or client computers are granted access through the UAG via DirectAccess by being members of a security group upon which Group Policy gets applied. And third, there are a few considerations for the kinds of computers you will be able to use as a DirectAccess endpoint.
In order to use DirectAccess you must have a Public Key Infrastructure (PKI) in place
. If you already have an in-house enterprise certificate server then you may already be set in this department, but if not, here is a TechNet Step-by-Step on how you'd set one up
in a lab. You should read through that and tailor it to your environment. The UAG Product Team also has a blog post relating to Certificate Enrollment on the UAG server
that you can read through.
Also, now would be a good time to generate a Web Server certificate for your UAG server too. This will be used for the IP-HTTPS connection but it does not need to be issued from a third party CA since the only clients that will access this web service will be domain members that should trust the in-house issuing CA. The "common name" should be the External DNS name that you set for the first external IP address. Once you've generated the certificate, just import it to the UAG server's Computer Account Personal Certificate store. You don't need to set anything in IIS becuase the UAG wizard will set that up for you.
Another component that plays a key role in your PKI will be the Certificate Revocation List (CRL). You'll want to make sure that you publish the CRL so that DirectAccess clients are able to check the validity of the certificates they are using. If the CRL is unavailable then the clients will not trust the certificates and connections / tunnels will not be established. The Test Lab Guide has some step-by-step instructions
on how to prepare the CRL.
While DirectAccess is enabled through Group Policy, those policies are applied only to members of the domain that belong to a security group. The GPO is actually liked at the root of the domian and the policy is filtered to only apply to a group that you will specify in the UAG wizard. You can specify several groups but you'll need to go through a couple step process to effect the changes an apply the policies to those groups. So instead I like to create one security group called "DirectAccess Enabled Computers
" and specify that in the UAG wizard. Then you can add computers or other groups to that group through Active Directory rather than re-run the UAG wizard and generate and apply the new policy.
To use DirectAccess your client computers must be running Windows 7 Enterprise or Windows 7 Ultimate. Lesser versions of Windows (including W7 Professional and all varieties of Vista and XP) will not work with DirectAccess. The computer must also be a domain member, so even if you have the right version of Windows, if it is just a workgroup computer at someone's house, they cannot use DirectAccess. This TechNet Article
also covers server requirements.
Also, while you can use DirectAccess on any computer that runs the right version of Windows, you would really be doing yourself a disservice if trying to use old, slow hardware. Not only from the stand point that Windows may be sluggish in general, but DirectAccess encrypts all traffic using IPSec
which will require some CPU overhead. So the faster your client computer is, the better the user experience will be. But that is always the case, isn't it?