Что такое код ldap_read

Содержание

Аутентификация 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 .

Основы протокола LDAP: иерархия данных и компоненты записей

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

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

Что такое служба каталогов?

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

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

Что такое LDAP?

LDAP (или lightweight directory access protocol) – это протокол, который определяет методы, с помощью которых можно получить доступ к службе каталогов. В более широком смысле LDAP формирует способ отображения данных в службе каталогов для пользователей, определяет требования к компонентам, используемым для создания записей данных, и описывает способ использования разных примитивных элементов для составления записей.

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

Основные компоненты данных LDAP

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

Атрибуты

Сами данные в системе LDAP в основном хранятся в элементах, называемых атрибутами. Атрибуты – это в основном пары ключ-значение. В отличие от некоторых других систем, ключи – это предопределенные имена, которые продиктованы объектными классами записи (мы обсудим это немного позже). Кроме того, данные в атрибуте должны соответствовать типу, указанному в первоначальном определении атрибута.

Атрибут состоит из имени атрибута и значения, которые разделяются двоеточием и пробелом. Например, атрибут mail, который определяет адрес электронной почты, будет выглядеть так:

Когда речь идет об атрибуте и его данных, обе части соединяются знаком равенства:

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

Записи

Атрибуты сами по себе бессмысленны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP атрибуты находятся внутри записи. Запись представляет собой набор атрибутов под описательным именем.

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

Запись, отображаемая в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

dn: sn=Amber,ou=people,dc=8host,dc=com
objectclass: person
sn: Amber
cn: Justin Amber

Вышеприведенный пример может быть допустимой записью в системе LDAP.

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

Например, если возможно иметь записи для пользователя и для элемента инвентаря, как их отличить? Один из способов различать записи разных типов – это установить отношения и группы. Это по сути функция, где помещается запись при ее создании. Все записи добавляются в систему LDAP в виде веток в деревьях, называемых информационными деревьями каталога, или DIT.

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

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

В примере, приведенном в предыдущем разделе, мы видим один признак DIT в строке dn:

Эта строка называется различительным именем записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь назад к root DIT. В этом случае есть запись sn=Amber. Прямым родителем является запись по имени ou=people, которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи происходят из домена 8host.com, который функционирует как root DIT.

Компоненты данных LDAP

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

Определения атрибутов

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

Например, это определение атрибута name:

attributetype ( 2.5.4.41 NAME ‘name’ DESC ‘RFC4519: common supertype of name attributes’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 <32768>)

‘name’ – это имя атрибута. Число в первой строке – это глобальный уникальный идентификатор OID (Object ID), присвоенный атрибуту, чтобы отличать его от остальных атрибутов. Остальная часть записи определяет, как ее можно сравнивать во время поиска, и указывает, где найти информацию о типе данных атрибута.

Важной частью определения атрибута является то, может ли атрибут быть определен в записи более чем один раз. Например, фамилия может быть определена только один раз для каждой записи, но атрибут родства (например niece) может присутствовать в одной записи несколько раз. Атрибуты по умолчанию многозначны; если атрибут можно установить только один раз для каждой записи, он должен содержать флаг SINGLE-VALUE.

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

Определения ObjectClass

Атрибуты собираются внутри объектов, называемых objectClasses. ObjectClasses – это просто группы связанных атрибутов, которые были бы полезны при описании конкретной вещи. Например, «person» является objectClass.

Записи получают возможность использовать атрибуты objectClass, устанавливая специальный атрибут objectClass, который нужно использовать. Фактически, objectClass – единственный атрибут, который вы можете установить в записи без указания дополнительного objectClass.

Поэтому, если вы создаете запись для описания человека, в том числе objectClass person, вы можете использовать в нем все атрибуты:

dn: . . .
objectClass: person

Тогда у вас будет возможность установить эти атрибуты внутри записи:

  • cn: имя
  • description: удобочитаемое описание записи
  • seeAlso: ссылка на соответствующие записи
  • sn: фамилия
  • telephoneNumber: номер телефона
  • userPassword: пароль для пользователя

Атрибут objectClass можно использовать несколько раз, если вам нужны атрибуты из разных objectClasses, но есть правила, их использования.

Два основных типа ObjectClasses – это структурный и вспомогательный. Запись должна иметь ровно один структурный класс, но может иметь ноль или больше вспомогательных классов, используемых для расширения атрибутов класса. Структурный objectClass используется для создания и определения записи, в то время как вспомогательные objectClasses вносят дополнительную функциональность через новые атрибуты.

Определения ObjectClass указывают, требуются ли предлагаемые атрибуты (указывается спецификацией MUST) или их использовать необязательно (обозначается спецификацией MAY). Несколько objectClasses могут предоставлять одинаковые атрибуты, а атрибут MAY или MUST может отличаться.

Например, objectClass person определяется так:

objectclass ( 2.5.6.6 NAME ‘person’ DESC ‘RFC2256: a person’ SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Он определяется как структурный objectClass, что означает, что его можно использовать для создания записи. Созданная запись должна указывать атрибуты surname и commonname и может указывать атрибуты userPassword, telephoneNumber, seeAlso или description.

Схемы

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

Схемы часто включают дополнительные определения атрибутов и могут потребовать атрибуты, определенные в других схемах. Например, objectClass person, о котором мы говорили ранее, требует, чтобы атрибут surname или sn были установлены во всех записях, которые используют objectClass person. Если они не определены на LDAP-сервере, схема, содержащая эти определения, может использоваться для добавления этих определений в словарь.

Формат схемы в основном представляет собой комбинацию указанных выше записей, например:

. . .
objectclass ( 2.5.6.6 NAME ‘person’ DESC ‘RFC2256: a person’ SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
attributetype ( 2.5.4.4 NAME ( ‘sn’ ‘surname’ )
DESC ‘RFC2256: last (family) name(s) for which the entity is known by’ SUP name )
attributetype ( 2.5.4.4 NAME ( ‘cn’ ‘commonName’ )
DESC ‘RFC4519: common name(s) for which the entity is known by’ SUP name )
. . .

Организация данных

Мы рассмотрели общие элементы, которые используются для создания записей в системе LDAP, и узнали о том, как эти блоки определяются в системе. Теперь нужно посмотреть, как в LDAP DIT организована и структурирована информация.

Размещение записей в DIT

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

Вершина DIT – это самая широкая категория, которая так или иначе является родительской для всех узлов. Как правило, самая верхняя запись просто используется как метка, указывающая организацию, для которой используется DIT. Эти записи могут быть представлены любыми объектными классами, но обычно они создаются с помощью компонентов домена (dc=example,dc=com для example.com), расположения (l=new_york,c=us) или организационных сегментов (ou=marketing,o=Example_Co).

Записи организации (папки) часто используют организационный объект object >

Именование и ссылки на записи в DIT

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

Чтобы однозначно сослаться на запись, используйте RDN записи в сочетании со всеми RDN-элементами своих родительских записей. Эта цепочка RDN возвращает к вершине иерархии DIT и обеспечивает однозначный путь к рассматриваемой записи. Эта цепочка называется отличительным именем записи (или DN). DN для записи указывается во время создания, чтобы система LDAP знала, где разместить новую запись (тогда RDN записи не будет использоваться другой записью).

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

Например, запись для человека по имени John Smith может быть помещена под записью «People» для организации example.com. Поскольку в организации может быть несколько человек по имени John Smith, ID пользователя может быть лучшим выбором для RDN записи. Запись может быть указана следующим образом:

dn: u > objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

Здесь нужно использовать objectClass inetOrgPerson, чтобы получить доступ к атрибуту uid в этом экземпляре (у вас все еще есть доступ ко всем атрибутам, определенным в объекте personClass).

Наследование LDAP

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

Наследование objectClass

Каждый objectClass – это класс, который описывает характеристики объектов этого типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть и часто являются экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно, потому что концепция LDAP класса – это просто набор атрибутов, которые он должен или может иметь (MUST или MAY). Это позволяет указать для записи несколько классов (хотя может и должен присутствовать только один objectClass STRUCTURAL), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов с наивысшим объявлением MUST или MAY.

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

objectclass ( 2.5.6.7 NAME ‘organizationalPerson’ SUP person STRUCTURAL
. . .

Родительский objectClass следует за идентификатором SUP. Родитель должен использовать тип objectClass определяемого objectClass (например, STRUCTURAL или AUXILIARY). Дочерний objectClass автоматически наследует атрибуты и требования родительского.

При назначении objectClass нужно указать только конкретного потомка цепочки наследования, чтобы получить доступ ко всем атрибутам. В последнем разделе мы использовали это, чтобы указать inetOrgPerson как единственный objectClass для записи John Smith, все еще имея доступ к атрибутам, определенным в классах person и organizationPerson. Иерархия наследования inetOrgPerson выглядит следующим образом:

inetOrgPerson -> organizationalPerson -> person -> top

Почти все деревья наследования objectClass заканчиваются специальным objectClass под названием «top». Это абстрактный objectClass, единственная цель которого – потребовать, чтобы объект objectClass был установлен. Он используется для обозначения верхушки цепочки наследования.

Наследование атрибутов

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

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

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

Варианты протокола LDAP

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

Стоит отметить некоторые варианты LDAP в обычном формате:

  • ldap://: Это базовый протокол LDAP, который позволяет осуществлять структурированный доступ к службе каталогов.
  • ldaps://: Этот вариант используется для поддержки LDAP по протоколу SSL/TLS. Обычный LDAP-трафик не зашифрован, хотя большинство реализаций LDAP поддерживают его. Этот метод шифрования соединений LDAP фактически устарел, и вместо этого рекомендуется использовать шифрование STARTTLS. Если вы работаете с LDAP по небезопасной сети, настоятельно рекомендуется перестать это делать и настроить шифрование.
  • ldapi://: Поддержка LDAP на IPC. Это часто используется для безопасного соединения с локальной системой LDAP в административных целях. Он связывается с внутренними сокетами вместо открытого сетевого порта.

Все три формата используют протокол LDAP, но последние два указывают дополнительную информацию о том, как именно он используется.

Заключение

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

5.3 Объединённая служба каталога (LDAP)

Служба каталога (Directory Service) — это программный комплекс для хранения и каталогизации информации. По своей сути это очень похоже на обычную базу данных, но с «уклоном» скорее на чтение данных, нежели на их добавление или изменение. Обычно служба каталога базируется на клиент-серверной архитектуре. Одна из наиболее известных таких систем — DNS (Domain Name Service): DNS-сервер производит взаимную «трансляцию» имён машин и их IP-адресов. Другие машины в сети могут обращаться к такому серверу за информацией о соответствии имени и адреса. Однако это очень простой пример каталогизации информации. Объекты в такой базе имеют ограниченное количество атрибутов — таких как имя, адрес и ещё несколько дополнительных параметров.

Протокол LDAP (Lightweight Directory Access Protocol) позволяет реализовать доступ по TCP/IP к службе каталогов и может легко расширяться.

Существует несколько реализаций данного протокола от различных фирм. Наиболее известные из них — Netscape Directory Service™, Novell Directory Service™ и Microsoft Active Directory™. Из некоммерческих реализаций LDAP наибольшее распространение получил проект OpenLDAP. Именно его мы и будем рассматривать в дальнейшем, хотя большинство понятий и определений применимо и к другим реализациям сервера LDAP.

Основные термины

Данные каталога хранятся в виде объектов или сущностей (от англ. entry), состоящих из специальных полей, называемых атрибутами (attributes). Набор атрибутов, их синтаксис и правила поиска определяются схемой каталога (scheme). Все объекты каталога идентифицируются специальным атрибутом — DN (Distinguished Name).

Данные в каталоге можно представить в виде древовидной структуры — DIT (Directory Information Tree). Это очень похоже на структуру, используемую многими файловыми системами. Вершиной такого дерева является корневой объект (Root Entry). DN корневого объекта одновременно является суффиксом каталога.

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

Илон Маск рекомендует:  Примеры использования объектной модели в PHP. DOM

DN администратора каталога (Root Distinguished Name) — это специальный объект, описывающий администратора каталога. Этот объект указывается в конфигурации сервера, но может отсутствовать в самом каталоге. К такому объекту не применяются списки доступа (ACL). В некоторых реализациях LDAP такой объект может не иметь суффикса.

База поиска (Base Distinguished Name) — объект каталога, начиная с которого производится поиск. Дело в том, что не всегда есть необходимость производить поиск по всему дереву каталога; ограничить область поиска можно указанием в запросе базы поиска. По умолчанию этот параметр соответствует суффиксу.

Объекты и атрибуты

Серверы LDAP могут поставляться с несколькими вариантами бэкенда (backend). Например, OpenLDAP имеет такие варианты, как LDBM — собственный формат хранения данных в текстовых файлах; SHELL — интерфейс к базе данных, использующий команды UNIX; PASSWD — простейшая база, использующая стандартные файлы /etc/passwd и /etc/group; SQL — интерфейс к любой базе данных, использующей SQL.

Для процедур импорта и экспорта данных всеми серверами LDAP поддерживается единый формат обмена данными — LDIF. Вот пример такого файла с описанием двух объектов:

Описание каждого объекта в таком файле начинается с атрибута DN. Специальный атрибут objectClass указывает, к каким классам относится данный объект и, следовательно, какие атрибуты он может иметь. В нашем случае принадлежность к классу top означает, что объект обязательно должен иметь атрибут objectClass, а принадлежность к классу organization предполагает наличие нескольких атрибутов, из которых атрибут o является обязательным.

Второй объект находится на одну ступеньку ниже по иерархии и поэтому в его DN включён DN объекта верхнего уровня. Этот объект относится к классу organizationalUnit и поэтому имеет обязательный атрибут ou.

Можно заметить, что некоторые атрибуты (для которых это применимо) могут иметь несколько значений. В данном примере атрибут description имеет два значения. А вот для атрибута dn допустимо только одно значение.

Классы, характеризующие объекты, и атрибуты, составляющие классы, описываются схемой базы. Её пример приведён ниже.

В данном фрагменте приводятся описания двух атрибутов и одного класса. Вот что означают эти записи:

Атрибут o (его можно также называть organizationName) является расширением атрибута name.

Атрибут description — это строка длиной до 1024 байт; при поиске в ней регистр символов не учитывается.

Класс organization является расширением класса top и, следовательно, он включает в себя все атрибуты составляющие этот класс плюс дополнительные атрибуты такие как userPassword, businessAddress, street, postOfficeBox и т.д. Кроме того, атрибут o является обязательным.

Установка и настройка

Процесс сборки и установки сервера OpenLDAP не отличается от установки другого программного обеспечения, поставляемого в виде готового пакета.

Настройка сервера

Сервер LDAP состоит из двух серверных процессов: slapd и slurpd. Процесс slapd занимается приёмом и обработкой запросов от клиентов; это основной процесс, который непосредственно работает с базой данных. Сервис slurpd используется в тех случаях, когда данные нужно реплицировать на другие сервера — он контролирует изменения в базе и, при необходимости, пересылает их на подчинённые сервера.

Приведём пример конфигурационного файла:

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

LDAP можно использовать для централизованной авторизации пользователей сети вместо NIS+. В таких случаях из каталога может запрашиваться конфиденциальная информация — например, пароль. Для предотвращения перехвата этих данных желательно использовать протокол LDAPS (LDAP via SSL/TLS).

База данных ldbm

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

Корнем информационной структуры будет являться объект dc=example,dc=com. В принципе, суффикс для каталога можно взять любой, например, o=Example Inc.,c=RU — это не накладывает абсолютно никаких ограничений на функциональность. Однако последнее время всё чаще используется именно первый вид суффикса, который подчёркивает, что информационная структура данного предприятия тесно связана со структурой его домена.

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

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

Формат ldbm поддерживает простейшие индексы с целью ускорения операций поиска. Такие индексы желательно создавать по атрибутам, предполагающим наибольшее количество запросов. Последний параметр данной опции указывает по какому критерию создаётся индекс. Это могут быть pres, eq, approx, sub, none. (present, equality, approximate, substring, no index).

Данные каталога не всегда находятся в публичном доступе. Для управления доступом могут использоваться списки доступа (access lists). В данном примере приводятся два списка — в первом из них ограничивается доступ к атрибуту userPassword (полный доступ к нему могут иметь только сам объект либо администраторы базы; для всех остальных доступ запрещён). Второе правило гласит, что всем даётся доступ на чтение любых данных (кроме ограниченного предыдущим правилом).

После настройки можно сразу запустить процесс slapd — например, такой командой:

Первый объект, который нужно создать в базе — корневой элемент (root entry), который указан в конфигурационном файле как suffix.

Настройка репликации

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

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

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

Настройка клиента

Существует огромное количество клиентов, работающих с LDAP. Это могут быть почтовые программы, которые обращаются к каталогу в поисках адреса электронной почты сотрудника или за информацией о маршрутизации почты, FTP-сервер, который берет информацию для авторизации своего клиента и многие другие программы — однако все они имеют схожие настройки. Прежде всего это адрес сервера и порт, на котором работает LDAP (обычно это 389 или, если сервер поддерживает протокол LDAPS, — 636). Вторым важным параметром является база поиска (Base DN) — в большинстве случаев этот параметр соответствует суффиксу сервера, однако иногда имеет смысл сузить область поиска. Например, если мы ищем пользователя чтобы авторизовать его на почтовом сервере, то вряд ли его нужно искать среди групп пользователей или списка компьютеров локальной сети. Третий важный параметр — фильтр поиска, т.е. критерий по которому мы выбираем объект из базы. Кроме того, существуют параметры, позволяющие ограничить поиск снизу — например, только самой базой или базой и её подобъектами первого уровня, параметры управляющие поиском в алиасах (alias) и т.п.

Трёх этих параметров (сервер, база поиска и фильтр) в большинстве случаев достаточно, чтобы выполнить запрос к любому серверу LDAP. Однако, если на сервере существуют ограничения на доступ к данным, может потребоваться авторизация. Авторизоваться в LDAP можно, указав DN одного из объектов базы данных LDAP; пароль для такого объекта будет искаться в его атрибуте userPassword.

Ниже приводится фрагмент настройки почтового сервера Postfix:

В данном фрагменте описывается, что при определении адреса получателя делается запрос в LDAP с целью найти объект, которому это письмо адресовано. Поиск делается по атрибуту cn. Результат берётся из атрибутов mailLocalAddress и mailRoutingAddress. Эти классы и атрибуты описаны схемой misc.

Использование LDAP

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

После этого создадим пользователя ldap, от имени которого будет работать наш сервер и запустим процесс slapd следующей командой:

Теперь можно создать базу данных — например, с помощью утилиты ldapadd или slapadd:

Или, если сервер не запущен:

Содержимое файла initial.ldif будет такое:

Проверим, что сервер работает, сделав к нему анонимный запрос:

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

Если вы нашли ошибку, выделите текст и нажмите Ctrl+Enter.

Information Security Squad

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

Я не буду показывать, как устанавливать определенные пакеты, поскольку это зависит от дистрибутива / системы.

Я сосредоточусь на «чистой» конфигурации всех компонентов, необходимых для аутентификации / хранения пользователей в LDAP.

Предполагается, что вы переходите от обычной аутентификации passwd / shadow, но она также подходит для людей, которые делают это с нуля.

Требования

Введение

Мы хотим добиться того, чтобы наши пользователи сохранялись в LDAP, аутентифицировались через LDAP (direct или pam) и чтобы вы имели некоторый инструмент для управления этими всем понятным для человека способом.

Таким образом, мы можем использовать все программное обеспечение, поддерживающее LDAP, или возвратимся к модулю LDAP PAM, который будет действовать как шлюз PAM-> LDAP.

Более подробную информацию о идее LDAP можно найти в Википедии: LDAP wikipedia

Настройка OpenLDAP

OpenLDAP состоит из slapd и slurpd-демона.

Этот способ охватывает один сервер LDAP без репликации, поэтому мы сосредоточимся только на slapd.

Я также предполагаю, что вы установили и инициализировали установку OpenLDAP (в зависимости от системы / распространения).

Если да, перейдем к части конфигурации.

В моей системе (Gentoo) конфигурация OpenLDAP хранится в /etc/openldap, нас интересует файл /etc/openldap/slapd.conf.

Но сначала мы должны сгенерировать пароль для администратора LDAP, чтобы поместить его в файл конфигурации:

Конфигурация выглядит так:

Не забудьте изменить суффикс и пути.

Это варианты с некоторыми базовыми ACL, необходимыми для изменения паролей пользователем.

Если вам нужна дополнительная функциональность, прочитайте руководство по OpenLDAP.

Теперь, когда у нас есть надлежащая конфигурация для slapd, мы можем запустить демон:

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

Теперь мы можем проверить, работает ли openldap и работает ли он правильно.

У нас еще нет данных в каталоге, но мы можем попытаться связать их как cn = Manager, dc = domain, dc = com.

Когда вас попросят ввести пароль, вы должны использовать тот, который вы создали (конечно, его текстовая версия :):

Миграция / добавление данных в каталог

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

Я покажу вам, как переносить существующие записи из обычных /etc/ passwd, /etc/shadow, /etc/groups

Первый шаг — настроить mogrationtools.

Конфигурационный файл в Gentoo находится в /usr/share/migrationtools/migrate_common.ph.

Как правило, вам нужно изменить только эти моменты:

Теперь вы готовы перенести данные (на самом деле это работает даже без команды export):

Теперь у нас есть данные в формате, понятном серверу LDAP.

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

После этого мы можем добавить данные из ldifs.

Вы можете попробовать найти некоторые данные:

Конфигурация клиента

Под клиентом я имею в виду машину, которая подключается к LDAP-серверу для получения пользователей и авторизации.

Это может быть и машина, на которой работает LDAP-сервер.

В обоих случаях мы должны отредактировать три файла: /etc/ldap.conf, /etc/nsswitch.conf и /etc/pam.d/system-auth

Начнем с ldap.conf, клиента ldap:

Теперь пришло время для nsswitch.conf и pam

Добавьте в nsswitch.conf:

И измените system-auth (или все, что у вас есть, например login, sshd и т. д.):

Время проверить его. Лучший инструмент для этого — хороший старый getent.

Выберите пользователя из вашей системы и введите:

Вы должны получить результат дважды, если nss_ldap работает нормально.

По часть pam , работоспособность может быть протестирована путем удаления пользователя из /etc/passwd и попытки входа в систему через ssh.

Apache mod_auth_ldap

Чтобы получить авторизацию LDAP в apache, вам необходимо загрузить модуль mod_auth_ldap

Теперь достаточно изменить .htaccess:

Обратите внимание, что этот метод можно также использовать для авторизации Subversion WebDAV

Средства администрирования LDAP

Есть несколько инструментов, которые я рекомендую использовать для администрирования сервера OpenLDAP

Активируем LDAP over SSL (LDAPS) в Windows Server 2012 R2

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

Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.

Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.

В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).

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

Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.

На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage.

Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template.

На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory).

На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.

На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.

Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.

На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).

