Лучший графический 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...

Подводные камни 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'а таких схем маловат