Udostępnij za pośrednictwem

Limiting ISATAP Services to DirectAccess Manage Out Clients

  • Artykuł

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]

Comments

  • Anonymous
    January 01, 2003
    @Mika - Thanks!

  • Anonymous
    January 01, 2003
    @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.

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @Glenn - great news, thanks for the feedback!

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @Cory - Hopefully the above comment answers your question too!

  • Anonymous
    January 01, 2003
    @Itismeap - Thanks! I don't think so as it is stateless I believe; you could maybe try netstat to see the list of connections?

  • Anonymous
    January 01, 2003
    @Malte - the use of ISATAP with NLB is not officially supported and although Rob has a working config, we have seen customers raise support calls with problems.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    July 16, 2013
    The comment has been removed

  • Anonymous
    September 03, 2013
    Hi Jason, 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? Thanks, Steve

  • Anonymous
    September 09, 2013
    The comment has been removed

  • Anonymous
    September 09, 2013
    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.

  • Anonymous
    March 06, 2014
    The comment has been removed

  • Anonymous
    March 11, 2014
    The comment has been removed

  • Anonymous
    March 12, 2014
    It's been a long time I did not publish something in the DirectAccess Challenge series . Let's

  • Anonymous
    April 11, 2014
    The comment has been removed

  • Anonymous
    June 02, 2014
    The comment has been removed

  • Anonymous
    June 05, 2014
    The comment has been removed

  • Anonymous
    July 30, 2014
    Remote Management is one of the top feature provided by DirectAccess. By default a DirectAccess client

  • Anonymous
    August 22, 2014
    The Server 2012R2 Direct Access guidance states that ISATAP is no longer supported for 'manage out' scenarios. Does that include this limited ISATAP model?

  • Anonymous
    December 15, 2014
    The comment has been removed

  • Anonymous
    February 12, 2015
    The comment has been removed

  • Anonymous
    March 10, 2015
    The comment has been removed

  • Anonymous
    July 28, 2015
    The comment has been removed

  • Anonymous
    July 28, 2015
    The comment has been removed

  • Anonymous
    July 28, 2015
    The comment has been removed

  • Anonymous
    July 28, 2015
    The comment has been removed

    • Anonymous
      July 05, 2016
      The comment has been removed

  • Anonymous
    June 10, 2016
    The comment has been removed

  • Anonymous
    November 18, 2016
    The comment has been removed

  • Anonymous
    February 03, 2017
    The comment has been removed