/ldap-notes

Repository contains notes about ldap and related entities.

Основные концепции LDAP

Перед работой с LDAP существует несколько важных концепций, которые должны быть описаны. Эта статья описывает важные понятия и идеи связанные с LDAP.

Серверы каталогов

Сервер каталогов (технически более известный как Directory Server Agent, Directory System Agent или DSA) - это тип сетевой базы данных, которая хранит информацию, представленную в виде деревьев состоящих из записей. Он отличается от реляционной базы данных, которая использует таблицы, состоящие из строк и столбцов, поэтому серверы каталогов могут быть рассмотрены как тип базы данных NoSQL (хотя серверы каталогов существуют гораздо дольше, чем термин NoSQL).

Обычно все серверы каталогов поддерживают LDAP, но некоторые серверы предлагают поддержку дополнительных протоколов, которые могут быть использованы для взаимодействия с данными. Вот пример некоторых из этих протоколов: X.500 (оригинальный протокол доступа к каталогу, для которого LDAP является более легковесной версией), протоколы разрешения имён, такие как DNS и NIS, протоколы на основе HTTP, такие как DSML и SCIM, и проприетарные протоколы, такие как NDS от Novell.

См. Серверы каталогов для получения дополнительной информации о самых популярных серверах каталогов.

Записи

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

DN и RDN

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

LDAP DN состоит из нуля или более элементов, называемых относительными отличительными именами, или RDN. Каждый RDN состоит из одной или более (обычно только одной) пары атрибут-значение. Например, «uid=john.doe» представляет RDN, состоящий из атрибута с именем «uid» со значением «john.doe». Если RDN имеет несколько пар атрибут-значение, они разделяются плюсами, как «givenName=John+sn=Doe».

Специальное отличительное имя, состоящее из нуля RDN (и поэтому имеет строковое представление, которое является пустой строкой), иногда называется «нулевым DN» и ссылается на специальный тип записи, называемый root DSE, который предоставляет информацию о содержимом и возможностях сервера каталога. См. DIT и LDAP Root DSE для получения дополнительной информации о записи корневого DSE.

Для DN с несколькими RDN порядок RDN определяет позицию связанной записи в DIT. RDN разделяются запятыми, и каждый RDN в DN представляет уровень в иерархии в порядке убывания (т.е. движется ближе к корню дерева, называемому контекстом именования). То есть, если вы удалите RDN из DN, вы получите DN записи, считающейся родительской для предыдущего DN. Например, DN «uid=john.doe,ou=People,dc=example,dc=com» имеет четыре RDN, с родительским DN «ou=People,dc=example,dc=com».

См. страницу LDAP DNs и RDNs для более подробного описания DN, RDN и их строковых представлений.

Атрибуты

Атрибуты хранят данные для записи. Каждый атрибут имеет тип атрибута, ноль или более attribute options и набор значений, которые составляют фактические данные.

Типы атрибутов - это элементы схемы, которые указывают, как атрибуты должны обрабатываться LDAP-клиентами и серверами. Все типы атрибутов должны иметь идентификатор объекта (OID) и ноль или более имен, которые могут быть использованы для ссылки на атрибуты этого типа. Они также должны иметь синтаксис атрибута, который указывает на тип данных, который может быть хранен в атрибутах этого типа, и набор правил сравнения, которые указывают, как должны выполняться сравнения с значениями атрибутов этого типа. Типы атрибутов могут также указывать, может ли атрибут иметь несколько значений в одной записи, и предназначен ли атрибут для хранения пользовательских данных (user attribute) или используется для работы сервера (operational attribute). Operational attribute обычно используются для конфигурации и/или информации о состоянии.

Attribute options не используются так часто, но могут быть использованы для предоставления некоторых метаданных об атрибуте. Например, attribute options могут быть использованы для предоставления различных версий значения на разных языках.

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

Классы объектов

Классы объектов - это элементы схемы, которые определяют коллекции типов атрибутов, которые могут быть связаны с определенным типом объекта, процесса или другой сущности. Каждая запись имеет структурный класс объекта(structural object class), который указывает, какой тип объекта представляет запись (например, является ли это информацией о человеке, группе, устройстве, сервисе и т.д.), и может также иметь ноль или более вспомогательных классов объектов(auxiliary object classes), которые предлагают дополнительные характеристики для этой записи.

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

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

Идентификаторы Объектов (OIDs)

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

См. Пониманимаем схему LDAP для обсуждения использования OIDs в схеме. См. Справочник OID LDAP для списка некоторых OIDs, используемых в LDAP.

Фильтры поиска

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

  • Фильтры присутствия могут быть использованы для идентификации записей, в которых указанный атрибут имеет хотя бы одно значение.
  • Фильтры равенства могут быть использованы для идентификации записей, в которых указанный атрибут имеет определенное значение.
  • Фильтры подстроки могут быть использованы для идентификации записей, в которых указанный атрибут имеет хотя бы одно значение, которое соответствует заданной подстроке.
  • Фильтры больше-или-равно могут быть использованы для идентификации записей, в которых указанный атрибут имеет хотя бы одно значение, которое считается больше или равно заданному значению.
  • Фильтры меньше-или-равно могут быть использованы для идентификации записей, в которых указанный атрибут имеет хотя бы одно значение, которое считается меньше или равно заданному значению.
  • Фильтры приблизительного соответствия могут быть использованы для идентификации записей, в которых указанный атрибут имеет значение, которое приблизительно равно заданному значению. Обратите внимание, что нет официального определения «приблизительно равно», и поэтому это поведение может варьироваться от одного сервера к другому. Некоторые серверы используют алгоритм «звучит как» типа Soundex или Metaphone.
  • Фильтры расширяемого соответствия могут быть использованы для предоставления болееadvanced типов соответствия, включая использование пользовательских правил соответствия и/или атрибутов соответствия внутри DN записи.
  • Фильтры AND могут быть использованы для идентификации записей, которые соответствуют всем фильтрам, заключенным внутри AND.
  • Фильтры OR могут быть использованы для идентификации записей, которые соответствуют хотя бы одному из фильтров, заключенным внутри OR.
  • Фильтры NOT могут быть использованы для отрицания результата заключенного фильтра (т.е., если фильтр соответствует записи, то фильтр NOT, заключенный вокруг этого соответствующего фильтра, не будет соответствовать записи, и если фильтр не соответствует записи, то фильтр NOT, заключенный вокруг этого не соответствующего фильтра, будет соответствовать записи).

Логика, используемая для выполнения соответствия, заключена в правилах соответствия, которые указаны в определениях типов атрибутов. Различные правила соответствия могут использовать разную логику для принятия решений. Например, правило соответствия caseIgnoreMatch будет игнорировать различия в регистре при сравнении двух строк, в то время как правило соответствия caseExactMatch не будет. Многие правила соответствия специфичны для определенных типов данных (например, правило соответствия distinguishedNameMatch ожидает работать только с значениями, которые являются DN и могут игнорировать незначительные пробелы между компонентами DN и RDN, игнорировать различия в порядке элементов в многозначном RDN и т.д.).

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

Search Base DN и области поиска

Все запросы поиска включают элемент Search Base DN, который указывает на часть DIT, в которой следует искать соответствующие записи, и область, которая указывает, какая часть этого поддерева должна быть рассмотрена. Определены следующие области поиска:

  • Область baseObject (часто называемая просто «база») указывает, что только запись, указанная в базе DN поиска, должна быть рассмотрена.
  • Область singleLevel (часто называемая «один» или «одноуровневая») указывает, что только записи, непосредственно расположенные ниже базы DN поиска (но не сама базовая запись), должны быть рассмотрены.
  • Область wholeSubtree (часто называемая «под») указывает, что запись, указанная как база DN поиска, и все записи ниже нее (на любую глубину) должны быть рассмотрены.
  • Область subordinateSubtree указывает, что все записи ниже базы DN поиска (на любую глубину), но не сама базовая запись, должны быть рассмотрены.

См. страницу Операция поиска LDAP для получения дополнительной информации о компонентах и поведении операции поиска LDAP.

Модификации и Типы Модификаций

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

Определены следующие типы модификаций:

  • Тип модификации add указывает, что одно или несколько значений атрибута должны быть добавлены к записи. Это может быть использовано для добавления нового атрибута или для добавления новых значений к существующему атрибуту. Всегда необходимо указать хотя бы одно значение атрибута для типа модификации add.
  • Тип модификации delete указывает, что одно или несколько значений атрибута, или атрибут, должны быть удалены из записи. Если модификация delete включает одно или несколько значений атрибута, то будут удалены только эти значения.
    Если модификация delete не включает никаких значений, то будет удален сам атрибут.
  • Тип модификации replace указывает, что набор значений для указанного атрибута должен быть заменен новым набором (который может или не может включать значения, уже присутствующие в записи). Если модификация replace имеет одно или несколько значений атрибута, то эти значения будут использоваться для соответствующего атрибута. Если модификация replace не имеет никаких значений, то соответствующий атрибут будет удален из записи, если он существует.
  • Тип модификации increment указывает, что целочисленное значение для указанного атрибута должно быть увеличено на указанное значение (или уменьшено, если значение increment отрицательное).

См. страницу Модификации LDAP для получения дополнительной информации о компонентах и поведении операции модификации LDAP.

URL LDAP

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

См. страницу URL LDAP для получения дополнительной информации о содержимом и строковом представлении URL LDAP.

Controls

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

Управления LDAP имеют три элемента:

  • Идентификатор объекта (OID), который уникально идентифицирует тип управления. Это обязательный элемент.
  • Критичность. Это флаг, который указывает, как сервер должен davranяться, если он не распознает предоставленное управление запроса, или если он не может поддерживать управление в контексте, в котором оно было запрошено. Критичность "true" указывает, что управление является критической частью запроса, и что сервер должен отклонить запрос, если он не может поддерживать управление. Критичность "false" указывает, что управление является более "хорошим" элементом запроса, и что если сервер не может поддерживать управление, то он должен продолжать обрабатывать операцию, как если бы управление не было включено. Критичность не играет роли, если сервер поддерживает управление в контексте запроса.
  • Необязательное значение, которое может предоставить дополнительную информацию для использования при обработке управления. Например, для управления сортировки на стороне сервера значение управления должно указать желаемый порядок сортировки. Кодировка управления варьируется в зависимости от типа управления.

Referrals

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

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

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

Псевдонимные записи

Псевдонимная запись - это тип записи, которая указывает на другую запись в DIT, аналогично тому, как символическая ссылка указывает на другой файл в файловой системе.

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

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

Обратите внимание, что не все серверы каталогов поддерживают псевдонимы. Если приложение предназначено для совместимости с широким диапазоном серверов каталогов, оно должно поддерживать использования псевдонимов.