Установка и настройка 389-AS/DS ( Развёртывание и настройка LDAP-сервера "389-AS/DS", с последующим созданием заготовки структуры записей и учётных записей для управления таковыми, а также активацией необходимых плагинов и схем данных. )

OS: "Linux Ubuntu 18 (Bionic) LTS".
Application: "389 Administration & Directory Server v.1.3.7".

Задача: развернуть и настроить LDAP-сервер "389-AS/DS", с последующим созданием заготовки структуры записей и учётных записей для управления таковыми, а также активацией необходимых плагинов и схем данных.

Последовательность дальнейших действий такова:



Установка и первичная настройка.

Дистрибутив LDAP-сервера "389-AS/DS" состоит из нескольких компонентов:


LDAP-сервер "389-AS/DS" выпускается в двух вариантах: коммерческий "Red Hat Directory Server (RHDS)" и бесплатная реализация "Fedora Directory Server (FDS)" на полностью открытых компонентах. В дистрибутивах вроде "Linux Debian/Ubuntu" поставляется только FDS, которая просто называется "389 Directory Server".

Нумерация дистрибутивов у RHDS и FDS различается, но чётко сопоставима:


Установим компоненты LDAP-сервера в реализации "389 Directory Server (1.3.7)":


Для установки были выбраны лишь необходимые APT-пакеты:


Опционально можно установить компоненты для сопроводительных утилит ("dsconf", "dscreate", "dsctl" & etc.), написанных на Python:


Одна из зависимостей дистрибутива "389 Administration Server" - web-сервер "Apache2", который сразу после установки запускается, в дальнейшем вхолостую прослушивая порт TCP:80. Если этот web-сервер нигде более не задействован, то его следует сразу отключить:


Перед установкой и вводом в работу LDAP-сервиса есть смысл проверить готовность несущей операционной системы - соответствие её параметров рекомендациям разработчиков. Для этого в дистрибутиве имеется соответствующая утилита:



В моём случае предупреждений два - очень долгое время ожидания активности в открытом соединении (позволит легко обеспечить DDoS) и слишком жёсткое ограничение на количество одновременно открытых файлов, что может затормаживать работу сервиса в ожидании высвобождения ресурсов.

Уменьшаем время жизни неактивного TCP-соединения до пяти минут:




Увеличиваем лимит количества одновременно открытых файлов (отдельная запись для "root" - обход специального системного ограничения):



Утилита конфигурации LDAP-сервера от "RedHat" требовательна к сетевой адресации - в процессе понадобится указать действительное доменное имя (FQDN), которое используется для приёма запросов к сервису. Если нет возможности зарегистрировать символическое имя в системе DNS, то придётся объявить его связку с IP-адресом локально (внутри несущего сервера):



Запускаем интерактивный конфигуратор "389 Administration & Directory Server" (написан на "Perl"):


В процессе подготовки конфигурации задаётся несколько вопросов на простом английском - приведу подсказки и примеры ответов на них:


Сервисы "389-AS/DS" не запустятся автоматически, пока это явно не будет разрешено. Сервер администрирования "389-AS" (специально настроенный "Apache2" с набором модулей от "RedHat") запускается просто, а для старта LDAP-сервисов "389-DS" наверчена дополнительная systemd-прослойка, позволяющая через один "unit" управлять произвольным количеством LDAP-инстансов.

Активируем автозапуск и стартуем LDAP-сервис (где "dirsrv" имя systemd-сервиса, а после символа "@" - имя "инстанса" 389-DS):


Активируем автозапуск и стартуем "389 Administration Server", после LDAP-инстанса (сервис администрирования хранит свою конфигурацию в одном из LDAP-инстансов, и без такового его запуск бессмыслен):


Проверим статус systemd-сервисов:



Проверим, прослушивают ли сервисы "389-AS/DS" выделенные им сетевые порты:



Самый первый и простой способ проверки работоспособности и отчасти выявления неисправностей - воспользоваться web-интерфейсом сервера администрирования, доступным через обычный "браузер" - в нашем случае по адресу "http://ldap0.example.net:9830".

Первый запрос к структуре данных свежеустановленного сервера "389-DS" наверное покажет, что таковым уже поддерживается два "Directory Information Tree (DIT)" - создаваемое по умолчанию для служебных целей "netscaperoot" и дерево пользовательских данных, с параметрами, определёнными во время конфигурирования скриптом "setup-ds-admin":



Для упрощения последующей автоматизации фоновых задач есть смысл сохранить пароль суперпользователя LDAP-сервера "cn=Directory Manager" в файле, доступном только суперпользователю несущей операционной системы "root" - в дальнейшем скрипты, аутентифицирующиеся от имени этого пользователя смогут здесь взять необходимый пароль:


Обязательно защищаем файл с паролем от посторонних:


Создание простой структуры записей данных.

Для разминки пройдём по этапам создания типовой структуры хранения записей данных о пользователях. В зависимости от способа установки и предварительной настройки часть из нижеследующего уже будет создана автоматически (ради тестирования можно просто удалить всё дерево DIT под суфиксом "dc=example,dc=net" и воспроизвести его заново).

Создаём корневую структуру данных (прикрепляя её к уже имеющемуся "пространству имён", иначе говоря набору файловых ресурсов, предназначенному для хранения данных; тип корневой записи "domain" вместо обычной в таких случаях "organization" выбирается для красоты и поддержки мультидоменности в перспективе):




Учитывая то, что DIT создаётся вручную, права доступа к нему тоже нужно будет задавать самостоятельно. Для начала добавим ACL, дающий фигурантам встроенной административной группе (в частности пользователю "uid=admin") полный доступ на правку записей нового DIT:




Создадим первые три ветви DIT, для групп пользователей, пользователей и сервисных учётных записей:




Создадим демонстрационную запись для группы пользователей:



Создадим запись описания произвольного пользователя с минимальным набором атрибутов:



Теперь включим пользователя "uid=userOne" в группу "cn=Group0":



Проверим, доступны ли атрибуты пользователя ему самому:


Запрещение анонимного доступа к данным LDAP.

По умолчанию в "389-DS" возможно анонимное чтение - это разрешено как на уровне функциональности LDAP-сервера, так и соответствующим ACL "Default anonymous access", автоматически создаваемыми для всех пользовательских DIT.

Например, любой может подключиться к сервису и узнать о его текущем статусе:



Также кто угодно может запросить сведения о любой записи или атрибуте (не в DIT конфигурации, конечно):



Режим анонимного доступа задаётся соответствующим параметром (default: on):



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

Запрет анонимного (без предъявления логина и пароля) доступа к LDAP осуществляется включением одного из двух режимов: полного запрета (value: off) и запрета для всего, кроме чтения корневого узла, что удобно для проверки доступности сервиса (value: rootdse) - второй вариант мне представляется более удобным:



Применение изменений требует перезапуска сервиса:


Как я упоминал выше, кроме функционального разрешения свободного доступа к данным в "389 DS" при каждом DIT по умолчанию автоматически создаются разрешающие анонимный доступ ACL - их просто найти в списке имеющих отношение к интересующему нас DIT:





Удаляем ACL-ы, разрешающий анонимный доступ (обратите внимание - содержимое атрибута "aci" должно быть указано буквально так, как оно зафиксировано в LDAP - утилита "ldapmodify" оперирует с текстом, а не логическими конструкциями):



Разрешение анонимного поиска по выделенным атрибутам.

Отдельно рассмотрим варианты предварительного поиска указателя (DN) на пользователя среди всех записей в LDAP. Если каталог закрыт напрочь от доступа без аутентификации (параметром "nsslapd-allow-anonymous-access: {off|rootdse}"), то для предварительного поиска потребуется служебная учётная запись, через которую вначале находятся сведения о пользователе, считываются его атрибуты и только следующим действием запрашивается аутентификация в LDAP уже от имени целевого пользователя с указанием его полного DN.

В случае, если жёстких требований на сокрытие сведений о перечне имеющихся пользователей на предприятии нет, то проще предоставить всем возможность выяснять ссылку на учётную запись (параметр "nsslapd-allow-anonymous-access: on") - процедура вроде поиска номера телефона в справочнике штатного расписания:



Пробуем найти запись о пользователе через анонимное подключение:


Пробуем прочитать свою запись с предварительной аутентификацией:


Разрешение пользователям читать и корректировать свои профили.

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



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



В случае, если наполнение записи атрибутами пользователь не контролирует, разрешаем ему лишь частичную правку своих атрибутов (как минимум позволяющую сменить пароль, например):



Создание учётных записей администраторов DIT.

Прежде всего разберёмся, какие бывают административные учётные записи в LDAP "389-AS/DS":


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

Суперпользователи второго типа могут быть использованы как для выполнения более широкого круга задач - удобство в том, что их учётные записи могут быть безболезненно изменены или заблокированы при необходимости. Важно только помнить, что эти записи хранятся в локальном контексте и не будут реплицированы на другие "инстансы" LDAP-сервиса.

Пользователи третьего типа, размещаемые в контексте управляемого и реплицируемого DIT наиболее практичны - далее о них.

Создадим пользователя "cn=Directory Administrator", предназначенного для неограниченного администрирования структуры целевого DIT:



Создадим группу "cn=Directory Administrators" (эта группа создаётся по умолчанию, если воспользоваться установкой по шаблону), пользователи которой получат возможность редактировать любые записи целевого DIT:



Добавим ACL, дающий указанной группе "cn=Directory Administrators" полный доступ на редактирование записей целевого DIT:



Теперь для редактирования структуры DIT "dc=example,dc=net" мы располагаем как минимум полноправным пользователем "cn=Directory Administrator,dc=example,dc=net", а в дополнение к нему в группу могут быть добавлены любые другие произвольные пользователи.


Создание учётных записей операторов DIT.

Наподобие того, как мы создали выше группу администраторов DIT, сделаем чуть менее властную группу "cn=Directory Operators", пользователи которой получат возможность править записи некоторой части целевого DIT:



Добавим ACL, дающий указанной группе "cn=Directory Operators" доступ на правку записей лишь указанных ветвей DIT:



Развивая идею выделения полномочий создадим группу "cn=Directory Viewers", пользователи которой получат возможность лишь просматривать все атрибуты записей некоторой части целевого DIT:



Добавим ACL, дающий указанной группе "cn=Directory Viewers" доступ на чтение всех атрибутов записей указанных ветвей целевого DIT:



Создание сервисных учётных записей.

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

Создадим сервисные группы для выделения их членам определённых привилегий:



Добавим ACL-ы, дающие группе учётных записей доступ на чтение записей определённой ветви DIT (в частности, одной только записей пользователей, но не групп или других сервисов, а другой - только записей групп):



Разумеется, по аналогии с группами и ACL "только для чтения" можно создать и другие, с правами на редактирование записей - очертив им любой ареал доступа.

Создадим сервисную учётную запись с минимальным набором атрибутов:




Далее включим пользователя "uid=app0" в группу с доступом на чтение только записей пользователей:



Теперь, если запросить через созданную только что сервисную учётную запись все доступные ей данные, то мы получим сведения о ветви "ou=People", записи с атрибутами всех её фигурантов и сведения о самой сервисной учётной записи "uid=app0":


Таким образом, учётную запись "uid=app0" можно использовать для "биндинга" при аутентификации пользователей какого-нибудь стороннего сервиса, вроде "Freeradius" или "Atlassian Crowd".

Оптимизация процедур выявления групповой принадлежности.

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

Обычно для включения записи пользователя в группу к записи последней добавляется атрибут "member" или "uniqueMember". Для большей наглядности, чтобы отобразить принадлежность к записям групп в запись пользователя также могут быть добавлены атрибуты "memberOf". Таким образом при просмотре записи группы по атрибутам "member" или "uniqueMember" просто узнать всех её пользователей, а при просмотре записи пользователя по атрибутам "memberOf" просто узнать все группы, в которые она включена. Очевидно, что можно потерять связность этих атрибутов при правке записей - и для синхронизации таковых предназначен поставляемый в дистрибутивном комплекте "389-DS" плагин "MemberOf Plugin", который требует явного включения и настройки.

Активируем плагин "MemberOf Plugin":



Задаём имя атрибута в записях групп, для идентификаторов включённых в группы пользователей:



Задаём имя атрибута в записях пользователей, для указания на группы, в которые они включены:



Для активации плагина перезапускаем LDAP-инстанс:


Важно помнить, что действие плагина "MemberOf Plugin" направлено только в одну сторону - от групп к пользователям - то есть, при создании в записи группы атрибута "uniqueMember" в записи соответствующего пользователя автоматически создаётся атрибут "memberOf". В обратную сторону это не работает. То есть, если вручную создать в записи пользователя атрибут "memberOf", то в записи группы не появится соответствующий пользователю атрибут "uniqueMember" - таким образом в структуре данных образовывается фальшивая связь, показывающая присутствие пользователя в группе, в которую он на самом деле не включён.

Частично проблема образования фальшивой связки может быть снята глобальным ACL, запрещающим пользователям вручную добавлять или изменять атрибуты "memberOf" (помним при этом, что суперпользователь вроде "cn=Directory Manager" совершенно не подвержен действию ACL):



Для решения проблемы уже имеющихся записей с некорректными атрибутами "memberOf" в дистрибутиве "389-DS" приложена специальная perl-утилита, создающая (на основе предустановленного шаблона "cn=memberof task") задачу удаления фактически несвязанных с группами атрибутов "memberOf":



Запущенная выше задача отработает и будет автоматически удалена после завершения.

Есть смысл поставить запуск этой задачи по расписанию, раз в сутки, часа в три ночи, например (в скриптах для утилиты "fixup-memberof" вместо ввода пароля в соответствии с ключем "-w -" можно забирать таковой из произвольного файла "-j filename"):



Оптимизация процедуры выделения "Posix UID & GID".

Если учётные записи в LDAP предназначены для аутентификации в операционных системах "Linux", рано или поздно возникает необходимость обеспечения неизменности числовых UID и GID пользователей при входе на любой компьютер предприятия - это достигается централизованным хранением идентификаторов в LDAP (в объектном классе "posixAccount") и заданием таковых на компьютерах при аутентификации пользователя.

Ничто не мешает задавать идентификаторы UID и GID вручную, но тогда обеспечение их уникальности и непересекаемости выливается в муторный процесс - и для автоматизации которого предназначен поставляемый в дистрибутиве "389-DS" плагин "Distributed Numeric Assignment Plugin (DNA; libdna-plugin)".

Задача плагина DNA состоит в том, чтобы при обнаружении в атрибутах "uidNumber" и "gidNumber" числа "99999" (недопустимое значение как условный ключ, дающий плагину понять, что нужно действовать; по умолчанию "0") автоматически вместо "99999" установить следующее значение из отсчитываемого плагином последовательного диапазона.

По умолчанию плагин DNA неактивен.

Включение в GUI "389 Console" выглядит так:


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

Добавление атрибутов и классов в схему данных.

Возможно имеющейся в дистрибутиве "389-DS" схемы данных окажется недостаточно для решения поставленных производством задач. Это легко исправляется - достаточно корректно (строго в соответствии с документацией) описать дополнительные сущности и добавить их к общей схеме.

Схема данных LDAP выстраивается из множества компонентов, объединяемых и наслаиваемых. Атрибуты и классы загружаются поэтапно и на каждом следующем могут переопределять имеющиеся. В общем случае порядок таков:


Предположим, нам необходимо хранить в профиле пользователя номер его читательского билета и дату последнего посещения. Создадим набор атрибутов и дополнительный класс для данных, имеющих отношение к библиотеке (синтаксис весьма строгий, регистр символов имеет значение; отбивка текстовых блоков знаками "#" полезна для отслеживания разрешённой длины строки - всего 80 символов):



Конфигурационные файлы схемы данных загружаются поочерёдно, в алфавитном порядке их имён - потому наш, начинающийся с "90*", будет применён примерно последним, уже поверх типовой схемы.

Для применения достаточно перезапустить LDAP-инстанс:



Экспорт и импорт данных (не резервное копирование).

Рассмотрим предлагаемые документацией способы экспорта записей (для импорта подходы аналогичные).

В дистрибутиве "389-DS" имеются специализированные утилиты для экспорта данных из "BerkeleyDB" в LDIF-файл. Написанная на "Bash" утилита "db2ldif" является обёрткой для более низкоуровневой утилиты "ns-slapd" и для работы требует кратковременной остановки LDAP-сервиса. Написанная на "Perl" утилита "db2ldif-online" является обвязкой для вызова команды создания задачи посредством "DSUtil::ldapmod", не требует остановки LDAP-сервиса, но не выдаёт результата немедленно.

Оба варианта не подходят для частых небольших выборок - остановка сервиса при этом неприемлема, а ожидание выполнения внутренней задачи и поиск её результатов слишком сложны и неочевидны.

Есть способ сделать это проще, посредством утилит "ldapsearch" и "ldapadd" (обе оперируют с форматом LDIF - "LDAP Data Interchange Format").

Запрашиваем все записи с атрибутами нужной нам ветви данных и выгружаем в текстовый файл:


Полученный LDIF-файл используем как источник данных для загрузки в другой LDAP-сервис:


Может статься так, что "Distinguished Name (DN)" записей в LDAP-сервисе, куда импортируются данные, отличается от исходного. Учитывая простоту синтаксиса LDIF, заменить атрибуты DN перед импортом "дампа" несложно:


Удаление конфигурации и данных "389-AS/DS".

После того, как наигрались с тестовыми "инстансами", их легко удалить посредством дистрибутивных perl-утилит "remove-ds" и "remove-ds-admin".

Файлы сервиса по большей части размещаются в следующих директориях - возможно их потребуется зачистить вручную:


Переход к настройке SSL-шифрования клиентских подключений.