The use of unencrypted LDAP poses a risk. It allows attackers to exploit a vulnerability to gain elevated privileges. These, in turn, can be used for man-in-the-middle attacks. Several LDAP settings can help admins protect their systems against these threats.
Philip Lorenz

To eliminate this security hole, Microsoft initially wanted to activate LDAP signing and channel binding via an update by default. However, this plan has now been replaced by an explicit recommendation, which can be found in the support document ADV190023.

There are several articles on the internet that compare LDAP signing with LDAP over SSL (LDAPS). However, the latter is a certificate-based protocol that is technically different from LDAP signing.

Although LDAPS also eliminates the risk of a possible man-in-the-middle attack, Microsoft recommends the use of LDAP signing and channel binding instead. The following sections explain the various techniques in detail, including their differences.

LDAPS

Domain controllers and clients are in constant exchange. The LDAP protocol, which communicates via port 389 (TCP and UDP), is primarily used for this purpose. Clients use this protocol to send authentication requests to domain controllers, Exchange servers query mail addresses, and domain admins manage Active Directory via this protocol.

Therefore, it is obvious that LDAP traffic should be encrypted. LDAPS protects the connection by using SSL certificates. It should be noted that the encrypted version does not communicate via port 389, but via 636.

To find out whether connecting via LDAPS is possible, use the tool ldp.exe, which is part of RSAT. First, check whether an unencrypted connection to the server over port 389 is rejected. Communication via LDAPS can be tested on port 636 by checking the SSL box.

Validating the LDAPS connection with ldp.exe_

Validating the LDAPS connection with ldp.exe_

The disadvantage of LDAPS is that not all devices are compatible with it. Old telephone systems or legacy applications use LDAP for authentication and do not offer support for communication via SSL.

Furthermore, some administrators who manage small infrastructures and rarely work with servers are not familiar with certificate management and hence would prefer a simpler way of securing LDAP.

Channel binding

Channel binding connects the application layer with the transport layer. This creates a unique fingerprint for LDAP communication.

After a reconnect, which would happen with a man-in-the-middle attack, the previous fingerprint is no longer valid within the new connection.

LDAP signing

LDAP signing adds a digital signature to the connection. It ensures the authenticity and integrity of the transmitted data. This means that the recipient can verify the sender and determine whether the data has been manipulated along the way.

The mechanism can be configured via the registry of clients and servers, usually by means of group policy.

LDAP security, as recommended by Microsoft

It is important to follow the correct order when implementing this best practice. First, the clients must be configured to request LDAP signing (i.e., its use is optional).

Once this setting has been set via GPO, you now have to wait until this change affects all clients. Only then can you configure the domain controllers so that they require a signature. Finally, LDAP signing is also enforced on the clients. If you don't adhere to this sequence, then in the worst case no client can log on.

Configuring the clients

Using a new group policy, first change the settings Network security: LDAP client signing requirements.

This can be found under: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.

Group policy to prepare clients for LDAP signing

Group policy to prepare clients for LDAP signing

The option is set to Negotiate signing. Wait until the setting has been applied to all clients.

Adjusting the domain controller

As soon as the change has affected all clients, create another group policy. In the same path as in the previous step, modify the setting Domain controller: LDAP server signing requirements.

Enforce signing of the LDAP communication for the domain controller

Enforce signing of the LDAP communication for the domain controller

There, select the Require signing option. Then, link the GPO to the domain controller container.

Finalizing the clients

If the changes are now also active on the DCs, the group policy from the first step can be adapted so that the clients also require LDAP signing.

The option Network security: LDAP client signing requirements can now simply be changed from Negotiate signing to Require signing.

Activating channel binding

Channel binding is configured on the domain controllers by adding or modifying a corresponding entry in the registry. If it does not already exist, create a new DWORD entry under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters with the description LdapEnforceChannelBinding. The values to be assigned are as follows:

DWORD-Value 0: Disabled

DWORD-Value 1: Enabled, if supported

DWORD-Value 2: Always enabled

In the long term, a value of 2 is recommended, but for the transition phase, the option with a value of 1 can be a good compromise. After the change, the respective domain controller must be restarted.

Since the March 2020 update, the group policy Domain controller: LDAP server channel binding token requirements has been available for this purpose. There, you can choose between the options Never, When supported, and Always.

Configuring channel binding for domain controllers via GPO

Configuring channel binding for domain controllers via GPO

LDAP signing and channel binding are now active. You can now check this again using LDP.

Check channel binding using ldp.exe_

Check channel binding using ldp.exe_

After successfully connecting using port 389, you can use the bind option (accessible via Connection) to check whether the configuration is working correctly. To do this, select Simple bind and enter the login data of a user.

Subscribe to 4sysops newsletter!

The error message Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required should now appear, confirming successful configuration.

5 Comments
  1. Avatar
    RW 3 years ago

    I thought signing & sealing was the default for windows domain clients?

  2. Avatar
    Miha Pecnik 3 years ago

    Thank you for the article. Could you elaborate on “Although LDAPS also eliminates the risk of a possible man-in-the-middle attack, Microsoft recommends the use of LDAP signing and channel binding instead.”, where is that recommendation coming from? A link, KB would be appreciated.

  3. Avatar
    Lode 2 years ago

    Same here. Does this mean MS prefers LDAP signing and channel binding over LDAPS ?
    And if so what is the reason behind it?

  4. Avatar
    James 3 months ago

    My colleague already set the clients to require signature. The DCs are seet to negotiate. I guess we either risk it and now update DCs to required or follow best practices to change clients to negotiate and then the DCs to required and finally clients to required.

    The worse case is users can no longer in is quite a serious one so if it means more time, i am prepared to revert back the step and start again.

    Let me know your thoughts as I need to put the doc in to get this approved first so If it is worth just changing DCs to required now (as client already required), please let me know.

  5. Avatar
    James 3 months ago

    This is an excellent document. A great find of a site in fact.
    Better than the Microsoft article infact.
    Great work.

Leave a reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2024

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending
WindowsUpdatePreventer

Log in with your credentials

or    

Forgot your details?

Create Account