В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).

Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.

Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer

А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).

certmgr.exe -add C:\ca_name.cer -s -r localMachine ROOT

Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.

Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.

как прокомментировать php родные ldap fuctions, такие как lda_connect, ldap_get_entries, ldap_search и ldap_read

У меня есть класс ниже, чтобы подключиться к серверу ldap, чтобы проверить, принадлежит ли пользователь группе или нет. Я хочу написать unit тест для этого класса. как мне это достичь. как издеваться над собственными функциями ldap php. может кто-то, пожалуйста, помогите мне с немного пример кода.

Взгляните на uopz — этот пакет позволяет переопределить собственные функции в PHP.

Пример использования ниже (см. Документы в Github, поскольку есть изменения между PHP 5 и 7).

uopz-2.0.x

uopz-5.0.x

Примечание: будьте осторожны с той версией, которую вы устанавливаете. >=5.x поддерживает PHP 7.x и поддерживает PHP 5.3.x

Обычно вам не нужно издеваться над этими функциями. Издевательство над ними на самом деле означает, что вы будете имитировать поведение сервера, которое может быть громоздким. У вас может быть недостаток в вашей реализации, который не работает с конкретным сервером ldap (настройка) или у вас есть недостаток в использовании вашего класса LdapAuthentication.

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

Одна из стратегий для этого — тестирование интерфейса. У LdapAuthentication есть открытый интерфейс, который вы используете в своем приложении. Чтобы проверить правильность вашего интерфейса приложения с типом, вы должны издеваться над этим классом. Это будет охватывать публичный интерфейс.

С другой стороны, вы хотели бы проверить, работает ли аутентификатор с экземпляром сервера ldap. Для этого требуется набор test-, который предоставляет все функции, представляемые публичным интерфейсом, на конкретном сервере. Это эффективно проверяет интерфейс сервера. В Phpunit это могут быть два случая test-. Один для интерфейса открытого класса и один для тестирования интеграции для конфигурации (lnap-server) (test-).

Два интерфейса для тестирования:

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

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

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

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

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

Эта дополнительная работа заключается в извлечении интерфейса из LdapAuthentication. Извлечение интерфейса означает, что вы создаете интерфейс (см. PHP-интерфейсы) с тем же именем, который содержит те общедоступные методы, которые вы используете в своем приложении:

Теперь, поскольку вы не можете иметь интерфейсы и классы с одинаковым именем, вы переименуете свой класс LdapAuthentication в другое имя, реализующее интерфейс:

(Пожалуйста, обратите внимание, что имя просто образцовое, вы должны быть в состоянии лучше подойти)

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

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

Одна из таких новых реализаций, например, станет LdapAuthenticationMock:

Затем вы можете передать его в тестах, чтобы проверить код приложения без использования ldap-сервера или даже этого расширения ldap PHP. Благодаря интерфейсу PHP уведомит вас, если вы его не внедрили полностью.

Рядом с тестом mock (который работает больше, чем вы записываете, как вы ожидаете, что этот класс будет работать, часто тесты записывают спецификацию в кодовом порядке), вам также нужен интеграционный тест конкретной реализации, который у вас есть против Ldap (test-), FooLdapAuthenticationTest.

Написание этих тестов поможет вам написать аутентификацию Ldap в изолированных случаях test- без запуска всего вашего приложения. Затем приложение — благодаря программированию против интерфейсов — может быть записано без дополнительной информации о деталях реализации FooLdapAuthentication или любой другой LdapAuthentication.

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

Имея макет как конкретный класс PHP, также имеет то преимущество, что вам не нужно настраивать его интенсивно снова и снова для других тестов, которые должны взаимодействовать с LdapAuthentication, вы просто вводите этот макет.

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

Это один из способов преодоления проблем, которые создают интеграционные тесты:

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

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

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

/привет/мир/etc

Периодические заметки о программировании

четверг, 31 октября 2013 г.

Что такое LDAP и с чем его едят

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

Концепцию служб каталогов и требования к их реализации определяет серия стандартов X.500 ITU-T. Здесь каталог — это специализированная база данных, оптимизированная для поиска и извлечения информации, также поддерживающая добавление и изменение данных.

Среди реализаций служб каталогов наиболее известные — OpenLDAP и MS Active Directory. Клиентами каталогов являются адресные книги почтовых клиентов, сетевые службы, такие как DNS, SMTP, корпоративные приложения и информационные системы.

Как правило, служба каталогов

  • реализует протокол для взаимодействия с клиентами,
  • поддерживает разграничение доступа,
  • поддерживает репликацию каталогов,
  • не поддерживает механизм транзакций.

Для взаимодействия со службами каталогов X.500 широко используется протокол LDAP (Lightweight Directory Access Protocol), специфицированный в RFC4510. LDAP работает поверх TCP/IP и является легковесной альтернативой протокола DAP (Directory Access Protocol), весьма требовательного к вычислительным ресурсам.

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

  • В каталоге хранятся записи (entry).
  • Запись — это коллекция атрибутов (attribute), имеющая уникальное имя (Distinguished Name, DN).
  • Каждый атрибут имеет тип (type) и одно или несколько значений. Синтаксис значений зависит от типа.
  • Атрибут objectClass позволяет контролировать, какие атрибуты обязательны и какие допустимы в записи. Таким образом, записи, как и атрибуты, имеют тип (object class).
  • Записи в каталоге организованы иерархически в виде дерева.
  • Определения типов записей (object classes) и типов атрибутов сами являются записями в каталоге, в специальном поддереве, известном как schema.

Запустим Softerra LDAP Browser и откроем одну из публичных служб каталогов, параметры соединения с которыми предустановлены по умолчанию. (Настроив соединение с MS Active Directory или OpenLDAP в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)

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

Текущая выбранная запись в каталоге Carnegie Mellon University (см. картинку выше) имеет уникальное имя DN o=CMRI,o=CMU,dc=cmu,dc=edu . Компоненты DN — имена узлов иерархической структуры от корневого до текущего (справа налево). Самый левый компонент DN называется относительным уникальным именем (Relative Distinguished Name, RDN). Таким образом, DN o=CMRI,o=CMU,dc=cmu,dc=edu состоит из RDN o=CMRI и DN родительской записи o=CMU,dc=cmu,dc=edu .

Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).

В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:

dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit

Эти имена, как и десятки других, — имена стандартных атрибутов, специфицированных в RFC 2256 и предназначенных для использования в объектных классах, описывающих людей, организации, их подразделения и т.п. Все реализациии LDAP поддерживают эти стандартные типы атрибутов. Вот еще несколько примеров: telephoneNumber , name , givenName , postalAddress , sn (аббревиатура от surname).

В рассматриваемой записи с DN o=CMRI,o=CMU,dc=cmu,dc=edu имеются три атрибута, objectClass , o и businessCategory , по каждому из которых можно искать эту запись в каталоге.

Для поиска записей в LDAP-каталоге задаются три компонента:

base DN (базовое уникальное имя) показывает, откуда в иерархии начать поиск scope (область поиска) показывает область поиска, одно из:

  • одна запись, идентифицированная base DN
  • записи уровнем ниже base DN, т.е. дочерние, но не внучатые
  • поддерево с корнем base DN, включая корень

filter (фильтр) задает условие отбора записей

Например, поиск по условию

вернет все записи из поддерева с корнем o=CMU,dc=cmu,dc=edu , удовлетворяющие фильтру (синтаксис фильтра в этом примере легко читаемый, но неправильный, см. далее).

На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.

В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:

В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):

Заметьте, что отсутствуют проверки > и . Проверка на приближенное равенство

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

Проверки в фильтре можно комбинировать при помощи логических операторов:

Внимание! Последний фильтр с NOT вернет также записи, не содержащие атрибута cn .

Формируя запрос, можно указать типы атрибутов, которые должны быть включены сервером каталога в ответ. Если список типов атрибутов пуст, то окно поиска LDAP Browser отображает идентифицирующие атрибуты найденных записей (это RDN) и DN родительских записей — вместе они образуют DN найденных записей. Поиск LDAP всегда возвращает DN найденных записей, помимо и независимо от списка атрибутов. Зададим явно список атрибутов, которые мы хотим видеть и повторим запрос (несуществующие типы атрибутов в списке игнорируются сервером и не приводят к ошибке):

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

Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).

Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.

4.5.19 Протокол LDAP (Lightweight Directory Access Protocol)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

1. Введение

LDAP (Lightweight Directory Access Protocol) представляет собой Интернет-протокол доступа к распределенным службам каталогов, которые организованы в соответствии со стандартом X.500 (1993г). Допускаются и другие модели реализации службы каталогов (например, X.511). Каталог представляет собой «собрание открытых систем, взаимодействующих друг с другом для предоставления службы каталогов» [X.500]. Пользователь каталога, который может быть человеком или другим каким-то объектом, получает доступ к каталогу (Directory) через посредство клиента или DUA (Directory User Agent). Клиент взаимодействует с одним или более серверов или DSA (Directory System Agents). Клиенты взаимодействуют с серверами, используя протокол доступа к каталогу. Слово каталог (directory) используется здесь в значении упорядоченной структуры записей: например, телефонный каталог (справочник) представляет собой алфавитно упорядоченный список людей с их адресами и номерами телефонов в каждой из записей. Доступ к каталогам возможен по каналам TCP/IP через порт 389. Каталог представляет собой дерево каталожных записей (entries). Запись для каталога, то же самое что и запись или строка в случае базы данных. Каждая запись состоит из набора атрибутов. Атрибут имеет имя (тип атрибута или описание атрибута) и одно или более значений. Содержимое записей в субдереве управляется схемой, известной под именем DIT (Directory Information Tree). Атрибуты определяются в рамках этой схемы. Атрибут для каталога, тоже самое, что поле для базы данных. LDAP предоставляет стандартный язык, с помощью которого приложение клиента и каталог сервера взаимодействуют друг с другом по поводу данных в каталоге. LDAP-каталоги отличаются от реляционных баз данных. Данные в этом случае имеют иерархическую древовидную структуру, подобную большинству файловых систем.

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

  • Синтаксис атрибута предоставляет информацию о типе информации, которая может быть записана в атрибуте.
  • Правила соответствия предоставляют информацию о том, как можно осуществлять сравнения значений атрибутов.
  • Использование правил соответствия указывает, какие типы атрибутов могут быть применены совместно с определенным правилом проверки соответствия.
  • Тип атрибута определяет OID и набор имен, который можно использовать при ссылке на данный атрибут, и ассоциировать этот атрибут с синтаксисом и набором правил соответствия.
  • Классы объекта определяют именованные группы атрибутов и разбивают их на наборы необходимых и опционных атрибутов.
  • Формы имен определяют правила для набора атрибутов, которые нужно включить в RDN записи.
  • Правила содержимого определяют дополнительные ограничения для классов объектов и атрибутов, которые могут использоваться совместно с записями.
  • Структурное правило определяет правила, которые управляют видами соподчиненных записей, которые данная запись может иметь.
