Что такое код ldap_unbind

Содержание

ldap_bind

ldap_bind — Bind to LDAP directory

Описание

Binds to the LDAP directory with specified RDN and password.

Список параметров

If bind_rdn and bind_password are not specified, an anonymous bind is attempted.

Возвращаемые значения

Возвращает TRUE в случае успешного завершения или FALSE в случае возникновения ошибки.

Примеры

Пример #1 Using LDAP Bind

// using ldap bind
$ldaprdn = ‘uname’ ; // ldap rdn or dn
$ldappass = ‘password’ ; // associated password

// connect to ldap server
$ldapconn = ldap_connect ( «ldap.example.com» )
or die( «Could not connect to LDAP server.» );

// binding to ldap server
$ldapbind = ldap_bind ( $ldapconn , $ldaprdn , $ldappass );

// verify binding
if ( $ldapbind ) <
echo «LDAP bind successful. » ;
> else <
echo «LDAP bind failed. » ;
>

Пример #2 Using LDAP Bind Anonymously

//using ldap bind anonymously

// connect to ldap server
$ldapconn = ldap_connect ( «ldap.example.com» )
or die( «Could not connect to LDAP server.» );

// binding anonymously
$ldapbind = ldap_bind ( $ldapconn );

if ( $ldapbind ) <
echo «LDAP bind anonymous successful. » ;
> else <
echo «LDAP bind anonymous failed. » ;
>

LDAP.com

Lightweight Directory Access Protocol

The LDAP Unbind Operation

An unbind operation allows the client to signal to the directory server that it is about to close its connection to the server. Upon receiving this request, the server should then close its connection to the client so that the connection is no longer usable even if the client fails to actually disconnect after sending the unbind request. There are no elements inside of an unbind request, and there is no result message to be sent in response to an unbind request.

Note that even though the name of the operation suggests that it is a counterpart to the bind operation, it does not have the effect of merely reverting the connection to an unauthenticated state. An unbind operation leaves the connection in an invalid state and neither the client nor the server should attempt to perform any additional communication over a connection on which the unbind operation has been processed. If a client wishes to revert a connection to an unauthenticated state, then it should perform an anonymous simple bind (i.e., a simple bind request with a zero-length bind DN and a zero-length password) on that connection.

Also note that sending an unbind request is generally considered a courtesy. Although an unbind request indicates to the server that the client is ready to close the connection, the server should also be able to handle the case in which the client merely disconnects without first sending an unbind request. However, preceding a disconnect with an unbind request is recommended to aid with troubleshooting, because if the server detects the loss of a client connection that was not preceded by an unbind request, then it may not be possible to determine whether the client actually initiated the closure or whether it might have been caused by some kind of network issue or other problem.

Протокол LDAP

Операции протокола LDAP

В протоколе определено 9 операций:

  • Операции запроса информации.
    • Search
    • Compare

    Операция Bind передает аутентификационную информацию от клиента к серверу.

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

    • Version : номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоры о номере версии не ведутся, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в сообщении BindResponce .
    • Name : имя объекта Каталога, от имени которого клиент хочет установить соединение. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного соединения или при использовании SASL-аутентификации.
    • Authentication : информация, используемая для аутентификации имени, указанного в запросе Bind . Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind . Аутентификацию с использованием механизмов SASL мы рассматривать не будем.

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

    BindResponce содержит статус запроса клиента на аутентификацию.

    Если доступ разрешен, то resultCode будет Success , в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError .

    Назначение операции Unbind состоит в завершении сессии протокола.

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

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

    Сообщение Search Request имеет следующие параметры:

    Перечислим параметры Search Request :

    • BaseObject : базовый объект, относительно которого будет выполняться поиск.
    • Scope : указание области поиска.

    Может существовать три типа области поиска:

    • baseObject — ограничивается только базовым объектом.
    • singleLevel — ограничивается только непосредственно подчиненными объектами.
    • wholeSubtree — поиск во всем поддереве данной записи.

    Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо «TRUE» , либо «FALSE» , либо «Undefined» . Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined , то данная запись при поиске игнорируется.

    Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.

    Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.

    Правило соответствия для элементов фильтра greaterOrEqual и l essOrEqual определяется правилом соответствия ORDERING для типа атрибута.

    Семантика соответствия для элементов фильтра approxMatch определяется реализацией.

    Следует заметить, что если запрошены все пользовательские атрибуты, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes , если они явно не перечислены.

    Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в Search Responses , которые являются LDAP-сообщениями, содержащими типы данных SearchResultEntry , либо SearchResultReference , либо SearchResultDone .

    После получения Search Request сервер будет выполнять необходимый поиск в DIT.

    Сервер может возвращать как найденные записи ( SearchResultEntry ), так и ссылки на другие серверы для продолжения поиска ( SearchResultReference ).

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

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

    • Object : модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не использует никаких alias для определения модифицируемой записи.
    • Modification : список выполняемых изменений. Список из-менений должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные из-менения могут нарушать схему Каталога, результирующая запись, после того как весь список изменений выполнен, должна соответствовать требованиям схемы Каталога. Значения поля operation имеют следующую семантику:
      • Add : добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.
      • Delete : удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или если удалены все текущие значения атрибута.
      • Replace : замена значений данного атрибута новыми; если атрибута не существует, он создается. Если при замене не указаны новые значения, то атрибут удаляется, если он есть, и игнорируется, если атрибута не существует.

      Результат изменения, которое пытался выполнить сервер при получении Modify Request , возвращается в Modify Response .

      При получении Modify Request сервер выполняет необходимые изменения в DIT.

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

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

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

      Параметрами Add Request являются:

      • Entry : полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.
      • Attributes : список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют RDN записи), атрибут objectClass и значения всех обязательных атрибутов классов объектов данной записи. Клиенты не должны указывать атрибуты, которые не могут модифицироваться пользователем, такие как createTimestamp или creatorName атрибуты, так как сервер создает их автоматически.

      Запись, указанная в поле entry в AddRequest , существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS , DC=Example , DC=NET , но запись DC=Example , DC=NET не существует, а запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN , содержащим DC=NET . Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.

      Операция Delete позволяет клиенту запросить удаление записи из Каталога.

      Сообщение Delete Request состоит из DN удаляемой записи. Заметим, что сервер не переходит по aliases, и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.

      Результат операции удаления, выполненной сервером при получении сообщения Delete Request , возвращается в сообщении Delete Response .

      Операция Modify DN

      Операция Modify DN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. Сообщение Modify DN Request имеет следующие параметры:

      Параметрами Modify DN Request являются:

      • Entry : DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.
      • Newdn : RDN определяет левый компонент нового имени записи.
      • Deleteoldrdn : Параметр типа boolean, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.
      • newSuperior : если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.

      Результат попытки изменения имени сервером при получении сообщения Modify DN Request возвращается в сообщении Modify DN Response .

      Например, если запись, указанная в параметре entry , была cn=OlgaLaponina , c=RU , newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU . Если запись с таким именем уже существует, то операция завершится с кодом ошибки entryAlreadyExists .

      Объект, указанный в newSuperior , должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET , запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN , содержащим DC=NET .

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

      Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. Compare Request имеет следующие параметры:

      Перечислим параметры CompareRequest :

      • Entry : имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.
      • Ava : утверждение, с которым сравнивается атрибут записи.

      Результат сравнения, выполненного сервером при получении Compare Request , возвращается в Compare Response .

      При получении Compare Reques t сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.

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

      Операция Abandon предоставляет возможность создания запроса на прерывание сервером выполняющейся операции.

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

      Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в Abandon Request . Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполнив новую операцию bind.

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

      В том случае, если сервер получил Abandon Request для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone . Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.

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

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

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

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

      req uestName есть OBJECT IDENTIFIER операции requestValue содержит информацию в том виде, в котором она определена в операции. Данная информация инкапсулирована в строку октетов.

      Сервер отвечает LDAPMessage , содержащим ExtendedResponse .

      Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult , содержащие код ошибки protocolError .

      LDAP / PHP — Когда Unbind

      У меня есть около 12 PHP функций, каждая из которых выполняет вызов $ ldap_connect, что делает использование ldap_bind ()

      Так что — это значит, что, когда я называю все функции моего сервера LDAP делает 12 Ldap привязок?

      Если да — когда если ldap_unbind) используется (функция? Я пытался искать это, но ничего плодотворного не придумало, все, что я, казался, найти был «отвязать каждый раз», но это на самом деле не специфично. Означает ли это, положи в отвязать во всех 12 функций непосредственно перед возвращает данные или отвязать на моей странице выхода из системы, где я также сделать session_destroy ()?

      Тогда я использую $ ldap_conn = create_ldap_connection ($ пользователю, $ пасс);

      Итак, мои 2 из моих функций будут:

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

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

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

      Хорошим примером может быть что-то вроде этого:

      Дурной пример будет что-то вроде этого:

      Это создало бы новую Ldap-соединение на каждом вызове connect() .

      Для того, чтобы изменить это в «хороший», например, вы должны изменить, что, как следует использовать подключение несколько раз:

      Что такое код ldap_unbind

      Note that the unbind operation cannot be used to destroy an authentication session while leaving the underlying connection established. If the client does not close the connection after sending an unbind request, then the server will. If there is a need to revert a connection to an unauthenticated state, then an Anonymous bind operation should be performed.

      The LDAP unbind request protocol op is defined as follows:

      An unbind request does not contain any elements, and the server will not send a response to an unbind request.

      LDAP. Настройка отказоустойчивого LDAP сервера

      В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

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

      Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

      Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

      • Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
      • Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
      • Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
      • Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
      • Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

      Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

      Ключевые особенности этого LDAP-сервера:

      • Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
      • Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
      • Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
      • SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
      • Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
      • Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.

      После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.

      Общая структура 389 Directory Server

      389 DS состоит из нескольких компонентов.

      • Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
      • Сервер администрирования (Administration Server). Он управляет сервером каталогов. Сервер предоставляет интерфейс управления через протокол HTTP(S), так же предоставляет веб-интерфейс для просмотра логов и статуса репликации. Физически это apache + модули для управления ns-slapd.
      • Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.

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

      Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).

      Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.

      После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.

      На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.

      Для нашего сервиса службы каталогов мы используем два сервера ldap00 и ldap01. На каждом из них будут установлены два инстанса LDAP сервера, один для нужд admin server-ов, второй для наших данных.
      План установки будет такой:

      1. Установка первого сервера на ldap00;
      2. Настройка репликации на ldap00;
      3. Установка и настройка ldap инстанса на ldap01;
      4. Установка admin server-а на ldap01;
      5. Установка и настройка ldap инстансов для хранения пользовательских данных.

      Установка первого сервера на ldap00

      Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.

      Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.

      Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.

      Вот некоторые из них:

      • setup-ds.pl — устанавливает инстанс LDAP-сервера, сервер создается не подключенным к admin server-у;
      • setup-ds-admin.pl — устанавливает admin server, при необходимости устанавливает инстанс LDAP-сервера для хранения своей конфигурации;
      • register-ds-admin.pl — подключает инстанс к admin server-у, при необходимости устанавливает admin server;
      • remove-ds.pl — удаляет инстанс;
      • remove-ds-admin.pl — удаляет admin server и все инстансы;
      • dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.

      Для начала запустим dsktune:

      # dsktune
      389 Directory Server system tuning analysis version 10-AUGUST-2007.

      NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).

      NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
      (120 minutes). This may cause temporary server congestion from lost
      client connections.

      WARNING: There are only 1024 file descriptors (hard limit) available, which
      limit the number of simultaneous connections.

      WARNING: There are only 1024 file descriptors (soft limit) available, which
      limit the number of simultaneous connections.

      Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.

      tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.

      echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

      Добавим в /etc/sysctl.conf:

      для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:

      запускаем еще раз dsktune и убедимся, что у нас все готово для установки.

      Теперь запускаем скрипт setup-ds-admin.pl
      Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.

      1. Express
      Allows you to quickly set up the servers using the most
      common options and pre-defined defaults. Useful for quick
      evaluation of the products.

      2. Typical
      Allows you to specify common defaults and options.

      3. Custom
      Allows you to specify more advanced options. This is
      recommended for experienced server administrators only.

      To accept the default shown in brackets, press the Enter key.

      Choose a setup type [2]:

      Выбираем третий пункт (мы же experienced server administrators =) )

      Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.

      If you do not yet have a configuration directory server, enter ‘No’ to
      be prompted to set up one.

      Do you want to register this software with an existing
      configuration directory server? [no]:

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

      Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).

      Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.

      Затем нас ждет вопрос о Directory Manager DN.

      Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.

      Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.

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

      Для подключения к серверу нужно поставить и запустить консоль управления 389-console.

      В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.

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

      Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local

      У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.

      Теперь немного теории о принципах репликации.

      В репликации участвуют два типа серверов, supplier и consumer.

      supplier — сервер, который копирует реплику на другой сервер.

      обязанности supplier сервера:

      • отвечать на запросы клиентов на чтение и запись;
      • поддержание информации о состоянии изменений реплики;
      • инициализация репликации на consumer сервера.

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

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

      consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.

      consumer должен:

      • отвечать на read запросы клиентов;
      • пересылать запросы на обновления данных на сервер;
      • при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.

      Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.

      Supplier сервер повторяет эти изменения на каждом consumer сервере.

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

      Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.

      Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.

      Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.

      Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.

      ldapmodify -h 127.0.0.1 -p 6389 -x -D «cn=root» -W
      Enter LDAP Password:
      dn: cn=replication manager,cn=config
      changetype: add
      objectClass: inetorgperson
      objectClass: person
      objectClass: top
      objectClass: organizationalPerson
      cn: replication manager
      sn: RM
      userPassword:

      Ответ должен быть
      adding new entry «cn=replication manager,cn=config»

      Итого, у нас получилось:

      Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:

      Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.

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

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

      Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.

      Ответы на вопросы скрипта аналогичны предыдущим.

      После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.

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

      ldapmodify -h 127.0.0.1 -p 6389 -D «cn=root» -W

      dn: cn=changelog5,cn=config
      changetype: add
      objectclass: top
      objectclass: extensibleObject
      cn: changelog5
      nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb

      changelogdir должен указывать на директорию с названием вашего инстанса.

      2) добавляем пользователя replication manager:

      dn: cn=replication manager,cn=config
      changetype: add
      objectClass: inetorgperson
      objectClass: person
      objectClass: top
      objectClass: organizationalPerson
      cn: replication manager
      sn: RM
      userPassword:

      20380119031407Z означает, что срок действия пароля не ограничен.

      3) Создаем суффикс netscaperoot:

      dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
      changetype: add
      objectclass: top
      objectclass: extensibleObject
      objectclass: nsMappingTree
      nsslapd-state: backend
      nsslapd-backend: NetscapeRoot
      cn: «o=netscaperoot»

      4) Создаем базу для суффикса netscaperoot:

      dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
      changetype: add
      objectclass: extensibleObject
      objectclass: nsBackendInstance
      nsslapd-suffix: o=netscaperoot

      Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.

      5) Создаем корневой o=NetScapeRoot:

      dn: o=NetscapeRoot
      changetype: add
      objectClass: organization
      objectClass: top
      o: NetscapeRoot

      6) Разрешаем репликацию для o=netscaperoot:

      dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
      changetype: add
      objectClass: nsDS5Replica
      objectClass: top
      nsDS5ReplicaId: 2
      nsDS5ReplicaRoot: o=netscaperoot
      cn: replica
      nsDS5Flags: 1
      nsDS5ReplicaBindDN: cn=replication manager,cn=config
      nsds5ReplicaChangeCount: 0
      nsds5ReplicaPurgeDelay: 604800
      nsDS5ReplicaType: 3

      Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).

      На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.

      Последним этапом будет:

      7) Настройка репликации от ldap01 на ldap00:

      dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
      tree, cn=config
      changetype: add
      objectClass: top
      objectClass: nsDS5ReplicationAgreement
      cn: Multimaster replication
      description: replication for netscaperoot
      nsDS5ReplicaBindDN: cn=replication manager,cn=config
      nsDS5ReplicaBindMethod: SIMPLE
      nsds5replicaChangesSentSinceStartup:
      nsDS5ReplicaCredentials:

      nsDS5ReplicaHost: ldap00.edu.scalaxy.local
      nsDS5ReplicaPort: 6389
      nsDS5ReplicaRoot: o=netscaperoot
      nsDS5ReplicaTransportInfo: LDAP
      nsds5replicaUpdateInProgress: FALSE

      nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
      nsDS5ReplicaCredentials — пароль

      8) Первичная инициилизация репликации с ldap00 на ldap01:

      На первом сервере выполняем эту команду:
      dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
      changetype: modify
      replace: nsds5beginreplicarefresh
      nsds5beginreplicarefresh: start

      Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.

      Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.

      Установка admin server-а на ldap01

      Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl

      Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot

      Дальнейшая настройка тривиальна, следуем указаниям скрипта.

      Установка и настройка ldap инстансов для хранения пользовательских данных

      Теперь подключаться через консоль управления можно к любому admin server-у.

      На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.

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

      Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.

      Аутентификация LDAP, ldap_sasl_bind_s не работает, но ldap_simple_bind_s работает

      У меня проблема, когда в ldap_sasl_bind_s не работает, но ldap_simple_bind_s работает.

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

      фрагмент кода PFA проблемы и предложить мне, если что-то не так с моим подходом.

      Я инициализировал LDAP, используя следующий код SNIP:

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

      Я ссылался на следующие ссылки и их ссылки, чтобы перейти к такому выводу:

      Digest-MD5 auth сложнее, чем просто отправить DN и пароль связывания. Вам нужно будет использовать ldap_sasl_interactive_bind_s и обеспечить обратный вызов, чтобы библиотека SASL могла объединить ваши учетные данные с предоставленным сервером nonce.

      Этот код (адаптированный из этот пост в блоге) работает для меня на сервере Active Directory:

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

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

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

      Схема определяет классы объектов. Каждая запись должна иметь атрибут 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 зависит от базового объекта.

    Могут присылаться и другие типы 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)

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

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

    Using spring ldapTemplate, how do i delete/unbind an LDAP entry?

    How do I unbind an LDAP entry via Spring LdapTemplate?

    I have an LDAP entry u >

    What I tried thus far:

    But the LDAP entry is not deleted, even though no exception is thrown.

    I also tried recursive unbind:

    But I get the following error:

    Edit: I found out the problem. There was a typo in the uid, which is why the unbind didn’t delete the LDAP entry.

    Аутентификация LDAP, ldap_sasl_bind_s не работает, но ldap_simple_bind_s работает

    У меня проблема, когда в ldap_sasl_bind_s не работает, но ldap_simple_bind_s работает.

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

    PFA фрагмент кода проблемы и предложить мне, если что-то не так с моим подходом.

    Я инициализировал LDAP, используя следующий код SNIP:

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

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

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