No news regarding this unfortunately. I guess it will be a wait and see kind of thing.
Microsoft pushed the deployment to March 2020 though.
Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.
A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.
I'm trying to keep a blog up to date on this.
On several sources I see this text:
If your identity sources are configured as “Active Directory (Windows integrated)” or “LDAPS” you don’t need to change anything.
However, that's how our Vcenter is configured and I still see the following events:
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
Client IP address:
Identity the client attempted to authenticate as:
(The IP address, domain and computer account have been anonymised)
It seems to me that we still need to change something to address this.
I built a lab specifically to test all these things and indeed the windows integrated still generates 2889 events now and again but it does work.
You shouldn't see anything with LDAPS though.
The news from Microsoft and the statement from VMware is delaying the inevitable. The big question is how do we make this work with LDAPS on vcenter? No one wants to have to deal with this again in the 2nd half of 2020. Come on VMware...quit being so damn obscure.
I, too, can't seem to properly get the exported LDAPS cert from my DC (verified working LDAPS) to import into vCenter to even attempt an LDAPS bind. Getting the dreaded Check the network settings and make sure you have network access to the identity source.
Is there a trick to the cert needing to be imported? I'm just exporting the LDAPS one from my DC. Do we need a private key (pfx), or not (cer)? Maybe that's incorrect...
The only thing VMware is being a little bit obscure about is the fact that Windows Integrated still generates 2889 events.
However it still works with channel binding and LDAP signing enabled.
This blog details very well how to retrieve the certificate.
You don't need the private key of course, just retrieve the certs on all DCs and add them to the identity source.