Update (5/13/2020): This post has been updated to reflect current guidance on this topic, and that Integrated Windows Authentication is affected by this change. There is good information in this post but more information can be found in the post “vSphere Authentication, Microsoft Active Directory LDAP, and Event ID 2889.“
—-
Update (2/6/2020): On February 4, 2020 Microsoft changed their guidance for the March 2020 Windows Updates to indicate that the defaults will NOT be changing in that update.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
We are leaving this post active as a reference but will prune the comments to flag and/or reduce unsupported & dangerous advice and discussion.
We continue to reiterate that supported versions of VMware vSphere work correctly with both LDAP binding settings, our recommendation is always to use encryption to protect data in flight on a network, and changing vSphere outside of guidance from VMware Global Support Services is not recommended or condoned and may affect product functionality and supportability.
—-
Update (1/16/2020): Updates to reflect the results of Integrated Windows Authentication testing.
Microsoft has recently released warnings to its customer base that, in the March 2020 updates to Windows, it intends to change the default behavior of the Microsoft LDAP servers that are part of an Active Directory deployment. These changes will make secure LDAP channel binding and LDAP signing a default requirement when accessing Microsoft Active Directory using LDAP or LDAPS. These changes are a response to a security concern documented in CVE-2017-8563, where bad actors can elevate their privileges when Windows falls back to NTLM authentication protocols.
Any system that connects to Active Directory via LDAP without using TLS will be negatively affected by this change. This includes VMware vSphere. If you are using unencrypted LDAP (ldap://, not ldaps://) or Integrated Windows Authentication to connect vSphere to Microsoft Active Directory please read further.
All supported versions of VMware vSphere have been verified by VMware Engineering to work as expected after these changes, where we expect unencrypted LDAP authentication to succeed with the old defaults, fail with the new defaults, and succeed when using TLS/LDAPS.
Integrated Windows Authentication (IWA) has also been tested by VMware Engineering. IWA uses GSSAPI and Kerberos to authenticate and does not send credentials in the clear. However, IWA uses unsigned LDAP behind the scenes to allow searching users and groups, and this will stop working. This may impact the ability to add users & groups to authentication configurations. VMware KB 78644 discusses some of this, and VMware is investigating changes that may improve this situation.
Important Notes
These issues are the direct result of Microsoft’s changes to Windows. While we at VMware are committed to helping our customers navigate issues like these, we do ask that you please direct feedback about Windows changes & updates to Microsoft themselves. Configuring authentication sources in vSphere is a documented & supported activity that the professionals at VMware Global Support Services (GSS) can assist with, but that comes with the prerequisite that your authentication source is usable and cooperative. Please contact Microsoft Support for assistance with reconfiguring and and all aspects of Microsoft Active Directory.
These issues affect any system using LDAP to access Active Directory and are not limited to VMware vSphere. You need to check the rest of your systems, too. As part of the documentation for these changes Microsoft lists ways to audit clear-text connections to your Active Directory infrastructure which may be helpful.
All screen shots in this post are of vSphere 6.7 Update 3 and the HTML5 vSphere Client. The experience should be similar for vSphere 6.0 and 6.5.
All testing and documentation of vSphere assumes a direct connection between vSphere and the authentication sources. If your authentication sources are proxied or behind an application load balancer you will need to independently assess how you are affected by these changes. Please consult the documentation and vendors of those products and systems.
If you enable auditing on your Active Directory implementation please review Microsoft’s documentation for what an event log entry means, when it will occur, and what information is gathered in the event log entry before opening a support case with Microsoft or VMware.
Who Is Affected?
If you have configured vCenter Server to access Active Directory over LDAP with TLS (LDAPS) or Identity Federation you will not be affected by this. You can check this by viewing your Identity Sources in the vSphere Client:

The red & green text has been added by us as an illustration. Sources using LDAP (ldap://, port 389) are likely to be affected. Sources using LDAPS (ldaps://, port 636) are likely fine if they are direct connections and not through proxies or load balancers.
Sources listing their type as “Active Directory (Integrated Windows Authentication)” will continue to authenticate, but their ability to search the Active Directory for users & groups will break, as it uses unsigned LDAP to do so. This may impact the ability to add users & groups to authentication configurations. VMware KB 78644 discusses some of this, and VMware is investigating changes that may improve this situation.
What Will Happen
Without proactive action on your part, once Microsoft releases these updates and they are applied the affected identity sources will stop working. This will appear as login failures in the vSphere Client:

as well as errors when attempting to add or reconfigure an identity source:

Notes & Suggestions on How to Test
We recommend testing in order to gain familiarity with these updates. Microsoft has released guidance on how to enable these settings:
- 2020 Microsoft LDAP channel binding and LDAP signing requirement for Windows (the starting point for all this)
- ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing (the security advisory)
- Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure (registry settings for some of the changes)
- How to enable LDAP signing in Windows Server 2008 (Group Policies for the other changes, see below for some important notes. Also contains guidance on how to discover clients that do not use the “Require Signing” option.)
- CVE-2017-8563 | Windows Elevation of Privilege Vulnerability (you need to have installed the Windows Updates listed here for this to work)
The document on enabling LDAP Signing in Windows Server 2008 indicates that you need to change the “Default Domain Policy” but in order for it to be effective for domain controllers you must also edit the “Default Domain Controllers Policy” or whichever policy applies to the domain controllers, if you’ve assigned a new one. The procedure in that document also appears to be applicable to all versions of Windows, not just 2008. Once the Group Policy edits are in place you can wait until the Group Policy refreshes automatically or use an Administrator-level shell to issue the “gpupdate /force” command.
Keep in mind that updating Group Policy affects other domain controllers & members as well. vCenter Server can configure multiple LDAP & LDAPS authentication sources, and can specify particular domain controllers, so we recommend creating a new & isolated Active Directory instance for testing (you can see my farm animal theme for test domains & forests in this post, which is separate from my main authentication source).
To test that the settings have taken effect use the “ldp.exe” utility (Start->Run->ldp) from the domain controller itself. From the Connection menu, choose Connect, and enter “localhost” and port 389:

From there, go back to the Connection menu and choose “Bind.” Enter your domain credentials and select “Simple bind” as shown here:

You should receive the error “Error 0x2028 A more secure authentication method is required for this server” as shown below, which indicates that you have correctly disabled clear-text LDAP binds.

If you do not get this error with this procedure the changes have not taken effect!
From here you can test vCenter Server connectivity to Active Directory, witnessing the behavior seen at the beginning of this post. As mentioned earlier, VMware vCenter Server can have multiple Active Directory instances configured, so testing with an isolated instance of Active Directory is recommended. Similarly, deploying a test vCenter Server appliance is recommended. Take a snapshot of the environment and you can restore it if everything goes wrong. Nested virtualization environments, in general, are an excellent way to test functional changes such as this. William Lam has extensive resources on his personal blog for nested ESXi.
For even more testing isolation, if you deploy the Windows Active Directory VM first and configure AD DNS you can use it as the DNS server for a test deployment of vCenter Server.
Possible Course of Action #1: Enable TLS on Active Directory (LDAPS)
Being security-minded, the first & best recommendation is to secure your authentication with TLS. As a matter of practice, all communications on a network should be encrypted. This is especially true of authentication traffic. Please refer to Microsoft documentation for configuring Active Directory Certificate Services and issuing certificates to Active Directory domain controller services.
Configuring vCenter Server to use LDAPS is straightforward and well-documented at docs.vmware.com. There is one twist: you will need the certificate for the domain controller. You can export it from Windows but if you have access to OpenSSL, either installed on a Windows PC or built into a Linux/UNIX host, this sample command is often easier:
echo | openssl s_client -showcerts -connect cows-ad-a1.cows.local:636
will display the certificate you need, between the “—–BEGIN CERTIFICATE—–“ and “—–END CERTIFICATE—–” lines. Copy those lines and everything between them into a text file and use that when prompted. Replace my farm animal test FQDNs with the native DNS name of the domain controller you are connecting to, of course!
Possible Course of Action #2: Proactively Configure These Settings to The Original Defaults
Being security-minded, making a decision that could negatively affect security can be tough. However, there’s a lot more to information security than just changing registry settings. Information security professionals use the “CIA triad” — confidentiality, integrity, and availability – to thoughtfully weigh the risk of a configuration, and the short timeframes and nature of these changes could seriously impact availability. If you’ve already been running in this configuration you likely have compensating controls in place, such as isolation (firewalls, separate networks), to protect against someone observing authentication traffic.
Microsoft has stated that these upcoming patches will change the defaults. Though they haven’t said it directly, this implies that you can proactively set the those settings to the current defaults, using these same processes (set the LdapEnforceChannelSigning registry key to 0, set the group policies to ‘None’). This assumes that Microsoft will not overwrite them with the patch, which is probably reasonable, but we will all want to verify that once the patches are available.
Should you do this? It might be the easiest way forward for now, but it doesn’t improve security, and is likely worth a conversation with your CISO.
Other Considerations
It isn’t a good idea to significantly delay patching. Patching is the ONLY way to remove a vulnerability from a system, and it’s the #1 way organizations and individuals can secure themselves (the #2 way is great passwords & account hygiene). Microsoft is making this big change for a reason, and we don’t yet know what has changed since the original 2017 vulnerability disclosure. It’s very likely that, in a few months, we will learn more about what is driving this. That won’t be good news, whatever it is. By delaying or omitting patches you delay the inevitable and you increase your risk, both from hackers and from well-intentioned humans accidentally applying cumulative updates.
Whatever course of action you choose, this is a great opportunity to make sure that you know and/or can retrieve the password for your vCenter Server SSO instance’s administrator account (often administrator@vsphere.local).
Active Directory is wonderful in that it’s a multi-master, replicating, distributed database, with built-in availability and recoverability features. Use this to your advantage and plan a staged rollout for both this issue and as a future patching strategy. Similarly, do not forget the flexibility vCenter Server has in targeting specific domain controllers, as well as the ability to apply Group Policies to specific domain controllers.
Thank You
As always, thank you for being a VMware customer. We appreciate you and hope that, like with our continued guidance on CPU vulnerabilities, this has been helpful in navigating these larger industry-wide changes.
For questions and feedback about Active Directory, Windows Updates, and these Microsoft Updates please contact Microsoft directly. We love feedback but if it’s about Active Directory and Windows the best we will be able to do is commiserate with you. Feedback is most powerful when it’s direct from a user to the responsible vendor.
For operational issues with VMware products please contact VMware Global Support Services, who are available 24×7 to assist. If there are other things we can help with, or you have questions or feedback about VMware products, please reach out to your account team or Technical Account Manager. For issues directly concerning this post please leave a comment below.
Last thing – subscribe to this blog and follow us on Twitter or on Facebook! We write a lot of technically-oriented articles like this, covering news and current topics, and we’d love to have you with us.
Thank you!
Leif Maxfield
This article doesn’t seem to make any mention of whether the “Active Directory (Integrated Windows Authentication)” method is affected by this change. In our environment, our domain-joined vCenters/PSCs that are using IWA for domain authentication are generating 2889 events on our DCs, which seems to indicate they will stop working after MS rolls out this patch. It would be helpful to get a clear answer about whether IWA will no longer be a viable identity source type after this change rolls out.
Jan Erik Holo
Active Directory integrated Identity Sources are NOT affected – Confirmed in a VMware Support Case.
https://kb.vmware.com/s/article/2149697 gives useful tips creating needed CER files and URLs to be used.
nc -v LDAP-SRV-IP 636 can be useful to test if LDAP server listens to port 636 (and similar for port 3269)
Sandro
We configured our Identity Source to use “Active Directory (Windows Integrated Authentication)”; I noticed event logs with id 2889 coming from our Virtual Center’s computer account. It look like “Active Directory (Windows Integrated Authentication)” uses unsigned SASL requests. Should I switch to Active Directory over LDAP and SSL enabled instead?
Baiju
You may try below steps in “Active Directory (Windows Integrated Authentication)” to enable Signed SASL requests:
– Enable SigningRequired to 1 by executing below command on VCSA
/opt/likewise/bin/lwregshell set_value ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’ SigningRequired 1
– Verify the value by executing list command
/opt/likewise/bin/lwregshell list_values ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’
– Restart the Services
Sudeep S Nair
I have created a test environmentand configured Identity Source as Active Directory (Windows Integrated Authentication). I have then hardened my test DC with the manual procedure. An ldp simple bind test shows that my DC will not accept unigned SASL request. However my vCenter Authentication works fine. I have removed the existing identity source and re-added giving me the same results. It works fine. Could we have a confirmation if Active Directory (Windows Integrated Authentication) is not affected with this change.
Pet deschacht
Sudeep can you confirm that you have the 2889 before and after the controller hardening ?
Can you also confirm you don’t have the below entry set?
Enable SigningRequired to 1 by executing below command on VCSA
/opt/likewise/bin/lwregshell set_value ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’ SigningRequired 1
Altan
To verify that IWA will default to LDAPS, check with below in the PSC (as Baiju said):
/opt/likewise/bin/lwregshell list_values ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’
“SigningEnabled” REG_DWORD 0x00000001 (1)
“SigningRequired” REG_DWORD 0x00000000 (1)
They should be both 1. If not, to set it
/opt/likewise/bin/lwregshell set_value ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’ SigningRequired 1
Than restart services
Tony
Hi,
I am using IWA and set the SigningRequired to 1 and even rebooted my vCenter.
But eventID 2889 is still popping up on our DCs.
What else can we do?
Adam
I have IWA and it appears we are generating a small number of 2889 events. I checked my VCSA settings with
/opt/likewise/bin/lwregshell list_values ‘[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]’
and I have:
“SigningEnabled” REG_DWORD 0x00000001 (1)
“SigningRequired” REG_DWORD 0x00000000 (0)
What are the impacts of changing “SigningRequired” to 1?
cotje
Are connections to the global-catalog (3268) also impacted?
Cam
3268 is equivalent to 389 and 3269 is equivalent to 636 (except the GC aspect). You should use port 3269 for LDAPS GC binds.
Semicolon
When working with “Active Directory (Windows Integrated Authentication),” do we also need to specify a trusted certificate, or is that step only required when configuring an “Active Directoryover LDAP” identity source?
Charlie Pelkey
We have Active Directory (Integrated Windows Authentication) configured as our identity in VMware and it shows up in the Windows Event ID 2889 log as an affected application. The identity is computer and not SPN. Would changing it to SPN fix this, or do we have to change to secure LDAP? Below is the (modified) event ID 2889…
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:
10.xxx.xx.xxxx:42728
Identity the client attempted to authenticate as:
DOMAIN\Machinename$
Binding Type:
0
Daniel
We also have IWA configured and have binging Type 0 (SASL without signing) in the logs. We are not going to plan to switch to the “AD over LDAPS” setting, because VMware recommends IWA (VMware BSC) and with “AD over LDAPS” in some DR scenarios or when a DC are not reachable the vCenter logon process takes much longer (Primary/Secondary config as well as use any domain controller).
I tested the settings as Bajiu describes, but I still have SASL without signing.
Daniel
I could clarify with the VMware BSC and tested it in our DEV Domain environment that type 0 events (SASL without signing) is still normal, because IWA is constantly checking all the possible LDAP connections. The type 0 event does not indicate that a LDAP bind with SASL is not signed from the vCenter perspective.
In our DEV Domain environment, I forced LDAP signing on the DC (GPO Domain controller: LDAP server signing requirements -> Require signing) and a logon to vCenter with a domain account is possible, but I still get an type 0 event in the DC event log.
Phil
In our environment, we are seeing the events generated from the *COMPUTER* account that vCenter has as a domain member (i.e., DOMAIN\vCenter65$) as Sandro mentioned and not from any logons via WIA. So it appears that the events we are seeing have nothing to do with SSO or users signing in to vSphere. Since this article is specifically geared towards SSO, is there any guidance for vCenter’s computer account itself generating 2889 events as “unsigned” or what may happen with vCenter itself authenticating to the domain after the Microsoft patches are in place?
Rob Hillis
This matches what I’m seeing. I’ve modified both our sandbox vCenter (6.7 with an integrated PSC) and the external PSC part of our one of our production vCenters with the registry change as described above.
The sandbox vCenter stopped generating 2889 events for a while, but perversely started up again after I made the same change to one of our two production vCenters.
I have an open case with VMware support at the moment – if this behaviour continues I’ll raise it with them and find out why RequireSigning isn’t actually requiring signing. It sounds like it should work when the changes come in, but I’d much rather not wait and get everything reconfigured and tested in advance.
Martin Gustafsson
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
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.
Bob Plankers
Thank you for indicating this, that change was a quiet one. The post has been updated to reflect that change.
John Kupski
“VMware vSphere’s mechanisms for interacting with Active Directory LDAP first try an unsigned bind, then on failure will try a signed bind and succeed.”
So you try insecure methods first, then “fall back” to secure methods? Is this not entirely opposite of good design?
Also, while I believe the claim that this will continue to work after applying the patch, does this not imply that vSphere will continue to fling plain text credentials across the network before authenticating securely (completely defeating the entire purpose of not allowing insecure authentication in the first place?)