Save to My DOJO
Back in summer of 2019, Microsoft announced a change to increase the security of network communications between an Active Directory Domain Services (AD DS) or an Active Directory Lightweight Directory Services (AD LDS) and its clients. This hardening update changes the default behaviour of Active Directory Domain Controllers (AD DC) to enforce LDAP channel binding and LDAP signing. Its purpose is to prevent an attacker from performing a man-in-the-middle attack on an LDAP server.
The statement was accompanied by a Windows support article setting the rollout date of the update to January 2020. Although it may seem like a long time to prepare for such a change, it turns out many software vendors did not react to it and didn’t provide any recommendations for proactive remediation. Other solutions simply offer no support for protocols other than unsigned LDAP. For these reasons, Microsoft delayed the rollout date to March 2020 to give customers and vendors more time to get ready and to wait after the 2019 holidays. Many customers restrict configuration changes during the holiday season and need more time to prepare and test…
It took VMware some time, a few VMTN posts and support tickets from several concerned customers before publishing official communication on the topic. The fact that no documentation was made available was a little worrying as such a change could harm the SLA of many production environments. In this blog, we will go over a few of the main VMware products and see how we can prepare for this Microsoft update.
Important: This blog contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure you know what you are doing and back up the registry before modifying it so you can restore it if a problem occurs. Changes to the registry on production domain controllers should be done with great care.
Identifying clients that could be impacted
To identify the clients that could experience a negative effect from the update we need to enable LDS diagnostic event logging on the domain controller. After this procedure, any Clients that rely on unsigned SASL LDAP binds or on LDAP simple binds over a non-SSL/TLS connection will generate an event with ID 2889 every time it makes a request.
Change the following registry key on the domain controller (No restart is required).
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
- “16 LDAP Interface events” : Set it to 2
Once this key has been edited, the event viewer will start logging diagnostic events under the “Directory Service” log.
Whenever a client makes an unprotected request, a 2889 event such as this one will appear. I displayed it in Powershell to show all of its information. It will show you the IP of the server making the request and which domain account was used. You may find some software other than VMware pop up in this list which you can proactively remedy as well.
vCenter server
The single-sign-on (SSO) component of vCenter leverages identity sources to allow users to connect using their AD or OpenLDAP credentials. We are obviously only dealing with AD here and the two (and a half) different ways to implement it as an identity source.
Active Directory (Integrated Windows Authentication)
Impact of the Microsoft Update: None
The machine on which the vCenter Single Sign-On service is running must be in an Active Directory domain to use this option. VMware released a blog on the 13/01/2020 in which they state the identity sources configured with Integrated Windows Authentication (IWA) will not be impacted by the Microsoft update.
| Integrated Windows Authentication (IWA) has also been tested by VMware Engineering and verified to be compatible with these changes. IWA uses different protocols and mechanisms to interact with Active Directory and is not affected by changes to the Active Directory LDAP servers. |
One odd thing about it is that it still generates 2889 events even though it works with the LDAP hardening settings enabled.
Active Directory as an LDAP Server
This option is available for backward compatibility and requires that you specify the domain controller and other information. It is also useful if you need to connect another domain than the one vCenter server is a member of. This mode can be configured for TLS encrypted communications with the Domain Controllers (LDAPS) or unencrypted communications (LDAP).
Encrypted (LDAPS)
Impact of the Microsoft Update: None according to VMware.
If your identity source is already configured with LDAPS you don’t need to change anything.
Unencrypted (LDAP)
Impact of the Microsoft Update: Login failure.
If you have an identity source configured for unencrypted LDAP you face failed logins whenever using a user on that domain. Any solution connecting to vCenter using AD accounts (usually service accounts) will be negatively affected once the change is rolled out by Microsoft. As a result, it is highly recommended to configure LDAPS on these identity sources.
| Any system that connects to Active Directory via LDAP without using TLS will be negatively affected by this change. This includes VMware vSphere. |
To proactively remediate this situation, you need to retrieve the domain controllers’ certificates and enable encryption on the identity source.
1. List all domain controllers in the domain (replace xav.test with your domain fqdn). Run the following command on your workstation.
nltest /dclist:xav.test
You will get the list of the domain controllers on the left with a mention on which one is the PDC (primary domain controller). I only have one DC in my lab but you will likely get several more lines for each DCs.
2. Retrieve the certificates of each domain controller. Run the following command on your workstation against each domain controller.
openssl s_client -connect xav-win-dc.xav.test:636 -showcerts
The output will contain the certificate to use to validate the identity when using LDAPs in vCenter.
3. Copy and paste the content of the certificate in a notepad. To have the full certificate chain, remove the extra text in between the server certificate and the root/intermediate CA certs. Save as xav-win-dc.xav.test.cer so you know which is which and open it to check that it is correct.
4. Log in vCenter using an SSO admin ([email protected]) > Administration > Configuration > Identity sources.
5. Edit the LDAP source > Enable LDAPs on the identity source by checking “Protect LDAP communication using SSL certificate (LDAPS)” and click “Next”.
If you use “Connect to any dc in the domain” and an “ldap://xxx” value is under the greyed out server URL field, check the other box, clear the field and check the first box again. Otherwise, the menu will incorrectly report ldap instead of ldaps.
6. Checking that box will add a pane to provide the domain controller certificates that we gathered earlier. Click the “+” button to add all the certificates. Click “Next” and finish.
A quick reminder that you need to add the DC server certificates, not the root CA certificate.
7. Complete the wizard and ensure that the menu is now showing ldaps.
Horizon View
VMware’s virtualized desktop infrastructure (VDI) solution binds with Active Directory to perform a number of tasks. VMware released KB76062 which states that the solution is compatible with the Microsoft update. The Horizon manager UI doesn’t offer any configuration for LDAPS anyway.
|
However, do make sure that the vCenter servers paired with Horizon are correctly configured. Failing to do so will result in vCenter being in error in Horizon administrator because it cannot connect to it due to the domain controller rejecting insecure communications.
App Volumes
Warning: App Volumes up to versions 2.18 and 4.0 is not compatible with LDAP Channel Binding. If the registry key LdapEnforceChannelBinding is set to 2, “login failure” will occur. VMware is currently working on a fix. The currently recommended actions are described in KB77093.
If you use App Volumes in your VDI environment, you will need to pay attention to how it binds to your Active Directory. If you use insecure LDAP you will once again face failed logins.
To proactively remediate we need to enable LDAPS.
1. Connect to App Volumes Manager and go to the AD Domains configuration pane. Select your insecure domain binding and click “Edit“.
2. Under “Security” select “Secure LDAP (LDAPS)“.
Note that it is not recommended to disable certificate validation but it will still work if you disable it.
To enable certificate validation you will need to save the certificate of your Root CA (and all intermediate CA) as a file named “adCA.pem” that you must store in “C:\Program Files (x86)\Cloud Volumes\Manager\config“. Finally, you will need to restart the “App Volumes Manager” service.
Enforcing LDAP signing and Channel Binding
You can temporarily enforce LDAP signing and Channel binding even before the update is distributed if you want to test your setup and see if things break in a controlled environment or just want to see for yourself in a lab.
It is safe to assume that this setting can be set back to the original value after the update is deployed in case of an emergency where some software stops working and you need a quick fix. However, it is of course not recommended to delay a security patching. If there’s more you wish to know about the subject of LDAP channel binding and LDAP signing, let me know in the comments below and I’ll get back to you!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Xavier Avrillier
