Today I want to talk about UAG DirectAccess Group Policy objects and some useful tweaks you can apply to them.

Using an Existing GPO

While the script generated by the UAG DirectAccess Configuration Wizard works well in most cases, in some cases you may have to edit the script.

Two reasons that may require you to edit the script are:

• If you don’t have permissions to create a GPO, but you do have permissions to edit one, you would need the AD administrator to create three GPOs for DirectAccess deployments, and you would use the generated UAG DirectAccess script to edit these three GPOs.
• You want to link the GPO to a specific OU so the effect of the GPO is limited, and not under the root (which is the default script behavior).

In these cases, you need to save the PowerShell script, and then edit it as follows:

1. In the first section of the file there are three variables called

• UAGDA_POLICY_APPSERV
• UAGDA_POLICY_CLIENT
• UAGDA_POLICY_GATEWAY

2. You should rename them from the “UAG DirectAccess: ….” name they currently have to other different preconfigured GPO names

• From:

• To:

3. Then you should comment out the calls to the function TryCreateGPO. There should be three calls, and you should comment out all three.

4. The next two lines (three if you are using End to End authentication) following the calls to TryCreateGPO indirectly call Set-GPPermissions to set the relevant permissions on the GPO, and you should disable them as well.

5. The next two lines (three if you are using End to End authentication) call LinkGpoToDomains. They need to be commented out as well.

Overall it should look as follows:

• From:

• To:

If you want to configure DirectAccess clients from one domain and have the UAG machine in another domain, you can use the steps described above to create the GPOs, then you should use conventional Group Policy tools to copy/move the client GPO from the UAG domain to the DirectAccess client domain.

Please note though that the client domain and the UAG domain should have full Kerberos trust between one another.

Manage Out “Only”

Some UAG DirectAccess customers were interested in deploying only the “infrastructure” tunnel for DirectAccess clients. This usually occurs where you want your DirectAccess clients to be “always managed”, but do not want them to have access to all of the corporate resources.

In that case, run the Forefront UAG DirectAccess Configuration Wizard as usual and in the “DirectAccess Server” step, in the Authentication Options screen, select the Clients that log on using a PKI smart card check box and then complete the Forefront UAG DirectAccess Configuration Wizard.

Save the exported PowerShell script generated by the UAG DirectAccess Configuration Wizard, and then edit it as follows:

1. Look for a line in the script that starts with PsNetshExec "Set UAG DirectAccess Client - Clients Corp Tunnel.", and comment it out.
2. Look for a line in the script that starts with PsNetshExec "Configure the SmartCard user group.” and at the end of the line, replace the string O:LSD:(A;;CC;;;S-1-5-65-1)with O:LSD:(D;;CC;;;WD).

Overall it should look like the following:

• From

• To

The new script creates a policy that contains only the “manage out” tunnel. That enables the clients to only get access to “infrastructure” servers defined in the UAG DirectAccess Configuration “Management” server list.

It affectively disables the “corp” tunnel by denying it from any user groups (instead of allowing it only to users that authenticated with smartcard)

One last note – always remember that the UAG DirectAccess Configuration Wizard, generates a new script each time you complete the wizard, so if you plan to use “tweaked GPOs” on a regular basis you should consider automating the script editing.

Oh yes, just one last thing, note that running the script is just one part of the configuration process, and you should always activate the configuration from the UAG Management console, whenever you make changes in the UAG DirectAccess Configuration Wizard.

And that’s about it for today…

Author:
Ben Bernstein, Senior Program Manager

Reviewers:
Tom Shinder, Technical Writer
Simon Rabinowitz, Technical Writer