In August 2018, Microsoft issued a security advisory ADV190023 Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing about unsigned LDAP communication blocking in Active Directory starting with March 2020. A quick poll identified that not all customers are aware about upcoming changes or have prepared to them.

What is LDAP Binding?

LDAP binding is a set of operations used to authenticate and authorize clients on LDAP server (domain controller). Along with authentication credentials, clients send LDAP connection configuration or settings (such as signing requirement) to use in subsequent messages within same connection. There are two LDAP bind types: simple bind and Simple Authentication and Security Layer (SASL). In simple bind, client authenticates on LDAP server by submitting account name and password in clear text form. SASL allows different authentication options that do not require password transmission in clear text. Such options include the use of NTLM and Kerberos. Microsoft products use only SASL bind type. Despite the fact that SASL is more secure, it doesn’t guarantee message integrity unless LDAP over TLS is used.

Description

In short, in March 2020, Microsoft is going to release a security update that will reject all incoming connections on domain controllers using unsigned LDAP. Using default OS configuration, Microsoft clients and servers do not require message signing when authenticating and communicating over LDAP. This means that if you don’t prepare your network to require LDAP signing will fail to communicate to domain controllers. On the other hand, domain controllers will stop receiving unsigned messages. Consequences will result in a massive domain outage.

Although, security update released in March 2020 will put both, domain controllers and domain members into consistent state (require signing), you will still experience connection issues because systems don’t install update at same time. For example, if domain controllers receive update before clients, they will stop receive connections from unpatched clients. Therefore, it is highly recommended to gracefully configure clients and domain controllers to use LDAP signing in advance. See Reference Materials section below for more details.

Mitigation for Microsoft Windows

In order to mitigate the vulnerability and possible outage caused by the update, configure LDAP signing requirements on domain controllers and Active Directory clients prior to installing the update. We recommend to perform systems configuration in this sequence:

  1. Configure clients to request LDAP signing;
  2. When all clients receive this configuration, configure domain controllers to require signing;
  3. Configure clients to require signing.

This sequence ensures that no client will stop working during transition.

Configure Clients to request signing

Use steps below to configure clients to request LDAP signing:

  1. On domain member with GPMC (Group Policy Management Console) installed, open GPMC console (gpmc.msc);
  2. Expand Forest\Domains\Current Domain\Group Policy Objects;
  3. Create new GPO item and provide GPO name (say, Client LDAP Signing);
  4. Edit created GPO;
  5. Expand Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options;
  6. Open Network security: LDAP client signing requirements item and select Negotiate Signing option;
  7. Link GPO to domain level.
  8. Repeat steps 1-7 for every domain in the forest.

Wait until all clients receive and apply new GPO.

Configure Domain Controllers to require signing

When new GPO is applied, create new GPO to configure domain controllers:

  1. On domain member with GPMC (Group Policy Management Console) installed,
    open GPMC console (gpmc.msc);
  2. Expand Forest\Domains\Current Domain\Group Policy Objects;
  3. Create new GPO item and provide GPO name (say, Server LDAP Signing);
  4. Edit created GPO;
  5. Expand Computer Configuration\Policies\Windows Settings\Security
    Settings\Local Policies\Security Options
    ;
  6. Open Domain controller: LDAP server signing requirements item and
    select Require Signing option;
  7. Link GPO to “Domain Controllers” container.
  8. Repeat steps 1-7 for every domain in the forest.

Wait until all domain controllers receive and apply new GPO. Test if all systems are able to communicate with domain controllers. In the event of failure, revert signing requirements to “None” and consult with vendor support to identify and resolve the problem.

Configure Clients to require signing

Use steps below to configure clients to require LDAP signing:

  1. On domain member with GPMC (Group Policy Management Console) installed, open GPMC console (gpmc.msc);
  2. Expand Forest\Domains\Current Domain\Group Policy Objects;
  3. Edit previously created GPO (Client LDAP Signing);
  4. Expand Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options;
  5. Open Network security: LDAP client signing requirements item and select Require Signing option;
  6. Repeat steps 1-5 for every domain in the forest.

Wait until all clients receive and apply new GPO. Then all domain members are ready to install new update referenced in security advisory.

Mitigation for other platforms

If your network contains non-Microsoft systems (*nix systems, firewalls/gateways, etc.) that communicate with AD domain controllers, it is highly recommended to contact manufacturer of that particular system for support.

Note: Advisory update doesn’t affect clients that use simple bind to authenticate on domain controllers. However, the use of simple bind is strongly discouraged unless LDAP over TLS is used, because simple bind exposes client password in clear text.

Reference Materials

15 Comments

  1. Avatar Tango on January 23, 2020 at 2:37 am

    To clarify , do I need to change software that connects via LDAP to DCs eg McAfee ePo/Moodle etc to use LDAPS or 3269 instead as well as enabling the group polcies in the article ?

    Thanks

    • Vadims Podāns Vadims Podāns on January 23, 2020 at 2:49 am

      As far as I understand, no need to change configuration when LDAP over TLS is used. LDAPS provides message integrity and privacy via TLS.

      • Avatar Tango on January 23, 2020 at 3:23 am

        So any systems that are just LDAP (389/GC (3268) need to be reconfigured to LDAPS (636)/GC (3289).
        It also looks as though Mac sytems are connecting using LDAP , I guess these will need changed too 🙂

        Thanks for your help.

        • Vadims Podāns Vadims Podāns on January 23, 2020 at 3:25 am

          Either, move to LDAPS, or just enable signing as mentioned in the article.

  2. Avatar Erwin van Rens on January 23, 2020 at 3:22 am

    No, the change above just adds a signature (i.e. a Hash) to the LDAP request, so both sides can validate message integrity. You can still perform queries over LDAP port 389.
    If you want to be even more secure then you would disable LDAP over port 389, and move completely to LDAPS over port 3269, however this may have additional impact as LDAPS requires your Domain Controllers to have a Certificate trusted by Clients (and any other LDAP Requestors like you mention). Especially Domain Join may become troublesome, as most AD Domains that use ADCS only distribute the internal root certificate and/or Domain Controller certificates to the CLient’s Trust List after DOmain Join.

    • Avatar Janus on January 27, 2020 at 9:48 pm

      Hi,

      So it’s either perform the signing for windows client and servers or implement ldaps?

      Thanks!

      • Vadims Podāns Vadims Podāns on January 27, 2020 at 11:57 pm

        exactly. LDAPS is more secure, since it offers privacy (encryption), but more expensive in implementation and maintenance.

  3. Avatar Janus on January 28, 2020 at 9:59 am

    Why is ldaps is expensive? Is it because of the certificate?

    From what I see channel binding/signing is geared more towards windows machine targets while ldaps is with non windows systems.

  4. Avatar Ryan on January 30, 2020 at 10:16 am

    What about LDAP Channel binding? Do we need to perform this as well? I’ve tested the LDAP signing using Ldp.exe and the GPO signing is working as intended. But I’m also seeing a lot about LDAP Channel Binding. Any advice would be great!

  5. Vadims Podāns Vadims Podāns on February 1, 2020 at 1:55 am

    Yes, LDAP Channel binding is affected by this update as referenced in original Microsoft statement. Use this article for more information about how to require secure channel binding: https://support.microsoft.com/en-us/help/4034879

  6. Avatar Mike on February 4, 2020 at 2:08 am

    The Microsoft article states that the March update “do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers”, but merely enables the future change. Then the actual changes will occur in a “further future monthly update”.

  7. Avatar Choi on February 5, 2020 at 2:23 pm

    I am currently working on this for our clients in regards to the March update.

    Please forgive me for my noob question.

    So if I were to simply setup the required signing per the steps above, it will still allow LDAP connections and binds?

    I have SonicWall appliances that use LDAP for authentication. will those need to be updated to LDAPS with a 3rd party cert?

    • ThePKIGuy ThePKIGuy on February 11, 2020 at 3:51 pm

      You don’t have to switch to LDAP/S. LDAP connection will still be allowed, they just must use the new LDAP signin/verification process. If you have apps on platforms other than windows that are performing LDAP lookups, they may break if they don’t support the new signing. For example a Cisco RADIUS server (for illustration purposes only) that is unable to perform this signing would no longer function after this update is pushed if it was using LDAP (instead of LDAP/S).

      So basically, LDAP/S – no change. LDAP – Requires new signing capabilities

  8. Avatar tchamabe cedric on February 11, 2020 at 11:58 am

    is this applicable to Windows Server 2016?

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.