Active Directory Hardening Series – Part 5 – Enforcing LDAP Channel Binding

Hi there! – Jerry Devore is back again to talk more about LDAP security. This time we’re going to cover LDAP channel binding. If you’ve been following this series, you probably already know that you need to enforce LDAP signing to prevent relay and MITM attacks. So what’s the purpose of enforcing LDAP channel binding? Well, channel binding can be used to prevent relay and MITM attacks on your LDAP. If that explanation doesn’t help, you’re not alone. Many people have a hard time understanding why both are necessary. I hope to clarify the issue and give you the information you need to move forward with confidence.

To get started, it might be helpful to review the following key points from before: mail About LDAP signing.

• A simple binding is created with a username and password.
• SASL bindings are created using integrated authentication such as NTLM and Kerberos.
• Performing a simple bind outside of a TLS session leaves credentials and data easily accessible over the network, open to MITM attacks.
• Simple binding over TLS leverages the session security provided by TLS to ensure that traffic is unreadable and not modified in transit.
• SASL bindings can require signing, which allows the client and server to exchange a session key that is used to keep communications private and ensure that packets have not been modified in transit.
• When SASL binding occurs over TLS, TLS session security supersedes the session security provided by LDAP signing.
• When enforcing LDAP signing on a domain controller, unsigned SASL binds and simple binds without TLS are rejected.

At first glance, LDAP signing seems to have all the bases covered. However, if you think like an attacker, you can find a possible loophole. What is that loophole? If a MITM can terminate a TLS session, they can manipulate the packets and retransmit them using a new TLS session. LDAP signing does not help with this attack because the new TLS session satisfies the signing requirements. Channel binding helps close this loophole by ensuring that the TLS session used to initiate the connection remains a TLS session for the lifetime of the session. This is achieved by leveraging: Extended Protection for Authentication (EPA) Generate a Channel Binding Token (CBT) for the session. Obtaining the CBT requires access to the client’s credentials, which the attacker does not have in an LDAP relay scenario.

Before we continue, it is important to clarify that simple binding does not use EPA or exchange CBT. Simple binding does not benefit from channel binding, but applying channel binding on the domain controller does not affect simple binding over TLS. Channel binding also does not affect SASL binding that does not use TLS.

Force setting

LDAP channel binding support was introduced in March 2020. Backport Going back to Server 2008, the GPO settings for enforcement are: Domain Controller: LDAP Server Channel Binding Token Requirements We will manage your registry settings. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding.

Configuring a policy has the following effects:

absoluteness: The server does not perform channel binding validation.

When applying: Clients advertising channel binding support will have their connections rejected if they do not provide a valid CBT. Clients that do not support channel binding are unaffected.

always: Any connection that does not provide a valid CBT is rejected, regardless of whether the client supports channel binding.

The LdapEnforceChannelBinding registry setting does not exist until the policy is configured. As a result, channel binding is not enabled on domain controllers by default. It is also worth noting that changing this setting takes effect immediately and does not require a domain controller reboot.

Customer Support

There is no client-side setup required to enable channel binding other than supporting channel binding. Environmental Protection Agency Introduced in August 2009.

thanks

If your domain controllers are from 2019 or later, you don’t have to worry about any unexpected surprises when channel binding takes effect. Below is an example of a 3075 event logged in the Directory Services log whenever a client binds without providing a CBT. As you can see, the event captures the source IP address and the account that performed the binding.

Server 2019 and 2022 updated to November 2023 will automatically log 3075 events as long as 16 LDAP interface events are set to level 2 or higher. This is the same diagnostic logging setting I covered in my LDAP signature. article. Additionally, the server’s channel bindings must be configured as follows: absoluteness or When applying To record an event

Another new event supported in 2019 and later is 3074. This is logged when an EPA client connection is rejected due to an incorrect CBT being presented.

Server 2016 and earlier versions provide more limited logging through event 3039, if the domain controller is configured. If supported, The 3039 event captures EPA-enabled clients that do not provide a valid CBT, but non-EPA clients do not trigger the event. After the server is configured always, The 3039 event is logged for both EPA and non-EPA clients. Logging a 3039 event requires the same LDAP diagnostic logging level as a 3075 event. If channel binding is configured. absoluteness 3039 events were not recorded.

Note that any connection that triggers a 3039 event is rejected, so this is not a useful event to monitor proactively. If your domain controllers are not older than 2019, you can initially apply channel binding to a limited number of domain controllers and monitor for 3039 events before applying the change domain-wide. Unfortunately, if you are not introducing new domain controllers, this approach or full-scale scrim testing is your only option.

LDAP load balancing… again.

As discussed previously in this series, load balancing LDAP connections to domain controllers is problematic. This is especially true when channel binding is enforced. If the load balancing solution bridges TLS sessions (terminating a TLS session on the client and opening a new TLS session to the domain controller), enforcing channel binding will reject that connection. If you need to use a load balancer for LDAP, the TLS session must persist from the client to the domain controller. To support this configuration, you need to add the FQDN of the load balancer VIP to the Subject Alternative Name field of the certificate installed on the domain controller. Another alternative is to configure the load balancing application to use simple binding instead of SASL.

Okay, you guys know the drill. Let me do it again. Do’s and Don’ts It helps you maintain employment status while enforcing channel binding in your environment.

• do Please note that channel binding only applies to SASL bindings that use TLS. SASL bindings without TLS and simple bindings with TLS are not affected by channel binding.
• Do not do Postpone domain controller upgrades. Mainstream support for Server 2016 ends in January 2022, and extended support ends in January 2027.
• do Configure channel binding When applying If you haven’t already, this will be a low-impact change, given that invalid CBTs aren’t a common issue.
• Do not do Assuming you have legacy clients (say XP), channel binding will not be applied automatically. It is unlikely that these older clients will use TLS when doing SASL binding.
• do Using a central logging solution to forward 3039, 3074, and 3075 events to a single location can help you manage these tasks more efficiently.
• Don’t do Configure channel binding always Until we investigate the root cause of the 3075 incidents.
• Don’t do Forget that SASL binds over TLS. It uses TLS session security instead of the session security provided by LDAP signing. So you need to enforce both LDAP signing and channel binding.
• do Check out this resource