LDAP-каталоги¶
LDAP-каталог — это специализированная иерархическая база данных, оптимизированная для операций чтения и поиска, которая хранит информацию о пользователях, группах, устройствах, ресурсах сети и их атрибутах, и доступ к которой осуществляется по протоколу LDAP (Lightweight Directory Access Protocol, «облегчённый протокол доступа к каталогам»). LDAP-каталоги широко применяются в корпоративных и образовательных сетях, а также в государственных и коммерческих организациях для централизованного управления учётными записями, аутентификации, авторизации и каталогизации ресурсов.
¶История и происхождение
Протокол LDAP был разработан в начале 1990-х годов как более лёгкая и простая в реализации альтернатива протоколу DAP (Directory Access Protocol), входящему в состав стандарта X.500, определённого Международным союзом электросвязи (ITU-T) и ISO. Основные авторы LDAP — Тимоти Хоуис (Timothy Howes), Марк Смит (Mark Smith) и Гордон Гуд (Gordon Good). Первая версия (LDAPv1) появилась в 1993 году, но широкое распространение получила версия LDAPv2, выпущенная в 1995 году (RFC 1777). Современная версия LDAPv3 стандартизирована в 1997 году в серии документов RFC (прежде всего RFC 2251–2256) и является общепринятым стандартом. Развитие LDAP-каталогов неразрывно связано с появлением таких реализаций, как OpenLDAP (открытое программное обеспечение) и Microsoft Active Directory (собственная реализация Microsoft, использующая LDAP в качестве одного из основных протоколов доступа наряду с Kerberos и DNS).
¶Архитектура и модель данных
¶Иерархическая структура
Данные в LDAP-каталоге организованы в виде дерева — каталога, называемого DIT (Directory Information Tree). Каждый узел дерева представляет собой запись (entry), которая содержит набор атрибутов. Записи имеют уникальное различимое имя (Distinguished Name, DN), которое строится из относительных различимых имён (RDN) последовательно от корня к листу. Корень дерева обычно соответствует домену или организации.
Пример DN: cn=Иванов Иван,ou=Отдел продаж,dc=example,dc=com
¶Атрибуты и схемы
Каждая запись описывается набором атрибутов, каждый из которых имеет тип и одно или несколько значений. Типы атрибутов, классы записей и правила наследования определяются схемой (schema). Схема LDAPv3 включает стандартные типы (например, cn — common name, sn — surname, mail, telephoneNumber) и объектные классы (например, inetOrgPerson, organizationalUnit, groupOfNames). Администратор может расширять схему пользовательскими атрибутами и классами.
¶Операции протокола LDAP
Клиент взаимодействует с сервером LDAP с помощью набора базовых операций:
- Bind — аутентификация (обычно по имени пользователя и паролю, возможно использование SASL);
- Search — поиск записей по заданным критериям (фильтр, база поиска);
- Compare — проверка наличия определённого значения атрибута;
- Add — добавление новой записи;
- Delete — удаление записи;
- Modify — изменение атрибутов записи;
- ModDN — переименование и/или перемещение записи (изменение DN);
- Unbind — закрытие соединения.
¶Типичные структуры LDAP-каталогов
¶Корпоративный каталог (Active Directory)
В среде Windows LDAP-каталогом является Active Directory (AD), которая хранит информацию о пользователях, компьютерах, группах безопасности, политиках и других объектах домена. Active Directory использует LDAP-протокол для запросов и изменений, но также полагается на DNS для поиска контроллеров домена и на Kerberos для аутентификации. Иерархия AD обычно строится по схеме:
- Корень домена (
dc=domain,dc=com) - Контейнеры для разных классов объектов (например,
CN=Users,CN=Computers) - Организационные единицы (Organizational Units, OU) для группировки пользователей и ресурсов по отделам.
¶Каталог на основе OpenLDAP
OpenLDAP — свободная реализация LDAP-сервера, используемая в Unix-подобных системах. Типичная структура включает одну или несколько баз данных (backend), каждая из которых хранит часть DIT. OpenLDAP поддерживает различные механизмы репликации (syncrepl) и может быть настроен как часть централизованной системы аутентификации (например, для NSS/PAM) совместно с Kerberos.
¶Спавочные и почтовые каталоги
LDAP-каталоги применяются для хранения справочной информации (телефонные книги, адреса сотрудников), а также как хранилище конфигурации для почтовых систем (например, Cyrus IMAP, Postfix). В таких системах записи часто имеют класс inetOrgPerson или organizationalPerson.
¶Применение
¶Аутентификация и управление доступом
Основное применение LDAP-каталогов — централизованное управление учётными записями и аутентификация. Пользователи могут входить в систему с единым именем и паролем (SSO). Примерами таких систем являются:
- Microsoft Active Directory (в Windows-среде);
- OpenLDAP с Kerberos (в Unix-среде);
- Red Hat Identity Management (IPA);
- FreeIPA.
При входе пользователя на рабочую станцию, веб-сервер или почтовую систему запрос на проверку подлинности направляется к LDAP-каталогу (часто через SASL или Kerberos). Многие приложения (например, Jira, Confluence, WordPress с плагином LDAP) поддерживают аутентификацию через LDAP.
¶Каталог ресурсов сети
LDAP-каталоги хранят информацию о сетевых принтерах, файловых серверах, общих папках и других ресурсах. Клиент может искать ближайший принтер или почтовый сервер по запросам LDAP.
¶Единый каталог для нескольких приложений
Организации могут хранить в LDAP-каталоге не только учётные данные, но и профили пользователей (почта, телефон, должность, подразделение, права доступа). Различные приложения (ERP, CRM, системы документооборота) могут получать эти данные через LDAP-запросы, избегая дублирования.
¶Хранение сертификатов и открытых ключей
LDAP-каталоги используются для публикации цифровых сертификатов (например, в инфраструктуре открытых ключей PKI). Сертификаты и списки отзыва (CRL) могут храниться как объекты в соответствии со стандартом RFC 4523.
¶Реализации и программное обеспечение
Наиболее известные реализации LDAP-каталогов:
| Реализация | Разработчик | Особенности |
|---|---|---|
| OpenLDAP | Сообщество | Свободное ПО, высокая гибкость настройки, поддержка многомастерной репликации, работа на большинстве Unix-подобных систем |
| Microsoft Active Directory | Microsoft | Проприетарная, тесно интегрирована с Windows, использует LDAP, Kerberos, DNS, поддерживает групповые политики |
| 389 Directory Server | Red Hat / Fedora | Свободный LDAP-сервер для Linux, ранее известный как Fedora Directory Server |
| Apache Directory Server | Apache Software Foundation | Написан на Java, поддерживает LDAPv3 и Kerberos |
| Oracle Internet Directory | Oracle | Проприетарный, используется в средах Oracle |
| IBM Tivoli Directory Server | IBM | Проприетарный, поддерживает LDAPv3 и X.500 |
| eDirectory (NetIQ) | Novell / Micro Focus | Ранее известный как Novell Directory Services, используется в сетях на базе Novell |
¶Безопасность
¶Аутентификация
LDAP поддерживает несколько механизмов аутентификации:
- Простая аутентификация (передача DN и пароля в открытом виде — не рекомендуется для производственных сетей без TLS/SSL);
- SASL (Simple Authentication and Security Layer) — позволяет использовать Kerberos, DIGEST-MD5, EXTERNAL (на основе сертификата) и другие механизмы;
- Аутентификация на основе сертификатов (через TLS).
¶Шифрование трафика
Для защиты данных при передаче применяются:
- LDAPS (LDAP over SSL) — устаревший вариант с отдельным портом 636;
- STARTTLS — расширение LDAPv3, позволяющее установить защищённое соединение на стандартном порту 389 после активации TLS.
¶Контроль доступа
Сервер LDAP может ограничивать доступ к записям и атрибутам на основе правил ACL (Access Control List). В Active Directory контроль доступа осуществляется через списки управления доступом (ACL), интегрированные с моделью безопасности Windows. В OpenLDAP используется директива olcAccess с гибкими правилами для разных уровней (например, разрешить чтение атрибута telephoneNumber всем, а запись — только владельцу).
¶Критика и ограничения
- Производительность при большом объёме изменений. LDAP-каталоги оптимизированы на чтение, а не на частые массовые записи. Высокая интенсивность операций модификации может вызывать задержки при репликации.
- Сложность настройки и администрирования. Для настройки правил репликации, схемы и ACL требуются квалифицированные администраторы.
- Зависимость от схемы. Изменения схемы могут потребовать остановки каталога или специальных процедур миграции.
- Отсутствие встроенных механизмов для сложных реляционных запросов. LDAP не поддерживает SQL, и операции перекрестных ссылок между записями выполняются на стороне клиента (с помощью фильтров и поисков).
- Безопасность простого Bind. При использовании простой аутентификации (не защищённой TLS) пароль передаётся в открытом виде; это частая причина уязвимостей.
- Совместимость реализаций. Несмотря на стандартизацию, различные реализации (OpenLDAP, Active Directory) имеют незначительные расхождения в семантике атрибутов и фильтров, что может вызывать проблемы при миграции.
¶Альтернативные технологии
С появлением облачных служб (например, Microsoft Entra ID, бывший Azure Active Directory) и технологий управления идентификацией (IAM) для SaaS-систем традиционные локальные LDAP-каталоги частично уступают место облачным каталогам, поддерживающим SCIM, OAuth, SAML. Однако локальные LDAP-каталоги остаются актуальными в организациях с гибридной инфраструктурой и строгими требованиями к изолированности данных.
¶Источники
- RFC 2251 — Lightweight Directory Access Protocol (v3)
- RFC 2252 — LDAPv3 Attribute Syntax Definitions
- RFC 2256 — A Summary of the X.500(96) User Schema for use with LDAPv3
- RFC 4510 — LDAP Technical Specification Roadmap
- Стандарты X.500 ITU-T (серия X.500)
- Документация OpenLDAP (openldap.org)
- Документация Microsoft Active Directory (learn.microsoft.com)
- Как настроить LDAP-аутентификацию: практическое руководство (статья на Habr, 2020)
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →


