Symptoms:
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.
In August 2019 Microsoft released guidance to Microsoft Active Directory (AD) administrators around hardening configurations for LDAP channel binding & LDAP signing on their AD domains. On February 4, 2020 Microsoft announced that the defaults would not be changing but recommended that customers enable diagnostic event logging in their AD implementations to identify where hardening might be needed.
When this type of logging is enabled, a client that attempts certain types of LDAP binds to the directory server will cause a log event with Event ID 2889 to be generated on that directory server. The event text will appear similar to the text listed in the “Symptoms” section of this article.
When vCenter Server is configured with IWA as the identity source it uses GSSAPI & Kerberos to authenticate users, and uses credential sealing with SASL to protect credentials. As such, it is not sending credentials in the clear.
In addition to authentication, in IWA configuration, the product queries Active Directory via LDAP on port 389/tcp for other, non-credential data, such as group membership and user properties. It uses sealing (encryption) to satisfy the protection against the MIM attack, but Windows logs Event ID 2889 anyway. For more details, see the section Logging anomaly of Event ID 2889 in Microsoft's article How to enable LDAP signing in Windows Server.
VMware is investigating methods to prevent Event ID 2889 binding type from being generated for IWA configurations.
As mentioned in the "Cause" section, Event ID 2889 is generated as an anomaly rather than a security risk when using IWA. The following options are available for strict requirements to remove any generation of Event ID 2889.
Usage of LDAPS meets the Microsoft criteria for a signed request, so 2889 events will no longer be logged. It also uses TLS to secure the authentication communications between vCenter Server and AD, improving overall security. Please refer to Configuring a vCenter Single Sign-On Identity Source using LDAP with SSL (LDAPS) for more information.
This enables vCenter Server to securely participate in enterprise identity management systems that have Microsoft Active Directory Federation Services enabled. More information can be found in VMware's blog about Identity Federation.