Илон Маск рекомендует:  Что такое код dup

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

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

Схема определяет классы объектов. Каждая запись должна иметь атрибут objectClass, содержащий именованные классы, определенные в схеме. Схемное определение классов записи определяет, какой вид объекта может представлять запись — например, персону, организацию или домен. Определения классов объектов определяет также список атрибутов, которые должны содержать значения и список атрибутов, которые могут содержать значения.

Например, запись, представляющая человека, может принадлежать классам «top» и «person». Членство в классе «person» требует от записи наличия атрибутов «sn» и «cn», и позволяет также записи содержать «userPassword», «telephoneNumber», и другие атрибуты. Так как записи могут иметь несколько значений ObjectClasses, каждая запись имеет совокупность опционных и обязательных наборов атрибутов, образованных путем объединения классов объекта, который они представляют. ObjectClasses может наследоваться, и одиночная запись может иметь несколько значений ObjectClasses, которые определяют доступные и необходимые атрибуты самой записи. Параллельно со схемой objectClass является определением класса и частным примером объектно-ориентированного программирования представляющего LDAP objectClass и LDAP-запись, соответственно.

Серверы каталогов могут опубликовать схему каталога, управляющую записью на уровне базового DN (Distinguished Name). DN так называется, из-за того что делает запись отличной от всех прочих записей. задаваемого операционным атрибутом subschemaSubentry. (Операционный атрибут описывает операцию каталога, а не пользовательскую информацию, и только он присылается при поиске, когда это явно запрошено).

Сервер LDAP может прислать ссылки на другие серверы для запросов, которые не может обслужить сам. Это требует именованной структуры LDAP-записей, так что можно найти сервер, хранящий данное DN. Другим способом локализации LDAP-серверов для организации является ресурсная запись DNS-сервера (SRV).

Организация с доменом example.org может использовать верхний уровень LDAP DN dc=example,dc=org (где dc означает компонент домена). Если LDAP-сервер имеет также имя ldap.example.org, верхним уровнем LDAP URL организации становится ldap://ldap.example.org/dc=example,dc=org.

Первоначально используются два стиля именования, как в X.500 [2008], так и в and LDAPv3, которые документированы в спецификациях ITU и IETF RFC. Исходная форма использует такие объекты верхнего уровня, как страны, например, c=US, c=FR. Модель доменных компонентов использует структуру, описанную выше. Примером именования с использованием национальной принадлежности может быть c=FR, o=некоторая организация, ou=некоторая организационная единица, L=Locality, или в США: c=US, st=CA, o=некоторая организация, ou=организационная единица, L=Locality и CN=общее имя (Common Name).

Смотри также LDAP Tutorial. Brad Marshall (добротное описание применения технологии LDAP) и LDAPSEARCH (руководство по использованию операций поиска в LDAP); LDAP Theory and Management. Brad Marshall.; LDAP Servers and Applications. Brad Marshall.

Каждая запись имеет уникальный идентификатор: его DN. Оно состоит из его RDN (Relative Distinguished Name), сформированного из некоторых атрибутов в виде массива, за которым следует DN родительской записи. DN следует рассматривать в качестве полного прохода к файлу, а RDN — относительный (напр. если C:\foo\bar\myfile.txt, является DN, тогда myfile.txt является RDN). LDAP представляет собой двоичный протокол.

Запись может выглядеть следующим образом (формат обмена данных LDAP = LDIF):

Команда для поиска данных при условии dc=example,dc=com для имени Yuri Semenov выглядит как:

$ ldapsearch -b dc=example,dc=com «(cn=Yuri Semenov)».

Если все работает, как положено, поиск выдаст следующий результат.

«dn» уникальное имя записи; это не атрибут и не часть записи. «cn=John Doe» является RDN записи, а «dc=example,dc=com» представляет собой DN родительской записи, где «dc» обозначает ‘Domain Component’. В других строках представлены атрибуты записи. Имена атрибутов обычно являются мнемоническими строками, например, «cn» common name (общее имя), «dc» — domain component (компонент домена), «mail» — e-mail адрес и «sn» — фамилия (surname). Иерархия имен-идентификаторов показана на рис. 1.

Рис. 1. Иерархия имен-идентификаторов в LDAP

Сервер хранит субдерево, которое начинается со специфической записи, напр. «dc=example,dc=com» и ее дочерние записи. Серверы могут также хранить ссылки на другие серверы, так что попытка получить доступ к «ou=department,dc=example,dc=com» может привести к получению ссылки на сервер, который содержит нужную часть дерева каталога. Клиент может тогда контактировать с другим сервером. Некоторые серверы могут поддерживать цепочные процедуры, когда сервер контактирует с другим сервером и присылает полученные там данные клиенту.

Ниже рассматривается версия 3 протокола LDAP (LDAPv3 — 1997г)). Описание протокола содержится в следующих документах:

  1. Вводное описание [RFC-4510]
  2. Протокол [RFC-4511]
  3. Информационные модели каталога [RFC-4512]
  4. Методы аутентификации и механизмы безопасности [RFC-4513]
  5. Представление строк выделенных имен [RFC-4514]
  6. Представление строк поисковых фильтров [RFC-4515]
  7. Универсальный ресурсный локатор (URL) [RFC-4516]
  8. Синтаксис и правила соответствия [RFC-4517]
  9. Интернационализированная подготовка строк [RFC-4518]
  10. Схема приложения пользователя [RFC-4519]

Данное описание является развитием ранее принятых норм каталожных сервисов, например RFC-3377, RFC-2830 или RFC-2251, которые считаются устаревшими. Далее следует перевод документа RFC-4511, за исключением приложения С в силу его ненормативности.

2. Соглашения

Названия символов в данном документе представляются в формате Unicode. Например, буква «a» представляется в виде или .

Термин «транспортное соединение» относится нижележащим сервисам, обеспечивающим протокольный обмен.

Термин «уровень TLS» относится к сервисам безопасного транспортного уровня (TLS), используемым для реализации безопасности протокола.

Термин «уровень SASL» относится к уровню сервисов безопасности и аутентификации SASL, используемым для реализации безопасности протокола.

Термин «уровень сообщений LDAP» относится к сервисам протокола сообщений LDAP, обеспечивающим сервисы каталогов.

Термин «сессия LDAP» относится к комбинации сервисов (транспортное соединение, уровень TLS, уровень SASL, уровень сообщений LDAP).

3. Модель протокола

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

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

Хотя серверы должны присылать отклики, всякий раз, когда такие отклики определяются в протоколе, не задается никаких требований синхронизации клиентов или серверов. Запросы и отклики при нескольких операциях между клиентом и сервером могут следовать в любом порядке. Если необходимо, синхронность поведения может контролироваться приложениями клиента. Базовые протокольные операции, рассмотренные в данном документе, могут быть поставлены в соответствие субнабору операций X.500.

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

3.1. Взаимоотношение операций и уровня сообщений LDAP

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

4. Элементы протокола

Протокол описан с использованием стандарта ASN.1 (Abstract Syntax Notation One) и базовых правил кодирования ([BER]).

В протоколе с самого начала предусмотрены механизмы будущих расширений.

Клиенты могут пытаться определить, какую протокольную версию поддерживает сервер, считывая атрибут ‘supportedLDAPVersion’ с корневой DSE (Distinguished Service Entry) [RFC4512].

4.1. Общие элементы

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

4.1.1. Конверт сообщения

Для целей протокольных обменов все протокольные операции вкладываются в общий конверт LDAPMessage, который определен следующим образом:

Функцией LDAPMessage является предоставление конверта, который содержит общие поля, необходимые для всех протокольных обменов. На данный момент единственными общими полями являются messageID и субполя управления.

Если сервер получает от клиента LDAPMessage, в котором метка последовательности LDAPMessage не может быть распознана, то messageID не может быть проанализирован, если метка protocolOp не воспринимается как запрос, или структура кодирования или длины полей данных не корректны, сервер должен прислать в ответ сообщения Notice или Disconnection рассмотренные в разделе 4.4.1, при этом resultCode должен быть равен protocolError, а сессия LDAP должна быть немедленно прервана.

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

4.1.1.1. MessageID

Все конверты LDAPMessage откликов, содержат значение messageID, соответствующее LDAPMessage запроса.

МessageID запроса должен иметь ненулевое значение, отличное от messageID любого другого активного запроса в рамках текущей сессии LDAP. Нулевое значение зарезервировано для сообщений уведомления.

Клиент обычно инкрементирует счетчик при возникновении любого запроса.

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

4.1.2. Типы строк

LDAPString является удобным обозначением того, что строка LDAPString-типа представлена в виде строки октетов ASN.1 символьного набора [ISO10646] (используется супернабор [Unicode] с кодировкой согласно алгоритма UTF-8 [RFC3629]). Заметим, что уникодные символы с U+0000 по U+007F совпадают с символами ASCII с 0 по 127, соответственно, и имеют идентичное октетное представление UTF-8. Другие уникодные символы имеют многооктетное представление UTF-8.

LDAPOID является удобным обозначением того, что разрешенным значением этой строки является (UTF-8 кодированное) десятично-точечное представление идентификатора объекта. Хотя LDAPOID кодируется как строка октетов, допустимыми значениями являются , описанные в разделе 1.4 [RFC4512].

4.1.3. Уникальные и относительно уникальные имена

LDAPDN определено как уникальное имя DN (Distinguished Name), закодированное согласно спецификации [RFC4514].

RelativeLDAPDN определено как относительно уникальное имя RDN (Relative Distinguished Name), закодированное согласно спецификации [RFC4514] .

4.1.4. Описание атрибутов

Определение и правила кодирования атрибута описаны в разделе 2.5 [RFC4512]. Коротко, описание атрибута представляет собой тип атрибута и нуль или более опций.

4.1.5. Значение атрибута

Поле типа AttributeValue является строкой октетов, содержащей значение атрибута. Значение атрибута кодируется согласно специфическому определению LDAP. Описание кодирования LDAP для различных синтаксисов и типов атрибутов содержится в [RFC4517].

AttributeValue ::= OCTET STRING

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

Значения атрибутов могут иметь произвольный и непечатный синтаксис. Конкретные реализации не должны отображать или пытаться декодировать значение атрибута, если его синтаксис неизвестен. Реализация может попытаться выявить субсхему объекта и получить описание ‘attributeTypes’ из [RFC4512].

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

4.1.6. Присвоение значения атрибуту

Определение типа AttributeValueAssertion (AVA) выполняется в соответствии со стандартами X.500. Оно содержит описание атрибута и правило соответствия ([RFC4512], раздел 4.1.3) при присвоении значения согласно его типу.

Синтаксис AssertionValue зависит от контекста выполняемой операции LDAP. Например, синтаксис правила соответствия EQUALITY для атрибута используется, когда выполняется операция Compare. Часто это тот же самый синтаксис, который используется для значений типов атрибутов, но в некоторых случаях синтаксис присвоения отличается от синтаксиса значений. Смотри, например, objectIdentiferFirstComponentMatch в [RFC4517].

4.1.7. Атрибут и PartialAttribute

Атрибуты и частичные атрибуты состоят из описаний атрибутов и их значений. Для PartialAttribute допустимо отсутствие значений, в то время как атрибуты требуют, по крайней мере, одного значения.

В соответствии с описанием раздела 2.2 [RFC4512] никакие два значения атрибута не могут быть эквивалентны.

4.1.8. Идентификатор правила соответствия

Правила соответствия описаны в разделе 4.1.3 [RFC4512]. Правила соответствия задаются в протоколе посредством печатного представления либо его , либо одного его дескриптора короткого имени [RFC4512], напр., ‘caseIgnoreMatch’ или ‘2.5.13.2’.

4.1.9. Сообщение результата

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

Нумерация resultCode является гибкой, как это определено в разделе 3.8 [RFC4520]. Сообщения, соответствующие кодам результата, приведены в приложении A. Если сервер детектирует несколько ошибок для одной операции, возвращается только один результат. Сервер должен вернуть результирующий код, который наилучшим образом характеризует природу встретившейся ошибки.

Поле diagnosticMessage этого структурного элемента может, по выбору сервера, использоваться для возврата строки, содержащей текстовое, читаемое человеком диагностическое сообщение, которое дает данные, разъясняющие значение resultCode. Если сервер решит не использовать текстовое сообщение, diagnosticMessage должно быть пустым.

Для определенных кодов результата (обычно, но необязательно noSuchObject, aliasProblem, invalidDNSyntax и aliasDereferencingProblem), поле matchedDN делается равным (субъект управления доступом) имени последней записи (объекта или псевдонима). Это имя используется для выявления адресуемого объекта.

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

4.1.10. Ссылки (referrals)

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

  • Адресат запроса не является локальным, но сервер знает о его возможном существовании где-то.
  • Операция запрещена на данном сервере — возможно из-за режима только для чтения данных, которые потребуется модифицировать.

Поле referral присутствует в LDAPResult, если код результата (resultCode) равен referral, и он отсутствует во всех остальных кодах результата.

Ссылки-Referrals в LDAP

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

Во время операции поиска (Search), после того как baseObject найден, а входные данные определены, отклик referral не возвращается. Вместо этого, присылаются ссылки продолжения, если для завершения операции нужно контактировать с другими серверами (см. раздел 4.5.3).

Если клиент хочет продолжить операцию, он контактирует с одним серверов, обнаруженных в ссылке (referral). Если присутствует несколько URI, клиент полагает, что для продолжения операции может использоваться любой поддерживаемый URI. Клиенты, которые следуют ссылкам referrals должны гарантировать, что они не сформируют цикл для серверов. Они не должны повторно контактировать с одним и тем же сервером при одном и том же запросе с одними и теми же параметрами. Некоторые клиенты используют счетчик, который инкрементируется каждый раз при использовании referral для каждой из операций, эти типы клиентов должны быть способны при выполнении операции работать, по крайней мере, с десятью вложенными ссылками.

URI для сервера, реализующий LDAP и доступный через TCP/IP (v4 или v6) [RFC793][RFC791], записывается как LDAP URL согласно [RFC4516].

Значения Referral, которые являются LDAP URLs следуют правилам:

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

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

Символы, закодированные в UTF-8, присутствующие в строке DN, поисковом фильтре или других полях значения referral, могут быть нелегальными для URI (напр., пробелы) и должны исключаться путем использования %-представления, описанного в [RFC3986].

4.1.11. Контроли

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

Контроли, посылаемые клиентом, называются контролями запроса, а посланные сервером — контролями отклика.

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

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

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

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

Серверы предоставляют список контролей запросов controlType, которые они распознают, в атрибуте ‘supportedControl’ в корневом DSE (раздел 5.1 [RFC4512]).

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

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

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

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

4.2. Операция Bind

Функцией операции Bind является разрешение обмена аутентификационной информацией между клиентом и сервером. Операция Bind должна восприниматься как операция аутентификации. Семантика аутенификации и безопасности этой операции представлена в [RFC4513].

Запрос Bind определен следующим образом:

Полями BindRequest являются:

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

