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.
[email protected]
/ 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. 🙂
Charles
/ March 24, 2021Hi M. Hicks,
I used DirectAccess (windows server 2012) in my organisation, it works properly.
But sometimes. I have The Connection client VPN interrupted for a few seconds (more or less 2 seconds)., but it comes back after.
I have checked the event viewer, I don’t find anything.
Did you have any idea ?
Thank you!
Richard M. Hicks
/ March 24, 2021This could be caused by any number of things. Most commonly it is due to loss of underlying network connectivity. For example, moving from one Wi-Fi AP to another or switching from Wi-Fi to LTE. It could also be caused by interruption in network connectivity anywhere in the path.
Charles
/ March 25, 2021This is arriving when you connect RDP via VPN direct Access,
The connection RDP is frozen for a few seconds( you can’t do it anything thing).
You can close the connection RDP and connect at new , but i think is not good solution .
This is problem arrived at different client when they used DirectAccess,
But with other VPN (OpenVpn,forticlient), I don’t have this problem.
Thank you!
Charles
/ March 25, 2021Sorry, i have found this error in the event Viewer
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.
Perhaps it’s this error cause my problem ?
Richard M. Hicks
/ March 25, 2021It’s possible, although I see that error commonly even when there are no issues at all.
Charles
/ March 29, 2021I have TLS1-1 and TLS 1-0 disabled in my Server
My DirectAccess use only TLS1-2.
I have this error type schannel:
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
Perhaps, i need to activate TLS1-1 ? what you think ?
Richard M. Hicks
/ April 1, 2021It does, absolutely. I came across this earlier this week on Windows Server 2019. Disabling TLS 1.0 and 1.1 does indeed break reporting. You’ll have to enable them to get reporting to work, unfortunately.