Рейтинг
+2.26

LDAP

4 читателя, 76 топиков

sudo+ldap в Calculate Directory Server

  • LDAP
Будьте внимательны: в популярном у ваятелей LDAP-based архитектур дистрибутиве CDS (Calculate Directory Server) sudo читает отнюдь не /etc/ldap.conf, а что-то другое. То есть конечно если вы внимательно изучали документацию по CDS, то знаете, что именно должен читать sudo в данном дистрибутиве, я же предпочёл попросту скачать свежую версию с офсайта sudo.ws и собрать её со следующими опциями:
./configure --prefix=/usr --with-ldap --with-ldap-conf-file=/etc/ldap.conf -with-ldap-secret-file=/etc/ldap.secret

Чудеса на PADL.COM'е

  • LDAP
Опытным путём сегодня благополучно выяснил, что в nss_ldap используется в режиме «nss_schema rfc2307bis» знаете какой атрибут членства в группе? uniqueMember! Что в этом необычного? А то, что в последней редакции RFC 2307bis, (которая так же, как и все предыдущие не утверждена IETF, а потому не совсем понятно, чего ради её тот же OpenDS использует по дефолту), в качестве атрибута членства в группе, хранящего полный DN, предлагается member, а не uniqueMember! Об этом по сути нигде толком не сказано, поди догадайся…
Кстати, само описание posixGroup в схеме я предлагаю в таком случае хакнуть при первой же возможности и сделать его следующим:
1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top 
STRUCTURAL MUST gidNumber MAY ( cn $ userPassword $ uniqueMember $ memberUid $ description )

Здесь cn вынесен в MAY атрибуты и добавлен MAY-атрибут uniqueMember
Я конечно понимаю, что это некоторое отклонение от стандарта, но… к сожалению иногда и стандарты страдают «несовершенством». Особенно это касается RFC 2307bis, где с одной стороны posixGroup стал вдруг AUXILIARY, что вынуждает добавлять в стек структурный класс, а с другой стороны — в objectClass'ах groupOfNames и groupOfUniqueNames, содержащих типы атрибутов member и uniqueMember соотв., они заявлены как MUST. Из сказанного следует, что даже если Member'ы формируются оверлеем dynlist, Вы всё равно обязаны постоянно держать в записи нечто вроде «uniqueMember: cn=dummy».
Редактирование же определения posixGroup в указанном ключе позволит вам избавиться от необходимости изворачиваться, стряпая противоестественного вида стек objectClass'ов с лишними значениями атрибутов или добавляя туда extensibleObject, что на мой взгляд — тоже хак в обход схемы.

Впрочем, всё сказанное касается исключительно тех, кто использует DN'ы для членов группы, для обычного memberUid'а хватает стандартной nis.schema, соответствующей RFC 2307

Как сделать просто ноду, "без прикрас"?

  • LDAP
Если нужно добавить элементарный узел в дерево LDAP, пользуйтесь чудесным objectClass'ом «applicationProcess» из RFC 2256.
Вот как выглядит типичный узел с objectClass=applicationProcess:
dn: cn=Accounts,cn=Security
objectClass: applicationProcess
cn: Accounts

Описание applicationProcess:
objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' 
SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description )

Поскольку непонятно, что это ещё за application process такой (thread что ли?), то я думаю, нет ничего противоречащего «букве и духу» LDAP в использовании данного objectClass'а для создания узлов без дополнительной смысловой нагрузки…

DNS+LDAP

  • LDAP
Лучшим решением для интеграции DNS с LDAP является PowerDNS.
Почему?
1) Очень прост в настройке
2) Один объект используется для A и PTR-записей
3) В одном объекте можно указать сколько угодно A-записей (просто указываешь IP и хоть тысячу имён хостов к нему впридачу)
4) Отличная схема, в которой нет ничего лишнего и есть много полезного
5) В итоге — самое главное, DNS-зона получается очень наглядной, даже лучше, чем в Active Directory

Почему нельзя использовать BIND+LDAP? Можно конечно, только вместо преимуществ вы получите какой-то слабочитабельный бред в своём Каталоге, который не годится ни для чего, кроме собственно DNS.

LDAP как источник аутентификации

  • LDAP
Две мои статьи на тему LDAP-аутентификации — написаны относительно давно, но для ознакомления с вопросом должно быть в самый раз:
Сервер каталогов LDAP как источник аутентификации — учётные записи
Сервер каталогов LDAP как источник аутентификации — интеграция с AD

LDAPCon 2010...

  • LDAP
Замечательной конференции, посвящённой проблемам LDAP, в этом году не будет. Сказались финансовые трудности, поглощение Sun'а Ораклом, довольно слабая предыдущая конференция. В итоге, следующий LDAPCon запланирован на 2011-й год.

Как научиться работать с LDAP?

  • LDAP
Ответом на это, разумеется, может быть только RTFM.
А именно, лучшей книгой в онлайн на эту тему, бесспорно, является опубликованный на сайте zytrax.com хрестоматийный учебник «LDAP for Rocket Scientists». Несерьёзное название книги полностью соответствует стилю изложения: лёгкому, слегка ироничному и максимально доходчивому. Собственно. авторы просто не хотели называть её «LDAP для Чайников» — это было бы похоже на моветон, да и сразу понижало бы в глазах потенциального читателя важность и полезность данной работы.
Читать учебник от корки до корки особого смысла, на мой взгляд, не имеет: он содержит множество примеров и различной практически полезной информации, так что «если срочно» (а оно почти всегда так и бывает), ищите в нём ответы на свои конкретно поставленные вопросы, да обрящете. Во всяком случае, зачастую это куда полезнее чтения сильно фрагментированного, непоследовательного, находящегося в перманентном состоянии дописывания руководстве OpenLDAP Administration Guide, и это даже при том, что после «LDAP for Rocket Scientists» именно документация проекта OpenLDAP является, на мой взгляд, наиболее толковой.

P.S. Я очень признателен Zytrax'у за выложенные на их сайте книги, и не только по LDAP, но и по DNS-серверу ISC BIND, например. Зитракс — это вообще отличный пример того как коммерческий проект может без каких-то значительных вложений сделать полезное и нужное дело для всех.

schema2ldif конвертер

  • LDAP
Скрипт для преобразования схем
из формата .schema в формат .ldif, пригодный для загрузки в динамическую конфигурацию cn=config. Необходимый параметр — имя файла схемы без расширения, который нужно преобразовать. Скрипт отправляет результат в стандартный поток вывода, откуда вы его можете через пайп перенаправить утилите ldapadd или просто сохранить в файл.

#!/bin/bash
schemaFile="$1"
[[ -f $schemaFile && -r $schemaFile ]] || exit 1
schemaName=${schemaFile##*/}
schemaName=${schemaName%.*}
sed -r \
 -e '/^\s*(#.*)?$/d' \
 -e 's%^\s+%  %' \
 -e 's%^objectclass\s+%olcObjectClasses: %I' \
 -e 's%^attributetype\s+%olcAttributeTypes: %I' $schemaFile | \
  sed "1idn: cn=$schemaName,cn=schema,cn=config\nobjectClass: olcSchemaConfig\ncn: $schemaName"

Это, наверное, самый простой и самый немудрёный schema2ldif из всех, когда либо сочинённых. Но мне его обычно хватает.
А если вам нужен продвинутый вариант конвертера — пожалуйста, один есть прямо в поставке OpenLDAP (тоже на shell, тоже называется schema2ldif), а другой, на мой взгляд, самый развитый, написан на Perl'е, и он вот здесь: storm.alert.sk/soft/schema2ldif/schema2ldif

UPD(2013.05.23): Тот, который на Perl'е, создаёт LDIF'ы для какого-то другого LDAP-сервера, не для OpenLDAP точно!

Лучший графический LDAP-клиент

  • LDAP
Уже очень давно пользуюсь во всех отношениях приятным LDAP-клиентом LDAP Browser/Editor. Эта компактная кроссплатформенная программа на Java с открытым исходным умеет всё или почти всё (не умеет, например, картинки JPEG напрямую в каталог запихивать). Её ближайшим конкурентом можно назвать Apache Directory Studio — клиент более функциональный, интеллектуальный и навороченный, но и более требовательный к ресурсам. Я предпочитаю пользоваться в основном LDAP Browser/Editor'ом и только в каких-то редких случаях — Apache Directory Studio. Из редких случаев стоит упомянуть работу со схемой, просмотр и редактирование Active Directory, а также загрузку любых файлов в каталог (для чего он совершенно не предназначен, поэтому такое кощунство требуется делать действительно редко).

И да, phpLDAPAdmin — штука довольно недоразвитая, ненаглядная и тормозная (как и большинство навязываемых нам «супер-пупер» веб-технологий), поэтому пользоваться ей рекомендую лишь в тех случаях, когда требуется админить LDAP-сервер удалённо из любой точки планеты, и не только под nix'ами, но и под форточками. Но по жизни для нервной системы полезнее будучи на Багамах всё же скачать автономный LDAP-клиент и пользоваться им.

Отличный обзор LDAP Browser/Editor можно найти на сайте LDAP-сервера OpenDS: www.opends.org/wiki/page/LDAPBrowserEditor Правда, указанная там ссылка на домашнюю страничку автора неактуальна уже (видимо, автор прекратил разработку или продолжил её в составе какого-то другого ПО). Тем не менее, программа очень популярна и скачать её можно во многих местах, например, здесь: www.novell.com/communities/files/Gawor_ldapbrow..., а RPM-пакет — здесь: rpm.pbone.net/index.php3/stat/4/idpl/11310306/d...

Mandriva Directory Server

  • LDAP
Mandriva Directory Server is not a Directory Server. Ну почти как WINE Is Not An Emulator.
MDS не является сервером каталогов, это просто веб-интерфейс для настройки стандартных компонент Linux-дистрибутивов на взаимодействие с LDAP. Аналогом можно было бы назвать Microsoft Management Console, если бы… собственно, именно MMC называется ключевой компонент MDS'а (первое слово аббревиатуры конечно не Microsoft)! MDS дирижирует оркестром из DNS, DHCP, Samba, Kerberos, Postfix, подсистем NSS, PAM и собственно сервера каталогов для того, чтобы довольно странным методом при наличии весьма кривой документации делать то же, что умеет (только явно логичнее и проще) Calculate Directory Server. Последний, кстати, тоже ни разу не Directory Server, а просто хороший дистрибутив для ваяния либо аналога nix'ового NIS'а на современный лад, либо nix-based контролера домена Windows, причём последнее по известным причинам более востребовано IT-социумом. Но если краеугольным камнем Calculate DS является OpenLDAP, то чем же рулит чудесная веб-консолька MMC? В теории должна бы уметь работать как с тем же OpenLDAP, так и с Fedora Directory Server, на практике… ну не было у меня такой практики Но по смыслу офдоков в общем-то понятно, что разработка компании Mandriva c продукцией RedHat'а дружит хуже, чем с OpenLDAP.Да, и повторюсь, смысла в данном продукте в принципе не очень много, он пригодится разве что совсем новичкам или тем, кому надо развернуть доменный контролер предельно быстро на «чистом» каталоге. Если у вас уже есть каталог со своей структурой, отражающей логическую структуру организации, то MDS Вам точно ни к чему, потому что вы точно знаете, почему красивый веб-интерфейс на PHP и кучка модулей на Python — это всё-таки ещё не Сервер Каталогов

Подводные камни OpenLDAP

  • LDAP
Если вы используете сервер каталогов OpenLDAP, в особенности для серьёзных Enterprise решений, избегайте следующего:

1) Консервативной склонности к редактированию конфигурационного файла slapd.conf. Сегодня, завтра и далее по расписанию мейнстримом является cn=config — схема, когда вся конфигурация доступна для динамического изменения через собственно протокол LDAP. Именно так это делается во всех без исключения известных мне современных серверах каталогов, и присутствие в OpenLDAP плоского файлика конфига было лишь временной мерой (при этом, заметьте, на этапе запуска OL ещё и время тратит на то, чтобы сделать из вашего slapd.conf'а всё тот же cn=config!)

2) Чрезмерного увлечения различными крутыми фичами OpenLDAP из любых придуманных Зейленгой RFC, носящих экспериментальный характер. Сегодня они есть, завтра их нет — такова жизнь

3) Если вам кажется, что «вот тот overlay/backend» делает как раз такой крутой хак с выворотом, который вам позарез нужен — больно бейте себя по рукам и сначала проверяйте статус разработки этого модуля. Нужно знать, насколько активно он разрабатывается, насколько подробно документирован, есть ли его более-менее подробное описание в официальном OL Admin Guide, а если есть, то подерживает ли он конфигурирование через cn=config. Если модуль не поддерживает cn=config — это верный признак того, что ему пора в топку, мейнтейниться он плохо или вообще никак, и в любой из новых версий OL, которые выходят, сами понимаете, нередко, он может просто кануть в небытие, оставив вас с носом

4) Боже упаси вас делать бэкапы непосредственно бинарных файлов баз типа bdb, hdb и пр. db. Знаете почему? Не только из-за потери транзакций (это как раз не так страшно: в LDAP интенсивные записи редки, а уж конкурентные подавно), но из-за перманентной проблемы несовместимости старых и новых версий библиотек для этих db. Во всяком случае, для BerkeleyDB нельзя быть уверенным даже в том, что минорные версии BDB будут совместимы между собой, а OL просто хлебом не корми, но подавай самые «свежие» библиотеки. Полагайтесь только на полноценные LDIF-дампы, переводя на время дампа базу в read-only, так вы получите заведомо соответствующий «неувядающему» фундаментальному стандарту формат бэкапа.

LDAP-клиенты: SymLabs LDAP Browser

  • LDAP
Написанный на Java LDAP-клиент полукоммерческого происхождения.
1) Под Mandriva Linux установился с правами, ограничивающими доступ даже на запуск исключительно админскими полномочиями (из чего видно, что сами разработчики LB работают в nix только под root'ом)
2) Квадратики вместо русских букв — просто фатальная ошибка
3) Возможности настройки ограничиваются выбором темы, используемой стандартным для Java откровенно уродливым GUI-движком

После того, как я попробовал это чудо, понял, что SymLabs LDAP Proxy, да ещё за деньги, меня совсем не интересует — пусть сами пользуются

LDAP-каталог для Zimbr'ы

  • LDAP
Хотя разработчики Zimbra и призывают использовать чудесную реализацию как бы своего сервера каталогов, это, поверьте мне, совсем не обязательно. Zimbra 6 поставляется с самым обычным OpenLDAP в комплекте и двумя самопальными схемами, в одной из которых все типы атрибутов, кто бы мог подумать (surprise!), имеют наименования вида zimbraЧЕГО_ТО_ТАМ, а другая якобы просто позарез нужна Amavis'у (вирусный/антиспам фильтр). Если Вы где угодно поставите тот же OpenLDAP и подсунете ему две эти схемы — Zimbra не отличит этот каталог от родного. Ну а чтобы не мучаться с перенастройкой местоположения master-ldap'а (после установки Zimbr'ы это как-то дюже хитро делается, а в офдоках альтернативное местоположение master'а можно задать только на этапе установки) можно сделать проброс localhost:389 по SSH (см опцию -L), так, чтобы Zimbra коннектилась к LDAP локально, а реально попадала туда, куда вам угодно. При этом за счёт шифрования вы и секьюрность обеспечите, и откажетесь от совершенно небоснованных претензий Zimbr'овцев на создание очередного сервера каталогов.

Знаете ли вы, что...

  • LDAP
— Атрибуты, чей синтаксис в схеме задан как IA5 String (например, небезызвестный homeDirectory — MUST атрибут objectClass'а posixAccount) по определению не могут содержать символов национальных алфавитов, потому что IA5 — это ни что иное как International Alphabet 5, он же «первая половина ASCII». Символы же национальных алфавитов, символы текстовой псевдографики и прочие специальные (математические дроби, например ), дополняя ASCII до 8-ми бит как раз и создают тот самый «зоопарк кодировок», который был головной болью администраторов до наметившегося тотального перехода всего и вся на использование исключительно Unicode'а.
Всё вышесказанное касается и синтаксиса PrintableString.

Фронтэнд для ldap-клиента OpenLDAP

  • LDAP
Дописал версию 1.0.1 фронтэнда и одновременно — API на языке оболочки BASH для стандартных LDAP-утилит из состава OpenLDAP
Фронтэнд позволяет:
1) Использовать «параметры по умолчанию» из конфигурационного файла в формате INI, каждая секция в котором описывает соединение с определённым сервером.
На данный момент в INI-файле можно задать такие параметры коннекта к LDAP-серверу, как:
BIND DN, BIND PASSWORD, BASE DN (база поиска по дефолту), ROOT DN (суфикс каталога);
2) Автодополнять DN-ы суфиксом каталога;
2) Гибко форматировать LDIF-вывод, нормализуя строки: значение атрибута длиной больше 79-ти символов будет выведено в одну строку;
3) Убирать BASE64-кодирование значений атрибутов там, где это требуется;
3) Получать информацию о глобальных настройках LDAP-каталога и его схеме с помощью команд ldapgetcaps и ldapgetschema соответственно.

Вот как это выглядит в действии на примере ldapsearch:
ldapsearch -c EXAD -N --b64 dn -- '(sAMAccountName=konovalov)' mail

Здесь «EXAD» — имя секции в config-файле, описыавющей параметры соединения и базу поиска «по умолчанию» (заметьте, что в самой команде ldapsearch параметр -b опущен)

Если кому-то сие интересно, могу выложить архив на FTP

P.S. Код потенциально ОЧЕНЬ интересен, поскольку львиная его доля находится в универсальных модулях, не имеющих отношения к ldap-специфике, а просто подключаемых во фронтэнде. Например, там есть функция getArgs (обработка ключей командной строки), по степени проработки сопоставимая с аналогами на языке Perl. Есть ещё parseINI, chk_fl, dbg_out, ну и многое-многое другое, что должно быть полезно хотя бы с точки зрения реализации заложенных в этом идей.

Преобразование из objectSid (Active Directory) в sambaSID (Samba schema)

  • LDAP
echo -n 'AQUAAAAAAAUVAAAAW9a4vvY/d/dUSY8vWA0AAA==' | \
perl -MMIME::Base64 -0777 -ne 'my $a=decode_base64($_);
print "S-" . unpack("C",substr($a,0,1)) . "-" . unpack("C",substr($a,7,1));
for $l (0 .. unpack("C",substr($a,1,1))-1) { 
 print "-" . unpack("I",substr($a,8+$l*4,4));
};
print "\n";'


@настроение: перемен, мы ждём перемен!

Реализация DNS-сервера в ApacheDS...

  • LDAP
