Microhint: Загрузка модуля OpenLDAP требует 2 файла, а не 1!

  • LDAP
Модули, содержащиеся в contrib исходных кодов openldap'а (и любые другие), требуют для своей загрузки не только файл с расширением ".la", но и соответствующий файл с расширением ".so", лежащий в одном каталоге с ".la".

Проблема может возникнуть из-за того, что неторопливсые люди наподобие меня могут получить в результате простого make'а соответствующего модуля файл с расширением ".la", скопировать его в каталог olcModulePath, радостно попытаться модуль подгрузить olcModuleLoad'ом и… получить «file not found» в логах, который по какому-то глупому недоразумению разработчиков OpenLDAP ссылается не на нехватку ".so", а на якобы отсутствие ".la". Но вы-то знаете, что этот файл на самом деле есть!
А в действительности файлик с расширением ".so" создаётся make install'ом, и без него модуль грузится не будет.

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

Компиляция OpenLDAP: хватит спотыкаться!

  • LDAP
После того, как я уже в 10-й раз споткнулся об одну и ту же дурацкую проблему, решил наконец записать себе на память и другим на заметку:
При компиляции OpenLDAP с оверлеями и бэкендами в виде модулей недостаточно просто сказать --enable-smth=mod, нужно до этого обязательно упомянуть --enable-modules=yes. Иначе вы просто замучаетесь искать свои модули в логе установки (то есть в сохранённом выводе make install): их там не будет.
Я не знаю, зачем разработчики подложили простым пользователям такую жирную свинью, но забывать о том, что сие животное в самый неподходящий момент может броситься к вам под колёса — совершенно не стоит.

Авторизация в Openmeetings с учетной записью Active Directory

  • FreeBSD
Так как Openmeetings напрямую к AD не прикручивается, действовать будем через OpenLDAP.
Итак. Ставим из портов OpenLDAP Server версии не ниже 2.3, так как более младшие версии не могут прозрачно передавать неизвестную схему.

Читать дальше →

Схема DUAConfigProfile (RFC4876) для OpenLDAP

  • LDAP
Поскольку уже конвертированной схемы не нашлось, выкладываю свою.
Схема в частности пригодится для интеграции SUDO и LDAP при дословной реализации штатного README на эту тему. Хотя обязательной её назвать нельзя, поскольку в действительности SUDO работает с LDAP-каталогом и без неё.

Читать дальше →

Permission denied при чтении конфигурационной директории OpenLDAP

  • LDAP
Столкнулся с такой загадочной проблемой: при попытке считать свою конфигурационную директорию, а именно файл cn=config.ldif, LDAP-сервер из штатной поставки Ubuntu 11.10 Oneiric страшно ругается Permission denied и спешно завершается.
Никаких объективных предпосылок для этого нет, права на чтение/запись пользователю openldap даны, sudo -u openldap cat <config_path>/cn=config.ldif отрабатывает правильно. И уж совсем странно, что будучи запущенным под рутом без опций -u и -g, slapd точно также не может получить доступ к своей конфигурации. Запустил его с strace'ом: на привилегированный порт 389 биндится, effective user id не меняет, к счастью, никаких chroot'ов без спроса не делает, но… но в итоге slapd всё равно благополучно валится:

open("/etc/openldap/domains/DOMAIN/conf/cn=config.ldif", O_RDONLY) = -1 EACCES (Permission denied)

Проблема решилась очень просто: взял исходники с openldap.org и собрал из исходников, получив совершенно адекватную рабочую версию сервера.
Ещё попробую изучить вопрос, но в любом случае предупреждаю, что в Ubuntu со штатной сборкой slapd явно что-то не так.

Путь до файла ldap.conf

  • LDAP
В некоторых ситуациях путь до файлов ldap.conf и ldap.secret (настройки модулей nss_ldap и pam_ldap) может быть полезным изменить: например, для объединения настройки клиентских библиотек и утилит из поставки OpenLDAP с настройкой модулей NSS/PAM от padl.com'а (трудно понять, зачем вообще эти файлы с одинаковым синтаксисом и названием опций изначально нужно было разделять), так и, например, для того, чтобы убрать ldap.secret «с глаз долой».
Просто соберите модули поддержки LDAP в NSS/PAM, со следующими опциями configure:

