One of the exciting new technologies we are now in the process of testing is called DirectAccess. DirectAccess allows a user/computer to be actively connected to the domain network no matter where in the world that user is. It doesn’t matter if the user is at Starbucks on their wireless network, at a hotel or even at home. This secure connectivity works from the moment the computer is turned on allowing it to receive all the latest group policies, as well as a user to connect to mapped drives, printers or other internal resources.
In order for DirectAccess to work, it requires a number of different technologies. Here are the technologies we are using.
- IPv6 – all traffic for DA uses IPv6
- Certificate Authority
- Windows 7 Enterprise/Ultimate
- Windows 2008 R2 – This is a server with two nics – one on the internet and one on the intranet
- Group Policy
- IPSEC
- Unified Access Gateway – This is an add-on product from Microsoft allowing us to connect to IPv4 resources.
Windows Server 8 is coming out with some changes to this, but for now, this is what we have running.
I have found that once a user has this, it is one of those technologies that you just can’t live without. It becomes such a part of your normal routine to be able to connect to every resource, that when it isn’t working it is very noticeable.
Microsoft has a downloadable client to make it easy to verify if access is working. This is called the DirectAccess Connectivity Assistant (DCA) (downloadable here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10322 ). This is a great tool that allows you to see if DA is working and generate logs for troubleshooting. (I have used these logs often to find issues with DA.)
Here are a few issues that we have found as we have implemented this:
- Computers newly joined to the domain may not have their computer certificate yet. (In our environment, it requires group membership and workstations aren’t added to the necessary group until a process runs every night.)
- For some of our HP laptops, we have found that when they wake from sleep they are unable to connect to the DA server. Usually running an ipconfig /flushdns takes care of the issue.
- One other issue we have run across is when some of our users play with the setting on the DCA to change it to use local DNS only. We have found that sometimes this setting gets “stuck” and they cannot connect to internal resources. (Making the change to only use local DNS is unnecessary in our environment as our DA is already setup to do split tunneling and only send traffic & DNS to our servers for internal resources). In this case, we have found that it is necessary to do the following.
- Check the following regkey: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableDAForAllNetworksand make sure it is set to 0 and not 2. You will probably need a reboot after the change. The values for the key are shown here:http://msdn.microsoft.com/en-us/library/ff957870(PROT.10).aspx
If you haven’t had a chance to play with DA, I would highly recommend it. Windows 8 is going to make it even easier by changing some of the requirements (including the need for a certificate authority server and an external NIC with two sequential IP addresses). Stick around, as it will be a good thing!
They say a picture is worth a thousand words, so here is a diagram of how DA works:
