Use newer protocol versions for remote DCOM WMI
Description
Acceptance / Success Criteria
Lucidchart Diagrams
Activity
David Schlenk August 27, 2020 at 7:08 PM
David Schlenk July 13, 2020 at 7:30 PM
I would also point out that very few tests exist for any of this stuff, so beyond the risk presented to TLS operations by the bouncycastle dependency it is probably Very Prudent to do some hands-on testing of each component touched. Happy to assist with that in whatever way I can. In real world testing I can confirm that WMI data collection works, but I haven't done any real world tests of WmiMonitor/detector, SmbMonitor/detector, JcifsMonitor or anything radius related.
Jeff Gehlbach July 7, 2020 at 3:57 PM
We're pulling this issue into the backlog for eng review, but I want to register an important concern about the implementation in the PR.
We excluded out a bunch of implied bouncycastle dependencies years ago because their presence in the classpath was masking JDK-provided JCE classes in some cases, resulting in TLS operations breaking when large key sizes were involved. See for details.
If we do merge this PR, let's be extremely careful to avoid a regression.
David Schlenk July 3, 2020 at 1:55 AM
Ended up being a little more involved to get the JCIFS and SMB monitors to work with the API changes but anyway it's PR #3058. Implementation notes:
the radius monitor was using the JCIFS implementation of MD4 which jcifs-ng removed in favor of BouncyCastle's implementation. No idea if that change actually works!
There's a lot more control over things like timeouts and such in jcifs-ng as you can use different contexts when you're doing different things. Generally speaking I just use the default BaseContext, except for the JCifsMonitor, where I replaced the brute forced implementation of timeout control with the use of a customized context. Cool! Except that timeouts are not behaving like they should. There seems to be a floor of about 5 seconds no matter the timeout you give it, and increasing the timeouts just adds onto that floor. I don't know if this is a big deal or not but I had to adjust the limit on the tests to get them to pass as a result of this behavior.
Yeah I know who in their right mind would care what the remote DCOM WMI code does in the year 2020 but also currently it has two significant deficiencies that are pretty easily rectified:
As is, it uses NTLMv1 for authentication and NTLMv2 for sessions. I didn't know that was possible either, but I found this document helpful in understanding what the various options for NTLM are. Fortunately, turning on full NTLMv2 support involves adding a single line to WmiClient.
Additionally, the version of j-interop and jcifs in use utilize SMBv1 which folks are encouraged to disable and which is no longer installed by default in Server 2016. Fortunately somebody else has already patched them to use SMBv2 and it works pretty okay-ish just by swapping out the jars. A small modification to WmiManager makes it work more betterer, as hosts return an error code about a lack of pipes being available (0x000000AC) when they haven't been queried in awhile, but immediately retrying is successful in every instance I've seen thus far. Will be submitting a PR for this shortly.