DirectAccess Reporting Fails and Schannel Event ID 36871 after Disabling TLS 1.0

IMPORTANT NOTE: The guidance in this post will disable support for null SSL/TLS cipher suites on the DirectAccess server. This will result in reduced scalability and performance for all clients, including Windows 8.x and Windows 10. It is recommended that TLS 1.0 not be disabled on the DirectAccess server if at all possible.

When performing security hardening on the DirectAccess server it is not uncommon to disable weak cipher suites or insecure protocols such as SSL 3.0 and TLS 1.0. However, after disabling SSL 3.0 and TLS 1.0 you will find that it is no longer possible generate reports. Clicking the Generate Report link in the Remote Access Management console returns no data.

DirectAccess Reporting Fails after Disabling TLS 1.0

In addition, the System event log indicates Schannel errors with Event ID 36871. The error message states that “A fatal error occurred while creating a TLS client credential. The internal error state is 10013.”

DirectAccess Reporting Fails after Disabling TLS 1.0

To resolve this issue and restore DirectAccess reporting functionality you must enable the use of FIPS compliant encryption algorithms on the DirectAccess server. This change can be made locally or via Active Directory group policy. Open the Group Policy Management Console (gpmc.msc) for Active Directory GPO, or the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing and select Enabled.

DirectAccess Reporting Fails after Disabling TLS 1.0

If using Active Directory GPO, ensure that the GPO is applied all DirectAccess servers in the organization. A restart is not required for this setting to take effect. Once this change has been made, reporting should work as expected.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites
DirectAccess Video Training Courses on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book on Amazon.com

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)

← Back

Thank you for your response. ✨

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

DirectAccess Network Connectivity Assistant (NCA) Configuration GuidanceThe DirectAccess Network Connectivity Assistant (NCA), first introduced in Windows 8, provides DirectAccess connectivity status information as well as diagnostic support on the client. The NCA validates that DirectAccess is working end-to-end by attempting to reach internal resources defined by the administrator during the configuration of DirectAccess. NCA configuration and operation is a source of much confusion. This article serves to provide best practice configuration guidance for the NCA to ensure optimum and reliable operation.

NCA Operation

When a DirectAccess client is outside the corporate network, it will attempt to establish a DirectAccess connection any time it has an active Internet connection. After a DirectAccess connection is made, the NCA will attempt to validate DirectAccess connectivity by verifying availability of corporate resources as defined in the DirectAccess configuration (Remote Access Management console, Step 1, Edit, Network Connectivity Assistant).

If the NCA can reach the defined internal corporate resource(s), the DirectAccess connection is verified end-to-end and it will report the connection status as “Connected”. If it fails to connect to any internal corporate resource, it displays “Connecting”.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 1. NCA successfully validated internal corporate resource connectivity.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 2. NCA failed to connect to one or more corporate resources.

NCA Configuration

When first installing DirectAccess, the Remote Access Setup wizard will collect information to be used by the NCA, including corporate resources, helpdesk email address, and DirectAccess connection name. It will also provide the option to allow DirectAccess clients to use local name resolution.

Note: The NCA settings configured in the Remote Access Management console pertain only to Windows 8.x and Windows 10 clients. They are not used by Windows 7 clients at all.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Intuitively it would appear that information needs to be entered in the Resource and Type fields. However, it is recommended to leave this blank when first configuring DirectAccess. This is because the Remote Access Setup Wizard will automatically populate this field later. Specifying a resource during initial configuration will result in two entries being included, as shown here.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

As you can see, the Remote Access Setup wizard automatically added the resource directaccess-WebProbeHost.<internal domain.>. A corresponding DNS record is created that resolves this hostname to the internal IPv4 address of the DirectAccess server. In this configuration, the DirectAccess server itself serves as the corporate resource used by the NCA.

Multiple Corporate Resources

Having more than one resource to validate connectivity to the internal network is problematic though. If there are multiple entries specified, they must ALL pass a validation check from the client to report the connection status as “Connected”. Some administrators configure multiple entries with the mistaken belief that it will provide redundancy for the NCA, but it actually has the opposite effect. Having more than one entry only increases the chance of a false positive.

NCA Configuration Best Practices

It is recommended that only a single corporate resource URL be defined for the NCA. The default directaccess-WebProbeHost running on the DirectAccess server can be used, or, alternatively, another internal web server can be specified if desired. Any web server will work, including Microsoft Internet Information Services (IIS), Apache, NGINX, and most Application Delivery Controllers (ADCs) or load balancers. HTTPS is not required for the web probe host, only HTTP. If using an internal web server, ensure that it is highly available.

Do NOT use the Network Location Server (NLS) as a corporate resource! The NLS is exempted from the Name Resolution Policy Table (NRPT) on the client and is not reachable over DirectAccess. This will result in the NCA failing and reporting a “Connecting” status perpetually. In addition, avoid the use of PING for validating internal corporate resources. Ping uses ICMP which is inherently unreliable and commonly blocked by host and intermediary firewalls, making it an unreliable indicator of corporate network connectivity over DirectAccess.

Summary

The NCA is a crucial and often misunderstood component in the DirectAccess architecture. Follow the guidance outlined here to ensure that the NCA works reliably and effectively in your environment.

Additional Resources

DirectAccess Clients in Connecting State when using External Load Balancer
Planning and Implementing DirectAccess on Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book