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.
Активируем LDAP over SSL (LDAPS) в Windows Server 2012 R2
По-умолчанию в Active Directory трафик по протоколу LDAP между контроллерами домена и клиентами не шифруется, т.е. данные по сети передаются в открытом виде. Потенциально это означает, что злоумышленник с помощью снифера пакетов может прочитать эти данные. Для стандартной среды Windows среды это в общем-то не критично, но ограничивает возможности разработчиков сторонних приложений, которые используют LDAP.
Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.
Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.
В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).
Отметим, что LDAPS преимущественно используется сторонними приложениями (имеются в виде не-Microsoft клиенты) в целях защиты передаваемых по сети данных (обеспечить невозможности перехвата имена и паролей пользователей и других приватных данных).
Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.
На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage. 
Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template. 
На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory). 
На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.
На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.
Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.
На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).
В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).
Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.
Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer 
А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).
certmgr.exe -add C:\ca_name.cer -s -r localMachine ROOT
Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.
Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.
