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

Leave a comment


  1. Thanks for the post! I was chasing my tail on this error. I saw the errors in eventvwr and didn’t think about the cryptography after running IISCrypto. I was leaning towards Microsoft putting out a bad update. So Thank You!!!

  2. Roshan Kumar

     /  November 20, 2018

    I have enabled this policy but then too i am unable to generate report. Also tried with Command Get-RemoteAccessConnectionStatistics –StartDateTime “1 November 2018 12:00” –EndDateTime “18 November 2017 12:00” | Export-Csv –Path “C:\Temp\DAConnections.csv” but getting an error unable to read or write from database.

  3. Roshan Kumar

     /  November 22, 2018

    Thankyou Richard but i thought if we disable the TLS 1.0 and then apply the above GPO, the reporting should work as expected. Is this correct ?

    • It should, unless something has changed since I wrote this. I haven’t tested this in quite a while and to be honest, this is why it is strongly discouraged to disable TLS 1.0 on Windows Server 2012. 🙂

      • Roshan Kumar

         /  November 26, 2018

        yes thanks Richard,we disabled TLS 1.0 about one month ago but this issue raised few days back with the same error code in the event viewer. so is their any other reason for the same or i have enable the TLS 1.0.

      • You may have to enable TLS 1.0 to fully restore DirectAccess functionality.


     /  May 1, 2019

    Enable FIPS also enable (override) disable TLS 1.0 so “solution” is WRONG…

    • Incorrect. Disabling TLS 1.0 on its own causes the failure. However, enabling FIPS does work even though it also disables TLS 1.0. It still isn’t a recommended solution because of the additional negative side effects, but it does work.

  5. Wins Pug

     /  January 31, 2020

    Now this FIPS does not work as we used IIS Crypto with Strict template.

    • It has been quite a while since I tested this. I would not be surprised if something changed and the workaround failed. However, I advise against using this workaround anyway, so it’s probably for the best. 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: