We’ve been replacing all our WS2012R2 DCs with WS2016 DCs. A non-Windows platform application which performs LDAPS queries against AD had a breaking issue. That application leverages a JDK library to establish the TLS connection (for LDAPS) with a domain controller.
See https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server for Microsoft details on the newly added crypto ciphers. An interesting detail is that the preferred crypto cipher for WS2016 is still in draft status! Presumably it was chosen because it is significantly faster than the other new/strong ciphers.
The exact details of the known problem are still a bit sketchy, so I can’t share that level of detail definitively. The facts are that both WS2016 server and JDK client have ciphers in common, but a mutually supported cipher is not negotiated (whereas a WS2012R2 server with the same JDK client does negotiate successfully). The JDK team has an issue tracking this which they have resolved based on wire-level examination showing that the WS2016 server doesn’t properly do TLS cipher negotiation: https://bugs.openjdk.java.net/browse/JDK-8178429.
So we looked to find a solution. We are aware that the ‘bouncy castle’ provider (instead of JDK) has been used in similar situations. Our working hypothesis was that WS2016 is just overzealous in negotiation when the newer ciphers are enabled or suggested first.
Our testing showed that switching the order so that the cipher still in draft status is not first was enough to allow the JDK based client to negotiate, which seems to support that hypothesis.
We rolled an order switch out, and plan to keep that in place for 6 months when the dependent application will be retired.
Some related links:
- TLS changes for WS2016: https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server
- Slightly dated broad overview of Windows cipher support: https://blogs.technet.microsoft.com/askds/2015/12/08/speaking-in-ciphers-and-other-enigmatic-tonguesupdate/
- Additional detail on WS2016 ciphers: https://msdn.microsoft.com/en-us/library/windows/desktop/mt490158.aspx
- Additional detail on Windows ciphers (not OS version specific): https://msdn.microsoft.com/library/windows/desktop/aa374757.aspx
- Someone with similar error: https://bugs.openjdk.java.net/browse/JDK-8178429
- Relevant tracked enhancement in JDK backlog: https://bugs.openjdk.java.net/browse/JDK-8171279
- Similar JDK error, solved by adding ‘bouncycastle’ provider:
- Oracle Java TLS overview: https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https