Remediating LDAP Client Security

In a previous blog post, we covered how to monitor for Lightweight Directory Access Protocol (LDAP) client security issues. It’s important to monitor for LDAP security issues before remediation to understand the scope of work ahead of you and to track your remediation progress. Remediating LDAP security issues is important because the default configurations on domain controllers (DCs) and clients leave them open to man-in-the-middle (MITM) and replay attacks. In this blog post, we discuss how to remediate those issues—and you may learn a thing or two about how LDAP security works along the way.

How to Enable LDAPS

To enable LDAPS, you need an applicable certificate installed in the Personal (or NTDS) certificate store of each DC to enable LDAP encryption. By default, if you have an Active Directory Certificate Services (AD CS) enterprise certification authority (CA) in your forest, DCs will automatically request a certificate based on the Kerberos Authentication template. Once the certificate is installed in the DC’s Personal or NTDS certificate store, LDAPS will be enabled immediately. There’s no need to restart any services on the DC.

Domain-joined clients in the DC’s forest will trust the CA that issued the DC’s certificate if it’s issued by an AD CS Enterprise CA. Non-domain-joined Windows clients and non-Windows clients typically require the CA certificate of all CAs in the certificate’s issuing hierarchy to be manually trusted for LDAPS connections to succeed. You’ll need to establish trust with the root CA and any intermediate CAs.

Require Signing for LDAP Binding

You should immediately configure the Group Policy setting Network security: LDAP client signing requirements to Negotiate signing. This setting can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options and should be configured in a Group Policy Object (GPO) linked at the domain level, because you’ll want this setting to apply to all member systems and DCs. Configuring this setting allows the Windows LDAP client and the DC to negotiate the use of LDAP signing. Once configured, LDAP signing will occur automatically, if possible. By doing so, it may reduce the number of clients you need to remediate. This setting is specific to LDAP clients. If all Windows clients on the network are running at least Windows 2000 SP4, it’s safe to change the policy setting Network security: LDAP client signing requirements to Require signing. This won’t affect non-Windows clients.

LDAP clients that don’t perform signing are clients that authenticate to a DC using a simple LDAP bind. The first thing to do in this scenario is to see if the configuration on the LDAP client can be adjusted to negotiate authentication using Simple Authentication and Security Layer (SASL). When SASL binding is used, the LDAP client and LDAP server negotiate on the authentication protocol to be used, such as Kerberos or NTLM. Table 1 shows a compatibility matrix of LDAP signing using SASL binds. If it isn’t possible to use SASL, you must implement LDAP encryption to prevent LDAP clients from transmitting credentials in clear text. Use of SASL or LDAPS will prevent DCs from logging events with event ID 2889.

Once all occurrences of event 2889 on every DC have been addressed, it’s safe to configure the Group Policy setting Domain controller: LDAP server signing requirements to Require signing. This setting can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. This setting only applies to DCs, so configure it in a GPO that’s only linked to the Domain Controllers OU. Table 2 shows a compatibility matrix of settings for LDAP signing using a simple bind.

A known issue exists where some non-Windows LDAP clients that are using LDAP signing and encryption still generate events on DCs with event ID 2889. You can safely ignore these events. The false positive is a result of using SASL Generic Security Service (GSS) Application Programming Interface (API), more commonly represented as GSS-API in the System Security Services Daemon (SSSD) configuration. To avoid these false positives, it’s recommended to instead use SASL Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) in the SSSD configuration.

Remediating LDAP Binding to use LDAP Channel Binding

The LDAP Channel Binding Tokens (CBTs) feature was introduced by Microsoft in 2020. The policy setting for configuring LDAP CBTs is called Domain controller: LDAP server channel binding token requirements, which has a default local policy value of When supported. This setting can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Configuring this setting with a GPO to When supported will likely have little value, especially since this won’t help you in auditing for clients that aren’t leveraging LDAP CBTs. This is contrary to what many articles (including Microsoft’s) and blogs state. When LDAP clients bind using LDAPS, and this setting is set to When supported or Always, Extended Protection for Authentication (EPA) is leveraged by the client and the DC to make the LDAPS connection more secure.

To force LDAPS clients to use LDAP CBTs, configure the policy setting Domain controller: LDAP server channel binding token requirements to Always. After doing so, you should immediately start monitoring for event ID 3039 on DCs. Use a Security Information and Event Management (SIEM) service to collect events from all DCs in the domain with this event ID. Figure 1 shows what this event will look like when using ldp.exe on an unpatched Windows XP SP3 client and binding to a DC using LDAPS on port 636, when DCs are configured to always require LDAP CBTs.

If any critical applications are impacted by the change, you’ll need to temporarily reconfigure the Domain controller: LDAP server channel binding token requirements setting back to When supported. Make sure you gather the information from the SIEM service where there are records of event ID 3039 before the information rolls over and is lost.

If you come across any events with event ID 3039, you may need to resolve the client IP address to a DNS address to create a punch list of identified clients that need remediation prior to configuring this setting back to Always. Make sure you do this immediately when you see the event, since client IP addresses can change.

With the client identified, the client will require an update to enable EPA functionality. If no such update exists for the client and if the client cannot be retired and is a critical asset to the organization, you won’t be able to reconfigure this setting back to Always without impacting the client.

Windows has supported EPA since Windows XP SP3 and Windows Server 2003 SP2. For non-Windows clients, it’s up to the vendor to provide LDAP channel binding/EPA functionality on the client. Unfortunately, there’s no centralized documentation for which non-Windows operating systems support this functionality. Red Hat, which is the most common enterprise Linux client, does support LDAP CBTs.

Summary

Once your environment is free of insecure LDAP configurations on your clients and DCs, you can rest easy knowing they’re no longer susceptible to LDAP-based MITM and replay attacks. Implementing controls to prevent these types of attacks from being successful is an important part of a defense-in-depth strategy. However, these controls aren’t fast or easy to implement. You’ll need to be patient and take an analytical approach to be successful.

If you need help with your LDAP security configuration, contact the experts at Ravenswood Technology Group.