Что такое код ldap_list

Содержание

Создание запросов LDAP с помощью Диспетчера Каталога [web-консоль]

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

Вы можете запрашивать устройства на основании указанных атрибутов, таких как тип процессора или операционная система. Вы также можете делать запросы на основании специфических выборочных атрибутов, например, идентификатора работника или подразделения.

Добавление каталога LDAP

Для управления каталогом LDAP вам необходимо добавить его в список Диспетчера Каталога. Для этого нужно знать местоположение каталога в сети и набор учетных данных для доступа к каталогу.

Для добавления каталога LDAP в Диспетчер Каталога:
  1. На панели инструментов web-консоли щелкните Распространение > Диспетчер каталога (Distribution > Directory manager).
  2. На панели инструментов нажмите кнопку Новый каталог (New directory).
  3. Введите URL-адрес для открытия каталога. В URL-адресе нет необходимости вводить префикс «LDAP://».
  4. Введите имя пользователя и пароль для доступа к каталогу.
  5. Нажмите OK.

Каталог отобразится на панели инструментов Диспетчера Каталога со значком дерева. Также можно выбрать его и нажать кнопку Правка (Edit) на панели инструментов для отображения его свойств.

Просмотр каталогов LDAP

После добавления хотя бы одного каталога вы можете просматривать элементы в каталоге в виде дерева Диспетчера Каталога, в котором отображаются все зарегистрированные каталоги и пользователи.

На панели действий находятся две вкладки – Целевой список LDAP (LDAP target list) и Запросы LDAP (LDAP queries). Щелкните их для отображения объектов LDAP, которые выбраны в качестве целей, и созданных запросов LDAP.

Выбор целевых объектов LDAP

Вы можете выбирать объекты в дереве Диспетчера Каталога и назначать их в качестве целей. Устройства, содержащиеся в этих объектах LDAP, могут быть выбраны в качестве целей для применения к ним действия, например, распространения программного обеспечения или сканирования исправлений и проверки соответствия.

Для выбора объектов LDAP в качестве целей:
  1. На панели инструментов web-консоли щелкните Распространение > Диспетчер каталога (Distribution > Directory manager).
  2. В дереве Диспетчер Каталога (Directory manager) выберите объект в каталоге LDAP.
  3. Выберите один или несколько элементов в списке Ресурсы каталога (Directory resources) на нажмите кнопку Цели LDAP (LDAP targets) на панели инструментов.
  4. Выберите средство, которое нужно применить к целевым устройствам. Выбранные целевые элементы отображаются в списке Список целей (Target list) для данного средства.

Создание запросов каталога LDAP

Можно создать запрос, который возвращает результаты для объекта каталога, такие как корень организации (o), доменный компонент (dc) или организационная единица (ou).

Для создание запроса LDAP:
  1. На панели инструментов web-консоли щелкните Распространение > Диспетчер каталога (Distribution > Directory manager).
  2. В дереве Диспетчер Каталога (Directory manager) выберите объект в каталоге LDAP. Запрос, который вы создадите, возвратит результаты поиска из этой точки далее вниз в дереве каталога.
  3. На панели инструментов нажмите кнопку Создать запрос LDAP (New query LDAP).
  4. Введите описательное имя для запроса.
  5. Выберите атрибут LDAP, который станет критерием для запроса.
  6. Щелкните для запроса оператор сравнения (=, =) и значение для атрибута. Если будет выбрано Содержит (Contains) или Существует (Exists), указывать значение не требуется.
  7. Если запрос сложный, выберите логические операторы AND или OR для объединения команд.
  8. Щелкните Вставка (Insert) для добавления команды.
  9. Создайте дополнительные команды, повторив действия 5-8.
  10. Для отмены команды выберите ее и щелкните NOT. Для удаления команды выберите ее и нажмите Удалить (Delete).
  11. После завершения создания запроса щелкните Тест (Test) для проверки результатов запроса.
  12. Если нужно изменить запрос и использовать для этого синтаксис LDAP, щелкните Дополнительно (Advanced). Запрос будет открыт в окне редактирования, где вы можете использовать любые варианты синтаксиса.
  13. После завершения нажмите Сохранить (Save). Сохраненный запрос появится на вкладке Запросы LDAP (LDAP queries) на панели действий Диспетчера Каталога.

Диалог расширенного запроса LDAP

В диалоге «Основной запрос LDAP» щелкните Дополнительно (Advanced), чтобы открыть диалоговое окно «Расширенный запрос LDAP» (Advanced LDAP query). Диалог «Расширенный запрос LDAP» (Advanced LDAP query) также открывается при изменении уже созданного запроса.

  • Имя (Name): Имя запроса LDAP. Изменение имени для создания копии существующего запроса.
  • Корень запроса LDAP (LDAP query root): Отображение корневого объекта в каталоге для данного запроса. Запрос, который вы создадите, возвратит результаты поиска из этой точки далее вниз в дереве каталога.
  • Запрос LDAP (LDAP query): Создание запроса LDAP в произвольной манере.
  • Тест (Test): Проверка созданного запроса.

Информация о протоколе LDAP (Lightweight Directory Access Protocol)

Протокол LDAP (Lightweight Directory Access Protocol) – это стандартный отраслевой протокол для доступа и просмотра информации о пользователях и устройствах. LDAP позволяет организовывать и хранить информацию в виде каталога. Каталог LDAP является динамическим и может обновляться по необходимости, а также является распределенным и защищенным от ошибок в какой-либо его точке.