Как вам такое: directory.apache.org/apacheds/1.5/561-dns-proto...?
А ещё есть NTP-сервер, например! Чудесно, не правда ли?
Теряюсь в догадках, почему разработчики MySQL не интегрировали в свою мега-СУБД веб-сервер lightHttpd, например. А лучше бы попросту взяли и написали с нуля свой веб-сервер и прямо вместе с кодом php-интерпретатора в код «мускула» его засунули.
Вот ведь уж сколько раз твердили миру, что все попытки воссоздать Active Directory в локальных масштабах не только бесперспективны и необоснованы, но и просто вредны. Очевидно же, что любой производитель софта, не являющийся монополистом со своей технологией в целевом секторе — не может пытаться навязать всем целую инфраструктуру софта. Лучше делать что-то одно и хорошо, даже отлично, как это имеет место в случае лучшего на сегодняшний день и наиболее динамично развивающегося сервера каталогов OpenLDAP, нежели ваять какое-то монструозное решение, в котором куда ни ткни — всё under strongly development, released forever and never. Novell потерялась во времени и пространстве со своим eDirectory, львиная доля функциональности которого без Netware добавляет глюков, но не резонности, теперь вот ещё и Apache Foundation в эту же степь полез со своей перманентной манией величия.
Чем хорош OpenLDAP? Тем, что он встраивается в любую существующую инфраструктуру, он невероятно гибок и метаморфен. Чем хорош ApacheDS? Тем, что предлагает вам заменить буквально всё на чудесное нечто, у которого гигантские пробелы в документации, но зато есть слово Apache в названии? Кхм, ну если бы не Apache, а NGINX, я бы ещё, пожалуй, подумал (вдруг этот сервер каталогов быстрее реактивного истребителя?), а так — ну зачем миру может пригодится yet another nedoAD? Разве что в качестве очередного прекрасного информационного повода для написания тонны-другой Java-кода, дабы на фриланс.ру народ не скучал и свои индусы не сильно голодали?

ПРАВИЛЬНАЯ инциализация OpenLDAP-сервера с динамической конфигурацией

  • LDAP
Положим, перед нами стоит задача «с нуля» настроить новый сервер каталогов, при этом использование безнадёжно устаревшего метода конфигурации, — редактирование slapd.conf, — полностью исключено, поскольку завещано нашими предками: «Делай хорошо, а плохо само получится!»
Исходные данные: есть установленный любым путём OpenLDAP-сервер и стандартные утилиты к нему (во многих дистрибутивах по каким-то странным соображениям клиентская и серверная части OL разнесены по разным пакетам, так что в этом случае вам необходимо установить и то, и другое)
Требуется: создать рабочую конфигурацию LDAP-каталога и добавить суффикс dc=example,dc=com, при этом использовать slapd.conf на любом этапе нельзя (мы же твёрдо решили отказаться от этого анахронизма).

Здесь перед вами встаёт дилема: раз нельзя использовать slapd.conf, значит нужно написать конфигурацию каким-либо иным образом. А поскольку известно, что физически на файловой системе дерево конфигурации представляет собой структуру каталогов со вложенными ldif-файлами, то первое, что приходит на ум — это изучение 5-й главы «Руководства администратора OpenLDAP» на предмет того, как бы написать все необходимые LDIF'ы самому (и при этом не сойти с ума, узнав, что operationalAttributes для cn=config никто не отменял). Когда я первый раз решил настроить свой сервер каталогов через cn=config и попытался создать всё дерево настроек вручную, скурпулёзно следуя этой самой 5-й главе, я потерпел фиаско, при этом с пользой потратив время на изучение внутреннего устройства конфигурации. Оказалось, что такой подход — неправильный. Дальнейшее изучение документации, в том числе и man-страниц (для проекта OpenLDAP вообще характерно, что в man'ах можно найти значительно более обстоятельную информацию, нежели в «Руководстве администратора»;) привело меня к тому, что можно создать некий простенький стартаповый файл конфигурации slapd.conf, который slapd при запуске со своеобразным «секретным» сочетанием параметров -f <путь_к_slapd.conf> -F <каталог_для_cn=config> — преобразует к формату cn=config'а (впрочем, он это в любом случае делает при каждом запуске) и сам выложит в «каталог_для_cn=config» всю нужную мне структуру. Таким образом я действительно добился результата, в заботливо созданном и подсунутом slapd в параметре -F каталоге и правда появилась структура с нужными ldif'ами, но… при этом получалось, что мне так и не удалось избавиться от slapd.conf, ведь на этапе инициализации он в минималистичном виде, но всё же понадобился. А хотелось не прибегать к помощи slapd.conf'а совсем, к тому же по всем признакам было понятно, что сами разработчики OpenLDAP'а не используют этот неудобный и явно устаревший метод. «А ларчик просто открывался» — решение, оказалось, лежало на поверхности!
Итак, всё НАМНОГО элементарнее, чем вы думали, если вы над этим уже думали, мой дорогой читатель, на что я, честно говоря, очень рассчитываю.
Перво-наперво нужно создать каталог для cn=config, он может называться как угодно и находиться по сути дела где угодно, лишь бы файловая система была доступна на запись и позволяла устанавливать права доступа для UNIX'овых пользователей. Например:
mkdir -p /etc/openldap/slapd.d/example

После создания каталога вам нужно определиться с паролем, который будет использоваться для доступа к конфигурации. Используйте утилиту slappasswd (на самом деле это тот же slapd) для получения шифрованного пароля:
slappasswd -h '{<МЕТОД_ХЕШИРОВАНИЯ>}' -s 'ПАРОЛЬ'

Например:
Команда: slappasswd -h '{MD5}' -s 'topsecret'
Вывод: {MD5}6oR5iLpZcn2/TjTudXJtww==