--with-ldap-conf-file=PATH_TO_CONFIG  --with-ldap-secret-file=PATH_TO_PASSWORD_FILE

Кстати, в случае с pam_ldap положение ldap.conf можно указать и динамически — с использованием опции config= в соотв. строке pam.conf или /etc/pam.d/*.

Компиляция BerkeleyDB для сборки OpenLDAP из исходников

  • LDAP
Сервер OpenLDAP для своей работы как правило требует хотя бы более-менее свежую версию Oracle BerkeleyDB. К сожалению, есть такие дистрибутивы, которые очень сложно или вовсе невозможно обновить, не переустанавливая (CentOS) и есть аналогичные энтерпрайз-решения, с которыми в общем таже беда (RedHat ES). При этом на BerkeleyDB завязаны многие дистрибутивные пакеты, а взаимодействие с этим движком файловых БД реализовано столь грамотно и удобно, что простая смена минорного номера версии запросто приводит к неработоспособности всего софта, который был скомпилирован для версии более старой. Так что же делать?
Ответ очевиден и прост до гениальности одновременно: компилировать движок BerkeleyDB отдельно так, чтобы только OpenLDAP его и «увидел».
Для начала установим BerkeleyDB (простейший вариант, без переопределения PREFIX'а установки — ибо ну и пусть себе следует прямой наводкой в /usr/local):


[[ -d ~/Compile ]] || mkdir ~/Compile
tar -xvf ~/Downloads/db-5.2.36.tar.gz -C ~/Compile
cd ~/Compile/db-5.2.36/build_unix
../dist/configure --enable-posixmutexes --with-mutex=POSIX/pthreads
make && su -c 'make install'


Ну а теперь компилируем OpenLDAP, не забыв показать скрипту configure, где лежит заветный BerkeleyDB:

CFLAGS=-L/usr/local/BerkeleyDB.5.2/lib CPPFLAGS=-I/usr/local/BerkeleyDB.5.2/include ./configure <здесь_могли_быть_ваши_опции>

Собственно, всё, с новым OpenLDAP'ом вас, господа!

P.S. Идея довольно простая, но тем не менее многие люди, включая и меня до недавнего времени, не решаются компилировать BerkeleyDB напрямую или пытаются обновить BDB, упираясь в непроходимы(й идиотизм)е дебри системы обновления своего дистрибутива: ведь даже в Gentoo пересобрать BDB для одного-единственного приложения не так-то просто…

Проект Pro-LDAP.ru

  • LDAP
Хочу представить свой проект Pro-LDAP.ru (Про LDAP по-русски), http://pro-ldap.ru/. О целях проекта рассказано на его главной странице, если коротко, хотелось бы собрать в одном месте максимум информации на русском языке, которая могла бы принести реальную пользу системным администраторам, занимающимся службами каталогов.
В ближайших планах: в 2011 году закончить перевод OpenLDAP 2.4 Admin Guide (текущий вариант перевода http://pro-ldap.ru/tr/admin24/), в 2012 — перевести man-страницы OpenLDAP.
Хотелось бы услышать Вашу оценку (критическую, разумеется) качества перевода, а также предложения по дальнейшему развитию проекта, нужен ли на сайте форум и т. п.
Если есть желание помочь с переводом, либо предоставить хорошие статьи/материалы, пишите, адреса есть на главной странице сайта проекта. Буду благодарен за любую помощь!

Две типичные проблемы сборки OpenLDAP из исходников

  • LDAP
По моему опыту две самые трудноразрешимые проблемы при компиляции OpenLDAP — это:
1) Требование установки Mozilla NSS library
2) Критичность наличия в системе самой свежей Berkeley DB

Если вы попытаетесь решить первую проблему «в лоб», скорее всего ничего у вас не получится: хотя вожделенный OpenLDAP'ом nssutil.h есть в каждом дистрибутиве, это на самом деле совсем не тот nssutil. который нужен для сборки. А чтобы достать нужный, придётся перекопать девелоперский сайт Mozilla и скомпилировать NSS+NSPR, полученные из «официальных источников». Если же, как говорил Прутков, «зрить в корень», то NSS сам по себе вовсе и не требуется для компиляции OpenLDAP, это всего лишь один из вариантов реализации TLS/SSL. Соответственно, намного проще использовать для этих нужд старый-добрый пакет OpenSSL, что и достигается элементарно установкой пакета openssl-devel (или аналогичного, содержащего заголовочные файлы для OpenSSL) и (необязательным) указанием опции --with-tls=openssl. Явное указание на реализацию TLS действительно необязательно, потому что значение по умолчанию with-tls=auto, то есть скрипт configure и сам последовательно проверит наличие в системе openssl, gnutls и moznss, остановившись на первой доступной реализации TLS из этого списка.

Читать дальше →

Динамические списки внутри не "списочных" объектов

  • LDAP
Положим, у вас уже есть объект с описанием отдела фирмы, содержащим массу полезных атрибутов, включая фотографию начальника в костюме деда мороза и ряженных в зайчиков подчинённых с последнего корпоратива. И вот возникла задача собрать ещё и список сотрудников внутри объекта отдела и формировать его, разумеется, не вручную, а, как и положено в лучших домах Лондона и Парижа, динамически.
Читать дальше →

RFC 3062 и метод хеширования паролей

  • LDAP
Все мы знаем или, возможно даже, предстоит нам ещё узнать о том, что в LDAP предусмотрена такая атомарная операция как «LDAP Modify Password». Описана она в RFC3062, реализована во всех известных мне серверах каталогов — разумеется, и в OpenLDAP тоже. Пароли хранятся в атрибуте userPassword, а простейшим типом объекта, включающим данный атрибут, является… ну конечно же simpleSecurityObject (кстати, пусть эта кажущаяся простота не будет для вас обманчивой, ибо этот objectClass AUXILIARY).
Ну да суть не в этом, а в том, что пароли в атрибуте userPassword принято хранить шифрованном виде и при запросе выполнения операции LDAP Modify Password серверу нужно бы выбрать какой-то метод… криптования, хеширования… ну, в общем, превращения пароля во что-то неудобочитаемое и не подлежащее восстановлению. Каким же образом можно сказать, например, серверу OpenLDAP использовать… положим, MD5 вместо SSHA, используемого по умолчанию? Для нужды сией существует атрибут с говорящим названием olcPasswordHash, значение которого должно быть представлено в формате {МЕТОД_ШИФРОВАНИЯ}, т.е. применительно к упомянутому выше гипотетическому случаю наличия потребности иметь все пароли захешированными в MD5, Вам нужно будет изменить глобальную конфигурацию cn=config (ниже)следующим образом:
dn: cn=config
changeType: modify
add: olcPasswordHash
olcPasswordHash: {MD5}

"LDAPCon 2011" ли Кто-со-мною-в-Гейдельберг? :)

  • LDAP
10-го — 11-го октября 2011-го года в немецком городе Гейдельберг состоится замечательное мероприятие — 3-я международная конференция LDAPCon. Данная конференция ориентирована прежде всего на IT-специалистов, интересующихся технологией иерархических объектно-ориентированных каталогов, а также представителей компаний, разрабатывающих ПО «для и с помощью» LDAP-каталогов.
В программный комитет мероприятия вошли известные в мире LDAP разработчики, учёные и представители крупных компаний.
Среди них есть и поистине легендарные личности:
  • Говард Чу, руководитель и координатор проекта OpenLDAP
  • Курт Зейленга, отец-основатель OpenLDAP, автор многих LDAP и XMPP-related документов RFC
  • Людовик Пуату (Ludovic Poitou), теперь уже единственный разработчик замечательного сервера каталогов OpenDS, работавший в Sun Microsystems до поглощения её Oracle'ом (см. заметку о Людовике в этом блоге)
  • Дэвид Чадвик, профессор из университета Кента, профессионально занимается проблемами идентификации личности и защиты персональных данных, автор множества публикаций на эту тему
  • Ну и конечно же Dieter Klünter, организатор конференции LDAPCon 2009. Если вы читаете рассылки проекта OpenLDAP, то вы непременно знаете и его :)
Организатором и спонсором (пока единственным) конференции «LDAPCon 2011» является компания DAASI International GmbH.

Чем отличается AD от "нормальных" LDAP каталогов?

Распространнным заблуждением является то, что Active Directory — вроде бы какой-то особый LDAP-сервер с присущими ему «волшебными» таинственно-проприетарными свойствами.
Вкратце скажу, что это не так: Active Directory вполне обычный LDAP-каталог, со своими плюсами и минусами и способы доступа к нему тоже вполне обычны.
Например, возьмём операцию BIND. BiND — это не только самый популярный DNS-сервер в мире от известной компании ISC, но ещё и операция аутентификации пользователя на LDAP-сервере, ассоциирующая его с тем или иным DN, либо же, в случае, если пользователь предпочёл оставаться инкогнито, он будет ассоциирован с таким всеобъемлющим понятием как «anonymous»
Читать дальше →

Принудительный LDIF line wrapping отменяется!

  • LDAP
Не прошло и пяти лет, как в ldapsearch наконец добавили опцию, позволяющую выводить LDIF без переносов строк. Напомню, что переносы эти ставились в соответствии со стандартом MIME, который сам по себе вообще весьма сомнительное отношение имеет к LDIF, но тем не менее. Особо хотелось бы отметить, что в реализациях ldapsearch родом из проекта iPlanet (детища консорциума Sun Microsystems и Netscape) подобная опция была с самого начала, а в OpenLDAP'овском клиенте её не добавляли исключительно по принципиальным соображениям строгого следования букве и духу стандартов, даже если это ограничивает свободу выбора или попросту противоречит здравому смыслу. Но в 2.4.24 они всё-таки сдались, так что скомпилировав его вы получите чудесный новенький ldapsearch, умеющий знаете что?
Вот:
ldapsearch -LLLZZZ -b 'dc=company,dc=com' -s one -o ldif-wrap=no

BASH Tips&Tricks #0002: Форматируем вывод ldapsearch

  • BASH
Если вам случалось писать на BASH скрипты, работающие с LDAP, то вы наверное уже в курсе, что клиентская утилита ldapsearch, входящая в поставку OpenLDAP, а потому имеющаяся в комплекте большинства дистрибутивов Linux, из каких-то своих соображений (оказывается, это требование RFC 2045) выводит результирующий LDIF со строками, длина которых не превышает 78 символов. Соответственно, те строки, что оказываются длиннее 78-и символов, попросту разбиваются по правилам формата LDIF: в начале продолжения предыдущей строки ставится один пробельный символ.
Анализ такого LDIF на языке оболочки bash может быть затруднительным, гораздо удобнее, когда значение атрибута умещается в одной строке.
Читать дальше →

Беспарольная авторизация на сервере OpenLDAP с использованием SASL

  • LDAP
Возникла как-то у вашего покорного слуги насущная потребность ходить на LDAP-сервер секьюрно (то есть по шифрованному соединению, а не со 100% гарантией безопасности, как можно было бы подумать), но без ввода пароля. Идея хорошая, но почему-то традиционно слова «секьюрно» и «без пароля» ассоциируются с такими громоздкими понятиями, как Kerberos, GSSAPI, SSO, Настройка всего этого — занятие не только трудоёмкое, но и не всегда оправданное: один человек это настроит, другой же, который рано или поздно придёт работать на его место, довольно быстро сойдёт с ума, а это нехорошо, потому что с людьми нужно быть… гуманнее как минимум :)

Читать дальше →

Архитекторы LDAP: Курт Зейленга

  • LDAP
Курт Зейленга — Исполнительный директор OpenLDAP-фонда и консультант Проекта OpenLDAP, он основал обе организации летом 1998-го года и занимал должность Главного архитектора Проекта OpenLDAP с момента его основания вплоть до 2007-го года.
В настоящее время Курт на условиях полной занятости работает Инженером-разработчиком в компании Isode Limited, занимающейся проектированием интернет-технологий и стандартов с акцентом в области каталогов, обмена сообщениями и безопасности. Интересы Курта затрагивают не только разработку каталогов, но и «менее очевидные» вещи — такие как интернет-службы обеспечения безопасности, в особенности используемые для защиты протоколов прикладного уровня [модели OSI].
Курт — активный участник Internet Engineering Task Force (IETF). Он состоит в Директорате LDAP, Директорате по Безопасности, и Директорате Прикладной области. Авторство многих документов Internet-Drafts (черновых вариантов интернет-стандартов) непосрественно принадлежит Зейленге, многие [другие] он редактировал. Некоторое количество черновых вариантов стандартов, написанных им, в итоге приобрели статус стандартов RFC*. Курт участвует в рабочих группах LDAP Revision (LDAPbis), Simple Authentication and Security Layer (SASL), также vCard и CardDav.

Также Зейленга занят в работе Фонда Стандартов XMPP и является автором нескольких спецификаций Протокола Расширений XMPP (XEP). Трудовая деятельность Курта в Isode Limited (и не только) тесно связана с этой областью.

* несмотря на присутствие слова few в англоязычном оригинале, количество это весьма внушительно

Англоязычный оригинал на сайте OpenLDAP Project

MultiMaster vs. Mirroring

  • LDAP
По возможности не используйте Multimaster-репликацию в её полноценном виде:

— теоретически неограниченое количество мастер-серверов,

— каждый мастер-сервер может принимать реплики изменений с любого другого мастер-сервера.

Дело в том, что это работает только в том случае, если все мастер-сервера создаются с нуля и практически одновременно. Это именно так в случае с простым тестом 050-multimaster, на который так любят ссылаться разработчики OpenLDAP. Тем не менее даже такой вроде бы стабильно работающий кластер взаимнореплицируемых серверов может потерять ноду… А потом вторую… В особенности это касается тех случаев, когда нод больше трёх: число три для режима Multimaster'а в OpenLDAP является каким-то магическим порогом, за которым начинаются эксперименты над критически важными данными с плохо прогнозируемыми последствиями.
Mirroring (зеркалирование) — технически тот же MultiMaster (найдите отличия в конфигурации? olcServerID?), но это иная стратегия репликации. Эта стратегия предполагает, что в штатном режиме работы запись производится лишь на одном сервере, а на второй сервер изменения пересылаются репликой. При этом чтение может осуществляться одновременно с двух серверов при помощи внешнего балансирующего нагрузку фронтэнда (не входит в поставку OpenLDAP можно использовать прокси-режимы работы OL). В случае отказа сервера, принимающего операции записи от клиентов, их начинает принимать неактивная часть «зеркала». Как только «отвалившаяся» часть зеркала поднимется, все операции записи, произведённые за время простоя, будут приняты репликой.
В общем, на самом деле, подчёркиваю, никакой принципиальной разницы между мультимастером и зеркалированием нет, кроме собственно количества нод. Но использование описанной стратегии даёт гораздо более предсказуемый результат, даже если вы не используете никаких внешних фронтэндов и все переключения осуществляете вручную.

P.S. Да, и в любом случае backup often

Одна из распространённых проблем репликации

  • LDAP
Если ваша база OpenLDAP упорно отказывается реплицироваться, запустите сервер, на который вы хотите залить реплику, с ключом -d 16384 (отладка механизма репликации). И если там будет явная «ругань» на то, что с мастер-сервера невозможно получить entryUUID для некоторых записей, это значит, что в исходном каталоге не хватает служебных атрибутов, без которых репликация действительно не пойдёт. Отложим обсуждение вопроса о том, почему так бывает, просто пофиксим эту проблему:
Если база относительно небольшая, переведите её в read-only и сделайте полный slapcat:
$ echo 'dn: olcDatabase={номер_базы}тип_бэкенда,cn=config changeType: modifyreplace: olcReadOnlyolcReadOnly: TRUE' | \ ldapmodify -x -D cn=config -Wbr /&
$ slapcat -F /path/to/config/dir -n номер_базы & my_db.ldif

А теперь… физически удалите файлы базы и залейте LDIF-дамп базы, полученный на шаге 1, обратно:
rm -f /path/to/db/files/*
slapadd -F /path/to/config/dir -n номер_базы -l my_db.ldif
chown -R openldap_user.openldap_group /path/to/db/files/

Примечание: под «номером базы» подразумевается то число, которое проставлено для этой базы в cn=config
То есть, например, для DN=olcDatabase={3}hdb,cn=config номер базы соответственно равен трём. Для самой cn=config номер всегда равен нулю (т.е. это всегда olcDatabase={0}config,cn=config)