Рейтинг
+2.26

LDAP

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

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

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

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

  • LDAP
Для запроса информации о действующей схеме LDAP-каталога прежде необходимо выполнить Операцию запроса возможностей, получив значение атрибута subschemaSubentry.
ldapsearch -x -H ldap://host:port -LLL -b "" '(objectClass=*)' subschemaSubentry

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

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

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

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

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

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

Например, при использовании LDAP-клиента из поставки OpenLDAP команда запроса возможностей может выглядеть как:
ldapsearch -x -H ldap://host:port -LLL -b "" '(objectClass=*)' suppotedControls supportedCapabilities

Apple Open Directory

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

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

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

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

Анонс LDAPCon 2009

  • LDAP
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-технологий.

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

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

  • 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) — позволяет для определённого отличительного имени сравнить выбранный атрибут с заданным значением

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

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

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

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

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

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

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

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

  • 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, захотите ли вы вкладывать дополнительные средства в его доработку силами штатных или наёмных программистов? Думаю, ответ очевиден…

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

  • LDAP
Overlay dynlist в OpenLDAP — это одна из (нескольких сотен) вещей, которые делают сомнительным преимущество Active Directory над OpenLDAP.
Как это работает: смотри www.openldap.org

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

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

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

HOWTO на означенную тему (аглицкая мова): www.whitemiceconsulting.com
Файл схемы dyngroup.ldif можно взять здесь: www.openldap.org
Особо пристальное внимание следует обратить на следующий момент (цитирую 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.

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

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

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

  • LDAP
Несовместим с динамическими конфигами в cn=config. В принципе это не особо страшно, поскольку держать отдельный инстанс slapd для скриптовой прослойки — дело техники, но следует отметить, что всё-таки лучше бы девелоперы реже добавляли новые фичи и зорче следили за тем, чтобы старые не пропадали втуне и не разваливались в буквальном смысле слова «от старости»

По мотивам списка рассылки 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.

Вышел OpenLDAP 2.4.17

  • LDAP
Как обычно, тихо и незаметно всем подписчикам списка рассылки openldap-announce свалилось на почту новое счастье — сообщение о выходе OpenLDAP версии 2.4.17!
Традиционно для «нечётной» версии разработчики в основном акцентировали своё внимание на исправлении ошибок и недоделок, найденных пользователями с момента релиза 2.4.16, но… есть-таки и новые приятные вещи:

— Теперь у нас будет замечательная утилита проверки корректности текущей схемы (разумеется, работает и с динамическим древом cn=config)
— У модуля, способного сделать из вашего LDAP-каталога подобие «Матрицы» (влияющего на все операции чтения/записи) — slapo-rwm, — теперь появилась опция rwm-drop-unrequested-attrs
— А поддержка мега-API SASL, о существовании которого OpenLDAP нам, кажется, уже никогда не даст забыть, расширилась и углубилась благодаря опции auxprop, отсеивающей ненужные SASL-плагины.

Уровни отладки сервера SLAPD (OpenLDAP)

  • LDAP
-1 any разрешить полное логгирование
0 ничего
1 (0x1 trace) трассировка вызовов функций (вывод на чётных уровнях отладки гораздо менее «замусорен»)
2 (0x2 packets) отладка обработки пакетов
4 (0x4 args) особо подробный trace вызова функций
8 (0x8 conns) обработка соединения
16 (0x10 BER) вывод дампа получаемых и отправляемых пакетов
32 (0x20 filter) обработка фильтров поиска
64 (0x40 config) обработка данных конфигурации
128 (0x80 ACL) показать как отрабатывают списки контроля доступа
256 (0x100 stats) итоговая статистика по соединениям/операциям/результатам
512 (0x200 stats2) итоговая статистика по количеству отправленных клиенту LDAP-записей
1024 (0x400 shell) показать информацию по взаимодействию с Shell-бэкендом
2048 (0x800 parse) показать процесс анализа записей
16384 (0x4000 sync) обработка взаимодействия с получателями реплики
32768 (0x8000 none) ничего
4294967295 журналировать всё

Следует отметить, что в современных версиях OL отладчик стал модульным, поэтому номера уровней отладки (а на самом деле битовые маски с одним установленным битом и прочими сброшенными) могут динамически добавляться/удаляться в следующих версиях OL и потенциально — менять свои номера. Поэтому во-первых лучше пользуйтесь следующим форматом:
slapd -d acl,filter,BER
А во-вторых — после установки нового SLAPD не забывайте перепроверять текущий state по уровням отладки:
slapd -d?

RFC 3687 - Unsupported

  • LDAP
OpenLDAP не поддерживает RFC 3687, так называемый Component Matching — анализ содержимого атрибута и синтаксическое деление его на логически целостные блоки с возможностью поиска соответствия не атрибуту целиком, а его компонентам.
Также данный RFC не поддерживается и большинством других серверов каталогов. Я пока не изучал этот вопрос только применительно к Active Directory (но учитывая общую склонность Microsoft перевирать стандарты или попросту игнорировать их, можно разве что надеяться на присутствие некоего аналога данного функционала под другим соусом).
Очень жаль, что будучи уже единожды реализованным в OpenLDAP ветки 2.3.х, RFC 3687 в современных реализациях LDAP-каталогов оказался не у дел. Реализация для OpenLDAP построена на базе ASN.1-компилятора SNACC и называется OpenLDAP-SNACC. OpenLDAP-SNACC написан совместно с программистами из IBM, этот код до сих пор присутсвует в дереве исходных кодов OL, но последнее изменение датируется 2006-ым годом. В настоящий момент по моим данным OL-SNACC компилируется совместно с последними версиями 2.3.хх и полностью несовместим с 2.4.хх. Очень жаль, но хотелось бы верить, что это не R.I.P Пока что девелоперы OpenLDAP ищут людей, готовых саппортить данный код, сами же за это взяться не имеют возможности.