Если вы немного параноик (что в принципе хорошо) и не привыкли оставлять не предназначенные для чужих глаз сведения в своём history, можете не указывать пароль в открытом виде и опустить опцию -s, но тогда вам придётся два раза вводить одно и то же, как в утилите passwd.
Скопируйте вывод команды slappasswd, например, просто выделив его мышью в окне терминала. Теперь вам предстоит… да-да, написать начальную конфигурацию, которая разрешила бы классическую дилему с курицей и яйцом, возникающую из-за того, что наполнить дерево cn=config можно только после запуска сервера, а сервер не запустить, если для него вообще нет конфигурационной информации.
Но это делается на самом деле даже проще, чем со slapd.conf'ом. Итак, открываем любимый текстовый редактор и пишем:
dn: cn=config
objectClass: olcGlobal
cn: config

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: ШИФР_ПАРОЛЬ

Собственно на место ШИФР_ПАРОЛЬ нужно вставить тот вывод slappasswd, который вы перед этим скопировали.
Вуаля, начальная конфигурация готова, её можно сохранить в файл — например, под именем startup-config.ldif. Теперь всё готово для того, чтобы в правильном формате «скормить» этот файл LDAP-серверу, при этом не запуская его. Для добавления данных в напрямую в бэкенды OpenLDAP, а не через посредство сервера, то есть в режиме оффлайн, предназначена утилита slapadd (опять же, на самом деле это просто ссылка на slapd, имя которой является своеобразным неявным параметром, определяющим, что данному бинарнику следует делать). Шаблон начальной конфигурации, в котором, заметьте, нашего пока ничего, кроме пароля, нет, загружается следующим образом:
slapadd -n 0 -F <КАТАЛОГ_ДЛЯ_cn=config> -l <ФАЙЛ_НАЧАЛЬНОЙ_КОНФИГУРАЦИИ>

Обратите внимание на то, что мы обязательно должны передать утилите slapadd параметр -n 0, что означает «добавить данные в базу номер ноль». Посмотрите на файл начальной конфигурации: в нём описание собственно самой базы cn=config находится в dn: olcDatabase={0}config,cn=config. Следует обратить внимание на число 0, указанное в фигурных скобках — это собственно тот самый индекс базы (для cn=config всегда равен нулю), который мы затем указываем в параметре -n для slapadd. Делать это явным образом нужно потому, что по умолчанию slapadd пытается добавить данные в базу, соответствующую первому инициализированному суффиксу с индексом больше единицы (обычно это уже собственно содержимое каталога, то есть пользовательские данные).
Итак, для примера считаем, что под нужды cn=config мы создали каталог /etc/openldap/slapd.d/example, тогда команда может выглядеть так:
Команда: slapadd -n 0 -F /etc/openldap/slapd.d/example -l ПУТЬ/К/ФАЙЛУ/startup-config.ldif
Вывод: _#################### 100.00% eta none elapsed none fast!
Closing DB...

Убедитесь в том, что теперь каталог cn=config'а не пуст, выполнив в нём ls -lR. Если вы видите структуру каталогов со вложенными ldif'ами, значит всё в порядке, в противном случае перечитайте всё изложенное мной выше и попытайтесь понять, что вы сделали не так :) Вроде бы всё сделали, но остаётся один маленький штришок: поскольку все предыдуще действия были произведены под суперпользователем, а OpenLDAP в целях безопасности должен запускаться с правами собственной учётной записи, если сейчас просто взять и запустить LDAP-сервер указав ему в параметре -F только что инициализированную нами базу cn=config, он не сможет получить доступ к файлам — ведь они принадлежат root и на них утилитой slapadd предусмотрительно установлена маска доступа со сброшенными битами для «группы» и «остальных». Поэтому в каталоге с базой cn=config'а нужно рекурсивно поменять владельца на того пользователя, с правами которого будет запускаться сервер. Для того, чтобы узнать имя этого самого пользователя, посмотрите вывод getent passwd | fgrep -i ldap, скорее всего его так и зовут: «ldap», — хотя в Debian'е, например, традиционно уже решили соригинальничать и назвали его openldap, что не суть важно (в особенности, если вы умеете быстро печатать десятипальцевым методом, который ваш покорный слуга так до сей поры чудесной и не освоил).
В примере после chown -R ldap.ldap /etc/openldap/slapd.d/example мы имеем готовую работоспособную конфигурацию, пусть и простейшую и теперь мы можем запустить сам сервер:
slapd -F /etc/openldap/slapd.d/example -u ldap -g ldap -h ldap:///

Итак, если вы точно следовали моим рекомендациям, уже сейчас у вас есть сервер OpenLDAP, который больше не нужно перезапускать, все оставшиеся действия по настройке (подключение модулей, расширение схемы, добавление суффиксов) вы будете делать только в режиме «онлайн», изменяя конфигурацию на работающем сервере!

