Monitoring for LDAP Client Security

Applications that use Lightweight Directory Access Protocol (LDAP) are prevalent in virtually every organization that uses Active Directory (AD). Unfortunately, the default AD configuration provides opportunities for insecure LDAP connections. These defaults have come into focus because of common, widely available AD attack tools such as NTLMRelayX. (For more information about NTLMRelayX, see How to Exploit Active Directory ACL Attack Paths Through LDAP Relaying Attacks.) The first step in remediating these settings is to monitor for LDAP connections that aren’t secure.

Configure AD Diagnostics

To start, you’ll need to configure some registry settings to properly identify insecure LDAP configurations in your environment.

Configure a Group Policy preference in a Group Policy Object (GPO) that’s linked to the Domain Controllers organizational unit (OU) to enable basic diagnostic logging. Detailed information about insecure LDAP configurations in the environment will begin to be recorded in the Directory Service log. The default diagnostic logging level is 0 (none).

• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key Path: SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
• Value name: 16 LDAP Interface Events
• Value type: DWORD
• Value data: 2

Configure a Group Policy preference in a GPO that’s linked to the Domain Controllers OU to set the Directory Service log to be 32MB to start with. The default size is 1MB. Having a sufficient size for this log is important so that you don’t miss events. It’s best to have at least a day’s worth of events to allow your monitoring system time to accommodate for any outages, so modify the size as required based on the volume of events in this log. Otherwise, the event log may roll over before your monitoring system has a chance to see the event.

Registry Item 1:

• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key Path: SYSTEM\CurrentControlSet\Services\EventLog\Directory Service
• Value name: MaxSize
• Value type: DWORD
• Value data: 33685504 (Decimal)

Registry Item 2:

• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key Path: SYSTEM\CurrentControlSet\Services\EventLog\Directory Service
• Value name: MaxSizeUpper
• Value type: DWORD
• Value data: 0 (Decimal)

To make auditing more convenient, you may wish to collect these events on a Security Information Event Management (SIEM) service. Doing so will give you a holistic view of insecure LDAP usage in your environment, which can be leveraged to prioritize LDAP clients that should be remediated.

Monitoring for LDAP without Encryption or SASL binding

LDAP clients that do not negotiate the authentication mechanism might not be using Simple Authentication and Security Layer (SASL) when binding. When SASL binding is used, the LDAP client and LDAP server negotiate on the authentication protocol to be used, such as Kerberos or NTLM. When SASL binding is not used, there is a potential that the credentials used during the bind process were sent in clear text.

LDAP clients that do not use encryption send all LDAP traffic (including the credentials used in an LDAP bind) over clear text. This isn’t necessarily a bad thing if the LDAP bind was performed using SASL.

When basic diagnostics on the LDAP interface for domain controllers (DCs) is configured, any LDAP client communicating insecurely will be identified with an event ID of 2889 in the Directory Service log on the DC that the LDAP client is trying to communicate with. This event means the client is using a simple LDAP bind when authenticating to the DC and didn’t do so over a Transport Layer Security (TLS) encryption tunnel. It also tells you that the LDAP traffic can be compromised because the LDAP client didn’t request signing for an LDAP bind request, which means the integrity can’t be validated. Figure 1 shows a sample event.

The event includes the client’s IP address and the identity initiating the insecure LDAP connection in the format of NetBIOSDomainName\SamAccountName. The Binding Type field will have a value of either 0 or 1. A value of 0 means the identity is a computer object, and a value of 1 means the identity is a user object. A computer object’s SamAccountName has a $ character as the last character, which also helps in identifying the object type.

Monitoring for LDAP Binding without Channel Binding

A few prerequisites must be met to reliably monitor for clients that can’t use LDAP Channel Binding Tokens (CBTs). These prerequisites include:

• Basic diagnostics on the LDAP interface for DCs must be configured.
• DCs must have the Domain controller: LDAP server channel binding token requirements setting configured to Always.
• DCs must have the LDAP encryption certificate installed.
• Clients must be able to establish an LDAP connection to DCs with encryption (STARTTLS on port 389 or explicit TLS on port 636).

Contrary to what many articles, such as this very popular Tech Community article, state about monitoring for clients not using LDAP CBTs, setting Domain controller: LDAP server channel binding token requirements to a value of When Supported isn’t enough. In fact, doing so likely won’t provide any new results, because DCs already have this setting by default in their local policy. DCs simply won’t log any new events unless the value is configured for Always. Configuring this setting to Always can potentially impact your environment but doing so is the only way to obtain the data you need to remediate.

As a side note, the setting Domain controller: LDAP server channel binding token requirements was only introduced in mid-2019 for DCs running Windows Server 2012 or better.

Windows LDAP clients dating back to Windows XP SP3 and Windows Server 2003 SP2 support LDAP CBTs; however, they must be fully patched or at least have the related patch installed that was released in 2009. If you have Windows LDAP clients binding to LDAP over TLS that aren’t running at least these operating systems (OSs) and the related patch, they will fail to bind to LDAP with TLS when the Domain controller: LDAP server channel binding token requirements setting is set to Always. For non-Windows OSs, it’s up to the vendor to provide LDAP channel binding functionality on the client. Unfortunately, there’s no inventory of which non-Windows OSs support this functionality. Red Hat, which is the most common enterprise-class Linux client, does support LDAP channel binding tokens—although a known bug exists in which events will be generated in the Directory Service log that indicate the client isn’t communicating securely over LDAP, even though that’s not the case.

Once the prerequisites have been met, watch for new events with event ID 3039 in the Directory Service event log. Figure 2 shows a sample event.

This event can be triggered manually by meeting the following prerequisites:

• You have an unpatched Windows XP SP3 or Windows Server 2003 SP2 computer joined to the domain, or more specifically a computer that doesn’t have the updates listed in Microsoft Security Advisory 973811 installed.
• You have ADSI Edit or any other LDAP browser installed. ADSI Edit is included in the support tools for Windows XP and Windows Server 2003.
• The DC you’re planning to test the connection with has an LDAP encryption certificate installed.
• The DC you’re planning to test the connection with has the Domain controller: LDAP server channel binding token requirements setting configured with a value of Always.

To generate an event ID 3039 using ADSI Edit:

1. Run adsiedit.exe from an unpatched Windows XP SP3 or Windows 2003 SP2 computer.
2. Right-click ADSI Edit at the top of the left pane and choose “Connect to…”
3. Under the Computer section, choose “Select or type a domain or server:”
4. Enter the Fully Qualified Domain Name (FQDN) of the DC you wish to test the LDAP connection against (e.g., DC01.MyTestDomain.com).
5. Click OK.
6. If you’ve met all the previously mentioned requirements, you’ll receive an error message on the client stating, “Client’s supplied SSPI channel bindings were incorrect.” If you’re using a different LDAP browser, you’ll get a more generic SSL/TLS error message such as, “A Client Certificate issued by server-trusted Certificate Authorities for has not been found. It’s now possible that the server may reject your SSL connection attempt in case it requires client authentication.”
7. Look in the Directory Service event log on the DC that the client attempted to connect to and search events with event ID 3039. You’ll see the client IP address in the event, which will confirm that you’re looking at the correct event.

Summary

Monitoring for insecure LDAP configurations can be eye-opening. As you can tell, monitoring isn’t hard—and it doesn’t have to be scary.
If you need help with your LDAP security configuration, contact the experts at Ravenswood Technology Group.