• ↓
  • ↑
  • ⇑
 
02:25 

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

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

14:36 

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

Дописал версию 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, ну и многое-многое другое, что должно быть полезно хотя бы с точки зрения реализации заложенных в этом идей.

19:41 

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


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";'

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

14:50 

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

Как вам такое: 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-кода, дабы на фриланс.ру народ не скучал и свои индусы не сильно голодали?

19:48 

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

Положим, перед нами стоит задача "с нуля" настроить новый сервер каталогов, при этом использование безнадёжно устаревшего метода конфигурации, - редактирование 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 мы имеем готовую работоспособную конфигурацию, пусть и простейшую и теперь мы можем запустить сам сервер:



Итак, если вы точно следовали моим рекомендациям, уже сейчас у вас есть сервер 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'а таких схем маловато, пока что можно особо не заморачиваться взаимозависимостями и сделать это так, как делал я:



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

Что ж, теперь у нас есть базовый набор схем и можно приступать к настройке суффикса. Впрочем, постойте, а поверх чего этот суффикс будет работать? Ведь наверняка же поверх бэкендов BDB или HDB? А модули для этих бэкендов загружены или, возможно, вполне возможно, всё необходимое статически скомпилировано со slapd? Для того, чтобы узнать, был ли slapd собран полностью статично, попробуйте следующий запрос:



Если в ответ на этот запрос вы получите строку, содержащую 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

16:59 

Относительно вопроса о том, мигрировать или не мигрировать на систему хранения настроек 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 (да ведь по сути, так оно и есть).


19:12 

GUI для OpenLDAP

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

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

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

 

 

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


18:51 

Active Directory и "Операция запроса схемы"

Небольшое дополнение к предыдущему посту: если Операция запроса возможностей работает везде, в том числе и в Microsoft Active Directory, то вот Операцию запроса схемы Active Directory по умолчанию отвергает, требуя пройти полную аутентификацию (напомню, что вообще-то запрос схемы - это специальный тип операции поиска, для которого аутентификация не требуется). Почему - это вопрос сложный, вполне возможно, что где-то это настраивается. Но факт налицо: и здесь AD традиционно уже не следует стандартам.

21:19 

Операция запроса схемы

Для запроса информации о действующей схеме LDAP-каталога прежде необходимо выполнить Операцию запроса возможностей, получив значение атрибута subschemaSubentry.



Полученное значение используется в качестве Отличительного имени базы поиска (baseDN) в Операции запроса схемы, которую можно описать так:
BIND анонимный;
* База поиска baseDN равна значению атрибута subschemaSubentry, возвращаемого Операцией запроса возможностей;
* Глубина поиска scope указана как base;
* Фильтр поиска: (objectClass=*);
* Перечень запрашиваемых атрибутов: либо явное перечисление, либо "+" (ВНИМАНИЕ! "*" не покажет значения служебных атрибутов, содержащих всю полезную информацию);

Например, при использовании LDAP-клиента из поставки OpenLDAP Операция запроса схемы может выглядеть так:

ldapsearch -x -H ldap://host:port -LLL -b "cn=Subschema" '(objectClass=*)' ldapSyntaxes matchingRules

19:57 

Операция запроса возможностей

В стандарте LDAP определена специальная операция, позволяющая клиентам получать информацию о поддерживаемых сервером версиях протокола и возможностях LDAP-сервера. Эта команда является надстройкой (расширением) для операции search и выполняется при следующем сочетании параметров последней:

* BIND анонимный
* База поиска baseDN указана как "" (пустая строка)
* Глубина поиска scope указана как base
* Фильтр поиска: (objectClass=*)

Например, при использовании LDAP-клиента из поставки OpenLDAP команда запроса возможностей может выглядеть как:


12:26 

Apple Open Directory

Apple Open Directory - интересный сервер каталогов и LDAP API. Ещё один пример успешного коммерческого продвижения СК на базе кода OpenLDAP. Существенно дополнен AD-подобной Kerberos-аутентификацией "из коробки" (то есть включает в себя серверные компоненты KDC), отлично интегрирован в MAC OS X Server, через него проходит аутентификация пользователей, групп, здесь же хранится аналог hosts, сервисные ветки автомонтировщика и многих других служб, таких как: DNS-сервер, DHCP-сервер, Samba (обеспечивает возможность работы Mac OS в роли контролера домена PDC).

16:36 

Открылся форум сообщества LDAP-специалистов

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

Добро пожаловать!

15:28 

Анонс LDAPCon 2009

20 и 21-го сентября в рамках организованной LinuxFoundation конференции LinuxCon 2009 пройдёт форум LDAPCon 2009. Место проведения - отель "Portland Marriott Downtown Waterfront", город Портланд, штат Орегон, США.
2-я интернациональная Конференция по LDAP (LDAPCon 2009) - это технический форум для IT специалистов, интересующихся LDAP-технологиями и всем, что с ними связано: серверы каталогов, приложения для управления каталогами, управление аутентификацией и контролем доступа, мета-каталоги. 1-я интернациональная Конференция по LDAP прошла в 2007 году в Германии.

Основное внимание на LDAPCon 2009 будет уделено реализации и интеграции серверов LDAP и LDAP-совместимых (а также, разумеется, и LDAP-ориентированных) приложений. Данное мероприятие предоставляет отличную возможность встретиться поставщикам и разработчикам ПО, активным и будущим участникам LDAP-сообщества с целью обмена полезной информацией и накопленным опытом в области стратегий развёртывания и обслуживания каталогов, взаимодействия серверов и приложений, обсуждения возможностей применения LDAP в новых проектах, получения информации о самых современных тенденциях и разработках в области LDAP-технологий.

Официальный язык конференции - английский.


13:39 

Краткое функциональное описание протокола LDAP

(копия моего материала, опубликованного на Wikipedia)
В протоколе LDAP определены следующие операции для работы с Каталогом:
  • Операции подключения/отключения
  • Подключение (bind) - позволяет ассоциировать клиента с определённым объектом Каталога (фактическим или виртуальным) для осуществления контроля доступа для всех прочих операций чтения/записи. Для того, чтобы работать с Каталогом, клиент обязан пройти аутентификацию как объект, отличительное имя (Distinguished Name) находится в пространстве имён, описываемом Каталогом. В запросе операции bind клиент может не указывать отличительное имя, в таком случае будет осуществлено подключение под специальным псевдонимом anonymous (обычно это что-то наподобие гостевой учетной записи с минимальными правами)
  • Отключение (unbind) - позволяет клиенту в рамках сеанса соединения с LDAP-сервером переключиться на аутентификацию с новым отличительным именем. Команда unbind возможна только после аутентификации на сервере с использованием bind, в противном случае вызов unbind возвращает ошибку
  • Поиск (search) - чтение данных из Каталога. Операция сложная, на вход принимает множество параметров, среди которых основными являются:
  • База поиска (baseDN) - ветка DIT, от которой начинается поиск данных
  • Глубина поиска (scope) - может иметь значения (в порядке увеличения охватываемой области): base, one, sub
base - поиск непосредственно в узле - базе поиска
one - поиск по всем узлам, являющимся прямыми потомками базового в иерархии, т.е. лежащим на один уровень ниже него
sub - поиск по всей области, нижележащей относительно базы поиска (baseDN)
  • Фильтр поиска (searchFilter) - это выражение, определяющее критерии отбора объектов каталога, попадающих в область поиска, задаваемую параметром scope. Выражение фильтра поиска записывается в обратной (префиксной) польской нотации, состоящей из логических (булевых) операторов и операндов, в свою очередь являющихся внутренними операторами сопоставления значений атрибутов LDAP (в левой части) с выражениями (в правой части) с использованием знака равенства.
Логические операторы представлены стандартным "набором": & (логическое "И"b), | (логическое "ИЛИ"b) и ! (логическое "НЕ"b).
Пример фильтра поиска:

(&(!(entryDN:dnSubtreeMatch:=dc=Piter,dc=Russia,ou=Peoples,dc=example,dc=com))(objectClass=sambaSamAccount)
(|(sn=Lazar*)(uid=Nakhims*)))

  • Операции модификации - позволяют изменять данные в Каталоге, при этом в понятие модификации входит как добавление, удаление и перемещение записей целиком, так и редактирование записей на уровне их атрибутов. Подтипы модификации:
  • Добавление (add) - добавление новой записи
  • Удаление (delete) - удаление записи
  • Модификация RDN (modrdn) - перемещение/копирование записи
  • Модификация записи (modify) - позволяет редактировать запись на уровне её атрибутов,
  • добавляя новый атрибут или новое значение многозначного атрибута (add)
  • удаляя атрибут со всеми его значенями (delete)
  • и заменяя одно значение атрибута на другое (replace)
  • Операция сравнения (compare) - позволяет для определённого отличительного имени сравнить выбранный атрибут с заданным значением

04:28 

Что такое Корпоративный Каталог и для чего он нужен?

Корпоративный каталог — это перечень (реестр) всех объектов организации, для которых необходимо представление в её информационной модели.

Сотрудники, организационные структурные единицы, парк ЭВМ, предоставляемые сервисы — всё так или иначе может быть представлено в Каталоге. При этом топологически Каталог должен отражать структуру организации, но в общем случае возможно и обратное — структура организации прежде всего декларируется Каталогом, а затем утверждается документально.
Нужно отметить, что важным свойством Каталога, выгодно отличающим его от любых СУБД, является наглядность представления данных. Поясню на примере: допустим, вы просматриваете Каталог, используя любое доступное приложение — простой LDAP-клиент. Сначала вы видите узел самого верхнего уровня — вашу фирму, тип этого узла - «o», что, очевидно, означает «Organization». Раскрывая этот узел, вы находите основные структурные подразделения организации, обозначенные как ou=ИМЯ_ПОДРАЗДЕЛЕНИЯ (опять же, «ou» - это и есть «Organizational unit», т.е. «Отдел», «Структурное подразделение»): отделы и департаменты. В каждом департаменте есть свои сотрудники и свои материальные ресурсы, которые вы сможете просмотреть, раскрыв соответсвующий узел. Всё на своих местах, всё читабельно и доступно для понимания даже при использовании сторонней программы, которая на самом деле ничего о вашей фирме не знает - за удобное представление даных отвечает сам Каталог!
Поскольку формат хранения данных и способ доступа к Каталогу стандартизован (формат — LDIF, протокол - LDAP) — можно говорить о потенциальной совместимости такого способа агрегации данных со всеми используемыми в организации приложениями, то есть как об универсальном «скелете» IT-инфраструктуры, содержащем наиболее важную базовую информацию об имеющихся объектах.
Важно подчеркнуть свойство авторитетности Каталога как «станового хребта» IT-инфраструктуры, поскольку сведения, имеющиеся в нём, должны быть первичны по отношению ко всем прочим имеющимся источникам, в том числе и по отношению к любым классическим СУБД. Отсюда вытекают три основных требования к любому Каталогу:

1. Актуальность
2. Высокодоступность
3. Логическая целостность и непротиворечивость

Актуальность Каталога заключается в разумной минимизации времени на обновление и добавление данных.
Высокодоступность Каталога — определяется во-первых его распределённой архитектурой и во-вторых — использованием множества взаимозаменяемых копий одного и того же участка Каталога (репликации в режиме мультимастера).
Логическая целостность и непротиворечивость определяются строгим требованием хранения всех сведений об объекте в одной записи и отсутствием переопределения/дополнения свойств объекта в каких-либо иных записях. Это требование к Каталогу можно было бы также сформулировать как требование целостности («монолитности») его объектов.

13:26 

Рефералы - стоит ли слепо следовать стандартам?

При "склеивании" распределённого LDAP-каталога с помощью объектов класса referral, нужно обязательно помнить о том, что в базовом случае, без дополнительных настроек, вся логика обработки ссылки, указанной в атрибуте ref, реализуется на стороне клиента. Это вроде бы очевидно, и тем не менее обязательно нужно понимать концептуальные следствия такого подхода. А главным следствием здесь является то, что если LDAP-серверы ещё худо-бедно подчиняются стандартам (не будем смотреть на CommuniGate LDAP и подобные "имитации" с крайне узкой сферой применения), то LDAP-клиенты, в особенности встроенные-во-что-то-ещё, реализуют как правило лишь самые основные возможности протокола, к числу которых referral'ы по мнению многих нерадивых разработчиков не относятся. Также могут возникнуть проблемы с клииентами, которые понимают referral'ы, но в буквальном смысле слова теряют bindDN и userPassword и пытаются переходить на связанные рефералами уровни без credentials, то есть анонимно.
Таким образом, реализация распределённого каталога, опирающаяся исключительно на стандарты, закладывается на интеллектуальную логику клиента работы со ссылками, смещая акценты стандартизации в сторону приложений, где они, эти проблемы, по жизни как раз стоят наиболее остро. Это источник проблем несовместмости, решение которых по идее является одной из задач протокола.
Вывод: используйте нестандартные расширения на стороне сервера, наподобие overlay chain в OpenLDAP, которые делают работу с распред. каталогом полностью прозрачной для клиентских приложений - иначе вам придется насильно подгонять под стандарты ваши приложения, что в идеале правильно, но в реальности - занятие крайне неблагодарное.

18:33 

Интеграция Open-XChange 6 с внешним LDAP-каталогом

Предыдущая новость была приятной, а эта, пожалуй, станет горькой пилюлей:
Дело в том, что Open-XChange, перешагнув рубеж пятой версии, благополучно растерял всю свою LDAP-ориентированность. В шестой версии в качестве внутреннего хранилища учётных записей используется MySQL, а внешняя аутентификация стала похожа на лабораторную поделку студентов, написанную на коленке за одну пару по принципу "лишь бы сдать".
Чего стоит один только BIND по distinguishedName, формируемому не на основе результатов отбора по значениям атрибутов, а конкатенацие АТРИБУТ=ЛОГИН,baseDN Это значит, что по мнению разработчиков - ВНИМАНИЕ, - все пользователи должны находиться в одном контейнере baseDN на одном уровне. Супер, зачем тогда вообще нужен LDAP, если всё и вся свалено в одну кучу, а список пользователей представляет собой Золотое Руно, которое будучи развёрнутым, в любой крупной организации окажется длиннее тракта Москва-Петербург и предстанет пред очами какой-нибудь секретарши не раньше, чем её разъярнный босс успеет уйти домой, уволив предварительно весь IT-отдел. А ещё модуль LDAP-аутентификации разделяет логин на локальную часть (внутри контекста) и доменную часть (имя контекста), при этом собственно работать с контекстами он не умеет, потому что эта самая контекстная часть не может быть использована в определении baseDN (собственно, там вообще ничего использовано быть не может, поскольку baseDN - это просто статичный набор символов).
Мне удалось обойти эту проблему с использованием оверлея Rewrite из поставки OpenLDAP (вполне стандартным методом, описанным в официальной документации по slapo-rwm), НО, заметьте, такой метод решения - это хакерство, не воспроизводимое на большинстве других серверов каталогов.
Что же делать, что нам предлагают разработчики Open-XChange? А они нам предлагают ни много, ни мало - самим написать на Java соответствующий класс, реализующий модуль LDAP-аутентификации. Нужно отдать должное, для этого разработчики предоставляют исчерпывающую документацию и в целом всё довольно несложно для тех, кто что-то понимает в Java-коде... В чистом виде OpenSource, only code и ничего личного. И всё бы ничего, если бы не было адекватных альтернатив OX, отлично умеющих работать с LDAP и если бы, на минутку вспомним, девелоперы Open-XChange не зарабатывали денег на продаже коммерческой версии, в которой эта проблема также присутствует. Потратив немалые деньги на приобретение Open-XChange, захотите ли вы вкладывать дополнительные средства в его доработку силами штатных или наёмных программистов? Думаю, ответ очевиден...

17:34 

Динамические списки

Overlay dynlist в OpenLDAP - это одна из (нескольких сотен) вещей, которые делают сомнительным преимущество Active Directory над OpenLDAP.
Как это работает: смотри www.openldap.org/doc/admin24/overlays.html#Dyna...

Это работает? Да, я проверял!

Что это нам даёт?
- Группы формируются по независимым признакам, а это значит, что мы не обязаны явно указывать членам группы, что мы их хотели бы видеть ТАМ
- Да и в самой группе тем более никого прописывать не нужно - список участников формируется динамически
- Соответственно, для того, чтобы член группы перестал принадлежать группе, не требуется никаких телодвижений: достаточно, чтобы он перестал удовлетворять критериям отбора (поиска) членов группы или, например, попросту был удалён

К чему бы это прикрутить?
1) Плохая новость: это не прикрутишь по человечески к posixGroup'ам - и только лишь потому, что существует gidNumber и нам его нужно заполнить для первичной группы пользователя! Проще говоря, в аккаунте пользователя мы обязаны явно прописать его принадлежность группе, что уже отрицает все преимущества DynList'ов. Спасибо за это PADL.com'у...
Казалось бы, ведь логично предположить, что для юзеров внутри контейнера - группы - эта группа является первичной. Очевидно - но не для PADL.com, которые всё ещё заставляют нас скурпулёзно переписывать всякую архаичную ахинею из passwd в LDAP-каталог прямо-таки "AS IS"
2) Хорошая новость: подписчики mail-списков рассылки, участники проектов и назначенные на таски в многочисленных Collaboration Suite'ах, члены доменов и многие-мнгоие другие - добавятся в свои группы автоматически, достаточно лишь косвенным образом соответствовать критериям участия в событии/проекте/списке рассылки!

HOWTO на означенную тему (аглицкая мова): www.whitemiceconsulting.com/2010/02/configuring...
Файл схемы dyngroup.ldif можно взять здесь: www.openldap.org/devel/cvsweb.cgi/~checkout~/se...
Особо пристальное внимание следует обратить на следующий момент (цитирую OLAG):
So, if you are planning in using this for posixGroups, be sure to use RFC2307bis and some attribute which can hold distinguished names. The memberUid attribute used in the posixGroup object class can hold only names, not DNs, and is therefore not suitable for dynamic groups.

19:26 

Операция инкремента

Если вам нужно атомарно и просто быстро увеличить значение атрибута какой-либо записи в LDAP, достаточно всего одной простой операции, описанной в RFC 4525 (Modify-Increment Extension):


dn: DN
changeType: modify
increment: ATTR2INCREMENT
ATTR2INCREMENT: VALUE

16:32 

Shell-бэкенд для OpenLDAP

Несовместим с динамическими конфигами в cn=config. В принципе это не особо страшно, поскольку держать отдельный инстанс slapd для скриптовой прослойки - дело техники, но следует отметить, что всё-таки лучше бы девелоперы реже добавляли новые фичи и зорче следили за тем, чтобы старые не пропадали втуне и не разваливались в буквальном смысле слова "от старости" (см. www.diary.ru/~ldap/p75445198.htm )

По мотивам списка рассылки openldap-software:

From: h.b.furuseth@usit.uio.no

Konovalov Andrey writes:
> > Is the Shell backend compatible with the cn=config method of
> > configuration data storage?

Nope. Try back-sock instead.

LDAP - заметки на полях

главная