My Legacy Blogs
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:
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.
Under the Details tab, set the GPO Status to User configuration settings disabled
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
ISATAP State: Enabled
Select from the following states: Enabled State
Once completed, this should result in the following output in the Settings tab:
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]
If the DA server are under NLB, how would you manage out? Thanks.
That is covered in the above text "...the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a DirectAccess cluster" - clients will then use the internal VIP as their IPv6 gateway to reach DA clients and NLB has the bi-directional affinity controls to allow for correct server determination on the way out
Just so I am 100% clear, which of the following need to be members of this limited ISATAP settings group?
(1) the Direct Access clients themselves?
(2) the Direct Access server?
(3) the internal computers which want to be able to 'manage out' the clients?
I am assuming that the answer is #3 only. Have I understood correctly?
Second question: do I need to enable IPv6 on the internal computers, or can they continue to use IPv4 only?
I am trying to clarification on this same question. What exaclty requires ISATAP communication. Does the NLS, DNS, email, and other support servers?
From what I have been reading the GPO only requires members that are actually "pushing" out communications or iniitaing the connection to the DA clients. Is this correct?
Thanks for the great info!
If you do not want to reboot machines, you can refresh their computer group membership (by forcing them to request new Kerberos tickets) with command "klist -li 0x3e7 purge" prior to starting group policy processing with e.g gpupdate.
@Mika - Thanks!
@Steve - Correct #3 only. With regard to IPv6, the manage out clients (the ones initiating outbound connections from the intranet) need to be IPv6 capable which can be achieved using native IPv6 or ISATAP.
@Cory - Hopefully the above comment answers your question too!
I was not able to manage out to DA clients and this article provided the silver bullet. Thanks for sharing this info!
@Glenn - great news, thanks for the feedback!
Great article. Is there a way to pull a list of all the ISATAP hosts that are 'connected' to the DA ISATAP server? We didn't control the ISATAP clients with a customer ISATAP hostname. We are going to remove the DNS entry now, but i'd like to see a list of clients which have connected so I can vet the list and add it to a security group for GP.
@Itismeap - Thanks! I don't think so as it is stateless I believe; you could maybe try netstat to see the list of connections?
What about Firewall Rules on the DirectAccess clients? Are any exceptions needed to allow ISATAP clients to reach the DA clients? For example, I want to ping a DirectAccess client. I'm on an ISATAP enabled computer. Do I need to make a Firewall rule on the DA client to allow ICMPv6 Echo and specify the ISATAP subnet as the Source network? Don't I also need to allow "Edge Traversal" for it to work over Teredo?
I think you already know the answer to that! Here is a good reference for that: http://blogs.technet.com/b/tomshinder/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx
For the systems in the custom ISATAP security group with the ISATAP Route enabled setting, when they attempt to communicate to systems on the intranet using the ipv4 address, how does that function? Since ipv6 is favored, will they attempt to route through the DA Box?