Enable Teredo Support after DirectAccess Has Been Configured

DirectAccess leverages IPv6 transition protocols to enable clients to connect to the DirectAccess server when both are located on the IPv4 Internet. When the DirectAccess server is located in a perimeter or DMZ network behind a NAT device, only the IP-HTTPS IPv6 transition protocol is used. When the DirectAccess server is edge facing with public IPv4 addresses assigned to the external interface, the 6to4 and Teredo IPv6 transition protocols are also supported.

Note: It is generally recommended that the 6to4 IPv6 transition protocol be proactively disabled. More details here.

To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. When you configure DirectAccess for the first time, Teredo will automatically be configured if the installation detects the proper requirements for it. If you neglect to add the second consecutive public IPv4 address to the external network interface and configure DirectAccess, the installation will complete successfully without enabling Teredo support and Teredo will not appear in the list of services operations status, as shown here.

Enable Teredo Support after DirectAccess Has Been Configured

To enable Teredo support after you’ve configured DirectAccess, add the second consecutive public IPv4 address to the external network interface and then execute the following PowerShell command from an elevated command prompt.

Set-DAServer –TeredoState Enabled

Enable Teredo Support after DirectAccess Has Been Configured

Once complete, you’ll receive a warning message that states:

WARNING: Two consecutive IPv4 addresses have been detected on the Remote Access server, and Teredo is enabled. To use Teredo, ensure that internal servers allow inbound ICMP traffic.

Teredo requires that ICMPv4 Echo Requests be allowed inbound to any Intranet resource that a DirectAccess client will access. Ensure that all firewalls (host and network) are configured to allow ICMPv4 Echo Request inbound and outbound to ensure proper Teredo operation.

Once complete, close and then reopen the Remote Access Management console (in some cases a server restart may be required) to confirm Teredo support.

Enable Teredo Support after DirectAccess Has Been Configured

Hotfix Available for DirectAccess OTP Configuration Issues

If you’ve ever tried configuring DirectAccess to use One-Time Password (OTP) authentication, you’ve no doubt discovered that the native Microsoft Remote Access Management console would return the following error when trying to detect and locate Certificate Authority (CA) servers.

No CA servers can be detected, and OTP cannot be configured. Ensure that
servers added to the list are available on each domain controller in the
corporate network.

Configure DirectAccess with OTP Authentication

The workaround for this issue required dropping to the command line and executing PowerShell commands to complete this configuration as I outlined here.

Thankfully Microsoft has made available a hotfix to address this issue, returning full GUI functionality for configuring DirectAccess and OTP authentication. For additional details about this hotfix and to request the update itself, click here.

Critical Update MS15-034 and DirectAccess

Microsoft Security Bulletin MS15-034 Vulnerability in HTTP.sys affects DirectAccessThe April 2015 monthly security update release from Microsoft includes a fix for a serious vulnerability in HTTP.sys. On an unpatched server, an attacker who sends a specially crafted HTTP request will be able to execute code remotely in the context of the local system account. DirectAccess leverages HTTP.sys for the IP-HTTPS IPv6 transition protocol and is critically exposed. Organizations who have deployed DirectAccess are urged to update their systems immediately.

More information can be found on MS15-034 here.

Monitoring DirectAccess Machine and User Activity with Windows Component Event Logging

Monitoring DirectAccess Machine and User Activity with Component Event LoggingThe monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is not visible using the native reporting tools. In addition, vital information such as source ports used by the DirectAccess server for internal connections and source ports used by DirectAccess clients is not available. This lack of granular connection logging creates a serious blind spot for administrators conducting forensic investigations.

As veteran Microsoft Premier Field Engineer (PFE) Martin Solis described in detail in a recent blog post, all of these details are in fact logged. However, gathering this information is not exactly intuitive. To collect this essential information it will be necessary to leverage Windows component event logging. By searching the IPHLPSVC, Base Filtering Engine Connections, Base Filtering Resource Flows, and WinNAT operational logs, it is possible to gather all of the information necessary for uniquely identifying DirectAccess corporate network communication.

Be sure to read Martin’s excellent article about using Windows component event logging to monitor DirectAccess machine and user activity, which can be found here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

Last year I wrote about Microsoft hotfix KB2953212 that that allowed users to disable the Name Resolution Policy Table (NRPT) on a DirectAccess client. This hotfix addressed a specific scenario where a DirectAccess client on the internal corporate network could not connect to local resources due to Network Location Server (NLS) unreachability.

When installing this update, you many encounter the following error message:

Windows Update Standalone Installer
The update is not applicable to your computer

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

This occurs because the KB2953212 hotfix was included in KB3000850, the November 2014 update rollup for Windows 8.1 and Windows Server 2012 R2. You can verify this by opening the Control Panel and selecting Programs and then clicking View installed updates under Programs and Features.

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

If you have the November 2014 update rollup installed there is no need to install KB2953212, as that hotfix is already included in the rollup.

DirectAccess NLS Deployment Considerations for Large Enterprises


For a DirectAccess deployment, the Network Location Server (NLS) is an infrastructure component that allows DirectAccess clients to determine if they are inside or outside of the corporate network. If the DirectAccess client can successfully connect to the NLS, it is on the internal network and DirectAccess is not used. If the NLS cannot be contacted, the client is outside of the network and will attempt to establish remote corporate network connectivity using DirectAccess.

High Availability

It is recommended that the NLS be made highly available by deploying at least two servers in a load balanced configuration to avoid potential service disruptions for DirectAccess clients inside the corporate network. While this approach is sufficient for networks that are contained in a single physical location, it does present some challenges for large organizations with internal networks that span multiple physical locations.

NLS Challenges

For DirectAccess, only a single NLS URL can be configured per DirectAccess deployment, as shown here.

DirectAccess NLS Deployment Considerations for Large Enterprises

If a WAN outage occurs on an internal network that spans multiple physical locations, internal DirectAccess clients in locations other than where the NLS resides will mistakenly believe they are outside of the corporate network. This can lead to degraded performance and potential loss of connectivity. NLS reliability can still be improved when the internal network spans multiple physical locations by deploying NLS at each physical location and configuring clients to use a local NLS. This will keep traffic off of the WAN and prevent service disruptions in the event of a WAN outage.

Redundant NLS

There are several strategies that can be used to configure internal DirectAccess clients to use a local NLS, including DNS round robin, a network load balancer, or Active Directory Group Policy. Using DNS or a load balancer requires only a single NLS URL. Using Active Directory Group Policy requires a unique NLS URL per physical location.


The simplest way to enable DirectAccess clients to use a local NLS is to use DNS round robin and take advantage of subnet prioritization. To do this, create an “A” resource record in DNS that resolves to the IPv4 address for each NLS. On the DNS server, open the DNS Manager, right-click the DNS server and choose Properties. Click the Advanced tab and select the options to Enable round robin and Enable netmask ordering.

DirectAccess NLS Deployment Considerations for Large Enterprises

This will ensure that name resolution requests for the NLS FQDN will be returned with the nearest NLS. More information about DNS netmask ordering can be found here.

Load Balancer

A Global Server Load Balancing (GSLB) solution can also be employed to route requests to a local NLS. Examples include F5 Global Traffic Manager (GTM) and Kemp Technologies LoadMaster GEO. Prescriptive guidance for configuring the Kemp LoadMaster for this scenario can be found here.

Group Policy

This method involves creating unique NLS URLs per site and overriding the default DirectAccess client configuration using Active Directory Group Policy. Separate Group Policy Objects (GPOs) are created and linked to Active Directory Sites to assign a local NLS to internal DirectAccess clients. To accomplish this, create a new GPO for each location where NLS will reside. Edit the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator. Double-click Specify domain location determination URL, choose Enabled, and then enter the URL that corresponds to the NLS for that location.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Remote Access Management Console, edit the Infrastructure Server Setup (Step 3) and add the FQDN for each NLS. Do not specify a DNS server. This effectively creates a Name Resolution Policy Table (NRPT) exemption so the NLS cannot be reached when the DirectAccess client is connected remotely.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Group Policy Management Console right-click on Sites and choose Show Sites.

DirectAccess NLS Deployment Considerations for Large Enterprises

Select each Active Directory site where NLS will reside.

DirectAccess NLS Deployment Considerations for Large Enterprises

Link the GPOs for each NLS to the corresponding site, then right-click the linked GPO and choose Enforced.

DirectAccess NLS Deployment Considerations for Large Enterprises

Note: Do not install the NLS on a domain controller! By design, the NLS is not reachable remotely by DirectAccess clients. This can lead to potential authentication issues and may prevent DirectAccess clients from connecting successfully.

Client Testing

To confirm that a client computer has been configured to use a local NLS, verify the currently associated Active Directory site by issuing the following command on the DirectAccess client computer:

nltest /dsgetsite

Next, confirm the setting of the NLS by issuing the following command:


As a reference, here are examples from two DirectAccess clients in two different internal physical locations:

DirectAccess NLS Deployment Considerations for Large Enterprises

DirectAccess NLS Deployment Considerations for Large Enterprises


The limitation of a single Network Location Server (NLS) URL for a DirectAccess deployment presents some challenges for DirectAccess architects seeking to eliminate single points of failure in their design. Using the techniques described in this article, administrators can ensure that DirectAccess clients will always connect to a local NLS, eliminating potential failure points and improving the overall reliability of the solution.

Windows Server 2012 R2 Administrator Cookbook

win_2012_r2_admin_cookbook_jkrauseRecently I had the opportunity to read Jordan Krause’s new book Windows Server 2012 R2 Administrator Cookbook. If the name of the author sounds familiar, it’s because Jordan is also the author of the popular Microsoft DirectAccess Best Practices and Troubleshooting title, both published by Packt Publishing.

If you’re new to Windows Server 2012 R2 and you’re looking for a good entry-level administrator’s guide, this is an excellent choice. The cookbook series is ideally suited to deliver clear, concise guidance for specific administrative tasks. The book provides a high level overview of nearly all aspects of the operating system, including configuring and administration using the server manager and PowerShell for DHCP, DNS, Active Directory, security, networking, remote access, IIS, certificate services (PKI), and much more.

For more information about Jordan’s book, including a free sample chapter, click here.

%d bloggers like this: