LDAP or LDAPS? Hardening with encrypted LDAP in your Active Directory

Today I'm bringing you a short (I wrote this at the beginning) guide in which we'll learn how to differentiate between LDAP, LDAPS, and LDAP Secure. Our goal is to understand these differences, put them into practice, and finally audit and prepare our environment to apply one of the most important CIS controls for Active Directory:

2.3.5.4 Security Options: Domain controller: LDAP server signing requirements recommended state is Require signing

LDAP, LDAPS and LDAP Secure

Let's start with the question: what are the differences between LDAP, LDAPS, and LDAP Secure? To be honest, we can find ambiguous and contradictory explanations online, so I'll just try to highlight those differences:

• LDAP : This is the basic protocol. It uses port 389 and allows us to choose if we want signing or not.

• LDAPS : It is an extension of LDAP that encrypt communications with a TLS certificate. It uses port 636.

• LDAP Secure: Sometimes this term is referred to as a synonym for LDAPS, while at other times it is interpreted as the use of LDAP with security conditions (signature and sealing).

So, what does the aforementioned CIS control refer to? It points to encrypted LDAP... it's essentially the second concept we covered regarding LDAP Secure. To comply with the CIS control, you need to use either LDAPS or signed LDAP. Therefore, if you're asked: no, this doesn't mean that LDAPS must be used throughout the entire domain . LDAP will still be used. Furthermore, closing ports or attempting to block LDAP is not recommended, as it goes against the Active Directory architecture.

Policies for requiring signed and/or sealed LDAP

Active Directory has policies requiring signed and/or sealed LDAP for both the server (DC) and the client. We have two different policies for the server and two more for the client.

For both Domain Controllers and clients, it's worth noting that since Windows Server 2022 23H2, new security policies have been added that, by default, enforce LDAP signing in Windows Server 2022 23H2 and Windows Server 2025. Let's review all these settings:

1st Policy for DCs

• Path: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directive: "Domain controller: LDAP server signing requirements"

• Values: "Never", "Require Signing"

Equivalent registry key

• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

• Key: LDAPServerIntegrity

• DWORD

• Values: 1,2

Depending on the value we choose, these will be the behaviors:

None (1)

With this value, the least secure LDAP connections are allowed:

• Simple Bind with LDAP (389).

• Bind with SASL without signing with LDAP (389).

Require Signing (2)

With this value, the previous connections are prohibited, allowing the other ones:

• Any type of bind with LDAPS (636).

• Bind with SASL signed with LDAP (389).

2nd policy for DCs (WS2022 23H2 and WS2025)

• Path: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directive: "Domain controller: LDAP server signing requirements Enforcement"

• Values: "Disabled", "Enabled"

Equivalent registry key

• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

• Key: LDAPServerEnforceIntegrity

• DWORD

• Values: 0, 1

Depending on the value we choose, these will be the behaviors:

Disabled (0)

With this value, the LDAPServerIntegrity registry key takes control of the actions.

Enabled (1)

With this value, only the following connections are allowed:

• Any type of bind with LDAPS (636).

• Bind with SASL signed with LDAP (389).

1st policy for client machines

• Path: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directive: "Network security: LDAP client signing requirements"

• Values: "None", "Negotiate Signing", "Require Signing"

Equivalent registry key

• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\

• Key: LDAPClientIntegrity

• DWORD

• Values: 0, 1, 2

Depending on the value we choose, these will be the behaviors:

None (0)

This value allows unsigned LDAP connections.

Negotiate Signing (1)

This setting allows the user to choose whether or not to perform an LDAP with signature, but only if they are using TLS (636). Otherwise, the signature will be mandatory.

Require Signing (2)

This value forces all LDAP connections to be signed, whether they use TLS or not.

2nd policy for client machines (WS2022 23H2, WS2025 and W11)

• Path: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directive: "Network security: LDAP client encryption requirements"

• Values: "None", "Negotiate Sealing", "Require Sealing"

Equivalent registry key

• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\

• Key: LDAPClientConfidentiality

• DWORD

• Values: 0, 1, 2

None (0)

This value allows LDAP connections without being sealed.

Negotiate Sealing (1)

This setting allows the user to choose whether or not to perform LDAP sealing, but only if they are using TLS (636). Otherwise, sealing and signing will be mandatory.

Require Sealing (2)

This value requires signing and sealing all LDAP connections, whether they use TLS or not.

LDAP Audit

For both testing and identifying devices that are insecurely consuming LDAP, we recommend modifying this registry key on the Domain Controllers:

• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

• Key: 16 LDAP Interface Events

• DWORD

• Value: 0x2 or more

After completing the tests/audit, we can revert the value to what it was before.

How to check the policy

In a LAB environment, we can configure policies and registry keys and cause errors with those connections that do not conform to the security standards we have already described.

To perform these tests we will need:

• Some machines. We will use up to 4 different ones, although depending on the tests to be carried out, the number can be reduced to 2. These are the ones we used:

• A valid LDAPS certificate on the DC. From a Windows Server CA, we can use the "Kerberos Authentication" template for this.

• Follow the order established by your domain's policies . The Default Domain Controllers Policy has "Domain controller: LDAP server signing requirements" set to None by default. To override this, I recommend prioritizing the policies you're about to create.

• The registry key 16 LDAP Interface Events with a value of 0x2 to improve auditing and thus obtain events that correlate the actions we perform with their result.

• A network traffic examination tool like Wireshark can be useful for examining the actual behavior of LDAP.

From a client, we will access ldp.exe and perform the following set of tests in each of the next sections:

• Simple Bind.

• Bind SASL with NTLM and without checking the encrypt traffic checkbox.

• Bind SASL with NTLM and check the checkbox to encrypt traffic.

Each test requires a new connection (Connection/Disconnect) and that we go through port 389 without SSL or port 636 with SSL.

LAB testing

For testing purposes, we will be continuously modifying these four policies:

• Domain controller: LDAP server signing requirements Enforcement (WS2022 23H2 or WS2025)

• Domain controller: LDAP server signing requirements

• Network security: LDAP client encryption requirements (WS2022 23H2, WS2025 or W11)

• Network security: LDAP client signing requirements

As we highlighted, there are two policies exclusive to the newer versions of Windows Server. Furthermore, client policies require a machine restart to function correctly.

Test 1: Unsafe Mode

We'll start with the insecure tests, so we'll set all policies to None and Disabled .

These should be the results in events and network trace:

• LDAP with Simple Bind : On the DC we have event 2889 with binding type 1. The password is seen in plain text in the network trace.

• LDAP with Bind SASL (NTLM) and unencrypted traffic : On the DC we have event 2889 with binding type 0. In the network trace, the Negotiate Sign flag is set to 0.

• LDAP with NTLM and encrypted traffic : We do not have event 2889 on the DC. The network trace shows the Negotiate Sign flag with a value of 1.

• LDAPS with any bind : We have no event 2889 on the DC. The network trace shows everything encrypted with TLS.

In all cases, the bind will be allowed and subsequently allow us to perform LDAP queries.

Test 2: Require Signing in DCs

This time, we've left the Domain Controller policy with the value Require Signing (2). In WS2022 23H2 and WS2025, we can choose to set its Enforcement policy to Enabled (1). After a gpupdate, we can see the effects in the tests. The only difference from the previous tests is that we will no longer be allowed to:

• LDAP with Simple Bind

• LDAP with Bind SASL and unencrypted traffic.

In the output of ldp.exe we will see errors like this:

0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 0)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NTLM (4230)); //v.3
{NtAuthIdentity: User='adrian'; Pwd=<unavailable>; domain = 'lab1.local'}
Error <8>: ldap_bind_s() failed: Strong Authentication Required.
Server error: 00002028: LdapErr: DSID-0C090343, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v65f4
Error 0x2028 A more secure authentication method is required for this server.

This block will prevent us from proceeding with LDAP queries; the bind is invalid.

Test 3: Negotiate/Require Signing on client

We reset the Domain Controller policy to None (1) and/or Disabled (0) and modify the client-side policy to Negotiate Signing (1). We restart the client. The results are now slightly different:

• LDAP with Simple Bind : On the DC we have event 2889 with binding type 1. The password is seen in plain text in the network trace.

• LDAP with Bind SASL (NTLM) and unencrypted traffic : We do not have event 2889 on the DC. The network trace shows the Negotiate Sign flag with a value of 1.

In the case of Simple Bind, it's again allowed even without encryption. With SASL, even though we didn't select the option to encrypt traffic after binding, the policy forces us to do so. In this state, it makes no difference whether we select it or not; the OS will always sign LDAP.

If we set the policy to Require Signing (2), the test would initially yield the same result. The difference would arise when using LDAPS, but to see the differences, we would need to decrypt the TLS traffic. If we didn't check the "Encrypt traffic after bind" box and examined the trace, we would observe that Negotiate Signing would be followed (Negotiate Sign with a value of 0), while Require Signing would not (Negotiate Sign with a value of 1).

Test 4: Negotiate/Require Sealing on client (WS2022 23H2, WS2025 or W11)

By setting the Signing policy back to None, newer Microsoft operating systems allow us to observe a new behavior with the "client encryption requirements" policy. If we select Negotiate Sealing or Require Sealing, we will see this difference in the network trace:

• LDAP with Bind SASL (NTLM) and unencrypted traffic : We have no event 2889 on the DC. The network trace shows the Negotiate Sign and Negotiate Seal flags with a value of 1.

In other words, this policy adds another layer of security, forcing LDAP signing just like the previous one does, but also forcing LDAP sealing.

How to track the hardening process in a production environment

Enforcing the use of signed LDAP is practically a legal requirement. Microsoft has released new products like Windows 11 and Windows Server 2025 where unsigned and unencrypted LDAP communications are disabled by default. Several policies need to be modified to maintain compatibility, and Microsoft will likely enforce the use of signed or encrypted LDAP in the future.

However, every change involves a process. Initially, we recommend auditing 2889 events and applying client-side hardening policies to all devices that do not report insecure LDAP communications.

For the systems that do generate 2889 events, we will need to contact the responsible teams (we have their hostnames, IP addresses, and the user account that was used) to review where unencrypted LDAP is being used and determine a reasonable timeframe for its removal. We will likely encounter applications that will not function without this security improvement. In this regard, we will need to assess the financial outlay required to migrate them, aiming to complete the migration by a specific date. The financial aspect might cause a delay in hardening, but it should never be a blockage... or do we intend to maintain a serious vulnerability in 10 years?

If 2889 events continue to appear and we are unable to identify the cause, we can always opt for a granular application of Domain Controller policies. We can also apply this for a reasonable period (for example, 8 hours) to see if there is an impact, notifying the machine owners to be alert for any reported issues. The ultimate goal should be for all machines in the domain to have "Require Signing" and "Require Sealing" enabled, while the Domain Controllers should have "Require Signing" and the enforcement policy set to "Enabled".

Sources of interest

How to enable LDAP signing - Windows Server | Microsoft Learn

2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412) - Microsoft Support

AD and LDS diagnostic event logging - Windows Server | Microsoft Learn

LDAP Channel Binding and LDAP Signing Requirements - Server 2025 updates | Microsoft Community Hub

Active Directory Hardening Series - Part 3 – Enforcing LDAP Signing | Microsoft Community Hub