LDAP-каталоги

LDAP-каталог — это специализированная база данных, организованная по иерархическому принципу и оптимизированная для операций чтения, поиска и аутентификации. Доступ к данным в таком каталоге осуществляется по протоколу LDAP (Lightweight Directory Access Protocol — облегчённый протокол доступа к каталогам). В отличие от реляционных баз данных, LDAP-каталоги предназначены для хранения статичной или редко изменяющейся информации об объектах (пользователях, группах, устройствах, ресурсах) и обеспечивают быстрое выполнение запросов на поиск и сравнение.

История и происхождение

Протокол LDAP был разработан в начале 1990-х годов как упрощённая альтернатива протоколу X.500, который использовался для создания глобальных каталогов в сетях OSI. X.500 был мощным, но сложным в реализации и требовал значительных вычислительных ресурсов. Группа исследователей из Мичиганского университета (Tim Howes, Steve Kille, Wengyik Yeong) создала LDAP как облегчённую версию, работающую поверх стека протоколов TCP/IP, что сделало его доступным для сетей на основе Internet.

Первая версия LDAP (RFC 1487) была опубликована в 1993 году. В 1997 году вышла версия LDAPv3 (RFC 2251), ставшая стандартом де-факто. Впоследствии спецификации были уточнены в RFC 4510–4533 (2006 год). LDAPv3 поддерживает расширения, механизмы безопасности (SSL/TLS, SASL) и гибкие схемы данных.

Структура и модель данных

LDAP-каталог построен на древовидной иерархии, называемой DIT (Directory Information Tree). Каждый узел дерева — это запись (entry), которая состоит из набора атрибутов (attribute). Атрибуты имеют тип и одно или несколько значений.

Основные компоненты

• Запись (entry) — базовый элемент каталога. Каждая запись имеет уникальное Distinguished Name (DN), которое определяет её положение в дереве. Например, cn=Иван Петров, ou=Сотрудники, dc=example, dc=com.
• Атрибут (attribute) — пара «тип — значение». Тип определяет синтаксис (строка, число, дата, бинарные данные). Примеры: cn (common name — полное имя), sn (surname — фамилия), mail (адрес электронной почты), userPassword (хэш пароля).
• Класс объекта (objectClass) — шаблон, задающий обязательные и опциональные атрибуты для записи. Например, класс inetOrgPerson требует атрибутов cn и sn, а mail — опционален.
• Схема (schema) — совокупность правил, определяющих типы атрибутов, классы объектов и синтаксисы. Схема может быть расширена администратором.

Иерархия

Корень дерева — это DSE (Directory System Agent), который не содержит пользовательских данных. Под ним располагаются записи, соответствующие доменам (dc — domain component), организационным единицам (ou — organizational unit) и конечным объектам (cn — common name, uid — user id). Типичная структура для организации:

`` dc=example, dc=com ├── ou=Сотрудники │ ├── cn=Иван Петров │ └── cn=Мария Смирнова └── ou=Группы └── cn=Администраторы ``

Протокол LDAP

LDAP — это клиент-серверный протокол, работающий поверх TCP (порт по умолчанию — 389 для незащищённого соединения, 636 — для LDAPS). Основные операции протокола:

• Bind — аутентификация клиента (простая — по имени и паролю; или через SASL — Kerberos, GSSAPI).
• Search — поиск записей с фильтрами (например, (&(objectClass=inetOrgPerson)(mail=*@example.com))).
• Compare — сравнение значения атрибута (например, проверка пароля).
• Add / Delete / Modify / ModDN — операции изменения данных (добавление, удаление, изменение атрибутов, переименование записи).
• Unbind — завершение сессии.

Фильтры поиска

LDAP поддерживает гибкие фильтры на основе булевой логики:

• (cn=Иван*) — поиск по шаблону.
• (&(sn=Петров)(mail=*)) — логическое И.
• (|(uid=1001)(uid=1002)) — логическое ИЛИ.
• (!(objectClass=inetOrgPerson)) — отрицание.

Применение

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

Аутентификация и авторизация

• Единый вход (SSO) — пользователь вводит пароль один раз, и все приложения (почта, файловые серверы, веб-порталы) проверяют его через LDAP.
• Централизованное управление доступом — группы пользователей и политики хранятся в каталоге.
• Проверка паролей — приложение отправляет запрос Bind с DN пользователя и паролем; сервер возвращает успех или ошибку.

Управление учётными записями

• Хранение профилей пользователей (ФИО, телефон, должность, подразделение).
• Автоматическая синхронизация с HR-системами.
• Управление членством в группах (например, «Администраторы», «Бухгалтерия»).

Сетевые сервисы

• DNS — некоторые реализации DNS (например, BIND с поддержкой LDAP) используют каталог для хранения зон.
• Почтовые системы — Microsoft Exchange, Zimbra, Postfix могут хранить почтовые ящики и правила маршрутизации в LDAP.
• Управление конфигурациями — хранение настроек для клиентов (например, параметры прокси, пути к серверам).

Каталоги ресурсов

• Печать, файловые серверы, сетевые устройства — их адреса и параметры могут быть опубликованы в LDAP.

Популярные реализации

OpenLDAP

Свободная реализация LDAP-сервера, поддерживающая LDAPv3, репликацию (Syncrepl), ACL, TLS и SASL. Распространена в Unix-подобных системах. Настраивается через конфигурационные файлы (slapd.conf) или динамически через OLC (Online Configuration).

Microsoft Active Directory

Собственная реализация Microsoft, основанная на LDAP, но с расширениями (схема, групповая политика, Kerberos). Active Directory использует LDAP для доступа к данным, но также включает собственные протоколы (Kerberos, NTLM, DNS). Является стандартом в корпоративных сетях Windows.

389 Directory Server (Fedora Directory Server)

Свободный LDAP-сервер от Red Hat, поддерживающий многомастерную репликацию, виртуальные атрибуты и интеграцию с Kerberos.

ApacheDS (Apache Directory Server)

Реализация на Java, полностью совместимая с LDAPv3, поддерживает Kerberos, NTLM, и может быть встроена в приложения.

Безопасность

LDAP-каталоги часто содержат критически важные данные (пароли, списки доступа), поэтому безопасность является приоритетом:

• LDAPS — шифрование трафика через TLS (порт 636).
• StartTLS — шифрование на существующем соединении (порт 389).
• SASL — механизмы аутентификации (Kerberos, GSSAPI, DIGEST-MD5).
• ACL — доступ к записям и атрибутам ограничивается правилами (например, только администратор может читать userPassword).
• Хранение паролей — обычно в виде хэшей (SSHA, SHA-256, bcrypt).

Критика и ограничения

• Производительность при записи — LDAP-каталоги оптимизированы для чтения, а не для частых изменений. Массовые обновления могут быть медленными.
• Сложность настройки — правильная настройка схемы, ACL и репликации требует квалификации.
• Отсутствие транзакций — в отличие от реляционных БД, LDAP не поддерживает ACID-транзакции в полном объёме (хотя некоторые реализации, например, OpenLDAP, предоставляют механизмы атомарности).
• Ограниченная модель данных — иерархическая структура не всегда удобна для сложных связей (многие-ко-многим).
• Устаревшие реализации — некоторые старые серверы (например, Netscape Directory Server) не поддерживают современные стандарты безопасности.

Интересные факты

• LDAP-каталоги могут содержать миллионы записей и обрабатывать тысячи запросов в секунду.
• Протокол LDAP используется не только для людей, но и для устройств (принтеры, маршрутизаторы) и даже для цифровых сертификатов (PKI).
• В России LDAP-каталоги активно применяются в государственных информационных системах (например, ЕСИА — Единая система идентификации и аутентификации).
• Существуют реализации LDAP для встраиваемых систем (например, OpenLDAP на OpenWrt).