В следующих примерах отображены запросы LDAP, которые могут быть использованы для поиска в каталоге:

  • Найти все записи: (object : (cn>=’bob’)
  • Найти всех пользователей с атрибутом электронной почты: (&(object : (&(object >Процесс определения формата фильтра поиска (от RFC 1960):

Если должно содержать один из символов * или ( или ), перед ним нужно указать символ косой черты (\) для отмены его обработки.

Аутентификация LDAP — настройки

Страница Аутентификация LDAP служит для настройки сервера LDAP с целью аутентификации пользователей устройств (многофункциональное периферийное устройство, цифровой копир или устройство цифровой отправки). Если аутентификация LDAP выбрана в качестве Способа регистрации для одного или нескольких Функций устройств на странице Диспетчер аутентификации, пользователь должен ввести действительные имя пользователя и пароль для получения доступа к этим функциям.

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

На странице Аутентификация LDAP можно задать параметры доступа к серверу LDAP и поиска информации пользователя. Обратите внимание, что данную страницу можно использовать только в том случае, если LDAP выбран в качестве Способа регистрации на странице Диспетчер аутентификации.

Подключение к серверу LDAP

Способ привязки сервера LDAP

Параметр Способ привязки сервера LDAP определяет, как устройство будет осуществлять подключение к серверу LDAP. Обратитесь к администратору сервера LDAP, чтобы определить наиболее оптимальный для вас способ.

  • Простой — Выбранный сервер LDAP не поддерживает шифрование. Обратите внимание, что пароль (если он существует) будет отправлен по сети в открытом виде.
  • Простой через SSL — Выбранный сервер LDAP поддерживает шифрование с помощью протокола SSL. Все данные, в том числе имя пользователя и пароль, будут шифроваться. Сервер LDAP должен быть настроен для поддержки SSL, включая настройку сертификата для его идентификации. Кроме того, сетевой интерфейс устройства должен быть настроен с использованием сертификата Центра сертификации (CA) для проверки сервера LDAP. Сертификат CA настраивается на вкладке Сеть Web-интерфейса. В некоторых конфигурациях серверов LDAP необходимо также создавать сертификат клиента, который настраивается на этой же вкладке Сеть.

Сервер LDAP

Параметр Сервер LDAP представляет собой имя хоста или IP-адрес сервера LDAP, которое будет использоваться для аутентификации пользователей устройства. В случае использования SSL введенное здесь имя или адрес должны соответствовать имени в сертификате, направляемом сервером.

В этом поле можно указать несколько серверов, разделяя их адреса знаком вертикальной полосы (‘|’, ASCII 0x7c). Эту функцию можно, например, использовать для указания основного и резервного серверов. Сетевой интерфейс поддерживает поддерживает только один сертификат CA, поэтому все серверы LDAP в этом списке должны использовать один сертификат CA.

Параметр Порт определяет номер порта TCP/IP, на котором сервер обрабатывает запросы LDAP. Обычно это порт 389 для Простой привязки или 636 для привязок Простой через SSL.

Имя пользователя и пароль для поиска

В аутентификации LDAP используется два способа аутентификации пользователя.

Первый способ называется Имя и пароль пользователя устройства ; он предполагает “конструирование” DN (отличительного имени) пользователя для аутентификации (“привязки”) в каталоге LDAP. В начало информации, вводимой пользователем на панели управления, добавляется Префикс DN , и данная строка добавляется к строке Привязка и начало поиска . Например префикс DN “CN” в сочетании с введенной пользователем строкой john.doe@nasa.gov и строкой привязки и начала поиска OU=Engineering,DC=NASA,DC=GOV определит DN пользователя: CN=john.doe@nasa.gov,OU=Engineering,DC=NASA,DC=GOV

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

Способ Имя и пароль пользователя устройства следует использовать, когда все пользователи находятся в одном контейнере каталога LDAP, а первым следует слагаемое DN, которое пользователь обычно использует для аутентификации. Обратите внимание, что допускается ввод нескольких строк привязки и начала поиска при условии разделения их знаком “|”, и устройство предпримет попытки поочередно аутентифицировать пользователя по каждому из значений привязки и начала поиска. Данный способ может быть применен, если пользователи находятся в нескольких контейнерах каталога LDAP.

Способ Использование имени пользователя и пароля администратора следует применять в том случае, если пользователи находятся в нескольких контейнерах, либо если первое слагаемое DN обычно неизвестно некоторым пользователям или не используется для аутентификации в других системах. При использовании этого способа пользователю может быть предложено ввести уникальный атрибут LDAP, такой как SAMAccountName или даже номер телефона пользователя — атрибут TelephoneNumber.

Имя и пароль пользователя устройства

В этом способе используется префикс привязки — строка, которую пользователь вводит на панели управления устройства, а также строка Привязка и начало поиска для воссоздания DN пользователя. Воссозданный DN используется для аутентификации пользователя.

Префикс привязки

Параметр Префикс привязки — это атрибут LDAP, используемый для построения DN пользователя для целей аутентификации. Этот префикс комбинируется с именем пользователя, введенным на панели управления, образуя относительное отличительное имя (RDN). Обычно используется префикс «CN» (для общего имени) или «UID» (для идентификатора пользователя).

Использование имени пользователя и пароля администратора

Это DN (отличительное имя) пользователя, имеющего права чтения каталога LDAP. Введенная здесь учетная запись может не иметь административного доступа к каталогу. Прав чтения достаточно.

Пароль пользователя, чей DN введен в поле «DN администратора».

Поиск по базе данных LDAP

Привязка и начало поиска

При выборе способа Имя и пароль пользователя устройства значение Привязка и начало поиска используется на обоих этапах аутентификации. На этапе проверки имени пользователя и пароля это значение комбинируется с RDN для воссоздания полного отличительного имени пользователя (DN). На этапе поиска информации пользователя это значение является DN записи LDAP, с которой начинается поиск.

При выборе способа Использование имени пользователя и пароля администратора строка Привязка и начало поиска используется только как начало поиска. Начало поиска в базе каталога LDAP может быть задано, и устройство выполнит поиск по всему дереву LDAP объекта пользователя, соответствующего введенному имени пользователя.

Строка состоит из пар «атрибут=значение», разделенных запятыми. Например:

При выборе способа «Имя и пароль пользователя устройства» в это поле можно ввести несколько несколько строк привязки, разделенных знаком вертикальной черты (‘|’, ASCII 0x7c). Это можно использовать, например, для указания альтернативных доменов LDAP. Устройство предпримет попытку привязать сервер LDAP, используя поочередно все строки в заданном порядке. После успешного выполнения привязки тот же корневой объект используется для поиска информации пользователя устройства.

Атрибут LDAP, соответствующий имени пользователя

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

Получение

адреса электронной почты, используя атрибут

После того, как пользователь устройства найден в базе данных LDAP, его электронный адрес находят в базе данных с помощью атрибута LDAP, указанного в поле адрес электронной почты, используя атрибут.

и имя, используя атрибут

Экранное имя пользователя получают из атрибута LDAP, указанного в поле имя, используя атрибут.

Тестирование

Функция Тестирование используется для проверки правильности параметров перед их применением. При нажатии этой кнопки вам будет предложено ввести имя пользователя и пароль, как если бы вы регистрировались на панели управления устройства. Если введенные регистрационные данные прошли аутентификацию и информация пользователя найдена в базе данных LDAP, появляется сообщение об успешном выполнении проверки. В противном случае появится сообщение об ошибке с указанием на отрицательный результат аутентификации.

АйТи бубен

Инструменты пользователя

Инструменты сайта

Содержание

LDAP (Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — это сетевой протокол для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP.

LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP- сервер принимает входящие соединения на порт 389 по протоколам Порты TCP или UDP. Для LDAP- сеансов, инкапсулированных в SSL сертификаты для для сайта, почты, обычно используется порт 636. Служба директорий LDAP основана на клиент-серверной модели. Один или несколько серверов LDAP содержат данные, которые создают directory information tree (DIT). Клиент соединяется с сервером и спрашивает его. Сервер дает клиенту ответ и/или указание, где получить дополнительную информацию(обычно, другой LDAP сервер).

Реализации LDAP

LDAP является широко используемым стандартом доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее известен сервер OpenLDAP, из проприетарных — поддержка протокола имеется в Active Directory — службе каталогов от компании Microsoft, предназначенной для централизации управления сетями Windows настройка, ускорение, частые вопросы. Другие реализации служб каталогов, поддерживающие LDAP как протокол доступа: Red Hat Directory Server, Mandriva Directory Server, Novell eDirectory, OpenDS.

OpenLDAP Software — открытая реализация LDAP, разработанная проектом OpenLDAP Project. Распространяется под собственной лицензией, называемой OpenLDAP Public License. LDAP — платформенно-независимый протокол. В числе прочих есть реализации для различных модификаций BSD, а также GNU/Linux, AIX, HP-UX, Mac OS X, Solaris, Microsoft Windows (2000, XP) и z/OS .

Часть 1. Обзор LDAP

Серия контента:

Этот контент является частью # из серии # статей: Работа с данными Active Directory c помощью сценариев

Этот контент является частью серии: Работа с данными Active Directory c помощью сценариев

Следите за выходом новых статей этой серии.

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

В приведенных ниже примерах используется имя домена – shelton.int, короткое имя — CATS.

Часто используемые сокращения:

  • AD – Active Directory (служба каталогов);
  • LDAP – Lightweight Directory Access Protocol (облегченный протокол доступа к каталогам);
  • DN – Distinguished Name (уникальное имя).

Подключение к службе Active Directory и просмотр объектов

Если рассматривать любой контроллер домена Windows как LDAP-сервер, то становится очевидным, что с ним можно работать стандартными средствами, предназначенными для чтения и записи данных в LDAP. Так, на нем можно обнаружить список открытых портов, похожий на приведенный в листинге 1 (из списка удалены порты, не относящиеся к LDAP):

Листинг 1. Список открытых портов типичного контроллера домена Windows

Как видно из листинга 1, контроллер домена предоставляет все необходимые сервисы: ldap на порту 389, ldap over ssl на порту 636 и т.д. В данном случае компания Microsoft не стала разрабатывать собственное решение, а воспользовалась хорошо известной и документированной службой LDAP. Правда, сама схема LDAP от Microsoft значительно отличается от существующих аналогов, так в листинге 2 приведено описание стандартного объекта «пользователь» (некоторые поля были опущены), полученное с помощью утилиты ldapsearch.

Листинг 2. Поля стандартного объекта AD «пользователь», создаваемые по умолчанию.

Для просмотра и редактирования объектов, загруженных из LDAP, существуют различные программы, например, GUI-приложение ldapbrowser, написанное на Java, или ldapsearch — программа, работающая из командной строки.

Программа ldapsearch — это важный инструмент администратора LDAP-сервера, примерно как ping и traceroute для системного администратора. Она позволяет загружать и использовать практически любые данные, существующие в LDAP. Некоторая проблема может возникнуть из-за того, что в этой программе используется собственный язык запросов. Он построен в соответствии с принципом «обратной польской записи», как в старинных программируемых калькуляторах, когда сначала задается знак операции, а потом перечисляются операнды. Все операнды разделяются отдельными скобками, из-за чего выражения становятся очень громоздкими. Поскольку это язык запросов, то в нем присутствуют только логические операции — И (&), ИЛИ (|), НЕ (!). Рассмотрим несколько примеров с использованием данного языка запросов.

  • ( description=* ) — любой объект, у которого определено поле description. При этом совершенно неважно какой будет длина этого поля, так, один символ точно так же попадет под фильтр » * «, как и длинная строка.
  • ( &(object >) — любой объект, у которого поле objectClass равно user И определено поле mail .
  • В листинге 3 приведен огромный запрос, используемый для загрузки глобальной адресной книги из LDAP (все содержимое запроса — это одна строка).
Листинг 3. Пример запроса к LDAP-серверу

Это запрос можно упросить, если воспользоваться знанием структуры каталога AD:

В значениях sAMAccountType нет ничего секретного — это просто 0x30000000 и 0x10000000 в десятичной форме, обозначающие соответственно тип объекта «пользователь» или «контакт». Ссылку на подробное описание языка запросов можно найти в разделе «Ресурсы».

После изучения языка запросов остается решить вопрос — как подключиться к LDAP из командной строки? При этом необходимо учитывать несколько моментов.

  1. В Windows Server отсутствует так называемый anonymous bind (возможность подключения к LDAP без указания имени пользователя и пароля). Эту возможность можно активировать при наличии необходимых полномочий, но по умолчанию она отключена. Поэтому перед тем, как начать работать с LDAP через ldapsearch или создавать сценарии, необходимо получить отдельную учетную запись и установить достаточно простой пароль. Я обычно использую пароль » qwerty <123>«, так как Windows 2003 Server считает его достаточно сложным, и имя пользователя ldapread . Для ldapsearch (и далее повсюду) в качестве значения параметра bind dn указывается строка @ , где домен — это имя AD, переведенное в верхний регистр, например ldapread@SHELTON.INT .
  2. Что указывать в качестве исходной точки для подключения ( base dn )? Обычно base dn формируется следующим образом: если AD называется shelton.int , то соответствующим значением base dn будет dc=shelton,dc=int . Если же оно называется kitten.cats.shelton.int (такие длинные имена возможны в больших инсталляциях), то соответствующим значением base dn будет dc=kitten,dc=cats,dc=shelton,dc=int . Разумеется, при подключении можно указать не корень AD, а какую-либо его ветку, например, CN=Computers,DC=shelton,DC=int , но в таком случае поиск никогда не поднимется выше ее границы. Проблема состоит в том, что логически правильным является создание организационных единиц ( ou — Organizational Unit), соответствующих разным филиалам, непосредственно в корне AD, поскольку эти ou будут содержать объекты разных типов — пользователей, компьютеры, группы и т.д. Поэтому для просмотра всей структуры AD лучше указывать корневой элемент.
  3. Как в AD хранится не-ASCII информация, т.е. данные на национальных (и на русском, в том числе) языках? Подобная информация хранится в виде текста в кодировке UTF-8, преобразованного с помощью Base64 в набор символов ASCII (см. соответствующую ссылку в разделе «Ресурсы»).
  4. Сразу же после установки OpenLDAP необходимо внести в файл /usr/local/etc/openldap/ldap.conf (который может храниться и в другом месте) строку » REFERRALS off «. Это необходимо сделать для всех версий AD, начиная с Windows 2003 Server.

После подготовки можно переходить к практическому использованию ldapsearch.

Листинг 4. Пример использования ldapsearch

Использованные ключи имеют следующее значение:

  • -D задает значение bind dn ;
  • -w — пароль для подключения;
  • -LLL обеспечивает максимальное упрощение выводимой информации;
  • -h — адрес сервера;
  • -b задает значение base dn ;
  • -P — версия протокола LDAP;
  • -a описан в man ldapsearch.

Далее приводится простой фильтр отбора записей и перечень атрибутов, которые нужно вывести. Если ничего не указывать, то будут выведены все атрибуты. В данном случае мы запросили атрибуты distinguishedName и sAMAccountType . Обратите внимание, что атрибуты, которые необходимо вывести, перечисляются через пробел, а не через запятые. Теперь можно попробовать добавить в информацию о пользователе (средствами Microsoft) поле title , равное » Читатель » и запросить его через ldapsearch.

Листинг 5. Пример использования ldapsearch

Заключение

В статье был представлен краткий обзор протокола LDAP и утилиты ldapsearch, использующейся для выполнения запросов к LDAP-серверам. В следующей статье мы рассмотрим использование ldapsearch из сценариев Bourne Shell.

I have a search query in LDAP like this. What exactly does this query mean?

2 Answers 2

  • CN = Common Name
  • OU = Organizational Unit
  • DC = Domain Component

These are all parts of the X.500 Directory Specification, which defines nodes in a LDAP directory.

You can also read up on LDAP data Interchange Format ( LDIF ), which is an alternate format.

You read it from right to left, the right-most component is the root of the tree, and the left most component is the node (or leaf) you want to reach.

Each = pair is a search criteria.

With your example query

In effect the query is:

From the com Domain Component, find the google Domain Component, and then inside it the gl Domain Component and then inside it the gp Domain Component.

In the gp Domain Component, find the Organizational Unit called Distribution Groups and then find the the object that has a common name of Dev-India .

What are CN, OU, DC?

What does the string from that query mean?

The string ( «CN=Dev-India,OU=Distribution Groups,DC=gp,DC=gl,DC=google,DC=com» ) is a path from an hierarchical structure (DIT = Directory Information Tree) and should be read from right (root) to left (leaf).

It is a DN (Distinguished Name) (a series of comma-separated key/value pairs used to identify entries uniquely in the directory hierarchy). The DN is actually the entry’s fully qualified name.

Here you can see an example where I added some more possible entries.
The actual path is represented using green.

The following paths represent DNs (and their value depends on what you want to get after the query is run):

  • «DC=gp,DC=gl,DC=google,DC=com»
  • «OU=Distribution Groups,DC=gp,DC=gl,DC=google,DC=com»
  • «OU=People,DC=gp,DC=gl,DC=google,DC=com»
  • «OU=Groups,DC=gp,DC=gl,DC=google,DC=com»
  • «CN=QA-USA,OU=Distribution Groups,DC=gp,DC=gl,DC=google,DC=com»
  • «CN=Dev-India,OU=Distribution Groups,DC=gp,DC=gl,DC=google,DC=com»
  • «CN=Ted Owen,OU=People,DC=gp,DC=gl,DC=google,DC=com»

Предыстория.

Сразу оговорюсь, что я простой админ локал-хоста и в таких энтерпрайзных вещах, как сервера директорий ничего не понимал до сегодняшнего дня, так что статья из разряда «чайникам от чайника» — что и как понял, то и рассказываю. Энтерпрайзных задач тоже не стояло — пока просто сделать централизованную авторизацию сервисов, без всяких там ACL и прочих заморочек.
Конфигурированию OpenLDAP и прикручиванию к нему различных сервисов посвящено множество статей. Проблема в том, что большинство из них основной упор делают на то, что нужно сделать, некоторые уделяют внимание тому зачем это надо делать, но практически никто не говорит о том, почему надо делать именно так и как можно по-другому. Ну, по крайней мере, мне не удалось найти таких статей. В свете этого, я попробую пойти с обратной стороны — не буду много писать о том, что делать, а сконцентрируюсь на вопросах почему именно так делают.
Процесс настройки я разбил на три этапа — запуск OpenLDAP в базовой конфигурации с парой тестовых пользователей, организация ауторизации с авторегистрацией пользователей redmine из LDAP и доступ на чтение/запись в SVN. Излагать буду в том же порядке.

Итак, лдап — это сервис директорий. Директории — это дерево. Узлы дерева могут хранить произвольную информацию (текстовую). Информация эта представляется в виде пар ключ-значения, которые называются атрибутами. Админ волен строить дерево совершенно произвольным образом, исходя из своих потребностей. С другой стороны, если позволить в каждый узел пихать что угодно будет хаос. По-этому существуют схемы и классы. Классы описывают какие атрибуты может иметь объект и какие обязан, при этом объект может принадлежать к множеству классов, таким образом можно набирать нужный список атрибутов. Ну а схемы — это описания возможных атрибутов и классов. Существует несколько готовых схем, определённых в RFC или специфичных для конкретного LDAP-сервера.
Вот в общих чертах теория. Для практики я по-быстрому поднял FreeBSD 9.1 в виртуалбоке и поставил туда OpenLDAP. Почему именно его? В принципе, серверов, реализующих LDAP несколько, можно взять любой другой, просто этот наиболее распространённый.
Конфиг сервера хранится в файле slapd.conf, откуда инклудятся файлы схем. Помимо настроек, относящихся к серверу там находятся ACL, суффикс верхнего уровня и пароль рута в зашифрованном виде. Само дерево хранится в базе данных (по умолчанию предлагается BerkeleyDB, но можно использовать и другие бекенды). Физическое расположение базы зависит от бекенда, для bdb, например, задаётся опцией directory (что бы полностью очистить базу можно тупо удалить все файлы из этой директории).
Принцип именования узлов в чём-то близок к формированию имён в DNS, возможно по-этому суффикс принято делать из двух частей:
«dc=example,dc=org»
В принципе, здесь можно писать что угодно, хоть dc=vasia,dc=pupkin — никакой связи с именами DNS тут нет (хотя некоторые клиентские софтины и могут попытаться такую связь установить). Магическое dc — это сокращение от domain component.
Рутовый пользователь домена задаётся строчкой «cn= ,dc=example,dc=org» (cn — common name, имя объекта).

Как работать в базой данных? Так как оно не plain text, то в ручную править записи не получится. Нужно либо писать инструкции, что сделать, в файле ldif и применить эти инструкции командой ldapadd, либо пользоваться спецсофтом, типа ldapadmin, или ldapphpadmin. Для начала проще воспользоваться ldif’ами, а потом перейти на гуйню. Кстати, для работы из консоли есть забавные утилиты ldapvi (использует EDITOR для редактирования дерева) и shelldap (клиент в стиле шела).

Как я уже сказал, дерево можно стоить как угодно. Я решил пока создать две директории в корне — одну для юзеров и одну для групп. Скелет у меня получился такой

Здесь создаётся 4 объекта — корневая директория (не путать с rootdn который мы прописали в конфиге), две поддиректории и одна группа. DN — это имя директории (всегда пишется полностью). Самое интересное тут, конечно, это objectClass, а точнее, почему они именно такие. Зачем нужен top, честно сказать, сам толком не понял — некий абстрактный класс без атрибутов. А вот остальных могу попробовать объяснить. Дело в том, что в данном случае мы описываем некую компанию, в которой есть люди, разделённые на отделы (группы). Класс organization как раз и предназначен для описания всяких организаций. В принципе здесь спокойно можно этот класс и не вешать. Кроме того наш example по совместительству кусок доменного имени, а значит ему нужен атрибут dc для получения которого вешаем dcObject. Группы имеют тип organizationalUnit — это не совсем логично, но такова общепринятая практика. На самом деле, здесь подошёл бы любой класс, содержащий свойство ou. Ну или любой другой, просто название свойства было бы другим, что мало на что влияет. Последний абзац описывает группу разработчиков, в которую я буду добавлять тех, кто имеет доступ к SVN.
Ну и самое интересное — собственно учётные записи пользователей:

На самом деле классов тут сильно с избытком, для простой авторизации вполне достаточно было бы, например, shadowAccount, или даже person — главное, что бы было поле userPassword. Для хранения логина в никсовых соглашениях принято использовать поле uid, альтернативно в самбовой схеме для логина используют sAMAccountName.
Кроме обычных пользователей желательно держать специального служебного объекта, который имеет право на чтение информации о пользователях (кроме пароля). Я его создал таким образом:

Redmine

Ну тут всё просто. Инструкция по настройке есть в wiki редмайна, единственное, что она заточена под виндовую схему авторизации. Как дружить с более привычной схемой можно посмотреть в форуме. Ниже приведу скрин своей конфигурации.

В ЛДАПе редмайн проводит авторизацию, но пользователь всё равно должен храниться в базе редмайна. Для того, что бы не заботиться о создании пользователей, предусмотрена галка авторегистрации (а что бы не заботиться об удалении есть плугин redmine_ldap_sync)
Можно заметить, что редмайн умеет брать из лдапа не только логин/пароль, но ещё и имя, фамилию и почту, которые потом использует для регистрации пользователя в своей базе. Именно для этого, кстати, понадобилось добавить класс inetOrgPerson.

Прикручивание SVN оказалось чуть менее тривиальной задачей, но в целом идея такая: заводим апач (обычно виртуал хост или локейшен), цепляем к нему svn по вебдав и ограничиваем доступ аутентификацией по LDAP. В принципе, можно обойтись без апача — сам svn тоже умеет авторизацию в лдапе, но настраивается чуть хуже.
Вот такой конфиг у меня получился:

Каталоги LDAP и их применение

Несколько лет назад у большинства отделов ИТ отсутствовал определенный взгляд на каталоги LDAP. С тех пор технология LDAP привлекла к себе должное внимание, но возникла она в ландшафте информационных инфраструктур как будто случайно.

Для некоторых специалистов первая встреча с LDAP состоялась при переходе с доменов Windows NT на домены Active Directory или при работе с Novell NDS/eDirectory. В других случаях поддержка LDAP была вторичной по отношению к основной функциональности. Так, у многих знакомство с LDAP произошло при настройке почтовых серверов Exchange 5.5 или Netscape Messaging, создании сайтов Web с требованиями аутентификации, в процессе работы с Web Proxy и т. д. В результате каталоги LDAP стали восприниматься как сугубо утилитарный инструмент для решения той или иной конкретной задачи. Цель настоящей статьи — дать читателям более широкое представление о возможностях применения этой технологии и о внутренней структуре каталогов LDAP.

КАТАЛОГИ LDAP

Каталогом LDAP называют любое хранилище данных с поддержкой протокола LDAP. Наиболее распространенные на сегодняшний день каталоги — Microsoft Active Directory, Sun ONE Directory Server (и более ранние версии того же продукта под марками Netscape и iPlanet) и Novell eDirectory (ранее известный как Novell NDS).

В более общем значении под каталогом (directory) обычно подразумевают хранилище относительно статичных данных, т. е. тех, которые считываются во много раз чаще, нежели изменяются. Основные типы данных, хранящиеся в каталогах LDAP, как раз удовлетворяют условию относительной статичности. К их числу принадлежат:

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

Заметим, что в компьютерном мире уже существует одна масштабная система, являющаяся, по сути, каталогом — это система серверов DNS. Имеющаяся специализированная технология DNS отлично себя зарекомендовала и не требует улучшений (хотя Microsoft и приняла решение реализовать DNS в Windows 2000 Server на основе Active Directory, т. е. по сути на основе технологии LDAP).

ПРИМЕНЕНИЕ КАТАЛОГОВ LDAP

По способу применения большинство каталогов LDAP можно разделить на несколько основных групп.

Каталоги сетевой операционной системы (Network Operating System, NOS). В настоящий момент наиболее часто встречающийся пример такого использования — построение корпоративной сети под управлением Windows на основе Microsoft Active Directory или Novell eDirectory.

Каталоги NOS содержат информацию обо всех объектах в сети: данные о пользователях, группах пользователей, рабочих станциях, серверах, принтерах и т. д. Внедрение такого каталога обеспечивает централизованное администрирование сети и управление аутентификацией и авторизацией при обращении к сетевым ресурсам. Это позволяет отказаться от дублирования учетной информации в разных точках ее использования. (Надо отметить, что функциональность Active Directory и eDirectory неравнозначна — естественным образом Active Directory лучше интегрирована с ОС Windows NT и 2000. Оба решения имеют как сильные, так и слабые стороны, а потому перед принятием решения необходимо тщательно взвесить целый набор факторов.)

Похожим способом может быть устроена аутентификация пользователей в сетях под управлением различных вариантов UNIX; в данном случае используются модуль PAM и любой каталог LDAP.

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

Характерным примером подобного подхода является линейка продуктов Sun ONE, включающая в себя, помимо прочего, сервер электронной почты, Web Proxy, календарный сервер, сервер Web. Эти продукты изначально рассчитаны на работу с Sun ONE Directory Server, причем все приложения могут хранить данные о пользователях в одном и том же сервере каталогов. Аналогично, почтовый сервер Exchange 2000 опирается на Active Directory как на хранилище данных о своих пользователях.

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

Каталоги в качестве адресных книг организаций. В каталоге может располагаться справочная информация о сотрудниках — адрес электронной почты, номер телефона, комнаты, название должности и т. п. В качестве пользовательского интерфейса применяется обычно почтовый клиент наподобие Microsoft Outlook или Netscape Messenger (только для поиска и чтения) или специально создаваемый клиент, как правило, доступный через Web. Адресная книга служит для поиска и просмотра информации, автоматического заполнения адресов электронной почты и хранения сертификатов PKI, необходимых для организации электронного обмена конфиденциальной информацией.

Каталоги внешних пользователей. При построении приложений Web, с которыми работают бизнес-партнеры или клиенты организации, требуется создать механизм аутентификации; для этого традиционно также используются каталоги LDAP.

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

Таким образом, один и тот же каталог LDAP способен выполнять целый ряд задач.

ПРОТОКОЛ LDAP

Упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) представляет собой протокол прикладного уровня; он поддерживает обмен информацией между клиентом и сервером и работает поверх протокола TCP/IP (по умолчанию LDAP использует TCP-порт 389). Идея создания LDAP возникла в ходе экспериментов с ранними реализациями стандарта X.500 в конце 1980-х — начале 1990-х гг. (эти реализации оказались очень сложны и чересчур требовательны к вычислительным ресурсам с клиентской стороны, что привело к необходимости разработки другого клиентского протокола). Технические спецификации нового протокола (RFC 1487 для LDAP версии 2 и RFC 1777 для повсеместно распространенного ныне LDAP версии 3) увидели свет в 1993 и 1995 гг., соответственно.

Первоначально LDAP использовался в качестве дополнения к основному клиентскому протоколу X.500 — протоколу DAP. Таким образом, информационная модель каталогов LDAP полностью унаследована от X.500. В современных каталогах протоколы X.500 либо не поддерживаются вовсе, либо существуют наравне с LDAP, но информационная модель X.500 все равно реализуется — клиент LDAP просто «не знает», от кого он получает информацию — от шлюза между LDAP и DAP или от независимого сервера LDAP.

Протокол LDAP с самого начала ориентировался на максимальную простоту: например, в нем отсутствует поддержка сложных транзакций. Стандарт определяет девять операций:

  • чтения и поиска — search, compare;
  • редактирования — add, delete, modify, rename;
  • установления и разрыва связи — bind, unbind, abandon.

Названия этих операций в основном говорят сами за себя и пояснения не требуют. Обратим только внимание на отсутствие операции read — ее функции выполняет search. (Далее мы поясним по механизму работы операции search.)

ХРАНЕНИЕ ДАННЫХ

Спецификации протокола не указывают, в каком именно формате должны храниться сами данные, и производители решают эту задачу по-разному. В большинстве серверов каталогов хранилища сконструированы специальным образом с учетом относительной статичности данных каталога. Каталоги, совмещающие поддержку X.500 и LDAP, используют формат хранения, предписываемый X.500. В каталогах Oracle Internet Directory и IBM SecureWay данные хранятся в реляционных СУБД соответствующих производителей (Oracle и DB2). Наконец, в качестве каталогов LDAP могут выступать и системы, для которых эта функциональность вторична, — например, почтовый сервер Exchange или среда Lotus Domino, где данные представлены в «родных» форматах.

Заметим, что при построении системы каталогов LDAP на базе продуктов, в основе которых лежит СУБД, заметная часть функционала этого хранилища останется неиспользованной и может отрицательно влиять на производительность системы. Поэтому достаточно логично, что наибольшее распространение получили каталоги, базирующиеся не на СУБД, а на специализированных хранилищах.

Наконец, продукты, наподобие MaXware Virtual Directory (MVD), представляют собой «виртуальные каталоги». MVD работает в качестве шлюза между любым форматом хранения данных (стандартным или нестандартным — к нему прилагается собственная библиотека API для обработки нестандартных форматов) и LDAP. При помощи MVD практически любое хранилище может быть представлено как каталог LDAP.

ИНФОРМАЦИОННАЯ МОДЕЛЬ

Данные в каталогах LDAP представлены как объекты; информация о каждом объекте хранится в наборе атрибутов (точнее, в виде пар «название атрибута — значение атрибута»). Важным отличием от СУБД является возможность присваивать одному объекту несколько атритубов с общим названием: например, объект, описывающий пользователя, может содержать несколько телефонных номеров или адресов электронной почты.

Набор возможных атрибутов задается для каждого каталога заранее. Стандартный набор при необходимости может быть изменен или расширен. Вместе с названием атрибута фиксируется его синтаксис (строка, число, дата и проч.), а потому, в отличие от мира СУБД, название атрибута почти всегда неизменно от каталога к каталогу. Так, атрибут c (country) повсюду означает название страны, l (locality) — населенного пункта, ou (organizational unit) — подразделения организации, cn (common name) — комбинацию имени и фамилии и т. д. В каталогах Active Directory широко применяется атрибут dc (domain component), обозначающий название сегмента корпоративной сети.

Каждый объект каталога принадлежит к одному или нескольким объектным классам. Объектный класс описывает тип объекта и определяет:

  • какие атрибуты обязаны присутствовать у объекта данного класса;
  • какие атрибуты могут присутствовать у объекта данного класса;
  • какой атрибут может использоваться для именования объектов данного класса

Объектные классы формируют собственную древовидную иерархию; объект, принадлежащий какому-либо объектному классу, автоматически принадлежит всем его надклассам (все классы являются подклассами универсального класса top) — на этот объект накладываются все заданные для подклассов ограничения, равно как и ограничения его собственного класса.

К примеру, объект, относящийся к классу person, обязан иметь непустые атрибуты cn и sn (фамилия, surname) и может иметь атрибуты telephonenumber, description и некоторые другие. Объект, принадлежащий подклассу organizationalPerson (подкласс person), должен удовлетворять тем же требованиям и может вдобавок содержать иные атрибуты, среди которых title (должность) и ou.

Наиболее распространенным объектным классом для хранения информации о пользователях является на сегодняшний момент inetOrgPerson (здесь inet используется как сокращение от Internet). Это подкласс класса organizationalPerson, он описан в RFC 2798 (в отличие от классов person и organizationalPerson, которые включены в стандарт X.521). Причина в том, что стандарты X.500 формулировались в 1980-х гг. еще до повсеместного распространения Internet, и в описанных там классах отсутствует, например, стандартное поле для адреса электронной почты.

Объектные классы каталога делятся на основные и дополнительные (auxiliary). Каждый объект обязан принадлежать хотя бы к одному основному классу и может принадлежать к дополнительному классу(-ам). Как правило, атрибуты последнего относятся к конкретному приложению. Например, в случае причисления объекта класса inetOrgPerson к дополнительному классу nsmessagingserveruser он объявляется пользователем почтового сервера Sun ONE Messaging; данный класс позволяет добавить к объекту атрибут nsmsgdisallowaccess, необходимый для работы этого сервера. Таким образом, механизм дополнительных классов позволяет задействовать уже имеющийся каталог в качестве хранилища данных о пользователях нового приложения.

Набор типов атрибутов и объектных классов, определенных для данного каталога, называется его схемой (schema). Схема всех основных каталогов LDAP настраивается администратором, хотя в настоящий момент стандартный способ ее настройки отсутствует, что приводит к определенной степени несовместимости: приложение, которому понадобится каталог LDAP для хранения данных о пользователях, должно поставляться с процедурами адаптации схемы каталога отдельно для каждого (широко используемого) сервера каталогов.

НАИМЕНОВАНИЕ ОБЪЕКТОВ КАТАЛОГА

Объекты каталога организуются в иерархическую логическую структуру — дерево. Его корнем служит пустой корневой объект root; объекты следующего уровня называются суффиксами.

У каждого объекта выделяется один именующий атрибут (Relative Distinguished Name, RDN). Полным идентификатором объекта (Distinguished Name, DN) является строка, полученная конкатенацией всех RDN при перемещении по дереву от данного объекта к корневому (см. пример далее). Заметим, что RDN не обязан быть уникальным в масштабах всего каталога: для обеспечения уникальности DN достаточно, чтобы RDN был уникален среди близлежащих объектов (тех, что расположены непосредственно под объектом, находящимся на один уровень выше).

Иерархия накладывает определенные ограничения на возможности удаления объектов каталога: объект, ниже которого остаются другие объекты, не может быть удален.

ФОРМАТ ОБМЕНА ДАННЫМИ

Формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) — это стандартный способ представления данных каталога в виде текстовых файлов. Благодаря LDIF информация может быть считана из каталога, отредактирована при помощи обыкновенного текстового редактора и экспортирована в тот же или в другой каталог. Файл LDIF может содержать данные о любом количестве объектов каталога.

В качестве примера посмотрим LDIF одного объекта Sun ONE Directory Server:

dn: u > cn;lang-ru:: 0JLQsNGB0LjQu9C40Lkg0Kj
QsNCx0LDRgg==
nsmsgdisallowaccess: pop http
preferredlanguage: ru
mailhost: mail.niichavo.ru
maildeliveryoption: mailbox
givenname;lang-ru:: 0JLQsNGB0LjQu9C
40Lk=
mail: vshabat@niichavo.ru
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: mailrecipient
objectclass: nsmessagingserveruser
cn: Vasily Shabat
uid: vshabat
sn;lang-ru:: 0KjQsNCx0LDRgg==
givenname: Vasily
sn: Shabat
ou: Administrators

Из примера видно, что:

    RDN объекта — «u >При простой аутентификации клиент должен либо объявить себя анонимным, либо представить DN пользователя и пароль в ходе операции подключения (bind). Содержащиеся в каталоге данные о контроле доступа позволяют установить, дано ли ему право на выполнение запрошенной операции.

Операция bind зачастую используется и другими приложениями, когда в работе с данными каталога нет непосредственной необходимости. Например, приложение может запросить имя пользователя и пароль, сформировать из них запрос к каталогу на операцию bind и проверить ее выполнение. Если операция проходит без ошибок, то аутентификация считается успешной. Заметим только, что в большинстве случаев, когда аутентификация проводится конечными пользователями, детали работы с DN не видны: приложение запрашивает имя пользователя и пароль, затем (соединившись с каталогом в соответствии с собственными правами) находит DN объекта с конкретным именем пользователя и только потом пытается выполнить команду bind.

Аутентификация может производиться и более сложными (но и более безопасными) способами, например при помощи ключей PKI.

Методы представления информации о контроле доступа (Access Control Information, ACI) до сих пор не стандартизованы и реализуются в различных серверах LDAP по-разному.

ПОИСК ДАННЫХ В КАТАЛОГЕ

Для выполнения операции поиска (search) в каталоге LDAP клиенту нужны следующие параметры:

  • адрес сервера (имя DNS или адрес IP);
  • номер порта (по умолчанию 389);
  • версия LDAP (2 или 3, по умолчанию 3). В настоящий момент серверы, поддерживающие только версию 2, встречаются редко, и многие клиенты по умолчанию используют версию 3;
  • DN пользователя, пароль — для аутентификации;
  • DN «базового» объекта (Base DN) определяет базу поиска. Поиск будет производиться только в части дерева, лежащей ниже указанного объекта;
  • фильтр поиска, где размещены содержательные требования к значениям атрибутов. Строчные атрибуты могут быть проверены на соответствие заданной строке или на наличие в них заданной подстроки. Для численных атрибутов возможен поиск в виде неравенств. Кроме того, в фильтрах можно также использовать стандартные логические операции (AND, OR, NOT);
  • область поиска (scope). Возможные варианты — subtree, one или base. При поиске по subtree (наиболее распространенном; многие клиенты задают этот параметр по умолчанию) просматривается часть дерева под базовым объектом. При поиске one рассматриваются лишь те объекты, что находятся непосредственно под базовым (т. е. на один уровень ниже). Наконец, при поиске по base анализируется только сам базовый объект (операция search с областью поиска base является, скорее, операцией считывания, нежели поиска, хотя соответствие записи фильтру поиска все равно проверяется);
  • требуемые атрибуты. По умолчанию поиск вернет атрибуты всех найденных записей, а по специальному запросу — значения конкретных атрибутов.

Фильтр поиска может состоять из требования к объектному классу. Например, фильтру «object >

Заметим, что в большинстве серверов предусмотрена зависимость контроля доступа от типа поисковой операции. Например, администратор может задать условие, чтобы объект был виден определенному пользователю исключительно при поиске base, т. е. когда пользователь ищет этот конкретный объект.

В примере, приведенном на Рисунке 1, фильтр поиска составлен как логическая связка AND условий на должность пользователя и его имя.

Рисунок 1. Параметры поиска в каталогах LDAP.

ТИРАЖИРОВАНИЕ, ПЕРЕАДРЕСАЦИЯ И ЭСТАФЕТНЫЕ ЗАПРОСЫ

К каталогам, как к часто используемым системам, предъявляются высокие требования в отношении доступности их сервиса. Это означает, что данные каталога необходимо размещать на нескольких связанных между собой серверах, что позволит реализовать:

  • географически распределенную систему, когда серверы каталога находятся в непосредственной близости к своим пользователям;
  • отказоустойчивую систему, когда данные дублируются на двух или более серверах, и выход одного из них из строя не прерывает работу каталога;
  • масштабируемую систему высокой доступности, способную выдержать значительные нагрузки благодаря их распределению между различными серверами.

Для реализации подобных систем нужен механизм разностного тиражирования данных между отдельными серверами каталогов (по сети передаются только изменения в содержании каталога). Такие механизмы предусмотрены во всех распространенных серверах каталогов, но они все еще не стандартизованы, а значит, организовать тиражирование между серверами различных производителей без привлечения сторонних средств невозможно.

Тиражирование бывает двух видов — с одним или несколькими главными серверами. Первый способ предусматривает, что каждый объект каталога может быть изменен на одном из серверов; его копии на других серверах доступны только для чтения. Второй снимает это ограничение. Полноценная отказоустойчивая система, т. е. система, которая продолжает обрабатывать запросы на редактирование данных после отказа одного из серверов, возможна только во втором случае. Тиражирование с несколькими главными серверами реализовано в каталогах Active Directory, eDirectory и Sun ONE Directory (в последнем случае главных серверов может быть не более двух). Заметим, что подобная схема потенциально опасна: при отсутствии механизма контроля за транзакциями изменения, внесенные на главных серверах, могут конфликтовать друг с другом. Соответствующий механизм решает, какие изменения в итоге осуществятся, а какие — нет (и, как следствие, будут потеряны).

Для реализации отказоустойчивых систем и систем высокой доступности требуются дополнительные средства по распределению нагрузки. Таким инструментом может стать proxy-сервер LDAP, DNS Round Robin или аппаратное решение, наподобие Cisco Local Director.

Несколько серверов можно увязать в единую систему и другими способами. При использовании переадресации (referral) сервер LDAP сообщает, что для обработки запроса клиент должен обратиться к другому серверу LDAP. Переадресация требует, чтобы все принимающие в этом участие клиенты LDAP правильно интерпретировали referral — к сожалению, большинство имеющихся на рынке клиентов этого не делают.

С другой стороны, передача эстафетных запросов (chaining) от клиента LDAP не предполагает никакой дополнительной функциональности: серверы LDAP разделяют дерево каталога между собой и сами пересылают запрос от сервера к серверу. Клиент LDAP в этом случае даже «не знает», что применялся эстафетный запрос. Эстафетные запросы реализованы в серверах каталогов, поддерживающих X.500, — Siemens DirX, Critical Path Directory Server, Nexor. Соответствующий протокол, DSP, является частью стандарта X.500.

АДМИНИСТРИРОВАНИЕ ДАННЫХ КАТАЛОГА

Каждый сервер каталога поставляется с интерфейсом, при помощи которого производится как конфигурация и управление сервером, так и администрирование данных каталога. Однако полностью вопрос администрирования данных этими средствами не решается.

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

С другой стороны, на рынке отсутствуют продукты, применение которых дало бы возможность полностью отказаться от средств администрирования любого из каталогов LDAP. Проблема в том, что такое средство должно позволять не только редактировать данные, но и управлять правами доступа и изменениями в схеме каталога, а подобные функции реализуются в разных серверах по-разному. Тем не менее в последнее время большую популярность приобрели такие инструменты, как Softerra LDAP Administrator и бесплатное средство для управления данными каталога LDAP Browser. Функционирование и того и другого ограничивается управлением данными каталога.

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

Наконец, различные хранилища пользовательских данных можно объединить в единую систему каталогов — при этом за синхронизацию между хранилищами отвечают метакаталоги. Так, при помощи метакаталога используемый в корпоративной сети каталог Active Directory можно объединить с Sun ONE Directory Server, используемым приложениями Sun ONE, к примеру Messaging Server, а также с корпоративной системой учета кадров. В результате управление содержимым каталога осуществляется автоматически на основе данных других систем.

Василий Шабат — менеджер отдела развития решений компании «Открытые технологии». С ним можно связаться по адресу: vshabat@ot.ru.

Поделитесь материалом с коллегами и друзьями

2. Понятия и обзор LDAP

Если Вы уже понимаете, что из себя представляет LDAP, для каких целей он подходит, что такое схемы данных, объектные классы, атрибуты, правила соответствия, операционные объекты и вся эта кухня — можете пропустить этот раздел. Однако, если Вы собираетесь делать нечто большее, чем вслепую следовать рецептам HOWTO, Вы должны понимать все эти вещи.

LDAP и X.500 имеют много общих терминов, некоторые из них важны, некоторые — просто ерунда. Для Вашего удобства мы создали глоссарий. Термины в него включены либо потому, что они важны, либо потому, что они часто используются в литературе.

Небольшое замечание о чувствительности к регистру в LDAP: здесь есть некоторая путаница, по крайней мере, мы считаем это путаницей. По правде говоря, путаниц тут хватает на каждом шагу. Единственные чувствительные к регистру вещи в LDAP — это пароли и содержимое отдельных (очень малоизвестных) атрибутов, в зависимости от их правил соответствия. Всё. В этой и других документациях Вы будете встречать и objectclass, и objectClass, и даже ObjectClass. Все эти формы работают. Точка. После первых шести лет изучения LDAP (шутка, конечно, хватит и четырёх) Вы уже не будете хвататься за сердце всякий раз, когда Вам доведётся опечататься в каком-нибудь имени. Итак, использование «верблюжьей» нотации — это, возможно, и неплохая практика, но даже если Вы где-то ошибётесь, солнце не упадёт на землю.

О букве D в LDAP: официально буква D в аббревиатуре LDAP означает Directory (каталог) — Lightweight Directory Access Protocol. Связано это главным образом с историческими истоками LDAP (и его предшественника DAP), которые были ориентированы на взаимодействие с классическими приложениями для работы с каталогом адресов электронной почты типа «белые страницы». Однако, любая терминология в конечном итоге может начать загонять саму себя и тех, кто ею пользуется, в какие-то рамки. Не заблуждайтесь, рассуждая о LDAP, мы говорим о доступе к данным, и если термин Directory ограничивает Ваше мышление из-за существующих ментальных моделей каталогов (наше уж точно ограничивает, хотя, возможно, мы просто сами по себе умственно ограничены), то, размышляя о LDAP, просто мысленно заменяйте его термином Data (данные), и получится Lightweight Data Access Protocol. Только никому не говорите, а то прослывёте вероотступником.

2.1 Краткая история LDAP

Когда-то в тёмном и далёком прошлом (конец 70-х — начало 80-х) ITU (International Telecommunication Union) начал работу над почтовыми стандартами серии X.400. Для этого стандарта требовался каталог имён (и другой информации), который мог бы быть доступен по сети в иерархической манере, схожей с DNS (для тех из Вас, кто знаком с её архитектурой).

Эта потребность в глобальном сетевом каталоге сподвигла ITU к разработке стандартов серии X.500 и, в частности X.519, которые определяют DAP (Directory Access Protocol), протокол для доступа к сетевой службе каталогов.

Серии стандартов X.400 и X.500 разрабатывались как составная часть полного стека OSI и были большими, громоздкими и потребляли много ресурсов. Фактически, стандартная ситуация для ITU.

Перенесёмся в начало 90-х. IETF осознала необходимость доступа к глобальным службам каталогов (первоначально, во многом, по тем же самым причинам хранения адресов электронной почты, что и ITU), но не поднимая при этом всех этих ужасных перенагруженных протоколов (OSI), и начала работу над Lightweight Directory Access Protocol (LDAP). LDAP разрабатывался так, чтобы обеспечить почти столько же функциональности, что и оригинальный стандарт X.519, но с использованием стека протоколов TCP/IP, при этом оставляя возможность взаимодействия с каталогами, основанными на X.500. Действительно, взаимодействие с X.500 (DAP) и его отображение всё ещё является частью серии RFC о LDAP от IETF.

Большинство вопросов в спецификациях LDAP, вызывающих серьёзную головную боль, как раз связаны с обратной совместимостью с X.500 и концепцией глобальной службы каталогов. Самый показательный из них — соглашение об именовании корневой записи.

В широком смысле, LDAP отличается от DAP в следующих аспектах:

  1. В LDAP используется TCP/IP — DAP использует OSI в качестве транспортного/сетевого слоёв.
  2. Некоторое сокращение функциональности — неясные, дублирующиеся и редко используемые функции X.519 (конёк ITU) тихо и благополучно отброшены.
  3. Замена в LDAP некоторых из ASN.1-нотаций (X.519) текстовым представлением (LDAP URL и поисковые фильтры). В этом вопросе IETF не снискала нашей безграничной благодарности: значительное большинство ASN.1-нотаций всё ещё остаются в прежнем виде.

2.2 Обзор LDAP

Технически, LDAP — это всего лишь протокол, определяющий методы, посредством которых осуществляется доступ к данным каталога. Он также определяет и описывает, как данные представлены в службе каталогов (Модель данных или Информационная модель). Наконец, он определяет, каким образом данные загружаются (импортируются) и выгружаются (экспортируются) из службы каталогов (с использованием LDIF). LDAP не определяет, как происходит хранение и манипулирование данными. С точки зрения стандарта хранилище данных и методы доступа к нему — это «чёрный ящик», за который, как правило, отвечают модули back-end (механизмы манипуляции данными) какой-либо конкретной реализации LDAP (обычно в них используется некоторая форма транзакционной базы данных).

LDAP определяет четыре модели, которые мы перечислим и кратко обсудим, а затем Вы можете спокойно забыть о них, поскольку для понимания LDAP они мало что дают.

Информационная модель: мы склонны использовать термин модель данных, на наш взгляд он более интуитивный и понятный. Модель данных (или информационная модель) определяет, каким образом информация или данные представлены в системе LDAP. Это может совпадать или не совпадать с фактическим методом представления данных в хранилище на физическом носителе. Как упоминалось выше, вопрос хранилищ данных лежит за пределами стандартов LDAP.

Модель именования: определяет все вещи наподобие ‘dc=example,dc=com’, с которыми Вы сталкиваетесь в системах LDAP. Здесь мы максимально придерживаемся спецификации, поскольку эти термины используются очень широко.

Функциональная модель: при чтении, поиске, записи или модификации LDAP Вы используете функциональную модель — кто бы мог подумать!

Модель безопасности: Вы можете контролировать, причём весьма детально, кто, что и с какими именно данными может сделать. Это сложная, но мощная штука. Мы постепенно внедрялись в данную концепцию и посвятили ей отдельную главу. На начальном этапе можно забыть о безопасности. Вы всегда можете вернуться и модернизировать безопасность в LDAP. Если модернизация впоследствии будет невозможна, мы будем описывать реализацию безопасности по тексту. Эта модель также включает в себя защиту данных при передаче по сети, такую как TLS/SSL. Хорошая, но на редкость сложная штука.

Сфера стандартов LDAP показана на диаграмме ниже. Обозначенные красным вещи (1, 2, 3, 4) определены в протоколе (различных RFC, определяющих LDAP). Происходящее же в «чёрных ящиках» (или, в данном случае, в зелёных, жёлтых и сиреневых ящиках), а также показанное чёрной стрелкой обращение к базам данных (5) выходит за рамки стандартов.

Каждый компонент кратко описан здесь, немного подробнее ниже и в мельчайших деталях в последующих главах. Но для начала четыре важных момента:

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

Когда Вы общаетесь с сервером LDAP, Вы понятия не имеете, откуда поступают данные: на самом деле одна из ключевых задач стандарта — скрывать такой уровень детализации. Теоретически, данные могут поступать из одной ИЛИ НЕСКОЛЬКИХ локальных баз данных, либо одной или нескольких служб X.500 (в наши дни это большая редкость). Откуда и каким образом Вы будете получать данные — это детали реализации, они важны только на этапе определения рабочей конфигурации Вашего LDAP-сервера (серверов).

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

Ряд коммерческих продуктов баз данных предоставляет LDAP-представление (LDAP-обёртку или LDAP-абстракцию) реляционной базы данных или базы данных другого типа.

2.3 LDAP и базы данных

LDAP характеризуется как сервис «один раз записал — много раз прочитал». Другими словами, от данных, обычно хранящихся в каталоге LDAP, не ожидается, чтобы они менялись при каждом доступе. Для иллюстрации: LDAP не подходит для ведения учета банковских операций, так как они, по своей природе, изменяются почти при каждом доступе (бизнес-транзакции). С другой стороны, LDAP как нельзя лучше подходит для учёта различных аспектов деятельности банка, меняющихся значительно реже: списка отделений, часов работы, сотрудников и т.д.

Оптимизация на чтение

Во фразе «один раз записал — много раз прочитал» до конца не ясно, насколько много это много?

Где проходит грань разумного использования между LDAP и классическими, ориентированными на транзакции реляционными базами данных, к примеру, SQLite, MySQL, PostGreSQL? Если обновление происходит при каждом втором доступе, будет ли разумно использовать в таком приложении LDAP, или нужно, чтобы обновления происходили раз в тысячу или в миллион обращений?

Литература по этой теме крайне редка и имеет тенденцию придерживаться таких беспроигрышных LDAP-приложений, как адресные книги, которые изменяются, возможно, раз в столетие.

Простого ответа на этот вопрос нет, однако следующие замечания могут оказаться полезными:

Увеличение нагрузки при операциях записи происходит из-за обновления индексов. Чем больше индексов (для ускорения поиска), тем, по возможности, реже должны выполняться обновления каталога. Соотношение чтение:запись в хорошо оптимизированных на чтение каталогах должно быть 1000:1 и даже больше. Для умеренно оптимизированных каталогов (2-3 индекса) разумным будет соотношение 500:1 и выше.

Репликация LDAP генерирует несколько транзакций для каждого обновления, таким образом, желательно снизить практическую нагрузку, связанную с обновлениями (следует ориентироваться на соотношение чтение:запись 500:1 или выше).

Если объём данных велик (скажем, больше 100 000 записей), то даже при небольшом количестве индексов время обновления может быть значительным. Поэтому желательно снизить количество обновлений до минимально возможного (10 000:1 или выше).

Если объём данных относительно невелик (скажем, меньше 1000 записей, чего обычно хватает для большинства стандартных применений каталогов LDAP), индексов немного (не более 2-3) и отсутствует репликация, мы не видим рационального объяснения, почему Вы не можете использовать LDAP в форме, приближенной к транзакционной системе, то есть соотношение чтение:запись 5:1 или 10:1. При добавлении репликации более подходящим будет соотношение 50:1 или 100:1.

Мы полагаем, что настоящий ответ на этот вопрос (с уважением к памяти ушедшего от нас Douglas Noel Adams): оптимальное соотношение количества чтений к количеству записей составляет 42!

Представление организации данных

Применяемые для доступа к каталогам LDAP примитивы (элементы протокола LDAP) используют модель данных, которая (возможно) абстрагирована от её физической организации. Эти примитивы обеспечивают представление данных в виде объектной модели и не заботятся об актуальной структуре данных. В действительности, относительная простота LDAP происходит именно от этой характеристики. Конкретная реализация сервера LDAP будет выполнять отображение примитивов LDAP в физическую организацию данных, используя свой механизм манипуляции данными как «чёрный ящик» в чистом виде.

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

Синхронизация и репликация данных

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

Главный LDAP-сервер и подчинённые ему серверы (или равноправные ему серверы в среде с несколькими главными серверами (multi-master)) используют простой асинхронный процесс репликации данных. В связи с этим во время цикла репликации возможна рассинхронизация данных в главной и подчинённой (или равноправной) системах. Во время этого (обычно очень короткого) периода времени запрос к главному и подчинённому серверам может дать разные результаты. Если вследствие такого расхождения мир с треском расколется пополам, значит для подобного приложения LDAP не подойдёт. Если же Bob Smith на несколько секунд (или даже меньше) будет числиться в бухгалтерии на одном LDAP-сервере, а на другом — в отделе продаж, вряд ли это кого-то сильно огорчит. В эту категорию попадает удивительно большое количество приложений.

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

2.3.1 Использование LDAP — резюме

Так в чём же преимущества LDAP (каталогов), и почему каждый здравомыслящий человек будет их использовать?

Прежде чем попытаться ответить на этот вопрос, давайте абстрагируемся от тактических соображений производительности. В целом, реляционные СУБД всё ещё значительно быстрее реализаций LDAP. По мере разработки служб каталогов второго поколения это положение меняется, и, хотя реляционные СУБД всегда будут оставаться быстрее LDAP, разрыв значительно сократился вплоть до точки, в которой различия становятся уже практически несущественными, если, конечно, Вы сравниваете подобное с подобным (единичные сетевые транзакции, а не обновление высокоиндексированного атрибута при каждой операции — в этом случае, не обессудьте, Вы получите (или не получите) ровно столько, сколько заслужили).

Так почему же нужно использовать LDAP? Вот наш список ключевых характеристик, которые делают высокий (всё ещё) уровень боли терпимым:

LDAP предоставляет стандартизированные как удалённый, так и локальный методы доступа к данным. Таким образом, вполне реально заменить одну реализацию LDAP на другую, совершенно не влияя на внешний интерфейс доступа к данным. Реляционные СУБД в основном реализуют стандарты локального доступа, такие как SQL, но удалённые интерфейсы всегда остаются проприетарными.

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

LDAP предоставляет метод, посредством которого данные могут быть перемещены (делегированы) в несколько мест, не затрагивая при этом внешнего доступа к этим данным. Используя метод отсылок LDAP, данные могут быть перемещены на альтернативные LDAP-серверы путём только изменения операционных параметров. Таким образом, можно построить распределенные системы, возможно, с данными, поступающими из отдельных автономных организаций, обеспечивая при этом для своих пользователей единое, последовательное представление этих данных.

Системы LDAP могут быть настроены на репликацию данных на один или несколько серверов LDAP или одному или нескольким приложениям только за счет операционных параметров, без необходимости добавления дополнительного кода или изменения внешнего доступа к данным.

Эти характеристики концентрируют внимание исключительно на стандартной природе доступа к данным LDAP, не учитывая отношения количества чтений к количеству записей, которое, как отмечалось выше, зависит от количества обслуживаемых операционных индексов. Они неявно сбрасывают со счетов использование систем LDAP для обработки транзакций, хотя есть тенденция, что некоторые реализации LDAP учитывают такие возможности.

2.4 Информационная модель (модель данных или объектная модель) LDAP

Каталоги LDAP используют модель данных, которая представляет данные как иерархию объектов. Это не означает, что LDAP является объектно-ориентированной базой данных. Как уже отмечалось выше, LDAP сам по себе является протоколом, позволяющим получить доступ к службам LDAP, и не определяющий, каким образом данные хранятся, — но операционные примитивы (чтение, удаление, модификация) работают с моделью (описанием/представлением) данных, имеющих (в основном) объектоподобные характеристики.

2.4.1 Структура дерева объектов

В этом разделе определяется сущность LDAP. Если Вы поймёте этот раздел и различные термины и отношения, с ним связанные, Вы поймёте LDAP.

В LDAP-системе данные представлены как иерархия объектов, каждый из которых называется записью. Полученная в результате древовидная структура называется Информационным деревом каталога (Directory Information Tree, DIT). Верхнюю часть данного дерева обычно называют корнем (root), (а также базой (base) или суффиксом (suffix)).

У каждой записи есть одна родительская запись (объект) и ноль или более дочерних записей (объектов). Каждая дочерняя запись (объект) является одноуровневой (братской) по отношению к другим дочерним записям своей родительской записи.

Каждая запись состоит из (является экземпляром) одного или нескольких объектных классов (objectClass). Объектные классы содержат ноль или более атрибутов (attribute). Атрибуты имеют имена (и, иногда, аббревиатуры или псевдонимы) и обычно содержат данные (наконец-то!).

Характеристики (свойства) объектных классов и их атрибутов описываются определениями ASN.1.

Уф! Теперь Вы знаете всё, что только можно знать о LDAP. Остальное — детали. Да, этих деталей, пожалуй, очень много. Но суть LDAP именно в этом.

Представленная ниже диаграмма иллюстрирует эти отношения:

Информационная модель (модель данных) LDAP DIT

Каждая запись (1) состоит из одного или нескольких объектных классов (2).

У каждого объектного класса (2) есть имя. Объектный класс представляет собой контейнер для атрибутов (в его определении идентифицируются атрибуты, которые он может или должен содержать).

У каждого атрибута (3) есть имя, он является членом одного или нескольких объектных классов (2) и содержит данные.

При наполнении DIT каждая запись будет уникально идентифицирована в иерархии (относительно своей родительской записи) данными, которые содержатся в этой записи (в атрибутах, которые содержатся в её объектном классе (классах)).

Теперь можно смело брать выходной на остаток дня и хорошенько отпраздновать!

2.4.2 Объектные классы

Объектные классы являются, по существу, контейнерами атрибутов. Они описываются с помощью определений ASN.1. У каждого объектного класса есть уникальное имя. Существует огромное число предопределённых объектных классов, в каждом из которых полным-полно атрибутов для почти всех возможных применений каталогов LDAP. Однако, само собой разумеется, что среди всех этих предопределённых объектных классов нет того, который Вам просто необходим! У объектных классов есть ещё три характеристики:

Объектный класс определяет, должен (MUST) ли входящий в него атрибут присутствовать в записи (обязательный атрибут), или он может (MAY) присутствовать (необязательный атрибут).

Каждый объектный класс принадлежит к определённому типу: он может быть структурным (STRUCTURAL), вспомогательным (AUXILIARY) или абстрактным (ABSTRACT) (детально эти типы описаны в следующей главе). На этом этапе достаточно знать, что в записи должен быть один и только один структурный (STRUCTURAL) объектный класс и может быть ноль или более вспомогательных (AUXILIARY) объектных классов.

Объектный класс может быть частью иерархии, в этом случае он наследует все характеристики своего родительского объектного класса (классов) (включая все содержащиеся в них атрибуты).

Объектные классы являются контейнерами и управляют тем, какие атрибуты могут быть добавлены к каждой записи. В целом же они, как правило, остаются вне поля зрения, когда речь идет о доступе и опросе (поиске) по DIT. Здесь на первый план выходят атрибуты и записи.

Больше (значительно больше) об объектных классах, — но только если Вы хорошо разобрались с данным материалом (в любом случае, мы будем разбираться с этим в следующей главе), — в противном случае продолжайте читать здесь.

Об уникальности: Каждое используемое в LDAP имя является уникальным. Имя каждого объектного класса уникально среди объектных классов, но на этом дело не заканчивается. Уникальное имя объектного класса (или имя любого другого элемента LDAP) также является глобально уникальным именем во всём LDAP. Например, существует объектный класс с уникальным именем person (с ним мы будем пересекаться позже), но это имя также является глобально уникальным именем во всём LDAP. Не существует атрибута (или любого другого элемента) с именем person.

2.4.3 Атрибуты

Каждый атрибут имеет имя (а также может иметь короткое имя или псевдоним) и обычно содержит данные. Атрибуты всегда связаны (являются членами) с одним или несколькими объектными классами. У атрибутов есть ряд интересных особенностей:

Все атрибуты являются членами одного или нескольких объектных классов.

Каждый атрибут определяет тип данных, которые он может содержать (ключевое слово SYNTAX в определении атрибута).

Атрибуты могут быть частью иерархии, в этом случае дочерний атрибут наследует все характеристики родительского атрибута. В данном случае иерархия атрибутов используется для упрощения и сокращения определений атрибутов (в ASN.1) там, где у нескольких атрибутов имеются одинаковые общие свойства, такие как максимальная длина, чувствительность/нечувствительность к регистру символов, или что-то ещё. Никакого другого смысла в иерархии атрибутов нет.

Атрибуты могут быть необязательными (ключевое слово MAY) или обязательными (ключевое слово MUST), согласно определениям ASN.1 того объектного класса, членами которого они являются. Атрибут может быть необязательным в одном объектном классе и обязательным в другом. Это свойство определяется в рамках объектного класса.

В разных местах этой документации в записях-примерах подобраны совершенно различные атрибуты, что может показаться путаницей. На самом же деле так происходит из-за необязательного характера большинства атрибутов. Это позволяет при составлении записей использовать подход «выбирай и соединяй»: находим нужный нам атрибут, находим объектный класс, членом которого является этот атрибут (таких классов может быть несколько), и надеемся, что все остальные атрибуты из данного объектного класса, которые мы не хотим использовать, окажутся необязательными! Чтобы яснее это себе представить, попробуйте посмотреть здесь.

У атрибутов может быть одно (SINGLE-VALUE) или несколько (MULTI-VALUE) значений (как описано в их определениях ASN.1). SINGLE-VALUE означает, что только одно значение данных может быть задано для этого атрибута. MULTI-VALUE означает, что этот атрибут может появляться в записи несколько раз с разными значениями данных. Если атрибут описывает, скажем, адрес электронной почты, может быть одно, два или 500 включений этого атрибута в запись, каждое с разным адресом электронной почты (атрибут многозначный (MULTI-VALUE)) — это один из ряда методов работы с почтовыми псевдонимами, применяемых при построении каталога. Значением по умолчанию для атрибута является MULTI-VALUE (что позволяет иметь несколько значений).

У атрибутов есть имя и, иногда, псевдоним (как описано в их определениях ASN.1), например, атрибут с именем cn является членом объектного класса, называемого person (и многих других), и имеет псевдоним commonName. Для ссылки на этот атрибут может использоваться как commonName, так и cn.

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

Атрибут (атрибуты), выбранные для хранения данных, составляющих уникальность записи, иногда называются атрибутом (атрибутами) именования или относительным уникальным именем (Relative Distinguished Name, RDN) — но подробнее об этом в следующем разделе.

Взгляните на некоторые распространённые объектные классы и атрибуты. На данном этапе всё это выглядит очень страшно. Просто забудьте о том, что Вы только что видели, и продолжим чтение.

Больше (значительно больше) об атрибутах, — но только если Вы хорошо разобрались с данным материалом (в любом случае, мы будем разбираться с этим в следующей главе), — в противном случае продолжайте читать здесь.

2.4.4 Описание дерева путём добавление записей (данных)

В конце концов мы хотим поместить немного данных в наш каталог и использовать-таки эту замороченную штуку.

Описание древовидной структуры и первоначальное наполнение данными осуществляется путем добавления записей (с ассоциированными с ними объектными классами и атрибутами), начиная от корневой записи DIT и двигаясь вниз по иерархии. Таким образом, родительская запись всегда должна быть добавлена перед тем, как пытаться добавить дочерние записи.

Записи состоят из одного или нескольких объектных классов (единственного структурного объектного класса и нуля или более вспомогательных классов), которые выступают в качестве контейнеров для атрибутов. Именно атрибуты, а не объектные классы, содержат данные.

Ранее мы определили, что при создании/наполнении DIT каждая запись будет уникально идентифицироваться (относительно своей родительской записи) в иерархии. Единственным уникальным элементом любой структуры данных являются данные. Чтобы однозначно идентифицировать запись, нам нужно определить уникальные данные среди тех, которые содержатся в ней. Данные, содержащиеся в записи, определяются в атрибутах (присутствующих в объектных классах), таким образом, нам нужно определить атрибут, содержащий данные, являющиеся уникальными. Напомним, что многие атрибуты являются многозначными, — они могут присутствовать в записи несколько раз с разным содержимым, — поэтому для создания абсолютной, несомненной уникальности нам нужно определить сразу и атрибут, и содержащиеся в нём данные. Это делается с использованием формата имя_атрибута=значение_(или_данные), который в терминологии LDAP зовётся утверждением значения атрибута (Attribute Value Assertion, AVA).

Для иллюстрации, если в данной записи (на данном уровне иерархии) уникальными данными является слово fred (да-да, мы знаем, пример так себе, маловероятно, чтобы это слово было уникальным, но вдруг мы находимся в Узбекистане?), и оно содержится в атрибуте с именем cn, то нашим AVA (утверждением значения атрибута) станет cn=fred. В данном случае, если мы хотим пооригинальничать или нам просто некуда девать время, мы можем записать его иначе: commonName=fred (у атрибута cn есть псевдоним commonName).

Но вдруг так случится, что cn=fred не будет абсолютно уникальным (Кто там хихикает на заднем плане? Мы всё слышим!), а значит не сможет быть уникальным идентификатором для данной записи. Мы можем либо изменить выбранное нами значение (в записи может оказаться несколько значений cn=value, из которых мы можем выбрать), либо изменить выбранный нами атрибут (может неплохо подойти sn=de Gamma, если, конечно, мы не в Португалии). Кроме того, мы можем использовать второе AVA для обеспечения уникальности. В этом случае мы сохраним наше cn=fred, но добавим AVA drink=tamarind juice (внесём элемент экзотики в наши серые будни). Тогда уникальное значение будет записываться как cn=fred+drink=tamarind juice. Уникальней просто некуда.

Добавление записей может происходить разными путями, один из которых — использовать файлы формата LDAP Data Interchange Files (LDIF), который полностью описан в одной из последующих глав. Файлы LDIF — это текстовые файлы, описывающие древовидную иерархию — информационное дерево каталога (Directory Information Tree, DIT), и данные, добавляемые в каждый атрибут. Ниже приведён простой пример LDIF-файла, описывающий корневое DN (dc=example,dc=com) и добавляющий три дочернии записи в ветку people.

На данном этапе не так важно досконально разбираться во всех значениях этого LDIF-файла. В примерах главы 5 охвачены подробности настройки LDIF-файлов, а в главе 8 LDIF-файлы разъясняются в красочных деталях. На данном этапе достаточно знать, что LDIF-файлы могут использоваться для создания DIT и выглядят примерно так, как приведено ниже (данный LDIF создаёт DIT со структурой, приведённой на русинке 2.4.4-1).

Добавление LDAP-записей может быть также выполнено с помощью LDAP-клиентов, таких как LDAP-браузеры общего назначения (смотрите LDAPBrowser/Editor) или специализированные приложения.

Важное замечание: Строки в приведённом выше LDIF-файле, начинающиеся с ‘dn:’, по существу сообщают LDAP-серверу, каким образом структурировать или располагать запись в DIT (об этом в следующем разделе). В общем случае не важно, значение какого атрибута используется для этой цели, при условии уникальности ‘dn:’. В первой записи ВТОРОГО уровня (третьей записи LDIF-файла) приведённого примера для этой цели было выбрано «dn: cn=Robert Smith, ou=people, dc=example, dc=com». Точно также могло быть выбрано, скажем, «dn: u становится чрезвычайно важным и определяет идентификатор входа в систему (в качестве которого, как правило, используется uid), или, на жаргоне, DN подсоединения. Иногда (особенно в контексте LDAP, используемого в Microsoft AD) имя записи называется DN принципала (Principal DN), хотя этот термин не используется в определениях стандартов LDAP. Дополнительная информация по этой теме.

Если данное примечание кажется вам белибердой, можете пока забыть о нём. Позже мы это подробнейшим образом осветим.

Мы расскажем о LDIF-файлах позже, поскольку они нам ещё понадобятся, а приведённый выше LDIF определяет следующую структуру:

Рисунок 2.4.4-1: Структура DIT, созданная LDIF-файлом

После того, как DIT определён и запущен в работу, в дальнейшем информацию в него можно добавлять с помощью LDIF, LDAP-браузера, web-интерфейса или другого программного интерфейса.

Используя LDIF-файлы, данные также можно экспортировать (сохранить) в качестве резервной копии или для других целей.

2.4.5 Навигация по дереву

После того, как мы поместили данные в наше дерево (DIT), обычно самое время начать с ними работать!

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

Короче говоря, мы должны осуществлять навигацию (ориентироваться) в каталоге.

Но для начала давайте введём ещё немного существенной терминологии.

В предыдущем разделе мы определили, что каждая запись должна быть уникально идентифицируемой (относительно своей родительской записи) с использованием одного (или нескольких) AVA (утверждений значения атрибута), например, cn=fred или, как в примере выше, cn=Robert Smith. Из правила, что каждое идентифицирующее AVA (или несколько AVA) должны быть уникальными (относительно родительской записи) в иерархии, следует, что путь к любой записи на любом уровне также должен быть уникальным (он представляет собой сумму индивидуально уникальных записей).

Терминология LDAP в области адресации заставляет задуматься об ограниченности английского языка. До сих пор для описания AVA записи мы использовали термин уникальное (unique), достаточно распространённое и понятное английское слово. Мы можем также сказать, что каждая запись имеет различное (different) имя. Кроме того (начинается!), мы можем также несколько извилисто выразиться, что, в силу своей уникальной идентификации, каждая запись отлична (distinguished) от своих соседей. Мы у цели! Основоположники служб каталогов в своей бесконечной мудрости решили использовать слово «Distinguished» («Отличительное», обычно в русскоязычной документации переводится как «Уникальное» — примечание переводчика).

Итак, AVA, например, cn=Robert Smith, уникально идентифицирующее запись, называется относительным уникальным именем (Relative Distinguished Name, RDN), то есть именем, уникальным по отношению к родительской записи. Путь от корневой записи DIT (она же базовая запись или суффикс) к данной записи представляет собой сумму всех RDN (соединённых через запятую (,) в порядке слева направо от младшей до старшей) называется уникальным именем (Distinguished Name, DN). Красота! Какими бы ни были Ваши взгляды на достоинства (или недостатки) LDAP и X.500, способность групп их стандартизации генерировать уникальную (или отличительную) терминологию не подлежит сомнению.

Для иллюстрации, в DIT из нашего примера путь от корневой записи до записи, уникально идентифицируемой AVA cn=Robert Smith, идёт от (RDN) dc=example,dc=com через (RDN) ou=people, и заканчивается на (RDN) cn=Robert Smith. Итоговое DN будет записываться как cn=Robert Smith,ou=people,dc=example,dc=com.

Три дополнительных момента, пока Вы ещё способны воспринимать информацию.

Напоминаем, что для создания уникального идентификатора можно применять несколько AVA, в этом случае RDN может выглядеть так: cn=Robert Smith + u >

DN записи ou=people: ou=people,dc=example,dc=com. DN описывает путь к любой записи в DIT.

В dc=example, dc=com, очевидно, два RDN (dc=example и dc=com). Это стандартная и легитимная конструкция (в дальнейшем мы её обсудим), используемая для определения корневой записи (она же базовая запись или суффикс). (Если Вы в настроении помудрствовать лукаво на эту тему, можно было бы назвать эту конструкцию много-RDN-ной RDN, но, честное слово, не стоит).

Для навигации по DIT мы можем задать путь (DN) к месту, где находятся наши данные (cn=Robert Smith, ou=people,dc=example, dc=com приведёт нас к уникальной записи), либо мы можем задать путь (DN) к месту, где, как мы предполагаем, находятся наши данные (скажем, ou=people,dc=example,dc=com), а затем выполнить поиск по паре или нескольким парам атрибут=значение, чтобы найти целевую запись (или записи). Если мы хотим выполнить изменения в каталоге (модификацию на жаргоне LDAP), как правило, следует указывать уникальную запись. Однако, если мы устраиваем DIT допрос с пристрастием, достаточно лишь примерной точности — мы получим всё, что соответствует критериям поиска.

Следующая диаграмма иллюстрирует DN и RDN:

2.5 Отсылки и репликация LDAP

Одним из наиболее мощных аспектов LDAP (и X.500) является вложенная в них способность делегировать ответственность за поддержание части каталога другому серверу, сохраняя при этом общую картину каталога как единого целого. Таким образом, можно создать в каталоге компании делегирование ответственности (отсылку (referral) в терминологии LDAP) той части всего каталога, в которой описан конкретный отдел, LDAP-серверу этого отдела. В этом аспекте LDAP почти полностью отражает концепцию делегирования DNS, если эта концепция Вам знакома.

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

OpenLDAP буквально следует стандартам и по умолчанию не выполняет сцепление, а всегда возвращает отсылку. Однако OpenLDAP может быть настроен на выполнение сцепления с помощью директивы overlay chain.

Встроенная функция репликации LDAP позволяет создать одну или несколько подчинённых копий каталога (DIT) от одной главной (и даже, в некоторых реализациях, распространять изменения между несколькими главными копиями DIT), таким образом, по сути, создаётся устойчивая структура.

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

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

Конфигурация репликации и отсылок рассматривается далее, а также в приводимых примерах.

2.5.1 Отсылки LDAP

Рисунок 2.5-1 демонстрирует поисковый запрос с базовым DN dn:cn=thingie,o=w >

Рисунок 2.5-1 — Запрос, удовлетворяемый только от LDAP1

Рисунок 2.5-2 демонстрирует поисковый запрос с базовым DN dn:cn=cheri,ou=uk,o=grommets,dc=example,dc=com к LDAP-системе с отсылками, ответ на который возвращается в результате серии отсылок к серверам LDAP2 и LDAP3, а LDAP-клиенты всегда следуют по отсылкам:

Рисунок 2.5-2 — Запрос, генерирующий отсылки к LDAP2 и LDAP3

  1. Все клиентские запросы начинаются с обращения к глобальному каталогу LDAP1.
  2. На сервере LDAP1 запросы любых данных, содержащие widgets в качестве RDN в DN, удовлетворяются непосредственно из LDAP1, например:
  3. На сервере LDAP1 запросы любых данных, содержащие grommets в качестве RDN в DN, генерируют отсылку на сервер LDAP2, например:
  4. На сервере LDAP2 запросы любых данных, содержащие uk в качестве RDN в DN, генерируют отсылку на сервер LDAP3, например:

Если LDAP-сервер сконфигурирован на выполнение сцепления (то есть на следование отсылкам, как показано альтернативными пунктирными линиями), то LDAP-клиенту будет отправлен один единственный ответ. Сцепление контролируется конфигурацией LDAP-сервера и значениями в поисковых запросах. Информация по сцеплению здесь.

На рисунках показано явное сцепление с использованием объектного класса referral. Серверы OpenLDAP могут быть настроены так, чтобы возвращать общую отсылку в случае, если запрашиваемый DN не был найден во время операции поиска.

2.5.2 Репликация LDAP

Функции репликации позволяют копировать обновления LDAP DIT на одну или несколько LDAP-систем в целях резервирования и/или повышения производительности. В этом контексте стоит подчеркнуть, что репликация работает на уровне DIT, а не на уровне LDAP-сервера, поскольку на одном LDAP-сервере может обслуживаться несколько DIT. Репликация происходит периодически, в течение промежутка времени, известного как время цикла репликации (по сути, это время, необходимое для отправки обновленных данных на сервер-реплику и получения подтверждения об успешном завершении операции). В общем случае, существуют методы уменьшения времени цикла репликации с помощью настроек, но обычно они приводят к снижению производительности или увеличению нагрузки на сеть. Исторически для выполнения репликации в OpenLDAP использовался отдельный демон (slurpd), но, начиная с версии 2.3, стратегия репликации коренным образом изменилась, были достигнуты серьёзные улучшения в гибкости и возможностях настройки времени цикла репликации. Существует два возможных типа конфигураций репликации, у каждого из которых есть несколько вариантов.

Главный-подчиненный (Master-Slave): В конфигурации главный-подчинённый обновляется одно единственное DIT (на жаргоне OpenLDAP оно называется главным (master) или поставщиком репликации (provider)), и эти обновления реплицируются или копируются на один или несколько указанных LDAP-серверов, на которых запущены подчинённые DIT (на жаргоне OpenLDAP они называются потребителями репликации (consumer)). Подчинённые серверы оперируют с доступной только для чтения копией главного DIT. Пользователи, которые выполняют только чтение, будут превосходно себя чувствовать, работая с серверами, содержащими подчинённые DIT, а пользователи, которым нужно вносить изменения в каталог, должны обращаться к серверу, содержащему главное DIT. При определённых условиях конфигурация главный-подчинённый позволяет существенно сбалансировать нагрузку. Однако, у неё есть два очевидных недостатка:

Если всем (большинству пользователей) дана возможность (требуется) вносить изменения в DIT, то либо им потребуется получать доступ к одному серверу (с подчинённым DIT) для осуществления чтения и к другому серверу (с главным DIT) для выполнения обновлений, либо они всегда будут обращаться к серверу, на котором запущено главное DIT. В последнем случае репликация выполняет только функцию резервного копирования.

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

Несколько главных (Multi-Master): В конфигурации с несколькими главными серверами могут обновляться несколько главных DIT, запущенных на одном или нескольких серверах, и результаты обновлений распространяются на другие главные серверы.

Исторически OpenLDAP довольно долго не поддерживал операции с несколькими главными серверами, но в версии 2.4 окончательно введены такие возможности. В этом контексте, наверное, стоит отметить две вариации общей проблемы конкуренции обновлений, специфичной для всех конфигураций с несколькими главными серверами. Эта проблема выявлена проектом OpenLDAP для своей конфигурации с несколькими главными серверами, но она относится ко всем системам LDAP:

Конкуренция значений. Если выполняется два обновления одного и того же атрибута в одно и то же время (в пределах времени цикла репликации) и при этом атрибуту назначаются разные значения, то, в зависимости от типа атрибута (SINGLE или MULTI-VALUED), результирующая запись может быть в неправильном или непригодном для использования состоянии.

Конкуренция удаления. Если один пользователь добавляет дочернюю запись в то же самое время (в пределах времени цикла репликации), когда другой пользователь удаляет оригинальную запись, то удалённая запись вновь появится.

Рисунок 2.5-3 показывает несколько возможных конфигураций репликации и объединяет их с отсылками из предыдущего раздела, чтобы показать всю мощь и гибкость LDAP. Следует отметить, что большинство конфигураций LDAP не настолько сложны.

Рисунок 2.5-3 — Конфигурации репликации

RO = только чтение, RW = чтение-запись

В случае LDAP1 клиент взаимодействует с подчинённой системой, доступной только для чтения. Для выполнения операций модификации (записи) клиенты должны обращаться к главной системе.

В случае LDAP2 клиент взаимодействует с главной системой, которая реплицируется на две подчинённые.

LDAP3 является системой с несколькими главными серверами и для выполнения операций чтения (поиска) и/или записи (модификации) клиенты могут обращаться к любому серверу. В данной конфигурации каждый главный сервер может, в свою очередь, иметь одно или несколько подчинённых DIT.

Глава 3 — Схема данных, объектные классы и атрибуты LDAP

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Сохраненные LDAP запросы в консоли Active Directory User and Computers

Сохраненные запросы (Saved Queries) в консоли Active Directory Users and Computers (ADUC) позволяют создавать простые и сложные LDAP запросы по выборке объектов Active Directory. Эти запросы можно сохранять, редактировать и переносить между компьютерами. С помощью сохраненных запросов можно быстро и эффективно решать задачи поиска и выборки объектов в AD по различным критериям. Saved Queries, например, помогут быстро: вывести список всех отключенных учетных записей в домене, выбрать всех пользователей определенной организации с ящиками на заданном сервере Exchange и т.п.

Важное преимущество сохраненных LDAP запросов — предоставление возможности выполнять групповые операции с объектами из разных OU (контейнеров) Active Directory, например массовая блокировка/разблокировка, перемещение, удаление учетных записей и т.п. Т.е. позволяют «избавиться» от недостатков иерархической структуры OU в Active Directory, собрав все нужные объекты в плоском табличном виде.

Большинство указанных операций можно выполнить с помощью PowerShell, dsquery, скриптов vbs и т.д., но, как правило, представление результатов в привычном графическом виде консоли намного удобнее и не требует особых навыков.

Active Directory Saved Queries впервые появились в Windows Server 2003 и продолжают поддерживаться во всех последующих версиях Windows Server

Покажем типовой пример использования сохраненных запросов в консоли Active Directory Users and Computers. Предположим, нам нужно вывести список активных учетных записей пользователей, наименование их отделов и адресов email.

Открываем консоль ADUC (dsa.msc), выбираем раздел Saved Queries, щелкнув по нему ПКМ выбираем New – > Query.

В поле Name указываем имя сохраненного запроса, которое будет отображаться в консоли ADUC.

В поле Query root можно указать контейнер (OU), в котором выполняется запрос. По умолчанию поиск по критериям запроса выполняется по всему домену AD. В нашем примере, мы сузим область поиска, выбрав контейнер Ekaterinburg.

Далее нажимаем кнопку Define Query, и в выпадающем списке Find выбираем пункт Custom Search.

Переходим на вкладку Advanced и в поле Enter LDAP query копируем следующий LDAP-запрос:
(&(objectcategory=person)(object >

Сохраняем изменения, нажав OK.

Выбираем в консоли ADUC созданный запрос, нажимаем F5 для перестроения списка. Результат работы запроса виден на скриншоте.

Чтобы отобразить дополнительные поля (email-адрес, отдел), в консоли ADUC открываем меню View и выбираем пункт Add/Remove Columns.

Добавляем нужные поля.

Мы добавили 3 дополнительных поля: User Logon Name, E-Mail Address, Department.

Полученный результат можно выгрузить в CSV или TXT формате для дальнейшего анализа и использования в табличном реакторе Excel. Для этого щелкаем ПКМ по сохраненному запросу и выбираем пункт меню Export List.

В консоли ADUC можно создать множество различных сохраненных запросов, которые можно организовать в древовидную структуру.

Сохраненные запросы хранятся локально в консоли на компьютере, на котором они были созданы (xml-файл с настройками находится здесь C:\Users\%USERNAME%\AppData\Roaming\Microsoft\MMC\DSA) . Для переноса сохраненного запроса между компьютерами, в консоли dsa.msc есть функция Импорта / Экспорта запросов через XML файлы.

В следующей табличке мы приведем примеры часто используемых LDAP запросов для выборки в Active Directory.

Active Directory LDAP понять как работает поиск по каталогам?

Вообщем столкнулся со следующей проблемой (непониманием):

Когда мне необходимо выбрать всех юзеров из AD я пишу примерно следующее:

И получаю результаты. Обратите внимание, в $base_dn находится корень AD, хотя сами юзеры не лежат в корне, а находятся в CN=Users

Теперь у меня возникает необходимость выбрать все Подсети из AD и если я в качестве BaseDn укажу корень (DC=example,DC=org), то получаю 0 результатов. Если же указать путь полностью (CN=Subnets,CN=Sites,CN=Configuration,DC=example,DC=org), то оно начинает работать.

Скажите, может я что то упустил? Почему в случае с юзерами он выбирает их всех при указании корня, а для подсетей приходится указывать полный путь?

  • Вопрос задан более трёх лет назад
  • 6163 просмотра

Во-первых: в параметрах поиска вы опускаете один параметр — область поиска (scope). Область поиска по-умолчанию обычно поддерево (SubTree) для заданного basedn.
Во-вторых: следует понимать, что у вас в каталоге AD изначально существует (в типовой конфигурации) 5 разделов. Так вот поиск работает только в пределах одного раздела.
При этом «DC=example,DC=org» — корень раздела домена, а «CN=Configuration,DC=example,DC=org» — корень раздела конфигурации. Поэтому при поиске с basedn = «DC=example,DC=org» и scope = SubTree вы не получите объекты из ветки CN=Configuration,DC=example,DC=org» — они расположены в другом разделе каталога.

Илон Маск рекомендует:  Opengl распределение компонент rgb в 3d пространстве
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL