Windows Server Active Directory (AD) uses the Lightweight Directory Access Protocol (LDAP) to communicate between the directory service, clients, and applications. LDAP is an open, industry-standard protocol used for accessing directory services on Internet Protocol (IP) networks.
Clients and applications can authenticate with Active Directory using LDAP bind operations. There are several different kinds of bind operation, like simple, regular, and anonymous. Simple binds work by sending usernames and passwords over the IP network in cleartext. LDAP uses simple binds and Simple Authentication and Security Layer (SASL) binds for authentication. Active Directory accepts simple binds by default.
SASL adds sign and seal capability to simple binds to provide integrity and encryption. If you have apps that use simple binds, try to update them to use SASL. If you have apps that can’t be updated, then the next best alternative is to use LDAP over Transport Layer Security (TLS), or LDAPS as it is sometimes known. Like anything that involves TLS, it is more complicated to implement and manage than SASL because it requires a certificate.
Active Directory LDAP channel binding and LDAP signing
While AD accepts LDAP simple binds by default, all currently supported versions of Windows negotiate signed LDAP connections by default. You can enforce this by setting LDAP signing to ‘Required’ in Group Policy. For server LDAP signing, the setting is Domain controller: LDAP server signing requirements under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
If you set server signing to ‘Required’, be sure to also set all your clients to ‘Required’. For client LDAP signing, configure Network security: LDAP client signing requirements under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The default setting in Windows 10 is ‘Negotiate signing’.
If you set signing to ‘Required’, LDAP simple bind and LDAPS simple bind requests are rejected. No Windows Server or client SKUs use LDAP simple bind or LDAPS simple bind to connect to AD.
The easiest way to require LDAP signing in an AD domain is to set both the Network security: LDAP client signing requirements and Domain controller: LDAP server signing requirements settings to ‘Required’ in the Default Domain Policy and Default Domain Controller Group Policy Objects (GPO). For more information about creating and applying GPOs, see How to Create and Link a Group Policy Object in Active Directory on Petri.
LDAP channel binding
That brings us to LDAP channel binding. When users request access to domain-based server resources, like file shares, first the client authenticates with AD using LDAP. Channel binding tokens (CBT) connect the authentication session to a specific protocol, like Server Message Block (SMB) in the case of accessing a file share. The idea is to protect domains against relay vulnerabilities.
LDAP changes coming in March 2020
The first set of changes are due to be rolled out to Windows in March 2020. Initially, no changes to LDAP signing or channel binding settings will be made. Here is what Microsoft has to say about it:
Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.
A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.
Administrators can prevent the feature update from making those change either by enabling LDAP signing and channel binding NOW or by configuring non-default values prior to installing updates that enable LDAP signing and channel binding by default.
The changes are being made to address the default LDAP signing and channel binding settings on domain controllers, which could let LDAP clients communicate with AD without enforcing channel binding and signing. Microsoft has determined that the current default settings could expose AD to elevation of privilege vulnerabilities.
What you need to do to prepare for LDAP security changes
Although the changes were originally due to drop in January 2020, they are now being delayed until later in the year to give organizations more time to prepare. Only in the second half of 2020 will Microsoft push out changes to enable LDAP signing and channel binding on domain controllers that currently have the default settings.
But you need to be prepared one way or the other. You can find the full security advisory from Microsoft here, including advice on the new recommended settings. Be aware that changing LDAP signing and channel binding settings could cause compatibility problems with some applications.
In an upcoming article on Petri, I’ll show you how to check whether insecure LDAP binds are an issue in your environment so you can understand the impact of the upcoming changes. And then I’ll look at how you should configure your domain controllers to make sure they are secure.