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.
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
Christopher Pigno
/ September 1, 2017Thanks 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!!!
Roshan Kumar
/ November 20, 2018I 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.
Richard M. Hicks
/ November 20, 2018That’s expected, and why it isn’t generally recommended that you disable TLS 1.0 on a DirectAccess server.
Roshan Kumar
/ November 22, 2018Thankyou 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 ?
Richard M. Hicks
/ November 23, 2018It 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, 2018yes 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.
Richard M. Hicks
/ November 29, 2018You may have to enable TLS 1.0 to fully restore DirectAccess functionality.
nomail@me.com
/ May 1, 2019Enable FIPS also enable (override) disable TLS 1.0 so “solution” is WRONG…
Richard M. Hicks
/ May 2, 2019Incorrect. 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.
Wins Pug
/ January 31, 2020Now this FIPS does not work as we used IIS Crypto with Strict template.
Richard M. Hicks
/ February 3, 2020It 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. 🙂