DirectAccess Manage Out and System Center Configuration Manager (SCCM)

The seamless and transparent nature of DirectAccess makes it wonderfully easy to use. In most cases, it requires no user interaction at all to access internal corporate resources while away from the office. This enables users to be more productive. At the same time, it offers important connectivity benefits for IT administrators and systems management engineers as well.

Always Managed

DirectAccess Manage Out and System Center Configuration Manager (SCCM)DirectAccess clients are automatically connected to the corporate network any time they have a working Internet connection. Having consistent corporate network connectivity means they receive Active Directory group policy updates on a regular basis, just as on-premises systems do. Importantly, they check in with internal management systems such as System Center Configuration Manager (SCCM) and Windows Server Update Services (WSUS) servers, enabling them to receive updates in a timely manner. Thus, DirectAccess clients are better managed, allowing administrators to more effectively maintain the configuration state and security posture for all their managed systems, including those that are predominantly field-based. This is especially crucial considering the prevalence WannaCry, Cryptolocker, and a variety of other types of ransomware.

DirectAccess Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)When manage out is configured with DirectAccess, hosts on the internal network can initiate connections outbound to remote connected DirectAccess clients. SCCM Remote Control and Remote Desktop Connection (RDC) are commonly used to remotely connect to systems for troubleshooting and support. With DirectAccess manage out enabled, these and other popular administrative tools such as VNC, Windows Remote Assistance, and PowerShell remoting can also be used to manage remote DirectAccess clients in the field. In addition, enabling manage out allows for the proactive installation of agents and other software on remote clients, such as the SCCM and System Center Operation Manager (SCOM) agents, third-party management agents, antivirus and antimalware software, and more. A user does not have to be logged on to their machine for manage out to work.

IPv6

DirectAccess manage out requires that connections initiated by machines on the internal network to remote-connected DirectAccess clients must be made using IPv6. This is because DirectAccess clients use IPv6 exclusively to connect to the DirectAccess server. To enable connectivity over the public IPv4 Internet, clients use IPv6 transition technologies (6to4, Teredo, IP-HTTPS), and IPv6 translation components on the server (DNS64 and NAT64) enable clients to communicate with internal IPv4 resources. However, DNS64 and NAT64 only translate IPv6 to IPv4 inbound. They do not work in reverse.

Native or Transition?

It is recommended that IPv6 be deployed on the internal network to enable DirectAccess manage out. This is not a trivial task, and many organizations can’t justify the deployment for just this one specific use case. As an alternative, IPv6 can be configured with an IPv6 transition technology, specifically the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). ISATAP functions as an IPv6 overlay network, allowing internal hosts to obtain IPv6 addresses and routing information from an ISATAP router to support manage out for DirectAccess clients.

ISATAP

When DirectAccess is installed, the server is automatically configured as an ISATAP router. Guidance for configuring ISATAP clients can be found here. Using ISATAP can be an effective approach to enabling DirectAccess manage out for SCCM when native IPv6 is not available, but it is not without its drawbacks.

• Using the DirectAccess server for ISATAP is only supported with single server DirectAccess deployments.
• Using the DirectAccess server for ISATAP does work when using Network Load Balancing (NLB) with some additional configuration, but it is not supported.
• Using the DirectAccess server for ISATAP does not work when an external load balancer is used, or if multisite is enabled.

ISATAP with Load Balancing and Multisite

It is technically possible to enable DirectAccess manage out for SCCM using ISATAP in load-balanced and multisite DirectAccess deployments, however. It involves deploying a separate ISATAP router and some custom configuration, but once in place it works perfectly. I offer this service to my customers as part of a consulting engagement. If you’re interested in restoring DirectAccess manage out functionality to support SCCM remote control, RDC, or VNC in load-balanced or multisite DirectAccess deployments, fill out the form below and I’ll provide you with more information.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments
DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
Video: Windows 10 DirectAccess in action (includes manage out demonstration)

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course on Pluralsight

Planning and Implementing DirectAccess with Windows Server 2016I’m pleased to announce my newest video training course, Managing and Supporting DirectAccess with Windows Server 2016, is now available on Pluralsight! This new course is a follow-up to my previous course, Planning and Implementing DirectAccess with Windows Server 2016. This latest course builds upon the first one and covers advanced configuration such as enabling load balancing, configuring geographic redundancy, and enforcing strong user authentication using one-time passwords (OTP) and smart cards.

In addition, monitoring and reporting is covered, as well as implementing manage out for DirectAccess clients in supported scenarios. The course also includes a full hour of in-depth DirectAccess configuration and connectivity troubleshooting that will be valuable for all DirectAccess administrators.

The course includes the following training modules:

Configuring High Availability
Enabling Strong User Authentication
DirectAccess Monitoring and Reporting
Implementing Outbound Management for DirectAccess Clients
DirectAccess Troubleshooting

Throughout the course, I share valuable knowledge and insight gained from more than 5 years of experience deploying DirectAccess for some of the largest organizations in the world. Pluralsight offers a free trial subscription if you don’t already have one, so watch my latest DirectAccess video training course today!

Additional Resources

Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Managing and Supporting DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Note: The issue described in this article has been resolved in Windows 10 version 1703 (Creators Update). Making these changes is no longer required after installing the Creators Update release of Windows 10.

Introduction

For organizations that have implemented DirectAccess manage out using the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), you may find connecting to remote DirectAccess clients by hostname using Windows 10 or Windows Server 2016 fails. Connections to remote DirectAccess clients using Windows 7, Windows 8.x, Windows Server 2008/2008R2, and Windows Server 2012/2012R2 work without issue.

Troubleshooting

On a Windows 10 or Windows Server 2016 host configured to use ISATAP for DirectAccess manage out, the remote DirectAccess client resolves to an IPv6 address correctly.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

In addition, a route to the DirectAccess client’s IPv6 prefix is also present in the routing table.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Nevertheless, attempts to connect to the remote DirectAccess client by name fail.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

The DirectAccess client is reachable by its IPv6 address, however.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Known Issue

There is a known issue with Windows 10 and Windows Server 2016 DNS client that prevents manage out using ISATAP on these operating systems from working correctly. A while back I wrote about implementing some registry entries as a workaround for this issue on Windows 10. Recently, Karsten Hentrup brought another effective workaround to my attention that also involves adding a registry entry on the ISATAP client machine. This method is preferred as it requires only one registry entry and does not adversely affect existing DNS operation. To make this change, on each machine that requires DirectAccess manage out functionality open an elevated PowerShell command window and run the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force

Summary

When using ISATAP, ensure that this workaround is implemented on any Windows 10 or Windows Server 2016 machine that will require manage out functionality to remote DirectAccess clients.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Implementing DirectAccess with Windows Server 2012 R2 Book

DirectAccess Consulting Services

ISATAP Recommendations for DirectAccess Deployments

ISATAP Recommendations for DirectAccess DeploymentsFrom a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the internal network, the DirectAccess servers uses two important protocol translatorsDNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients.

ISATAP

To support outbound communication originating from the Intranet to connect DirectAccess clients, the DirectAccess server is configured as an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router. ISATAP is an IPv6 transition technology that allows hosts on the intranet to initiate outbound communication to DirectAccess clients on the Internet by tunneling IPv6 communication over the internal IPv4 network.

ISATAP can be enabled by populating internal DNS with a host record called ISATAP that resolves to the IPv4 address assigned to the Internal network adapter on the ISATAP router, in this case the DirectAccess server (don’t forget to remove ISATAP from the DNS global query block list!). When a client resolves ISATAP to an IP address successfully, it enables an ISATAP tunnel adapter and assigns itself an ISATAP IPv6 address. Once enabled, any host with an ISATAP tunnel adapter configured can initiate outbound communication to DirectAccess clients on the Internet.

Important note: It is not recommended to deploy ISATAP globally via DNS. See below for more details.

When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk administrator can proactively initiate a remote desktop session to a remote client connected via DirectAccess to troubleshoot an application. Systems management engineers can push software out to DirectAccess clients without requiring an agent on the remote client to “phone home” to receive software updates. This model is often referred to as “manage out”.

Limitations

In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISATAP as described above was standard operating procedure. However, we soon learned that there are some serious drawbacks to deploying ISATAP. While the DirectAccess manage out scenario is an important and frequently requested feature of a DirectAccess implementation, it often causes more trouble than it solves. In its default configuration, ISATAP is a global change that affects all hosts that can resolve the hostname ISATAP to an IP address. The challenge here is that this change can break or impair normal network communication for some hosts on the Intranet. For example, if an internal host is able to resolve a public hostname to an IPv6 address, it may attempt to connect to the site via ISATAP.

Unfortunately, in this scenario ISATAP does not lead to the public Internet. Rather, ISATAP is used to provide network connectivity exclusively for our DirectAccess clients. Since IPv6 is preferred in most modern operating system’s networking stacks, it can lead to failed or seriously delayed communication to Internet resources. In addition, once ISATAP is enabled globally there will be a lot of IPv6 communication taking place on the network, which in large enterprise networks can be a source of confusion for those individuals with the responsibility for monitoring the network.

ISATAP also suffers from a lack of robust monitoring tools for this very essential service. Additionally, ISATAP turns the OSI model upside down. ISATAP relies on upper-layer protocols (DNS) to provide its service. If there are issues with DNS that prevent proper name resolution, ISATAP routing will cease to function, which is fundamentally backward.

Targeted Deployment

ISATAP Recommendations for DirectAccess DeploymentsAs I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you deploy IPv6 on any internal systems that will participate in any DirectAccess manage out scenarios. Unfortunately this will not be possible in many cases, as additional network changes are often required to support IPv6 on the Intranet. In these cases we recommend that instead of configuring ISATAP in DNS globally, you target individual systems for ISATAP configuration as required. This can be accomplished in a number of ways.

Group Policy

This is recommended way to deploy ISATAP settings to systems that require DirectAccess manage out functionality. It is the easiest to manage and the most scalable as well. A unique ISATAP hostname (for example, DirectAccess-ISATAP) is created in the internal DNS that resolves to the internal IPv4 address of the DirectAccess server. Create a new GPO in Active Directory to assign it to management workstations using security group filtering or OU targeting. Edit the GPO setting Computer Configuration > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set ISATAP State (Enabled and set to Enabled State) and > Set ISATAP Router Name (Enabled and enter the ISATAP hostname created previously).

ISATAP Recommendations for DirectAccess Deployments

PowerShell

Using PowerShell is an alternative method of configuring an individual system to use ISATAP. Although not as scalable as the group policy method, it is still very effective. On the system that requires network connectivity to DirectAccess clients, open an elevated PowerShell command window and run the following command:

Set-NetISATAPConfiguration -Router <NameOrIPAddress>

Netsh

Another command line method for configuring the ISATAP is to use netsh.exe. In an elevated command prompt window run the following command:

netsh interface isatap set router <NameOrIPAddress>

HOSTS File

This is the least desirable way to configure ISATAP, but I’ll mention it here because it is quick and simple and does work. On any system that requires ISATAP for DirectAccess manage out, simply edit the HOSTS file in C:\Windows\System32\Drivers\Etc and add a host record for ISATAP that resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. Obviously this is the least scalable alternative and should only be used in test environments or very small production networks.

Supportability

ISATAP is only supported for single server DirectAccess deployments. ISATAP will work when Network Load Balancing (NLB) is enabled, but it requires some additional configuration. ISATAP does not work when an external load balancer is in use and/or multisite is enabled. To restore manage out functionality for DirectAccess for load-balanced and multisite deployments, additional infrastructure and configuration is required. Fill out the form below to request more information.

Summary

As you can see there are numerous drawbacks to configuring ISATAP on a global scale. Fortunately there are simple and effective workarounds that allow you to target specific systems for ISATAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!

Additional Information

Want to enable DirectAccess manage out for System Center Configuration Manager (SCCM) remote control or Remote Desktop Connection (RDC) in load-balanced and multisite deployments? Fill out the form below for more information.

%d bloggers like this: