Secure LDAP signings / bindings

Increase the security for communications between LDAP and AD domain controllers

A set of unsafe default configurations for LDAP channel bindings and LDAP signings exist on AD domain controllers that let LDAP clients communicate with them without enforcing LDAP secure connections.

This could potentially open AD domain controllers to an elevation of privileges vulnerability, which could allow ‘man-in-the-middle’ attackers to successfully forward an authentication request.

 

Introduction

In August 2019, Microsoft published (ADC190023) and announced a chage 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 it’s clients.
It was to alleviate any potential threats of “man-in-the-middle” attacks upon a LDAP server.
Microsoft also had plans to release a patch in March, 2020 that would enforce requirements for LDAP channel bindings and LDAP signings – originally, this was intended to be a mandatory (non-optional) update.

Microsoft have later regressed, and are leaving it to the customers to decide when to enforce settings, now and in the future.

 

Auditing capabilities

New auditing capabilities were introduced with the March 2020 update, through new Group Policy settings, you can configure auditing for LDAP binding/signing events.

*LDAP signing events has been around for a while, while binding events hasn’t.
These events are logged in the Directory Service logs, in Event Viewer.

You can enable auditing via Registry (on each Domain Controller)
LDAP server responds dynamically to changes in this registry entry.

 

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\
  • Each of these REG_DWORD values under ‘Diagnostics’ subkey presents a type of event that can be written to the event log.
  • Logging levels, each entry can be assigned a value of 0 to 5, to determine the level of detail of the event that are logged.
    • Logging Levels:
      0 = (None)
      1 = Minimal
      2 = Basic (Basic logs are sufficient for monitoring LDAP activity)
      3 = Extensive
      4 = Verbose
      5 = Internal: This level logs all events, including debug strings and configuration changes.
  • To enable LDAP binding/signing events to be logged properly, we’ll need to change the value of ’ LDAP Interface Events’ (change value to ‘2’)

 

Or simply change registry key via:

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostic /v “16 LDAP Interface Events” /t REG_DWORD /d 2

Collect information

Before you enforce a policy to enable secure LDAP bindings and signings communications, you might want to collect information, which system that are currently using a non-secure method of authenticating.

After the ‘LDAP Interface Events’ have been updated, and as mentioned previously, the change is dynamically live – meaning, you’ll see direct results from your Event Viewer.

LDAP events are logged under the ‘Directory Services’ events, in Event Viewer.

  

For LDAP signings: (at a glance)

Event ID 2886: Domain Controller are not requiring LDAP signings.

Event ID 2887: How many binds occurred

Event ID 2888: If the Directory Server is configured to reject unsigned SASL LDAP binds over a non-SSL/TLS connection, the DS will log a summary event (once every 24h)

Event ID 2889: Triggered when a client does not use signing after authentication on session on the LDAP port (389).

This event ID (2889) will also display which IP address and Account that are making these requests.

 

For LDAP bindings: (at a glance)

Event ID 3039: Triggered when a client attempts to bind without valid CBT (channel binding token) – client performed an LDAP bind over SSL/TLS and failed the LDAP token validation.

This event ID (3039) will also display which IP address and Account that are making these requests.
 

Event ID: 3040: Triggered (every 24h by default) when CBT (channel binding token) group policy is set to ‘Never’ and at least one unprotected bind was completed

Event ID 3041: Upon startup or start of service, when the CBT group policy is set to ‘Never’

 

Log Collection

In Event Viewer, and ‘Directory Service’ logs, you can then simply then filter logs by only searching for these events with “2886-2889”+”3039-3041”

To collect logs only referring to LDAP signing and binding events.

‘2889’ and ‘3039’ will display IP addresses and accounts that are performing these insecure LDAP connections.

Powershell: Event Log (example)

PS C:\> Get-EventLog -LogName `Directory Service´ | Where-Object { $_.eventID -eq ‘2889’ } | Format-List -Property *

 

Adjust your environment

To avoid any incidents, begin with identifying clients that could be impacted and collect the information of which systems that currently aren’t using SSL/TLS communication from the event (Directory Service) logs on each of the Domain Controllers – then begin to gradually implement changes to the specific applications or systems that aren’t currently using any SSL/TLS communication.

 

Caution

  • If you enforce a new group policies to require LDAP bindings and signings, the applications or systems that aren’t configured to use SSL/TLS will fail to communicate with the Domain Controllers, since those sessions will be rejected.

Powershell: Test LDAPS Port (example)

PS C:\> Test-NetConnection <FQDN-servername> -Port 636

Root CA

Recommendation would be to setup a proper Certificate Authority hierarchy and issue your DCs Certificates.
A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by client computers in your organization.
All certificate chains terminate at a root CA, whether you use enterprise or stand-alone CAs, you need to designate a root CA.
A root CA serves as the foundation upon which you base your CA trust model, it guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues.
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority

 

Testing! 
It’s always a good idea to test that it’s all actually working as intended.
To do this, you can use tools such as 'ldp.exe' (available on DC servers and as part of the AD DS management tools)

 

If the following configurations connect successfully then you should be good to go:

(Host: FQDN of DC server. For example, <DC01.AD.example.company.net> This is so that there are no name mismatches when validating the certificate.)

 

Security: Simple authentication with:
- SSL( / TLS) on port 636
- TLS on port 389
- SASL on port 389

 

* A “simple bind” over LDAPS (TCP/636) will continue to work, but poses no security risk as all LDAPS communication is now encrypted using SSL/TLS - However, a simple bind over LDAP (TCP/389) should not.

 

Enable and enforce LDAP policy

How do we enforce and implement these LDAP policies?
In the Registry, you can dynamically enforce the new LDAP policy by changing the values of the current DWORD keys or creating any missing entries.

  • Before you make any changes to your Domain Controllers, be thorough with collecting logs of which system that might be affected by these changes.

  • Implement changes to the system and/or applications to use SSL/TLS, before enforcing LDAP policy.

 

Enforce LDAP Signing

Policy Setting: Domain Controller: LDAP Server signing requirements.
Registry Setting: LDAPServerIntegrity
DataType: DWORD
Registry Path: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

This Registry entry is a preexisting entry:

Group Policy Setting

Registry Setting

None

1

Require Signing

2

 

LDAPServerIntegrity = ‘2’ (Enforced Policy)

Enforce LDAP Binding

Policy Setting: Domain Controller: LDAP Server channel binding token requirements.
Registry Setting: LdapEnforceChannelBinding
DataType: DWORD
Registry Path: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

This Registry entry needs to be created (DWORD):

Group Policy Setting

Registry Setting

Never

0

When Supported

2

Always

3


LdapEnforceChannelBinding
= ‘3’ (Enforced Policy)

Rollback plan

The rollback plan is quite simple.

Either, you could take a “backup” of the Registry before making any changes.
In Registry, click on ‘File’ menu, and click ‘Export’ and select a location where you want to save the Registry-backup(.reg) file.

However, since these registry keys are dynamically updated, you could just change the value of the DWORD value to rollback to your previous state. (no reboot required)

 

LDAP Binding rollback:

Rollback policy, by changing the value:
‘\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding
LdapEnforceChannelBinding = ‘0’ (Never/Disabled)

LDAP Signing rollback:

Rollback policy, by changing the value:
‘\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrityLDAPServerIntegrity’ = ‘1’ (None/Disabled)

 

More Information and reference

Here is some referance to Microsoft website.

2020 LDAP channel binding and LDAP signing requirements for Windows

How to enable LDAP signing in Windows Server

 

I hope you found this blog post useful

#AtYourService
Magnus Qvist

Subscribe to blog