Схема каталога LDAP

Содержание

1. Что такое схема LDAP

Схема каталога — это набор правил о том, какие объекты и какие атрибуты в нём допустимы. Она состоит из двух базовых словарей:

• Типы атрибутов (attributeTypes): имя атрибута, его OID, синтаксис (строка, число, DN, SID…), правила сравнения, однозначность (SINGLE-VALUE). Пример: sAMAccountName, mail, uidNumber.
• Классы объектов (objectClasses): какие атрибуты обязательны (MUST) и допустимы (MAY) у объекта, от какого класса он наследует (SUP), и его вид:
  • structural — самостоятельный объект (user, group, organizationalUnit);
  • auxiliary — «добавка» к объекту, подмешивает атрибуты (posixAccount, mailRecipient);
  • abstract — только для наследования (top).

Каждый элемент схемы имеет глобально уникальный OID и публикуется самим сервером, чтобы клиенты (ADSI, SSSD, ldapsearch) знали, что он поддерживает. В RFC-мире определения отдаются через subschemaSubentry (атрибуты attributeTypes / objectClasses); в Active Directory та же информация лежит в отдельном разделе CN=Schema,CN=Configuration как объекты attributeSchema и classSchema, а их сводка — в CN=Aggregate.

2. Какие схемы бывают

Исторически сложились несколько семейств схем. Они совместимы по базовым атрибутам, но различаются набором классов и тем, как хранят POSIX-данные, SID, Kerberos и т. д.

Ключевое отличие на практике: в OpenLDAP/389-DS пользователь — это обычно inetOrgPerson + posixAccount, а идентификатор для Unix берётся из uidNumber. В AD пользователь — это user, идентичность задаётся objectSid, а POSIX-идентификаторы — опциональная добавка.

3. Схема, которую использует HopeDC

HopeDC поднимает схему Active Directory — ту же, что у Windows Server 2016+ (objectVersion 88). Это сделано намеренно: HopeDC эмулирует контроллер домена AD, поэтому и словарь объектов у него ровно как у AD.

• Около 1500 объектов attributeSchema (типы атрибутов);
• около 270 объектов classSchema (классы объектов);
• объект-корень схемы dMD и сводка CN=Aggregate.

Шаблон схемы — выгрузка схемы настоящего AD, встроенная прямо в бинарник (schema_base.txt). Определения подсхемы (attributeTypes / objectClasses / ditContentRules / extendedAttributeInfo / extendedClassInfo) не хранятся готовыми, а строятся из объектов attributeSchema/classSchema по тем же правилам, что у NTDS. Генератор сверен с CN=Aggregate живого контроллера AD: все 3803 значения совпадают байт в байт.

4. Как и когда схема создаётся

• При создании домена/леса в базу пишется раздел CN=Configuration,<лес> и в нём CN=Schema,… со всеми объектами схемы (функция ядра ensure_forest_schema).
• При каждом старте для уже существующих лесов схема идемпотентно досоздаётся/ проверяется (ensure_all_forests) — на случай обновления версии продукта.
• В кластере объекты схемы детерминированы: на всех узлах они получаются побайтно одинаковыми (одинаковый дайджест состояния), поэтому репликация их не «дёргает».

5. POSIX-атрибуты и вход Linux

AD-схема HopeDC включает атрибуты RFC 2307 (uidNumber, gidNumber, homeDirectory, loginShell, класс posixAccount) — они входят в раздел «Services for Unix» (msSFU30…) стандартной схемы AD. Поэтому вход Linux работает двумя способами:

• По SID (по умолчанию в SSSD ad) — SSSD вычисляет uid/gid из objectSid алгоритмически, POSIX-атрибуты в каталоге заполнять не обязательно.
• По RFC 2307 — если нужны фиксированные uidNumber/gidNumber (единые с существующим NFS/Unix-парком), их можно задать в каталоге, и SSSD будет брать их. HopeDC умеет подобрать следующий свободный POSIX-идентификатор по всему каталогу.

При импорте из FreeIPA/389-DS (где пользователь — posixAccount/ inetOrgPerson) HopeDC сопоставляет объекты с AD-классами и переносит POSIX- и Kerberos-данные в свою схему.

6. Расширение схемы

Схему можно расширять как в настоящем AD: добавление нового объекта attributeSchema или classSchema в раздел схемы сразу отражается в CN=Aggregate, и клиенты (ADSI SchCache) перечитывают её по изменённой метке времени. Это позволяет приложениям, рассчитанным на расширение AD-схемы (например, установка собственных атрибутов), работать штатно.

7. Почему именно AD-схема

• Windows-клиенты «из коробки». Доменный вход, RSAT, оснастки ADUC/ADSI Edit, групповые политики ожидают именно классы и атрибуты AD.
• Linux без конвертации. SSSD в режиме ad — штатный путь ввода Linux в домен; он рассчитан на AD-схему.
• Миграция с MS AD. Объекты переносятся «один в один», без маппинга классов.
• Инструменты экосистемы. Всё, что умеет работать с AD/Samba AD по LDAP, работает и с HopeDC.

Схемы OpenLDAP (inetOrgPerson + RFC 2307) выбрали бы, если бы продукт был «обычным» LDAP-каталогом для Unix-парка. HopeDC же заменяет контроллер домена AD, поэтому совместимость с AD-схемой — обязательное требование, а не одна из опций.

8. Короткий ответ