One of the great things about DirectAccess is that all of the connectivity settings the client computers need in order to connect are contained within a Group Policy Objects (GPO). This means that you can turn new client computers into DirectAccess-connected clients without ever touching that system. Once configured properly, all you need to do is add the new computer account to an Active Directory security group and, during the next automatic Group Policy refresh cycle (usually within 90 minutes), that new laptop will be connecting via DirectAccess whenever outside the corporate network.
You can certainly choose not to pre-stage anything with the GPOs and DirectAccess will still work. When you get to the end of the DA configuration wizard, it will inform you that two new GPOs are about to be created inside Active Directory. One GPO is used to contain the DirectAccess server settings, and the other GPO is used to contain the DirectAccess client settings. If you allow the wizard to handle the generation of these GPOs, it will create them, link them, filter them, and populate them with settings automatically. About half of the time, I see folks do it this way and are forever happy with letting the wizard manage those GPOs now and in the future.
The other half of the time, it is desired that we maintain a little more personal control over the GPOs. If you are setting up a new DA environment but your credentials don't have permission to create GPOs, the wizard is not going to be able to create them either. In this case, you will need to work with someone on your Active Directory team to get them created. Another reason to manage the GPOs manually is to have better control over placement of these policies. When you let the DA wizard create the GPOs, it will link them to the top level of your domain. It also sets Security Filtering on those GPOs so they are not going to be applied to everything in your domain, but when you open up the Group Policy Management console you will always see those DA policies listed right up there at the top level of the domain. Sometimes this is simply not desirable. So for this reason as well, you may want to choose to create and manage the GPOs by hand, so that we can secure placement and links where we specifically want them to be located.
While the DirectAccess wizards themselves are run from the DA server, our work with this recipe is not. The Group Policy settings that we will be configuring are all accomplished within Active Directory, and we will be doing the work from a Domain Controller in our environment.
To pre-stage GPOs for use with DirectAccess, follow these steps:
- In your Domain Controller, launch the Group Policy Management Console.
- Navigate to Forest | Domains | Your Domain Name. There should be a listing here called Group Policy Objects. Right-click on that and choose New.
- Name your new GPO something like
DirectAccess Server Settings. - Click on the new DirectAccess Server Settings GPO and it should open up automatically to the Scope tab. We need to adjust the Security Filtering section so that this GPO only applies to our DirectAccess server. This is a critical step for each GPO to ensure the settings that are going to be placed here do not get applied to the wrong computers.
- Remove Authenticated Users that are prepopulated in that list. The list should now be empty.
- Click the Add... button and search for the computer account of your DirectAccess server. Mine is called
RA1. By default, this window will only search user accounts, so you will need to adjust Object Types to include Computers before it will allow you to add your server to this filtering list. - Your Security Filtering list should now look like this:
- Now click on the Details tab of your GPO.
- Change the GPO Status to User configuration settings disabled. We do this because our GPO is only going to contain computer-level settings, nothing at the user level.
- The last thing to do is link your GPO to an appropriate container. Since we have Security Filtering enabled, our GPO is only ever going to apply its settings to the
RA1server but, without creating a link, the GPO will not even attempt to apply itself to anything. MyRA1server is sitting inside the OU called Remote Access Servers, so I will right-click on my Remote Access Servers OU and choose Link an Existing GPO....
- Choose the new DirectAccess Server Settings from the list of available GPOs and click on the OK button. This creates the link and puts the GPO into action. Since there are not yet any settings inside the GPO, it won't actually make any changes on the server. The DA configuration wizards take care of populating the GPO with the settings that are needed.
- Now we simply need to rinse and repeat all of these steps to create another GPO, something like DirectAccess Client Settings. You want to set up the client settings GPO in the same way. Make sure that it is filtering to only the Active Directory Security Group that you created to contain your DirectAccess client computers. And make sure to link it to an appropriate container that will include those computer accounts. So maybe your client's GPO will look something like this:
Creating GPOs in Active Directory is a simple enough task, but it is critical that you configure the Links and Security Filtering correctly. If you do not take care to ensure that these DirectAccess connection settings are only going to apply to the machines that actually need the settings, you could create a world of trouble with internal servers getting remote access connection settings and causing them issues with connection while inside the network.
The key factors here are to make sure your DirectAccess Server Settings GPO applies to only the DA server or servers in your environment, and that the DirectAccess Client Settings GPO applies to only the DA client computers that you plan to enable in your network. The best practice here is to specify this GPO to only apply to a specific Active Directory security group so that you have full control over which computer accounts are in that group. I have seen some folks do it based only on the OU links and include whole OUs in the filtering for the clients GPO (foregoing the use of an AD group at all), but doing it this way makes it quite a bit more difficult to add or remove machines from the access list in the future.