Tuesday, 8 November 2011

Limiting ISATAP Services to UAG DirectAccess Manage Out Clients

A common requirement or ask for most UAG DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This is often termed ‘manage out’ and is one of the major benefits of a UAG 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 if the customer is not running IPv6 within their environment. This challenge is often met by configuring an intranet transition technology called ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).

Unfortunately, the ISTAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista, Windows 7 and Windows Server 2008/R2. This DNS lookup requires the creation of a global ‘isatap.domain.com’ DNS host record, and this will ultimately enable ISATAP, and automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support 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 UAG DirectAccess manage out, 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 enabled specific clients to use this custom ISATAP router name and we have a mechanism of controllers 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 UAG DirectAccess array. 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.

Step 2: Create a Windows Security Group

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

Step 3: Create a New Group Policy

Using GPMC, create a new group policy object called UAG 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; UAG 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 UAG DirectAccess Manage Out Clients Windows security group.

Please Note: It will be necessary to reboot clients and servers after adding them to the UAG 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 an 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!

53 comments:

  1. Nice article keep updating

    ReplyDelete
  2. Great article, JJ.
    I implement ISATAP to my customers in exactly the same way :)

    ReplyDelete
  3. That is far more elegant and manageable than individually modifying HOSTS files. Thanks!

    ReplyDelete
  4. Fantastic post Jason. Do we still need to remove ISATAP from global query blocklist on DNS server???

    ReplyDelete
    Replies
    1. Thanks - no, there is no need to remove a custom ISATAP entry from the DNS blocklist as only things like ISATAP and WPAD are blocked.

      Delete
  5. Excellent! Do you still need to register the address in DNS for the VIP and both DIPS for NLB configuration?

    ReplyDelete
    Replies
    1. Yep, same DNS requirements, just a custom name...

      Delete
  6. Any issue applying making this group policy change in the GPO that is created for the DIrectAccess Client machines as part os UAG config?

    ReplyDelete
    Replies
    1. Yes, as customisations will get overwritten next time you apply changes in the UAG console...use a custom GPO

      Delete
    2. You could just next the new ISATAP Manage out group inside the group you use for DA Clients as well. That should "stick" since the group doe not get recreated right?

      Delete
    3. No really, as the groups defines what can do the managing, not what is being managed...

      Delete
  7. This may sound stupid but where does the ISATAP DNS Record need to point?

    ReplyDelete
  8. To the Ip address bound to the UAG internal interface

    ReplyDelete
    Replies
    1. If using an array it needs to point to the internal interface VIP and all array member dedicated ip addresses

      Delete
    2. IPv6 or IPv4 address of internal interface?
      Could this solution also be implemented regarding Direct Access 2012?

      Delete
    3. IPv4 addresses

      Yes the same solution works for DA 2012 but MS recommended moving to native IPv6 not ISATAP

      Delete
    4. Tnx Jason I could not find any good article regarding manage out vs DA 2012.

      Delete
    5. I could not find out these "small" answers that I needed.
      Like, what IPv6 address should SCCM use?

      example:

      da server - 2002:c2f7:dc1a:3333::1
      sccm - 2002:c2f7:dc1a:3333::2

      is this config ok?

      Delete
  9. I used this guide to setup ISATAP for my DirectAccess clients and I pointed the ISATAP to my DirectAccess Server. It seems work work pretty well.

    Thank you very much for the guide! I can now communicate with my DirectAccess clients.

    FYI: I am running a full Server 2012 and Windows 8 Environment. Loving it!

    ReplyDelete
  10. I am understanding, if I want to use External Load balancer; I need to deploy external ISATAP router before DA deployment. Will that external router will be a single point of failure? what kind of architecture people following for this?

    ReplyDelete
    Replies
    1. I believe that is the recommendation, but I have heard the single point of failure concern before. Let me ask around to find out what is best practice...

      Delete
  11. Should it be computernameisatap.domain.com or computername.isatap.domain.com pointing to the DA Server?

    ReplyDelete
    Replies
    1. It doesn't really matter as long as though it resolves the name the correct place and you have defined it in group policy. However, I would use .domain.com and keep the domain the same as your clients primary DNS suffix.

      Delete
  12. How would this work if I have 2 DA arrays? We cant do stretched VLAN on internet side and hence are deploying 2 clusters in 2 data centres for 50% of the clients each.

    If the helpdesk are in this policy how will they get out to the clients if they resolve to the array that the client is not currently connected to or vice versa?

    Thanks

    ReplyDelete
    Replies
    1. Things get a bit more complicated with dual data centres as you need to look at using dedicated ISATAP routers and thinking about IPv6 in a bit more detail. The following may also help: http://www.windowsnetworking.com/articles_tutorials/configuring-isatap-router-windows-server-2008-r2-part2.html

      Delete
    2. Thanks, can you expand on that at all? Is it even possible?

      Delete
    3. Not really, as I don't have any specific experience. Multi-site DA has only recently become possible with DirectAccess 2012 so it is still quite early in terms of practical multi-site experience...

      Delete
    4. P.S. With DirectAcces 2012 multi-site, MS are not recommending the use of ISATAP anyhow and say people should be using native IPv6.

      Delete
  13. A couple of questions:

    1) Which machines need to go into the ManageOut group? Obviously the machines that will be outside the perimeter, but you seem to imply that servers will need to be in it as well.

    2) I'm managing a transition from an older server to a newer server with UAG on Win2k8 R2 for both. The old implementation uses isaptap.example.com, and I've set up us-isatap.example.com as a replacement, but isatap.example.com can't go away while I'm setting up the newer machine. In light of question 1), how might you handle this?

    Thanks,

    Kurt

    ReplyDelete
    Replies
    1. Hey Kurt,

      A1: Any machine that needs to initiate an outbound IPv6 connection with a DA client will need to be in the group. This could include internal client or internal servers; but should not include the UAG servers themselves.

      A2: The two solutions should co-exist just fine as clients that don't receive the GPO will just use the default FQDN. Those clients that do receive the GPO will use the custom FQDN. This is the beauty of using this method as it is client targeted.

      Delete
  14. OK - trying to wrap my head around this...

    So, my Win2k8R2 DCs need to be in it, as well as my WSUS, Antivirus and other servers? Won't that interrupt communication with the old installs?

    Kurt

    ReplyDelete
    Replies
    1. No, manage out is all about "outbound initiated" connections when you want to use RDP or remote assitance to reach your DA clients. This is nomrally only needed from servers like SCCM servers or terminal servers than run your management tools. If you just need to access DA clients from a couple of internal machines to "manage out" to them, then just add these to the ISATAP GPO group.

      Things like WSUS are actually inbound as the clients "pulls" data from the server and opposed to the server "pushing" out...

      Hope that helps!

      Delete
  15. OK - that makes decent sense. I don't think we'll need to probe for new machines from the AV server, or things like that.

    Thank you for the explanation.

    Kurt

    ReplyDelete
  16. Jason, I have a question regarding manage out clients.
    You said "DA 2012 MS recommended moving to native IPv6 not ISATAP", so if I get it right, I have to add IPv6 address to SCCM server.
    Example:
    da01 - 2002:c2f7:dc1a:3333::1
    sccm - 2002:c2f7:dc1a:3333::2

    Am I right? :)

    Tnx in advance

    ReplyDelete
    Replies
    1. Yes, you need to provide static IPv6 addressing as appropriate for your network. This assumes your network is IPv6 ready of course...

      Delete
  17. Hi Jason
    I am planning to deploy DA in. 2 sites in the US and UK and they are on the same single domain.
    Is it possible to create 2 DNS entries for ISATAP, say usisatap.xxx.com and ukisatap.xxx.com and filter the gpo to the the relevant machines that require to manage out depending on where they are located to ensure they use their local DA server?

    ReplyDelete
  18. Yes, that will allow you to ensure that clients receive the ISATAP address from a known (closer) location, but it doesn't guarantee that traffic will exit from the correct gateway and that is down to routing, not address selection...

    ReplyDelete
  19. Thanks Jason. It looks like the actual resolution is to implement border routers but I am looking for an easier way around this :-)

    Thanks

    ReplyDelete
  20. Thanks Jason...This worked just perfect!

    Bart Timmermans

    ReplyDelete
  21. Hi Jason

    Just testing this with 2012 DA. When enabling NLB the pre-req check ensures that ISATAP is present in DNS for all internal IP addresses.

    If you name the dns entry isatap.domain.com it doesn't recognise the name. Looks like you can only use the name ISATAP.
    Do you know if there is a work around such as renaming the DNS entry afterwards or just using the DNS name ISATAP but not enabling it on the DNS servers?



    Thanks

    ReplyDelete
    Replies
    1. Hmmm...maybe putting a ISATAP reference in the hosts file would be enough to trick/satisfy the pre-req checker...guess it depends on how thorough the test is...putting the native ISATAP DNS name with a fake IP address (to prevent clients from receiving addresses) may also be enough to pass the check...

      Delete
  22. Cheers Jason, I will test this.

    ReplyDelete
  23. Hello Jason,

    Excellent article! I have installed DA in a 2008R2 AD environment. We are using Win 7 ENT clients. It was very straight forward install. Shortly after installation our logon times increased to 3 -5 minutes internally. I fully suspected the ISATAP/DNS issue.

    I followed your article and the logon times returned to normal. Now my external DA clients now take 3 -5 minutes to logon and the shares no longer are present.

    One point is that our External Authorative DNS is no an AD DNS. It is hosted on a SUN server.

    Do you have any ideas?

    Thanks VERY much.

    ReplyDelete
    Replies
    1. ISATAP is irrelevant when the client is external, so shouldn't be that - what machines did you put into the management clients group as these normally wouldn't include the actual DA clients themselves...

      Delete
    2. Hello Jason,

      I have the Direct Access server and the Network Location Server. I don't have the AD/DNS or the File servers in there as I assumed that latency was due to AD/DNS servers were the issue.

      Should these servers be members?

      Thanks VERY much Jason...
      Todd

      Delete
  24. Hi,

    If you have a back firewall between corpnet and DA servers what do I need to configure for this to work.

    I belive its Protocol 41 but between which IP's? IP 6 IP's or IP 4?

    If I add the IPv4 helpdesk subnet with a destination to the internal IP4 nics of the DA servers will that do the trick?

    ReplyDelete
    Replies
    1. ISATAP is essentially IPV6 encapsulated in IPv4 so you need to define all ACLs using IPv4 addresses. Yes, IP protocol 41 is required through the back firewall between the management clients and the DA server internal interfaces.

      Delete
  25. I am trying to get domain isolation to work with DA but have no success.
    I Think the problem now is that DA server (2012) travers ipv6 to ipv4 and then the ipsec transport (isolation) fails.
    When I connect to internal host from DA client and do a netstat I see that the DA client Connection is established to internal host with the DA server IPv4 adress.

    regards Jonas

    ReplyDelete
    Replies
    1. Hi Jonas,

      In DirectAccess 2012, when using ISATAP, you need to enable AAAA queries for DNS64 with the PowerShell cmdlet, Set-NetDnsTransitionConfiguration -OnlySendAQuery $false

      This may be the cause of your problems...

      Cheers

      JJ

      Delete