2020 LDAP channel binding and LDAP signing requirements for Windows

Introduction

LDAP channel binding and LDAP signing provide ways to increase the security for communications between LDAP clients and Active Directory domain controllers. A set of unsafe default configurations for LDAP channel binding and LDAP signing exist on Active Directory domain controllers that let LDAP clients communicate with them without enforcing LDAP channel binding and LDAP signing. This can open Active Directory domain controllers to an elevation of privilege vulnerability.

This vulnerability could allow a man-in-the-middle attacker to successfully forward an authentication request to a Microsoft domain server which has not been configured to require channel binding, signing, or sealing on incoming connections.

Microsoft recommends administrators make the hardening changes described in ADV190023.

On March 10, 2020 we are addressing this vulnerability by providing the following options for administrators to harden the configurations for LDAP channel binding on Active Directory domain controllers:

Domain controller: LDAP server channel binding token requirements Group Policy.

Channel Binding Tokens (CBT) signing events 3039, 3040, and 3041 with event sender Microsoft-Windows-Active Directory_DomainService in the Directory Service event log.

Important: The March 10, 2020 updates, and updates in the foreseeable future, will not change LDAP signing or LDAP channel binding default policies or their registry equivalent on new or existing Active Directory domain controllers.

The LDAP signing Domain controller: LDAP server signing requirements policy already exists in all supported versions of Windows.

Why this change is needed

The security of Active Directory domain controllers can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as the Negotiate, Kerberos, NTLM, and Digest protocols.

Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle (MiTM) attacks in which an intruder captures packets between the client and the server, changes the packets, and then forward them to the server. If this occurs on an Active Directory Domain Controller, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client. LDAPS uses its own distinct network port to connect clients and servers. The default port for LDAP is port 389, but LDAPS uses port 636 and establishes SSL/TLS upon connecting with a client.

Channel binding tokens help make LDAP authentication over SSL/TLS more secure against man-in-the-middle attacks.

March 10, 2020 updates

Important The March 10, 2020 updates do not change LDAP signing or LDAP channel binding default policies or their registry equivalent on new or existing Active Directory domain controllers.

Windows updates to be released on March 10, 2020 add the following features:

New events are logged in the Event Viewer related to LDAP channel binding. See Table 1 and Table 2 for details of these events.

A new Domain controller: LDAP server channel binding token requirements Group Policy to configure LDAP channel binding on supported devices.

The mapping between LDAP Signing Policy settings and registry settings are included as follows:

Policy Setting: «Domain controller: LDAP server signing requirements»

Registry Setting: LDAPServerIntegrity

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

Group Policy Setting

The mapping between LDAP Channel Binding Policy settings and registry settings are included as follows:

Policy Setting: «Domain controller: LDAP server channel binding token requirements»

Registry Setting: LdapEnforceChannelBinding

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

Group Policy Setting

Table 1: LDAP signing events

The security of these domain controllers can be significantly improved by configuring the server to enforce validation of LDAP signing.

Triggered every 24 hours, on startup or start of service if the Group Policy is set to None. Minimum Logging Level: 0 or higher

The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.

Triggered every 24 hours when Group Policy is set to None and at least one unprotected bind was completed. Minimum Logging Level: 0 or higher

The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.

Triggered every 24 hours when Group Policy is set to Require Signing and at least one unprotected bind was rejected. Minimum Logging Level: 0 or higher

The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.

Triggered when a client does not use signing for binds on sessions on port 389. Minimum Logging Level: 2 or higher

The following client performed an LDAP bind over SSL/TLS and failed the LDAP channel binding token validation.

Triggered when a client attempts to bind without valid CBT. Minimum logging level: 2

During the previous 24 hour period, # of unprotected LDAPs binds were performed.

Triggered every 24 hours when CBT Group Policy is set to Never and at least one unprotected bind was completed. Minimum logging level: 0

The security of this directory server can be significantly improved by configuring the server to enforce validation of LDAP channel binding tokens.

Triggered every 24 hours, on startup or start of service if the CBT Group Policy is set to Never. Minimum logging level: 0

To set the logging level in the registry, use a command that resembles the following:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v «16 LDAP Interface Events» /t REG_DWORD /d 2

For more information how to configure Active Directory diagnostic event logging, see the following article in the Microsoft Knowledge Base:

314980 How to configure Active Directory and LDS diagnostic event logging

Recommended actions

We strongly advise customers to take the following steps at the earliest opportunity:

Install the March 10, 2020 Windows updates on domain controller (DC) role computers when the updates are released.

Enable LDAP events diagnostic logging to 2 or higher.

Monitor Directory services event log on all DC role computers filtered for:

LDAP Signing failure event 2889 listed in Table 1.

LDAP Channel Binding failure event 3039 in Table 2.

Note Event 3039 can only be generated when Channel Binding is set to When Supported or Always.

Identify the make, model, and type of device for each IP address cited by event 2889 as making unsigned LDAP calls or by 3039 events as not using LDAP Channel Binding.

Group device types into 1 of 3 categories:

Appliance or router

Contact the device provider.

Device that does not run on a Windows operating system

Verify that both LDAP channel binding and LDAP signing are supported on the operating system and then application by working with the operating system and application provider.

Device that does run on a Windows operating system

LDAP signing is available to use by all applications on all supported versions of Windows. Verify that your application or service is using LDAP signing.

LDAP channel binding requires that all Windows devices have CVE-2017-8563 installed. Verify that your application or service is using LDAP channel binding.

Use local, remote, generic, or device-specific tracing tools including network captures, process manager, or debug traces to determine whether the core operating system, a service, or an application is performing unsigned LDAP binds or is not using CBT.

Use Windows Task Manager or equivalent to map the process ID to process, service, and application names.

Security update schedule

The March 10, 2020 updates will provide controls for administrators to harden the configurations for LDAP channel binding and LDAP signing on Active Directory domain controllers. We strongly advise customers to take the actions recommended in this article at the earliest opportunity.

Required: Security Update available on Windows Update for all supported Windows platforms.

Note For Windows platforms that are out of standard support, this security update will only be available through the applicable extended support programs.

LDAP channel binding support was added by CVE-2017-8563 on Windows Server 2008 and later versions. Channel binding tokens are supported in Windows 10, version 1709 and later versions.

Windows XP does not support LDAP channel binding and would fail when LDAP channel binding is configured by using a value of Always but would interoperate with DCs configured to use more relaxed LDAP channel binding setting of When supported.

Windows 10, version 1909 (19H2)

Windows Server 2019 (1809 \ RS5)

Windows Server 2016 (1607 \ RS1)

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2 SP1 (ESU)

Windows Server 2008 SP2 (Extended Security Update (ESU))

Frequently asked questions

For answers to frequently asked questions about LDAP channel binding and LDAP signing on Active Directory domain controllers, see Frequently asked questions about changes to Lightweight Directory Access Protocol.

What is LDAP Authentication?

February 1, 2021

Quick Links

Guide

The IT Admin’s Guide for Managing a Remote Environment

Read this guide to keep employees secure and productive wherever they work.

Updated on February 1, 2021

The Lightweight Directory Access Protocol, or LDAP for short, is one of the core authentication protocols that was developed for directory services. LDAP historically has been used as a database of information, primarily storing information like:

• Users
• Attributes about those users
• Group membership privileges
• … and more

This information was then used to enable authentication to IT resources such as an application or server. They would be pointed to the LDAP database, which would then validate whether that user would have access to it or not. That validation would be done passing a user’s credentials. As a result, a common question is: what is LDAP authentication? Continue reading for the answer to this question, and to learn how the JumpCloud Directory Platform can deliver LDAP authentication as a cloud-based service.

Origins of LDAP

Before we define what LDAP authentication is, we should talk about the significance of LDAP as a whole. According to Tim Howes, co-inventor of the LDAP protocol, LDAP was developed at the University of Michigan where Tim was a graduate student to initially replace DAP (the Directory Access Protocol) and provide low-overhead access to the X.500 Directory – the directory service that LDAP would eventually replace.

I was in a group of young upstarts who were trying to bring Unix and the Internet to campus. The Internet was just emerging, and the International Organization for Standardization (ISO) was creating standards for everything related to the Internet, including email and directory services. So, we were working with X.500, which was ISO’s standard for directory services. At that time, I was also working for the University’s information technology division. I was assigned this project to deploy an X.500 directory for the campus, which I completed, but I quickly learned that it was way too heavy of a protocol and too complicated for the machines that were on most people’s desktops. LDAP came out of my desire to do something a little lighter weight in order to accommodate the Macs and PCs that were on everybody’s desktop.”

LDAP has been highly successful ever since it was first introduced in 1993. In fact, LDAP.v3 became the Internet standard for directory services in 1997, according to Wikipedia. LDAP also inspired the creation of OpenLDAP ™ , the leading open source directory services platform, which spawned numerous other open source solutions based on LDAP (389 Directory, Apache Directory Service, Open Directory, and more), and formed the foundation for Microsoft ® Active Directory ® (AD) in the late 1990s. LDAP is even a core aspect of modern cloud directories like JumpCloud Directory Platform. So, it’s safe to assume that LDAP authentication will be a foundational element of identity management for years to come despite its age.

Interview with Tim Howes, Co-Creator of LDAP

Basic LDAP Authentication and Common Challenges

LDAP authentication follows the client/server model. In this scenario, the client is generally an LDAP-ready system or application that is requesting information from an associated LDAP database and the server is, of course, the LDAP server. The server side of LDAP is a database that has a flexible schema. In other words, not only can LDAP store username and password information, but it can also store a variety of attributes including address, telephone number, group associations, and more. As a result, a common LDAP use case is to store core user identities.

In doing so, IT can point LDAP-enabled systems and applications (for example) to an associated LDAP directory database, which acts as the source of truth for authenticating user access.

How does LDAP authentication between a client and server work?

So, how does LDAP authentication between a client and server work? In short, a client sends a request for information stored within an LDAP database along with the user’s credentials to an LDAP server. The LDAP server then authenticates the credentials submitted by the user against their core user identity, which is stored in the LDAP database. If the credentials submitted by the user match the credentials associated with their core user identity that is stored within the LDAP database, the client is granted access and receives the requested information (attributes, group memberships, or other data). If the credentials sent don’t match, the client is denied access to the LDAP database.

What does it take to implement LDAP?

While LDAP authentication has certainly proven to be effective, the amount of time required to implement and customize LDAP-based infrastructure to meet a modern organization’s identity management needs can be significant. Historically, LDAP has also been an on-prem implementation, requiring dedicated servers that must be integrated into an organization’s overall identity management infrastructure (which has also historically been on-prem).

This type of setup can be difficult to achieve, especially for smaller or cloud-forward IT organizations. After all, most modern organizations would like to shift their entire on-prem identity management infrastructure to the cloud. This has become an even greater priority as organizations shift to remote work. However, as more organizations replace their traditional on-prem infrastructure with cloud alternatives, the question becomes, “How do I provide LDAP authentication without anything on-prem?”

Cloud-Based LDAP Authentication

Fortunately, a next generation cloud directory platform has emerged that can provide LDAP authentication as a cloud-based service. It’s called JumpCloud Directory Platform, and it not only provides cloud-based LDAP authentication, but also securely manages and connects users to their systems, applications, files, and networks without anything on-prem. This is because the JumpCloud directory platform has taken a cross-platform (e.g., Windows ® , macOS ® , Linux ® ), vendor neutral (e.g., Microsoft ® , Google ® , AWS ® ), protocol driven approach (e.g., LDAP, SAML, RADIUS, SSH, OAuth, and more) to managing modern IT networks. The end result is that IT organizations are free to leverage the best resources for them, knowing they can effectively manage it all with JumpCloud.

Learn More about JumpCloud LDAP Authentication

We hope this was helpful, but if you’re still asking, “What is LDAP Authentication?” We invite you to sign up for a free account or schedule a demo to see JumpCloud LDAP authentication in action. We offer 10 free users and 10 systems to help you explore the full functionality of our platform, including JumpCloud Cloud LDAP, at no cost. Of course, you are also more than welcome to contact the JumpCloud team if you have any questions. We also offer 10 days of premium 24×7 in-app chat support to help you get started.

General LDAP FAQ

How does LDAP work with Active Directory?

LDAP provides a means to manage user and group membership stored in Active Directory. LDAP is a protocol to authenticate and authorize granular access to IT resources, while Active Directory is a database of user and group information.

What is LDAP injection?

LDAP injection occurs when a bad actor uses manipulated LDAP code to modify or divulge sensitive user data from LDAP servers. Prevent malicious injections with LDAP filter validation and by checking the LDAP client applications.

Where do we use LDAP?

LDAP is used as an authentication protocol for directory services. We use LDAP to authenticate users to on-prem and web applications, NAS devices, and SAMBA file servers.

Is LDAP secure?

In order to secure communications, LDAP transactions must be encrypted using an SSL/TLS connection. To set up, use either LDAPS on port 636 or StartTLS on the standard LDAP 389 port.

What is the difference between Kerberos and LDAP?

While both are network protocols used for authentication (verification of a user’s ID), LDAP differs in that it can also authorize (determine access permissions) clients and store user and group information.