Клиент устанавливает это поле равным желательной версии протокола. Если сервер не поддерживает специфицированную версию, он должен послать отклик BindResponse, где в resultCode записывается protocolError.

  • имя: если поле не пусто, имя объекта Directory, с которым клиент хочет взаимодействовать. Это поле может принимать нулевое значение (строка нулевой длины) для целей анонимных соединений ([RFC4513], раздел 5.1) или при использовании SASL [RFC4422] аутентификации ([RFC4513], раздел 5.2). Когда сервер пытается локализовать именованный объект, он не должен выполнять разыменование псевдонима.
  • аутентификация: Информация, используемая при аутентификации. Этот тип является расширяемым, как это определено в разделе 3.7 [RFC4520]. Серверы, которые не поддерживают выбора, предоставляемого клиентом, возвращают BindResponse с кодом resultCode равным authMethodNotSupported.
  • Текстовые пароли (состоящие из символов определенного символьного набора и кодировки) передаваемые серверу с использованием простого AuthenticationChoice должны передаваться в виде UTF-8 [RFC3629] [Unicode]. Перед передачей клиенты должны подготовить текстовый пароль в виде строк запроса с привлечением профайла SASLprep [RFC4013] алгоритма [RFC3454]. Пароли, содержащие другие данные (такие как произвольные октеты) не должны модифицироваться. Определение того, является ли пароль текстовым, решается клиентом локально.

    4.2.1. Обработка запроса Bind

    Перед обработкой BindRequest, все незавершенные операции должны быть либо завершены, либо прерваны. Сервер может либо ждать завершения операций, либо прервать их. Сервер затем продолжает аутентифицировать клиента в одношаговом или многошаговом процессе Bind. Каждый шаг требует от сервера посылки BindResponse, чтобы отразить состояние аутентификации.

    После посылки BindRequest, клиенты не должны посылать новые LDAP PDU до тех пор пока не получат BindResponse. Аналогично, серверы не должны обрабатывать или реагировать на запросы в ходе обработки BindRequest.

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

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

    Для некоторых механизмов аутентификации SASL, может быть необходимо для клиента отправить BindRequest несколько раз ([RFC4513], раздел 5.2). Клиенты не должны запускать операции между двумя Bind-запросами, выполненными как часть многошагового Bind.

    Клиент может абортировать согласование SASL-соединения путем посылки BindRequest с другим значением поля механизма SaslCredentials, или AuthenticationChoice.

    Если клиент посылает BindRequest со значением поля sasl-мехнизм равным пустой строке, сервер должен прислать BindResponse со значением resultCode равным authMethodNotSupported. Это позволит клиенту абортировать согласование, если он хочет попытаться снова запустить тот же механизм SASL.

    4.2.2. Отклик Bind

    Отклик Bind определен следующим образом.

    BindResponse представляет собой индикацию сервером состояния запроса аутентификации клиента.

    Успешная операция Bind индицируется откликом BindResponse с результирующим кодом resultCode, указывающим на успех. В противном случае соответствующий код результата устанавливается в BindResponse. Для BindResponse, может использоваться код результата protocolError, чтобы индицировать, что номер версии, использованный клиентом, не поддерживается.

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

    Поле ServerSaslCreds используется в качестве части механизма SASL bind, чтобы позволить клиенту аутентифицировать сервер, с которым он обменивается данными, или выполнить аутентификацию по схеме «запрос-отклик». Если клиент реализует соединение с простым выбором, или серверу не нужен механизм SASL для отправки данных клиенту, тогда это поле не следует включать в BindResponse.

    4.3. Операция Unbind

    Функцией операции Unbind является завершение сессии LDAP.

    Операция Unbind не является противоположностью операции Bind, как это может показаться из названия. Названия этих операций являются историческими.

    Операция Unbind следовало бы назвать «завершить» («quit»).

    Операция Unbind определена как:

    UnbindRequest ::= [APPLICATION 2] NULL

    Клиент, после передачи UnbindRequest, и сервер после получения UnbindRequest, должны корректным образом прервать сессию LDAP, как это описано в разделе 5.3.

    Незавершенные операции обрабатываются согласно спецификации раздела 3.1.

    4.4. Незапрошенное уведомление

    Незапрошенное уведомление представляет собой LDAPMessage, посланное сервером клиенту, которое не является откликом на какое-либо сообщение LDAPMessage, полученное сервером.

    Эта операция используется для уведомления об экстраординарной ситуации в сервере или в ходе LDAP-сессии между клиентом и сервером.

    Уведомление является по своей природе рекомендательным, и сервер не ожидает какой-либо реакции со стороны клиента.

    Незапрошенное уведомление структурировано как LDAPMessage, в котором messageID равен нулю а протокольная операция соответствует выбору extendedResp, использующему тип ExtendedResponse (смотри раздел 4.12).

    Поле responseName ExtendedResponse всегда содержит LDAPOID, который уникален для этого уведомления.

    Одно незапрашиваемое уведомление (уведомление разъединения) описано в данном документе. Спецификация незатребованного уведомления состоит из:

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

    4.4.1. Уведомление о разъединении

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

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

    Заметим, что эта нотификация не является откликом на Unbind, запрошенный клиентом. Незавершенные операции обрабатываются в соответствии со спецификацией из раздела 3.1.

    responseName имеет идентификатор 1.3.6.1.4.1.1466.20036, поле responseValue отсутствуетt, а resultCode используется для индикации причины разъединения.

    Когда strongerAuthRequired возвращает resultCode с таким сообщением, это указывает, что сервер детектировал проблему с ассоциацией безопасности системы клиент-сервер.

    После передачи сообщения Notice of Disconnection (нотификация разрыва связи), сервер завершает LDAP-сессию, как это описано в разделе 5.3.

    4.5. Операция поиска

    Операция Search используется для запроса сервера прислать набор объектов, отвечающих набору критериев поиска с учетом контроля доступа.

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

    4.5.1. Запрос поиска

    Запрос поиска определен следующим образом:

    Заметим, что операция списочного типа X.500 может быть эмулирована операцией поиска singleLevel с фильтром, проверяющим присутствие атрибута ‘objectClass’, а операция типа чтения может быть эмулирована операцией поиска baseObject с тем же фильтром. Серверу, который реализует шлюз к X.500, не обязательно использовать операции Read или List.

    4.5.1.1. Базовый объект SearchRequest

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

    4.5.1.2. Зона SearchRequest

    Специфицирует зону поиска. Семантика (как это описано в [X.511]) определенных значений этого поля выглядит следующим образом:

    baseObject: Зона ограничена содержимым baseObject.

    singleLevel: Зона ограничена непосредственно подчиненным объектом, на который указывает baseObject.

    wholeSubtree: Зона ограничена объектом, указанным в baseObject и всеми его подчиненными объектами.

    4.5.1.3. SearchRequest.derefAliases

    Индикатор того, был ли псевдоним объекта (как это определено в [RFC4512]) разыменован на фазе операции Search.

    Разыменование псевдонима включает в себя рекурсивную процедуру разыменования псевдонимов, которые ссылаются на псевдонимы.

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

    Семантика определенных значений этого поля имеет вид:

    neverDerefAliases: Не разыменовывать псевдонимы при поиске или при локализации базового объекта поиска.
    derefInSearching: При поиске подчиненных объектов базового объекта, разыменовывать любые псевдонимы в пределах зоны поиска. Разыменованные объекты становятся вершинами последующих зон поиска, где также реализуется операция Search. Если зона поиска соответствует wholeSubtree, поиск продолжается в субдереве любого разыменованного объекта. Если зона поиска имеет singleLevel, поиск происходит во всех разыменованных объектах, но не касается их соподчиненных объектов.

    Серверы должны исключать дублирующие объекты, которые возникают из-за разыменования при поиске.

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

    Разыменовывать псевдонимы, как при поиске, так и при локализации базового объекта поиска.

    4.5.1.4. Предельный размер SearchRequest

    Предельный размер, который ограничивает максимальное число объектов, возвращаемых в результате поиска. Значение нуль в поле указывает, что не существует какого-либо ограничения на число объектов при поиске со стороны клиента. Серверы могут также ввести ограничение на число возвращаемых объектов.

    4.5.1.5. SearchRequest.timeLimit

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

    4.5.1.6. SearchRequest.typesOnly

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

    4.5.1.7. Фильтр SearchRequest

    Фильтр, который определяет условия, которые должны быть выполнены при поиске для данного объекта.

    При формировании фильтров могут использоваться операторы ‘and’, ‘or’ и ‘not’. При использовании операторов ‘and’ или ‘or’ должен присутствовать, по крайней мере, один фильтрующий элемент.

    Сервер должен оценивать фильтры согласно трехзначной логики [X.511] — «TRUE», «FALSE» или «Undefined».

    Если фильтр получил TRUE для конкретного объекта, тогда атрибуты этого объекта посылаются в качестве результата поиска.

    Если фильтр получил FALSE или Undefined, тогда объект при поиске игнорируется.

    Значение фильтра для случая оператора «and» равно TRUE, если все фильтры набора выдали результат TRUE, и FALSE, если, по крайней мере, один фильтр выдал результат FALSE, в противном случае будет получен результат Undefined. Значение фильтра для случая оператора «or» равно FALSE, если все фильтры набора выдали результат FALSE, и TRUE, если хотя бы один фильтр выдал результат TRUE, в противном случае получается результат Undefined. Значение фильтра для случая оператора ‘not’ равно TRUE, если фильтр выдает результат FALSE.

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

    • Описание атрибута в фильтрах equalityMatch, greaterOrEqual, lessOrEqual, approxMatch или extensibleMatch не распознается сервером.
    • Тип атрибута не определяет приемлемое правило соответствия.
    • MatchingRuleId в extensibleMatch не распознано сервером или некорректно для данного типа атрибута.
    • Запрошенный тип фильтрации не применим.
    • Значение некорректно.

    Например, если сервер не распознает тип атрибута shoeSize, abkmnhs (shoeSize=*), (shoeSize=12), (shoeSize>=12), и (shoeSize [RFC4512]). Сервер не должен использовать короткое имя, если это имя известно серверу как неопределенное, или если это может вызвать проблемы совместимости.

    4.5.3. Ссылки продолжения в результате поиска

    Если клиент был способен локализовать запись, на которую ссылается baseObject, но не смог или не захотел ее искать или записи не являются локальными, сервер может вернуть одно или более сообщений SearchResultReference, каждое из которых содержит ссылку на другой набор серверов для продолжения операции. Сервер не должен возвращать какое-либо сообщение SearchResultReference, если оно имеет нелокальный baseObject и, таким образом, не подвергался поиску. В этом случае будет возвращен SearchResultDone, содержащий либо ссылку (referral), либо результирующий код noSuchObject (в зависимости от знания сервером имени записи в baseObject).

    Если сервер имеет копию или частичную копию соподчиненного контекста имен (раздел 5 [RFC4512]), он может использовать фильтр поиска, чтобы определить, следует или нет посылать отктик SearchResultReference. В противном случае отклики SearchResultReference всегда присылаются, если находятся в пределах зоны.

    Тип данных SearchResultReference является тем же, что и у Referral.

    Если клиент хочет продолжить поиск, он запускает новую операцию Search для каждого SearchResultReference, который прислан. Если присутствует несколько URI, клиент полагает, что для продолжения операции можно использовать любой поддерживаемый URI.

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

    Заметим, что операция Abandon (прекращение), описанная в разделе 4.11, допускается только при определенных операциях обмена между клиентом и сервером. Клиент должен индивидуально отменять последующие операции Search, если он хочет этого.

    URI для сервера, реализующего LDAP и доступного через TCP/IP (v4 или v6) [RFC793][RFC791] записываются как LDAP URL в соответствии с [RFC4516].

    Значения SearchResultReference, которые являются LDAP URL, должны следовать определенным правилам:

    • Должна обязательно присутствовать -часть LDAP URL, с новым именем объекта-адресата. Клиент использует это имя, когда осуществляет переход по ссылке.
    • Некоторые серверы (напр., участвующие в распределенном индексировании) могут предоставлять разные фильтры для LDAP URL.
    • Если -часть LDAP URL присутствует, клиент использует этот фильтр в своем следующем запросе, чтобы продолжать поиск, а если она отсутствует, клиент использует тот же фильтр, который использовался в поиске до этого.
    • Если исходная область поиска была singleLevel, -часть LDAP URL будет «базовой».
    • Чтобы избежать неопределенности, рекомендуется, чтобы присутствовала -часть. В отсутствии -части, предполагается, что используется исходная зона поиска.
    • Другие аспекты нового запроса поиска могут быть теми же, что и в других запросах, генерирующих SearchResultReference.
    • Имя неисследованного субдерева в SearchResultReference зависит от базового объекта.
    Илон Маск рекомендует:  Что такое код dio_open

    Могут присылаться и другие типы URI. Синтаксис и семантика таких URI будут рассмотрены позднее. Клиенты могут игнорировать URI, которые не поддерживают.

    Символы с кодировкой UTF-8, встречающиеся в строке DN, поискового фильтра, или других полях строки referral могут быть нелегальными для URI (напр., пробелы) и должны быть заменены с привлечением %-метода [RFC3986].

    4.5.3.1. Примеры

    Например, пусть осуществляется контакт с сервером (hosta), который получил запись и . Он знает, что два LDAP-сервера (hostb) и (hostc) содержат (один является основным, другой — теневым ), и что LDAP-сервер (hostd) содержит субдерево . Если контактному серверу запрошен поиск wholeSubtree , он может прислать следующее:

    Разработчики клиента должны помнить, что по завершении SearchResultReference, может быть сформирован дополнительный SearchResultReference. Продолжая пример, если клиент, подключенный к серверу (hostb), выдает запрос Search для субдерева , сервер может среагировать следующим образом:

    Аналогично, если подключенному серверу запрошен поиск singleLevel , он может прислать следующее:

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

    4.6. Результат поиска

    Операция Modify позволяет клиенту запрашивать модификацию записи, которая должна быть выполнена сервером. Запрос Modify определен следующим образом:

    Полями запроса Modify являются:

    • object: Значение этого поля содержит имя записи, которую нужно модифицировать. Сервер не должен выполнять разыменований псевдонимов, определяя объект, подлежащий модификации.
    • changes: Список модификаций, которые нужно выполнить над записью. Полный список модификаций, которые нужно выполнить в порядке их записи в рамках одной операции.

    В то время как отдельные модификации могут нарушать определенные аспекты схемы каталогов (такие как определения классов объектов и правило содержимого для DIT (Directory Information Tree)), результирующая запись после полного списка модификаций, которые нужно выполнить, должна соответствовать требованиям каталожной модели и схеме управления [RFC4512].

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

    Значение этого поля имеет следующую семантику:

    add: Добавить значения, перечисленные в атрибуте модификации, создавая атрибут, если это необходимо.

    delete: Уничтожает значения, перечисленные в атрибуте модификации. Если список пуст, или если все текущие значения атрибута содержатся в списке, удаляется весь атрибут.

    relace: Замещает все существующие значения атрибута модификации новыми значениями из списка, создавая атрибут, если его не было. Замещение при отсутствии нового значения приводит к ликвидации атрибута, если он существовал, и команда игнорируется, если атрибута не было.

    • modification: PartialAttribute (который может иметь пустой набор значений) используется для хранения типа атрибута или типа атрибута и значений, которые нужно модифицировать.

    После получения запроса Modify, сервер пытается выполнить необходимые модификации в DIT и прислать результат в отклике Modify, определенном как:

    ModifyResponse ::= [APPLICATION 7] LDAPResult

    Сервер пришлет клиенту один отклик Modify, указывающий на успешное завершение модификации DIT, или причину, по которой операция модификации не выполнена. Из-за требования атомарности при использовании списка модификаций в запросах Modify, клиент может ожидать, что никаких модификаций DIT не было выполнено, если полученный отклик Modify указывает на какую-либо ошибку, и что все запрошенные модификации были выполнены, если отклик Modify Response свидетельствует об успешном завершении операции Modify. Произведена ли модификация или нет, клиент не может узнать, если не получен отклик Modify (напр. , сессия LDAP была завершена или операция Modify прервана).

    Серверы должны гарантировать, что записи адаптированы для пользователя, для правил схемы системы или для других ограничений модели данных. Операция Modify не может быть использована для удаления из записи любых существенных данных, т.e., таких значений, которые образуют относительное DN записи. Попытка сделать это приведет к тому, что сервер вернет результирующий код notAllowedOnRDN. Операция Modify DN, описанная в разделе 4.9, используется для переименования записи.

    Для типов атрибутов, которые не специфицируют соответствия равенства, правила описаны в разделе 2.5.1 [RFC4512].

    Заметим, что благодаря упрощениям выполненным в LDAP, здесь нет прямого соответствия изменений в LDAP ModifyRequest и изменений в операции DAP ModifyEntry.

    4.7. Операция Add

    Операция Add позволяет клиенту запросить добавление записи в каталог (Directory). Запрос Add определен следующим образом:

    Полями запроса Add являются:

    • entry:Имя записи, которое нужно добавить. Сервер не должен разыменовывать любые псевдонимы при локализации записи, подлежащей добавлению.
    • attributes: Список атрибутов, которые, совместно с полученными из RDN, формируют содержимое записи, которую нужно добавить. Клиенты могут или не могут включить RDN-атрибуты в этот список. Клиенты не должны предоставлять атрибуты NO-USER-MODIFICATION, такие как createTimestamp или creatorsName, так как сервер поддерживает их автоматически.

    Серверы должны гарантировать, что записи адаптированы для пользователя и для правил схемы системы, а также согласуются с другими ограничениями модели данных. Для типов атрибутов, для которых не специфицировано соответствие равенства, используются правила раздела 2.5.1 [RFC4512].

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

    После получения запроса Add сервер попытается добавить запрошенную запись. Результат попытки исполнить запрос Add будет возвращен клиенту в отклике Add, который определяется следующим образом:

    AddResponse ::= [APPLICATION 9] LDAPResult

    Успешный отклик индицирует, что новая запись была добавлена в каталог.

    4.8. Операция Delete

    Операция Delete позволяет клиенту запросить удаление записи из каталога. Запрос Delete определен следующим образом:

    DelRequest ::= [APPLICATION 10] LDAPDN

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

    Только периферийные записи (которые не имеют соподчиненных записей) могут быть удалены этой операцией.

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

    DelResponse ::= [APPLICATION 11] LDAPResult

    4.9. Операция Modify DN

    Операция Modify DN позволяет клиенту изменить RDN (Relative Distinguished Name) записи в каталоге и/или переместить субдерево записей в новое место каталога. Запрос Modify DN определяется следующим образом:

    Полями запроса Modify DN являются:

    • entry: Имя записи, которое нужно изменить. Эта запись может иметь, а может и не иметь соподчиненных записей.
    • newrdn: Новая RDN-запись. Значение старой RDN предоставляется при перемещении записи в новую без изменения ее RDN.

    Значения атрибутов новой RDN, не совпадающие с любыми другими значениями, добавляются в запись.

    • deleteoldrdn: Булево поле, которое управляет тем, будут ли старые значения RDN-атрибутов сохранены в записи или будут удалены.
    • newSuperior: если присутствует, это имя существующей объектной записи, которое становится непосредственным прародителем существующей записи.

    Сервер не должен разыменовывать любые псевдонимы при локализации именованных объектов записи или newSuperior.

    После получения ModifyDNRequest, сервер попытается выполнить изменение имени и пришлет результат в отклике Modify DN, который определяется следующим образом:

    ModifyDNResponse ::= [APPLICATION 13] LDAPResult

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

    Серверы должны гарантировать, что записи адаптированы для пользователя и для правил схемы системы или для других ограничений модели данных. Для типов атрибутов, для которых не специфицировано соответствие равенства, используются правила из раздела 2.5.1 [RFC4512].

    В newSuperior должен существовать именованный объект. Например, если клиент попытается добавить , записи нет, а запись имеется, тогда сервер пришлет результирующий код noSuchObject с полем matchedDN, содержащим .

    Если поле deleteoldrdn равно TRUE, значения атрибутов, образующих старое RDN (но не новое RDN), удаляются из записи. Если поле deleteoldrdn равно FALSE, значения атрибутов, образующих старое RDN, будут возвращены в качестве неизвестных значений атрибута записи.

    Заметим, что X.500 ограничивает операцию ModifyDN воздействием только на записи, которые содержатся только в одном сервере. Если LDAP-сервер взаимосогласован с DAP, тогда это ограничение будет применено и будет прислан отклик с кодом результата affectsMultipleDSAs, если случится эта ошибка. Вообще, клиенты не должня предполагать, что возможны произвольные перемещения записей и субдеревьев между серверами или между именованными контекстами.

    4.10. Операция сравнения

    Операция Compare позволяет клиенту сравнить введенное значение со значениями определенного атрибута в определенной записи каталога. Запрос Compare определен следующим образом:

    Полями запроса сравнения являются:

    • entry: Имя записи, которое будет сравниваться. Сервер не должен разыменовывать любые псевдонимы в локализуемой записи, для которой осуществляется сравнение.
    • ava: Содержит значение атрибута, которое будет использовано при сравнении.

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

    CompareResponse ::= [APPLICATION 15] LDAPResult

    resultCode устанавливается равным compareTrue, compareFalse или соотвествующему коду ошибки. compareTrue указывает, что введенное значение в поле ava согласуется со значением атрибута или субтипа согласно правилам EQUALITY для атрибутов. compareFalse указывает, что введенная величина в поле ava и значения атрибута или субтипа не согласуются. Другой результирующий код указывает, что либо результат сравнения не определен (раздел 4.5.1.7), либо что произошла какая-то ошибка.

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

    4.11. Операция Abandon (прерывание)

    Фуекцией опреации Abandon является разрешение клиенту запросит сервер прервать незавершенную операцию. Запрос Abandon определен следующим образом:

    AbandonRequest ::= [APPLICATION 16] MessageID

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

    Для операции Abandon отклика не предусмотрено. После получения AbandonRequest, сервер может прервать операцию, идентифицированную MessageID. Так как клиент не может отличить прерванные и незавершенные операции, приложение операции Abandon ограничено случаями, когда такая информация не требуется.

    Операции Abandon, Bind, Unbind и StartTLS не могут быть прерваны.

    В случае, когда сервер получает запрос Abandon при выполнении операции поиска во время передачи откликов поиска, сервер должен прервать передачу откликов для прерываемого запроса немедленно и не должен посылать SearchResultDone. Конечно, сервер должен гарантировать, что передаются только правильно закодированные LDAPMessage PDU.

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

    Серверы должны игнорировать запросы Abandon для messageIDs, которые они не распознают, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.

    4.12. Расширенная операция

    Расширенная (Extended) операция позволяет определить дополнительные операции для серверов, которые пока не определены в рамках протокола; например, добавить операции обеспечения безопасности на транспортном уровне (смотри раздел 4.14).

    Расширенная операция позволяет клиентам выполнять запросы и получать отклики с предопределенным синтаксисом и семантикой.

    Каждая расширенная операция состоит из расширенного запроса и расширенного отклика.

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

    Сервер среагирует на это LDAPMessage, содержащим ExtendedResponse.

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

    Когда requestName не распознано, сервер возвращает protocolError. (Сервер может вернуть protocolError.)

    Поля requestValue и responseValue содержат информацию, ассоциированную с операцией. Формат этих полей определен спецификацией расширенной операции. Реализации должна быть готова обрабатывать произвольное содержимое этих полей, включая нулевые байты. Величины, которые определены в терминах ASN.1 и BER-кодировке согласно разделу 5.1, также следуют правилам расширяемости из раздела 4.

    Серверы перечисляют requestName расширенных запросов, которые они распознают, в атрибуте ‘supportedExtension’ в корневом DSE (раздел 5.1 [RFC4512]).

    Расширенные операции могут быть специфицированы в других документах. Спецификация расширенной операции состоит из:

    • Объектный идентификатор (OBJECT IDENTIFIER) присвоенный requestName,
    • Объектный идентификатор (если имеется), присвоенный responseName (заметим, что один и тот же объектный идентификатор может использоваться как для requestName так и responseName),
    • Формат содержимого requestValue и responseValue (если имеются), и
    • Семантика операции.

    4.13. Сообщение IntermediateResponse

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

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

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

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

    • Объектный идентификатор IDENTIFIER (если имеется) присвоенный responseName, формат содержимого responseValue (если имеется), и
    • семантика, ассоциированная с сообщением IntermediateResponse.

    Расширения, которые позволяют посылать несколько типов сообщений IntermediateResponse, будут идентифицировать эти типы, используя уникальные значения responseName (заметим, что один из них может не иметь значения). В разделах 4.13.1 и 4.13.2 описаны дополнительные требования на включение responseName и responseValue в сообщения IntermediateResponse.

    4.13.1. Использование LDAP ExtendedRequest и ExtendedResponse

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

    4.13.2. Использование контролей LDAP-запросов

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

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

    • два или более контролей, использующих сообщения IntermediateRespons, включены в запрос для любой LDAP-операции или
    • один или более контролей, использующих сообщения IntermediateResponse, включены в запрос с расширенной LDAP-операцией, которая использует сообщения IntermediateResponse.

    4.14. Операция StartTLS

    Целью операции StartTLS (Start Transport Layer Security)является инициация формирования TLS-уровня. Операция StartTLS определена с использованием механизма расширенных операций, описанного в разделе 4.12.

    4.14.1. Запрос StartTLS

    Клиент запрашивает установления TLS путем передачи серверу сообщения-запроса StartTLS. Запрос StartTLS определен в терминах ExtendedRequest. requestName имеет вид «1.3.6.1.4.1.1466.20037», а поле requestValue всегда отсутствует.

    Клиент не должен посылать какого-либо LDAP PDU на уровне LDAP-сообщений вслед за этим запросом, до тех пор пока не получит расширенного отклика StartTLS и, в случае успешного отклика, завершает согласование TLS.

    В случае детектирования проблем с порядком следования (в частности таких, которые описаны в разделе 3.1.1 [RFC4513]), результат в resultCode устанавливаться равным operationsError.

    Если клиент не поддерживает TLS (либо из-за устройства, либо благодаря существующей конфигурации), он присылает результирующий код resultCode равный protocolError, как это описано в разделе 4.12.

    4.14.2. Отклик StartTLS

    Когда получен запрос StartTLS, серверы, поддерживающие операцию, должны прислать отправителю запроса сообщение отклика StartTLS. responseName, когда имеется, равно «1.3.6.1.4.1.1466.20037» (смотри раздел 4.12). responseValue всегда отсутствует.

    Если сервер хочет и способен согласовать использование TLS, он присылает отклик StartTLS с результирующим кодом resultCode равным success. После того как клиент получил успешный отклик StartTLS, протокольный партнер может начать согласование TLS, как это описано в разделе 3 [RFC4513].

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

    4.14.3. Удаление уровня TLS

    Либо клиент, либо сервер могут удалить уровень TLS и оставить уровень LDAP-сообщений незатронутым, посылая и получая уведомления о закрытии TLS.

    Инициирующий протокол партнер посылает уведомление о закрытии TLS и должен ждать получения уведомления о закрытии TLS от другого партнера, прежде чем посылать последующие LSAP PDU.

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

    Протокольный партнер может завершить LDAP-сессию после отправки или получения уведомления о завершении TLS.

    5. Протокол кодирования, соединения и передачи

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

    Один из подобных сервисов, LDAP поверх TCP, определен в разделе 5.2.

    Этот сервис предназначен для приложений предоставляющих или потребляющих каталожные услуги, базирующиеся на X.500 в Интернет. Данная спецификация писалась с ориентацией на ТСР.

    Реализации LDAP поверх TCP должны обеспечивать взаимодействие, описанное в разделе 5.2.

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

    Рис. 2. Взаимодействие партнеров в рамках протокола LDAP

    5.1. Протокол кодирования

    Протокольные элементы LDAP кодируются для обмена согласно правил BER (Basic Encoding Rules) [ASN.1] со следующими ограничениями:

    • Используется только определенная форма длины кодирования.
    • Значения строк октетов (OCTET STRING) кодируются только примитивным образом.
    • Если значение Булевого типа равно ИСТИНА, кодирование октета значения имеет шестнадцатеричную форму «FF».
    • Если значение типа равно «по-умолчанию», то оно отсутствует. В этом протоколе только некоторые Булевы и целые типы имеют значения по-умолчанию.

    Эти ограничения имеют целью облегчить кодирование и декодирование определенных элементов в BER.

    Эти ограничения не относятся к ASN.1-типам, инкапсулированным с строки октетов, таким как значения атрибутов.

    5.2. Протокол управления передачей данных (TCP)

    Кодированные LDAPMessage PDU преобразуются в поток байтов TCP [RFC793], с использованием BER-кодирования, описанного в разделе 5.1. Рекомендуется, чтобы реализации сервера, работающие поверх TCP обеспечивали протокольного слушателя возможностью использования стандартного номера порта LDAP 389 [PortReg]. Серверы могут вместо этого предоставить слушателю другой номер порта. Клиенты должны поддерживать связь с серверами через любой оговоренный TCP-порт.

    5.3. Завершение LDAP-сессии

    Завершение LDAP-сессии обычно инициируется клиентом путем посылки UnbindRequest (раздел 4.3), или сервером путем отправки Notice of Disconnection (уведомление о прерывании) (раздел 4.4.1). В этих случаях, каждый протокольный партнер прерывает сессию стандартным образом путем прекращения обменов на уровне LDAP-сообщений, разрыва на уровне SASL или TLS и закрывание транспортного соединения.

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

    Когда LDAP-сессия завершается, незавершенные операции обрабатываются так, как описано в разделе 3.1.

    6. Соображения безопасности

    Данная версия протокола обеспечивает возможности простой аутентификации с вводом пароля открытым текстом, а также с привлечением любого SASL-механизма [RFC4422]. Инсталляция SASL и/или TLS может обеспечить целостность данных и другие сервисы безопасности.

    Предусмотрена также возможность аутентификации сервера клиентом, если он этого захочет.

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

    Серверам рекомендуется предотвращать модификации каталогов клиентами, которые авторизованы анонимно [RFC4513].

    Соображения безопасности для методов аутентификации, механизмов SASL и TLS описаны в [RFC4513].

    Заметим, что аутентификационный обмен SASL не обеспечивает конфиденциальности данных или обеспечения их целостности для полей версии, имени BindRequest, resultCode, diagnosticMessage или полей referral BindResponse, а также для любой информации, содержащейся в контролях, присоединенных к запросам или откликам. Таким образом, информации, содержащейся в этих полях, не следует доверять, если не используются какие-то дополнительные средства обеспечения безопасности (например, используется безопасный транспортный уровень).

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

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

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

    Серверы присылать ссылки (переадресации) или ссылки на результаты поиска, которые переадресуют клиентов на другие серверы. Вполне возможно, что сомнительное приложение может инжектировать такие ссылки в поток данных с целью попытаться переадресовать клиента на вредоносный сервер. Клиентам рекомендуется проявлять осторожность и возможно отвергать ссылки, когда меры конфиденциальности находятся не на должном уровне. Клиентам рекомендуется отвергать ссылки в случае операции StartTLS.

    Поля matchedDN и diagnosticMessage, а также некоторые значения resultCode (напр. , attributeOrValueExists и entryAlreadyExists), могут раскрыть присутствие или отсутствие специфических данных в каталоге, которые являются субъектами доступа и других административных контролей. Реализации сервера должны ограничивать доступ к защищенной информации, как в нормальных условиях, так и в случае ошибок.

    Протокольные партнеры должны быть готовы обрабатывать некорректные входные коды произвольной длины. Некорректными протокольными кодировками считаются: кодовые исключения BER, исключения форматных строк и UTF-8, исключения переполнения, исключения целых величин, а также исключения, связанные с флагами двоичного режима on/off.

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

    7. Нормативные ссылки

    [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 «Information Technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation».
    [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, «Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) и Distinguished Encoding Rules (DER)», 2002.
    [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) — Architecture и Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
    [RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.
    [RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.
    [RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
    [RFC3454] Hoffman P. и M. Blanchet, «Preparation of Internationalized Strings (‘stringprep’)», RFC 3454, December 2002.
    [RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.
    [RFC3986] Berners-Lee, T., Fielding, R., и L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.
    [RFC4013] Zeilenga, K., «SASLprep: Stringprep Profile for User Names и Passwords», RFC 4013, February 2005.
    [RFC4234] Crocker, D. и P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 4234, October 2005.
    [RFC4346] Dierks, T. и E. Rescorla, «The TLS Protocol Version 1.1», RFC 4346, March 2006.
    [RFC4422] Melnikov, A., Ed. и K. Zeilenga, Ed., «Simple Authentication и Security Layer (SASL)», RFC 4422, June 2006.
    [RFC4510] Zeilenga, K., Ed., «Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map», RFC 4510, June 2006.
    [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol (LDAP): Directory Information Models», RFC 4512, June 2006.
    [RFC4513] Harrison, R., Ed., «Lightweight Directory Access Protocol (LDAP): Authentication Methods и Security Mechanisms», RFC 4513, June 2006.
    [RFC4514] Zeilenga, K., Ed., «Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names», RFC 4514, June 2006.
    [RFC4516] Smith, M., Ed. и T. Howes, «Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator», RFC 4516, June 2006.
    [RFC4517] Legg, S., Ed., «Lightweight Directory Access Protocol (LDAP): Syntaxes и Matching Rules», RFC 4517, June 2006.
    [RFC4520] Zeilenga, K., «Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)», BCP 64, RFC 4520, June 2006.
    [Unicode] The Unicode Consortium, «The Unicode Standard, Version 3.2.0» is defined by «The Unicode Standard, Version 3.0» (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the «Unicode Standard Annex #27: Unicode 3.1» (http://www.unicode.org/reports/tr27/) и by the «Unicode Standard Annex #28: Unicode 3.2» (http://www.unicode.org/reports/tr28/).
    [X.500] ITU-T Rec. X.500, «The Directory: Overview of Concepts, Models и Service», 1993.
    [X.511] ITU-T Rec. X.511, «The Directory: Abstract Service Definition», 1993.

    9. Информативные ссылки

    [CharModel] Whistler, K. и M. Davis, «Unicode Technical Report #17, Character Encoding Model», UTR17, , August 2000.
    [Glossary] The Unicode Consortium, «Unicode Glossary», .
    [PROTOS-LDAP] University of Oulu, «PROTOS Test-Suite: c06-ldapv3»

    Приложение A. Коды результата LDAP (RFC-4511)

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

    Дополнительный код результата может быть определен для использования с расширениями [RFC4520]. Клиентские реализации будут считать любой код результата, который они не распознали, как неизвестное условие ошибки.

    Описания предлагаемые здесь не полностью анализируют меры, связанные с подменой кодов результата, и направленные на предотвращение несанкционированного доступа к данным (например, замена noSuchObject на insufficientAccessRights или invalidCredentials на insufficientAccessRights).

    A.1. Неошибочные коды результатов

    Эти коды результатов (названные неошибочными кодами результата) не указывают на условия ошибки:

    Коды результата success, compareTrue и compareFalse указывают на успешное завершение (и, следовательно, называются кодами успешного результата).

    Результирующие коды переадресаций (referral) и saslBindInProgress указывают, что клиенту нужны дополнительные действия, чтобы завершить операцию.

    A.2. Коды результата

    Существующие коды результата LDAP описываются следующим образом:

    Индицирует успешное завершение операции. Заметим: этот код не используется в операции Compare. Смотри compareFalse (5) и compareTrue (6).

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

    Например, этот код возвращается, если клиент пытается запустить StartTLS [RFC4346], в то время как другие операции не завершены или, если TLS-уровень был уже инсталлирован.

    Индицирует то, что сервер получил некорректно сформатированные данные.

    Для операции Bind только, этот код также используется для индикации того, что сервер не поддерживает запрошенную версию протокола.

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

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

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

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

    Индицирует то, что операция Compare была успешно завершена и результат охарактеризован как FALSE или Undefined.

    Индицирует то, что операция Compare была успешно завершена и результат охарактеризован как TRUE.

    Индицирует то, что метод или механизм аутентификации не поддерживается.

    Индицирует то, что сервер требует более строгой аутентификации для завершения операции.

    При использовании с операцией Notice of Disconnection, этот код указывает, что сервер детектировал, что установленная ассоциация безопасности между клиентом и сервером оказалась повреждена или скомпрометирована.

    Индицирует то, что нужно, чтобы завершить операцию, следовать по ссылке (смотри раздел 4.1.10).

    Индицирует то, что превышен административный лимит.

    Индицирует то, что критический контроль не распознан (смотри раздел 4.1.11).

    Индицирует то, что необходима защита конфиденциальности данных.

    Индицирует то, что сервер требует от клиента посылки нового запроса bind, с тем же самым механизмом SASL, чтобы продолжить процесс аутентификации (смотри раздел 4.2).

    Индицирует то, что именованная запись не содержит специфицированного атрибута или его значения.

    Индицирует то, что поле запроса содержит нераспознанное описание атрибута.

    Индицирует то, что была совершена попытка использовать правила соответствия, неопределенные для данного типа атрибута.

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

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

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

    Индицирует то, что подразумеваемое значение атрибута не соответствует синтаксису данного атрибута.

    Индицирует то, что объект отсутствует в DIT.

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

    Индицирует то, что поля LDAPDN или RelativeLDAPDN (напр., база поиска, запись адресата, ModifyDN newrdn, и т.д.) запроса не соответствуют требующемуся синтаксису или содержат значения атрибутов, которые противоречат синтаксису типа атрибута.

    Индицирует то, что возникла проблема при разыменовании псевдонима. Обычно псевдоним встречается в ситуации, где ему не разрешено или отказано в доступе.

    Индицирует то, что сервер требует от клиента предоставления определенных параметров аутентификации.

    Индицирует то, что предоставленные параметры аутентификации (напр., имя пользователя и пароль) не верны.

    Индицирует то, что клиент не имеет достаточно прав, чтобы выполнить операцию.

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

    Индицирует то, что сервер завершает свою работу или нужна система для завершения операции в режиме offline.

    Индицирует то, что сервер не желает выполнять операцию.

    Индицирует то, что сервер выявил внутреннее зацикливание (напр., в ходе разыменования псевдонимов или в случае цепочки операций).

    Индицирует то, что имя записи нарушает регламентации именования.

    Индицирует то, что запись нарушает регламентации объектного класса.

    Индицирует то, что операция выполняется некорректно для неконечной записи (non-leaf).

    Индицирует то, что операция некорректно пытается удалить значение, которое образует RDN записи.

    Индицирует то, что запрос не может быть выполнен, так как адресуемая запись уже существует.

    Индицирует то, что модификация класса объекта записи запрещена.

    Например, этот код присылается, когда клиент пытается модифицировать структурный класс объекта записи.

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

    Индицирует то, что сервер столкнулся с внутренней ошибкой.

    Приложение B. Полное ASN.1 описание (RFC-4511)

    Это приложения является нормативным.

    Приложение С удалено в силу его ненормативности.

    Получение читаемого пользователем имени через LDAP с использованием PHP только с регистрационными именами

    Я интегрирую свою регистрационную форму с активным каталогом Microsoft. Я аутентифицирую пользователей через библиотеку php LDAP.

    Когда пользователь пытается войти в систему, они вводят имя пользователя &. Подключение к серверу успешно завершено, аутентификация через «LDAP_bind» также дает мне true или false в соответствии с правильностью значений. Теперь я не могу получить реальное имя пользователя, чтобы отобразить его на экране.

    ВСЕ Информация У меня есть ldap uri с номером порта и имя пользователя & пароль, введенный через веб-форму.

    вот мой текущий код,

    за $ _REQUEST [ «имя пользователя»] не человек для чтения, так что мне нужно прочитать атрибуты пользователя или только по меньшей мере, отображаемое имя.

    ldap_search и ldap_read функции не помогли, я попробовал этот код:

    не повезло, там любая другая информация, я должен иметь, чтобы сделать ldap_search или ldap_read работу успешно. другими словами, можно ли это сделать, имея имя пользователя и пароль и только ldap uri?

    Создан 29 дек. 16 2020-12-29 10:10:54 user-stacker

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL