There are a number of key prerequisites that you should have in place prior to implementing UAG DirectAccess. While I won’t be going into step-by-step detail on these components in this guide, I will give you some pointers in case you need them.
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.
Tom Shinder’s Test Lab Guide: Base Configuration walks you through a basic build of a certificate authority.
To make your life with Certificates easier it is a good idea to enable Certificate Auto-Enrollment for your domain computers, or at least for your computers that will be DirectAccess enabled. This will allow the computers to request, enroll and renew their certificates on their own. Otherwise you will need to manaully request a certificate on every computer AND remember to renew them before they expire. Auto-Enrollment is a fairly simple Group Policy setting so you can apply it however you like.
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 match an External DNS name that will resolve to the first external IP address of your UAG server. 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 because the UAG wizard will set that up for you.
Check out Step 2F in Tom’s Test Lab Guide for UAG SP1 for some specific steps on preparing the Certificate Template and enrolling for the certificate.
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 IP-HTTPS certificate. If the CRL is unavailable then the clients will not trust the certificates and connections / tunnels will not be established. This requirement often leads people to use a 3rd party certificate instead since their CRL is already published and trusted. The Test Lab Guide has some step-by-step instructions on how to prepare the CRL. You can also use some information in the Pre-SP1 Base Configuration Test Lab Guide on way to publish your CRL.
Another option is to publish the CRL through a trunk in UAG itself. You can read about that at Tom’s blog too.
Active Directory Groups vs OU’s
To enable a computer to use DirectAccess you can use either Active Directory Security Groups or Active Directory OU’s (new to SP1). However you can only use one or the other, so you need to decide which method is best for your environment.
I prefer using the “old” way of using a security group (or groups) because it allows the computers to reside anywhere in the AD OU hierarchy. The computers need to be added to the group manually, but I like to think of this as a sanity checkpoint, ie: it requires someone to decide to enable the computer for DirectAccess.
Alternatively, you can use an OU, or multiple OU’s which allows you place a computer somewhere in AD and they will inherit the DirectAccess policy like any other GPO. If you use SCCM for doing Operating System Deployment this can be pretty handy since you can specify the OU that newly built computers get placed in and thereby automatically enable DirectAccess via OSD. The drawback here is that you may need to reorganize your AD OU hierarchy to accommodate the deployment plan.
Depending on which method you want to use, now is a good time to make your preparations.
Using Security Groups?
I generally recommend that you create a single Security Group for the purposes of enabling DirectAccess. I like to use a name like “UAG DirectAccess Enabled Computers” since it is very obvious what it’s purpose is. This can be a Global or Universal group and can reside anywhere in Active Directory. The key to remember is that members of this group can be Computer objects (not users!) or other Groups of computers. Once a computer is a member of this group they simply need to run gpupdate or reboot and they’ll be enabled for DirectAccess. Pretty simple.
Using AD OUs
If you prefer to have your DirectAccess enabled computers in their own Active Directory Organizational Unit (OU) then you can create it now. You can use multiple OU’s so if you have an AD structure that breaks out in some logical manner that lends itself to defining DA clients then this might be a fit for you. Just like with the security group method above, once a computer is placed in this OU they simply need to run gpupdate or reboot and they’ll be enabled for DirectAccess. Also pretty simple.
To use DirectAccess your client computers must be running Windows 7 Enterprise, Windows 7 Ultimate or Windows Server 2008 R2. 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.
Note: UAG can be used to connect legacy clients via an SSL VPN. this guide focuses on DirectAccess but you can read more about SSTP and the legacy Network Connector at TechNet.
Also, while you can use DirectAccess on any computer that runs the right version of Windows on your domain, 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 incur 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?