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.
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.”
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.
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 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.
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.
The 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.
DirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.
