Lightweight Directory Access Protocol

Purpose

The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs on a layer above the TCP/IP stack. It provides a mechanism used to connect to, search, and modify Internet directories.

The LDAP directory service is based on a client-server model. The function of LDAP is to enable access to an existing directory.

The data model (data and namespace) of LDAP is similar to that of the X.500 OSI directory service, but with lower resource requirements. The associated LDAP API simplifies writing Internet directory service applications.

Where applicable

The LDAP API is applicable to directory management and browser applications that do not have directory service support as their primary function. Conversely, LDAP is neither applicable to creating directories, nor specifying how a directory service operates.

Developer audience

The LDAP API documentation in the Platform Software Development Kit (SDK) is intended for experienced C and C++ programmers and Internet directory developers.

LDAP supports the C and C++ programming languages.

A familiarity with directory services and the LDAP Client/Server Model are necessary for the development with the LDAP API.

Run-time requirements

Client applications that use the LDAP API, run on WindowsВ Vista. All platforms must have TCP/IP installed.

Active Directory servers that support client applications using the LDAP API include Windows Server.

In this section

General information about the Lightweight Directory Access Protocol API.

Programmer’s guide to using the Lightweight Directory Access Protocol API.

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 used for?

I know that LDAP is used to provide some information and to help facilitate authorization.

But what are the other usages of LDAP?

16 Answers 16

I will focus on why using LDAP, not what is LDAP.

The use model is similar like how people use library cards or phonebooks. When you have a task that requires “write/update once, read/query many times”, you might consider using LDAP. LDAP is designed to provide extremely fast read/query performance for a large scale of dataset. Typically you want to store only a small piece of information for each entry. The add/delete/update performance is relatively slower compared with read/query because the assumption is that you don’t do “update” that often.

Imagine you have a website that has a million registered users with thousands of page requests per second. Without LDAP, every time users click a page, even for static page viewing, you will probably need to interact with your database to validate the user ID and its digital signature for this login session. Obviously, the query to your database for user-validation will become your bottleneck. By using LDAP, you can easily offload the user validation and gain significant performance improvement. Essentially, in this example, LDAP is another optimization layer outside your database to enhance performance, not replacing any database functions.

LDAP is not just for user validation, any task that has the following properties might be a good use case for LDAP:

You need to locate ONE piece of data many times and you want it fast

You don’t care about the logic and relations between different data

You don’t update, add, or delete the data very often

The size of each data entry is small

You don’t mind having all these small pieces of data at a centralized place

LDAP-«аутентификация» — это антипаттерн

Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.

Со временем LDAP стал службой аутентификации де-факто. Широко распространенные и доступные службы LDAP, такие, как Active Directory, стали лакомым кусочком для разработчиков программного обеспечения, которые хотят встроить аутентификацию в свои продукты. Клиентские библиотеки LDAP доступны практически для любого фреймворка, а реализовать интеграцию относительно легко.

Но несмотря на то, что применение LDAP может помочь решить задачу внедрения аутентификации пользователей в различных приложениях компании, оно создает множество проблем. В отличие от специально предназначенных протоколов аутентификации, при использовании LDAP возникают различные уязвимости информационной безопасности.

Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.

Как работает LDAP-аутентификация

Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!

Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.

К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.

В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.

К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.

Недостатки LDAP как системы аутентификации

В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.

1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными

Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.

В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.

С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.

Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.

2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных

LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.

3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной

Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.

Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.

К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.

4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать

В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.

Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.

5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом

При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.

Ниже представлены примеры ужасов некорректной настройки.

• Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
• Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
• Отправка паролей в открытом виде на 389-й порт.
• Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?

Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.

6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга

Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.

Какие есть варианты?

Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.

Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.

Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.

В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.