Сделав наш сервер максимально гибким и конфигурируемым благодаря динамическому дереву настроек cn=config, мы конечно же не можем не вопользоваться теперь предоставленными нам широчайшими возможностями для того, чтобы создать суффикс dc=example,dc=net (ведь именно это нам в конечном счёте и нужно, не правда ли?).
Но дабы вы не наступали всё на те же чудные грабли, на которые наступал я и не раз, даже не надейтесь на то, что хотя бы минимально необходимые атрибуты и классы объектов сейчас есть в составе автоматически созданного сервером дерева настроек. Да оно в общем и не мудрено — ведь прописывали же вы все так называемые файлы схем в древнем, как сама история файлике slapd.conf? И ведь там даже core.schema нужно было явным образом указывать, иначе вообще ничего у вас не заработало бы. Ну так я могу вас обрадовать тем, что в случае с cn=config определённый прогресс уже есть и то, что лежит в core по умолчанию будет лежать у вас в cn=schema,cn=config. Всё остальное же нужно добавлять самим. При этом очевидно, что поскольку сама по себе схема каталога интегрирована в дерево cn=config, то и добавлять её составляющие нужно будет как обычные LDIF-файлы: ведь именно то, что мы видим в дереве конфигурации — это и есть представление данных именно в том виде, в котором их читает сервер, эта конфигурация уже не интерпретируется, как раньше происходило с файлом slapd.conf, где include'ы считывались в процессе парсинга. Но где же взять файлы нужных схем в формате LDIF, спросите вы? Вопрос не праздный, потому что никаких утилит преобразования файлов schema в LDIF'ы в поставке OpenLDAP'а нет (что, вообще говоря, довольно странно и вообще вряд ли сей факт имеет какое-о разумное объяснение с учётом того, что до сих пор большинство кустарных схем к огромному количеству самого разного софта так и поставляется в старом формате). Если вы внимательно рассмотрите содержимое каталога /etc/openldap/schema (соответственно, это может быть другой каталог, в зависимости от того, что у вас за система и/или какое значение prefix вы задали на этапе конфигурирования), то найдёте там несколько важных (если не сказать ключевых) и наиболее часто используемых файлов схем в формате LDIF. Любые другие схемы можно добавить, переконвертировав их из schema в ldif довольно простым скриптом на bash, который я приведу чуть позже. А пока давайте просто добавим схемы в том порядке, в котором их взаимные зависимости будут удовлетворены. Поскольку в поставке OpenLDAP'а таких схем маловато, пока что можно особо не заморачиваться взаимозависимостями и сделать это так, как делал я:
while read s; do ldapadd -x -D 'cn=config' -w 'ПАРОЛЬ_ДЛЯ_cn=config' -f $s; done < <( find /etc/openldap/schema/ -type f -name '*.ldif' -a ! -name 'core.ldif' ) 

Собственно, вся «хитрость» данного подхода заключается в том, что схемы в алфавитном порядке имён файлов грузятся правильно, а если их попытаться «скормить» серверу том порядке, в котором их находит find, возникают конфликты неразрешённых зависимостей. В общем, это всё не суть важно, можно и руками загружать при желании.

Что ж, теперь у нас есть базовый набор схем и можно приступать к настройке суффикса. Впрочем, постойте, а поверх чего этот суффикс будет работать? Ведь наверняка же поверх бэкендов BDB или HDB? А модули для этих бэкендов загружены или, возможно, вполне возможно, всё необходимое статически скомпилировано со slapd? Для того, чтобы узнать, был ли slapd собран полностью статично, попробуйте следующий запрос:
ldapsearch -xLLL -b 'cn=subschema' -s base '(objectClass=*)' '+' | fgrep olcModuleList

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

Для того, чтобы точно узнать, требуются от вас какие-либо дополнительные действия или нет, действуйте по принципу доказательства от противного: попробуйте загрузить LDIF для нового пространства имён (суффикса), например:

dn: olcDatabase=bdb,cn=config
objectClass: top
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: bdb
olcSuffix: dc=example,dc=com
olcRootDN: cn=manager,dc=example,dc=com
olcRootPW: ШИФР_ПАРОЛЬ
olcDbDirectory: /var/lib/ldap

Надеюсь, для тех, кто хоть раз настраивал сервер OpenLDAP, всё достаточно очевидно. ШИФР_ПАРОЛЬ сформируйте командой slappasswd по аналогии с тем, как вы это делали для cn=config. В olcDbDirectory прописывается путь к каталогу, в котором будут размещаться файлы базы данных-бэкенда (например, Berkeley DB), то есть это аналог директивы directory в slapd.conf. Если при попытке добавить данный LDIF в дерево конфигурации вы получаете ошибку, свидетельстующую об отсутствии objectClass'а olcBdbConfig, значит, либо не загружен соответствующий модуль (но для этого предыдущая проверка должна была пройти успешно и objectClass olcModuleList присутствует в текущей схеме), либо кто-то (возможно, вы сами) умудрился статически скомпилировать slapd без поддержки Berkeley DB. Аналогично и в случае с HDB.
Если выяснилось, что вам нужно подгрузить модуль, в соответствии с п.п. 5.2.2 «Руководства администратора», добавьте следующий LDIF:
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: ПУТЬ/К/МОДУЛЮ/back_bdb.la

Заметьте, что индексы в фигурных скобках в начале RDN (как тот же «cn={0}module» в Руководстве) на самом деле генерируются сервером автоматически, их нужно указывать явно _только_ в особых случаях (например, когда нужно «раздвинуть» существующие индексы, вставив новый элемент).
Стоит особо отметить, что при истинно модульной конфигурации OpenLDAP, подобной модульной сборке ядра операционной системы, все компоненты по возможности находятся в отдельных подключаемых во время исполнения бинарных файлах с расширением «la». В этих случаях иногда требуется подключить не один-два модуля, а, например, десяток или даже больше. Понятное дело, что каждый раз указывать полный путь к файлам модулей в директиве olcModuleLoad в этом случае несколько нерационально, в особенности если у вас все la-шные файлы лежат в одном и том же каталоге. В этом случае можно добавить директиву olcModulePath, которая выполняет ту же функцию, что и системная переменная PATH — определяет пути поиска файлов по умолчанию. В этом случае LDIF для добавления нужных модулей может выглядеть так:
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap/bin:/usr/share/samba/ldap/modules:<и т.д.>
olcModuleLoad: back_bdb.la
olcModuleLoad: back_hdb.la
olcModuleLoad: back_sock.la
olcModuleLoad: <ещё_один_модуль>.la

Мигрировать или не мигрировать?

  • LDAP
Относительно вопроса о том, мигрировать или не мигрировать на систему хранения настроек LDAP-каталога в дереве cn=config вместо плоского конфигурационного файла slapd.conf, могу сказать совершенно точно, что только крайний консерватизм, берущий свои истоки из глупости и простого непрофессионализма (непонимания, отсутствия опыта работы с другими серверами каталогов, где в отличие от OpenLDAP, конфигурация всегда хранилась как часть самого каталога) может стать препятствием на пути использования исключительно cn=config.

У cn=config масса преимуществ, среди которых:

1) Прозрачный и всегда понятный иерархический вид конфигурации, существенно снижающий вероятность ошибки из-за указания параметров «не там», благодаря тому, что в cn=config настройки представлены в том виде, в котором с ними работает сам сервер

2) Динамическая конфигурация — можно управлять OpenLDAP-сервером в режиме «онлайн», не нужно перезапускать сервер или заставлять его перечитывать свои конфиги после каждого изменения

3) Из пункта 2 следует, что и новые суффикы каталога, и списки контроля доступа к ним можно создавать «налету» Сервер и обслуживаемый им каталог могут постоянно меняться, используемая схема может расширяться как угодно и когда угодно, но сам по себе сервер всегда будет доступен, ничто не помешает аптайму OpenLDAP 'а устремиться к бесконечности

4) Хотя cn=config отображается в пространстве каталога и доступен для просмотра/модификации по протоколу LDAP, тем не менее у вас всегда остаётся возможность в каких-то критических ситуациях получить доступ к конфигурации даже при остановленном сервере. Магия проста: бэкендом для cn=config является обычная файловая система UNIX, то есть это просто множество ldif-файлов, описывающих объекты, вложенных в каталоги-узлы, отражающие иерархические связи внутри дерева. Если что-то пошло не так, всегда можно вооружиться любимым текстовым редактором и отредактировать нужные объекты дерева так, словно вы правите обычный LDIF (да ведь по сути, так оно и есть).

GUI для OpenLDAP

  • LDAP
Задали мне вопрос на форуме о том, какими инструментами с графическим интерфейсом заводить пользователей в OpenLDAP. Ответ на этот вопрос прост до безумия: теми, какие вам больше нравятся. Дело в том, что человек, задавший вопрос, либо предварительно не искал ответ на свой вопрос, либо искал не там.

Впрочем, поделюсь «секретом фирмы»: сам я когда-то пользовался LDAP Account Manager'ом и остался им очень доволен. Конечно, это Web-приложение, но тем не менее не думаю, что тем же кадровикам будет трудно им пользоваться.

По опыту же в большинстве организаций от мала до велика данную «проблему» решают путём интеграции самописного LDAP-клиента в Интранет-портал. Дело в том, что инструменты типа LAM могут использоваться только по отношению к информации Windows-доменов, для интеграции LDAP-каталога с другими службами наподобие почтового сервера или DNS нужно использовать уже какие-то другие веб-инструменты. Удобно же иметь всё под рукой… Кстати, такое решение есть и не только для Active Directory, который свою супер-интеграцию распространяет исключительно на Windows-службы, но и для нормальных LDAP-каталогов общего назначения. Называется это решение GOSA.

P.S. Да, кстати, предвижу вопрос о том, почему я не стал отвечать на форуме. Всё достаточно банально: я забыл пароль и теперь с нетерпением жду письма от форумного движка (хотя вряд ли он мне его отправит) или хотя бы тотального SSO во вём мире