Ready for Microsoft’s LDAP Changes? What You Need to Know

Ready for Microsoft’s LDAP Changes? What You Need to Know

What is Changing?

In March, Microsoft will be releasing a patch that includes new audit events, additional logging, and some changes to group policy settings. Later in 2020, Microsoft will be changing the behavior of the default values for LDAP channel binding and signing. They’re making these changes because the current default settings allow for a potential man-in-the-middle attack that can lead to privilege escalation. This means, once the default settings are changed, that any new domain controllers will have secure defaults, and any domain controllers that were not explicitly configured, would experience this change. To get ahead of this, Microsoft is recommending everyone changes these settings to their secure configuration now, so they have time to understand what will be affected when the automatic change comes. At the very least, you should configure non-default values for these settings, so there is no impact on your environment when the change does get forced upon you.

Channel Binding

Channel binding takes two components of an LDAP call and binds them together, making your request distinct. This helps prevent NTLM relay attacks, where an attacker would intercept your request and re-use it. An NTLM relay attack would require a new TLS connection, which would not match up with the LDAP request that was sent originally. 

LDAP Signing

LDAP Signing requires the source to sign the LDAP traffic, which enforces the integrity of the contents being sent and allows the receiver to verify where it came from. This means that unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or LDAP simple binds over non-SSL/TLS connections will not work.

The Details

So now that you understand what is changing, let’s dive into the specifics. To make these changes, I’d suggest leveraging group policy, but I intend to cover the underlying changes to the registry that occur with the group policy changes.

The following registry key controls the behavior of Channel Binding on a Domain Controller:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding

By default, whether this value exists or not, it is set to 0. 0 indicates that Channel Binding validation is completely disabled. A value of 1 indicates enabled when supported. This means that a version of Windows that supports channel binding, must use it. This is a compatibility setting for an environment that may have some legacy applications or machines. A value of 2 indicates enabled, always. This means all clients must provide channel binding information. Be sure to install CVE-2017-8563 prior to changing these settings, otherwise, you may experience issues.

The following registry key(s) controls the behavior of LDAP Signing on a Domain Controller:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity

By default, whether this value exists or not, it is set to 0. 0 indicates that LDAP Signing is off, or not required. A value of 1 indicates that LDAP Signing is not required. A value of 2 indicates required.

What You Can Do

Hopefully, everything makes sense now, and all that there is left to do is help you figure this all out. Below, is an example of a StealthAUDIT job that will report on which domain controllers are currently set as default or insecure, as these are both situations that may cause problems down the line. Whether that be a man-in-the-middle attack or Microsoft changing default behaviors, you’re susceptible to something.

A StealthAUDIT job reporting on Domain Controller settings
A StealthAUDIT job reporting on Domain Controller settings

And, if you’re interested, Stealthbits is now offering a free tool that you can take advantage of!

Click here to gain access to StealthINTERCEPT, our real-time policy enforcement solution designed to monitor and block unwanted and unauthorized activities in Active Directory. StealthINTERCEPT’s LDAP module provides complete visibility into all ‘nonsecure’ LDAP queries. allowing you to not only determine whether or not the query was executed securely and where it was coming from, but what the query was actually requesting from the directory.

Using StealthINTERCEPT’s LDAP blocking functionality, organizations can also simulate the effect of the update in broad or selective ways, without actually modifying Active Directory configurations.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free Stealthbits Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other