Limiting ISATAP Services to DirectAccess Manage Out Clients

Please Note: This blog post was adapted from a previous UAG DirectAccess blog post and was originally written when the use of ISATAP for the Manage Out scenario was fully supported by Microsoft. However, with the advent of Windows Server 2012 supportability for the use of ISATAP was specifically limited to a single server topology due to known scaling and reliability issues as summarised in the following TechNet reference: https://technet.microsoft.com/en-us/library/dn464274.aspx#bkmk_isa

A common requirement, or ask, for many DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This functionality is often termed ‘manage out’ and is one of the major benefits of a DirectAccess solution when compared to traditional VPN remote access solutions. The ability to reach a managed client, irrespective of their location, irrespective of whether they are logged in, is a power tool for IT administrators.

However, the need for corporate connected manage out clients to be IPv6 capable often presents a challenge when not running IPv6 within the intranet environment. This challenge is often met by configuring an intranet IPv6 transition technology called Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP for short.

Unfortunately, the ISATAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista and above operating systems. This DNS lookup requires the creation of a global ‘isatap.domain.com’ DNS host record, and this will ultimately enable ISATAP by way of an ISATAP router,. The router will automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support globally using ISATAP is desirable, but for many deployments, adding IPv6 capabilities to all Windows systems is not desirable; especially when Windows will naturally favour IPv6 communications over IPv4. For many customers, the cultural change this IPv6 preference brings to a desktop and/or server administrator is more than a little confusing, and definitely not something that should be enabled globally without some thought.

So, how do we provide the IPv6 capabilities required for DirectAccess manage out clients, whilst still preserving a more traditional IPv4 experience for other Windows systems?

The main way to solve this problem is to move away from using the global ‘isatap.domain.com’ DNS host record that is hard coded into all Windows Vista+ systems, and use a custom ISATAP router name that is specific to your environment. With this DNS host record created, all we need to then do is enable specific clients to use this custom ISATAP router name and we have a mechanism of controlling ISATAP on our terms.

Please Note: An alternate approach using HOSTS files is feasible for very small deployments, but this has limited scalability and does not allow for the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a DirectAccess cluster. Therefore this approach is not recommended outside of a lab environment.

In my opinion, the best way to achieve this technically is by way of Group Policy and a dedicated Windows security group for manage out clients, as follows:

Step 1: Create a Custom ISATAP DNS Record

Create a new DNS record called [something]isatap.domain.com, or similar. Configure this DNS record to point to the internal IP address of the DA server. If using a cluster, you will need to defined the record multiple times; once for each DA cluster member internal IP address, and once for the internal cluster VIP.

Please Note: As the ISATAP router name is customised, it will not be necessary to remove this name from the default DNS block.

Step 2: Create a Windows Security Group

Create a new Windows security group called DirectAccess Manage Out Clients, or similar.

Step 3: Create a New Group Policy

Using GPMC, create a new group policy object called DirectAccess: Manage Out Clients (Enable ISATAP) or similar, with the following properties:

image

Under the Scope tab, remove Authentication Users from the Security Filtering section and add the Windows security group created above; DirectAccess Manage Out Clients in our example.

image

Under the Details tab, set the GPO Status to User configuration settings disabled

image

Edit the newly created GPO and define the following settings:

Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies

ISATAP Router Name: Enabled

Enter a router or relay name: [something]isatap.domain.com

image

ISATAP State: Enabled

Select from the following states: Enabled State

image

Once completed, this should result in the following output in the Settings tab:

image

Step 4: Add Computer Accounts to Windows Security Group

All that now needs to be done is to add the computer accounts for machines that will be used for remote management of DirectAccess clients to the DirectAccess Manage Out Clients Windows security group.

Please Note: It will be necessary to reboot clients and servers after adding them to the DirectAccess Manage Out Clients windows security group before the new GPO will be applied.

Once this has been done, the specific manage out clients that you have defined by group membership should now receive ISATAP addressing and prefix information making them IPv6 capable.

Once configured correctly, you should receive a 2002:WWXX:YYZZ:8000:5efe:w.x.y.z format address (or similar) on the ISATAP adapter and will be able to remotely manage DirectAccess clients from this predetermined group of manage out machines.

Please Note: If the ISATAP adapter address assignment is not successful, it may also be necessary to use the following command to refresh the adapter state: sc control iphlpsvc paramchange

Hope this helps!

[This article has been adapted from a previous UAG DirectAccess blog post and hence screenshots may show UAG references which can be ignored]