Что такое код ldap_modify


Содержание

Компонент Ldap¶

Установка¶

Также вы можете клонировать репозиторий https://github.com/symfony/ldap.

If you install this component outs >vendor/autoload.php file in your code to enable the class autoloading mechanism provided by Composer. Read this article for more details.

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

Класс Ldap предоставляет методы для аутентификации и запросов к LDAP-серверу.

Класс Ldap использует AdapterInterface , чтобы общаться с LDAP-сервером. adapter для встроенного расширения LDAP PHP, к примеру, может быть сконфигурирован, используя следующие опции:

host IP или имя хоста LDAP-сервера

Например, чтобы присоединиться к start-TLS защищённому LDAP-серверу:

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

Метод bind() аутентифицирует ранее сконфигурированную связь, используя как различимое имя (РИ), так и пароль пользователя:

После привязки (или если вы включили анонимную аутентификацию на вашем LDAP-сервере), вы можете запросить LDAP-сервер, используя метод find() :

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

Создание или обновление записей¶

Компонент Ldap предоставляет инструменты для создания, обновления или даже удаления LDAP записей:

Массовое обновление¶

Используйте метод менеджера записей applyOperations() для обновления нескольких аттрибутов за раз:

Возможные типы операций: LDAP_MODIFY_BATCH_ADD , LDAP_MODIFY_BATCH_REMOVE , LDAP_MODIFY_BATCH_REMOVE_ALL , LDAP_MODIFY_BATCH_REPLACE . Параметр $values должен быть NULL при использовании типа операции LDAP_MODIFY_BATCH_REMOVE_ALL .

New in version 4.2: Метод applyOperations() появился в Symfony 4.2.

New in version 4.1: Методы addAttributeValues() и removeAttributeValues() появились в Symfony 4.1.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Linux.yaroslavl.ru

Учебник РНР
Назад Вперёд

ldap_modify — модифицирует LDAP-вхождение.

Описание

bool ldap_modify (resource link_identifier, string dn, array entry)

Возвращает TRUE при успехе, FALSE при неудаче.

ldap_modify() используется для модификации существующих вхождений в LDAP-директории. Структура вхождения — та же, что и в ldap_add() .

Modify passwords in an LDIF file using ldapmodify command

I have a LDIF file that consists of a set of test users and I would like to change the passwords for these users.

I used the ldapmodify command:

And I get the following error:

  1. What does this mean?
  2. The syntax I have used can be used for only one user, I would like to modify the passwords of all the test users in my LDIF file. Is there a way to do so?

2 Answers 2

The given error is an indication that the server specified by the hostname and port could not be contacted, that is, a connection could not be established. Also, the legacy OpenLDAP ldapmodify client defaults to a SASL bind when the -x command line option is not specified.

The LDIF input can contain any number of entries to be modified, not just one:

Внесение изменений в систему OpenLDAP с помощью файлов LDIF

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

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

Требования

  • Сервер OpenLDAP, настроенный по мануалу Установка и настройка OpenLDAP и phpLDAPadmin в Ubuntu 14.04.
  • Знание базовой терминологии LDAP (читайте Основы протокола LDAP: иерархия данных и компоненты записей).

Формат LDIF

LDIF (или LDAP Data Interchange Format) – это текстовый формат для представления данных и команд LDAP. При использовании системы LDAP вы, скорее всего, будете использовать формат LDIF для указания данных и изменений, которые вы хотите внести в LDAP DIT.

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

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

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

Добавление записей в DIT

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

Перечисление записей в DIT

Самый простой способ определения новых записей для LDAP – это просто перечислить все записи целиком, точно так же, как они обычно отображаются инструментами LDAP. Запись начинается с DN (distinguished name, отличительное имя).

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

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

dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

Вы можете добавить несколько записей в один файл. Каждая запись должна быть отделена по крайней мере одной полностью пустой строкой:

dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

dn: ou=othergroup,dc=example,dc=com
objectClass: organizationalUnit
ou: othergroup

Как вы можете видеть, этот формат LDIF почти точно соответствует формату, который вы увидите при запросе записей с этой информацией из дерева LDAP.

Создание новой записи с помощью changetype: add

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

Это похоже на метод, который мы рассмотрели выше, но непосредственно под спецификацией DN нужно указать changetype: add. Например, чтобы добавить запись John Smith в DIT, который уже содержит структуру ou=People,dc=example,dc=com , используйте LDIF следующим образом:

dn: u > changetype: add
objectClass: inetOrgPerson
description: John Smith from Accounting. John is the project
manager of the building project, so contact him with any que
stions.
cn: John Smith
sn: Smith
uid: jsmith1

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

Также следует обратить внимание на использование многострочного значения для атрибута description. Поскольку следующие строки начинаются с пробела, они будут объединены, а пробелы удалены. Первая дополнительная строка в данном примере содержит еще один пробел, но это часть самого предложения, разделяющая слова «project» и «manager».

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

# Add John Smith to the organization
dn: u > changetype: add
objectClass: inetOrgPerson
description: John Smith from Accounting. John is the project
manager of the building project, so contact him with any qu
estions.
cn: John Smith
sn: Smith
uid: jsmith1

# Add Sally Brown to the organization
dn: u > changetype: add
objectClass: inetOrgPerson
description: Sally Brown from engineering. Sally is responsibl
e for designing the blue prints and testing the structural int
egrity of the design.
cn: Sally Brown
sn: Brown
uid: sbrown20

Обработка дополнительных записей

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

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

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

ldapadd -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f newgroups.ldif

Также можно использовать ldapmodify –a:

ldapmodify -a -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f newgroups.ldif

Если вы используете второй формат, с объявлением changetype, вам нужно будет использовать команду ldapmodify без флага -a. Поскольку эта команда и формат работают для большинства других модификаций, ее, вероятно, проще использовать в большинстве случаев. Если вы сохранили два дополнения в файле newusers.ldif, вы могли бы добавить новые записи в DIT с помощью команды:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f newusers.ldif

Это позволит вам добавлять записи в ваш DIT по своему усмотрению. Вы можете легко хранить много записей в одном LDIF-файле и заполнять свой DIT с помощью одной команды.

Удаление записей из DIT

При добавлении записей вы можете использовать опцию changetype. Этот параметр – метод для указания типа модификации высокого уровня. Для удаления записи нужно установить здесь значение delete

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

Например, чтобы удалить запись ou=othergroup из DIT, LDIF-файл должен содержать только это:

dn: ou=othergroup,dc=example,dc=com
changetype: delete

Чтобы обработать это изменение, вы можете использовать ldapmodify. Если файл с запросом удаления называется rmothergroup.ldif, применить его можно следующим образом:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f rmothergroup.ldif

Это удалит запись ou=othergroup.

Изменение атрибутов записи

Изменение атрибутов записи стало возможным с помощью changetype: modify после DN записи. Типы модификаций, которые вы можете внести в атрибуты, в основном отражают изменения, которые вы можете внести в собственную запись. Потому детали типа изменения запрашиваемого атрибута указываются впоследствии с помощью дополнительных директив.

Добавление атрибута в запись

Вы можете добавить атрибут, используя команду add: после changetype: modify. Она должна указывать атрибут, который вы хотите добавить. Затем вы должны установить значение атрибута. Таким образом получится такой формат:

dn: entry_to_add_attribute
changetype: modify
add: attribute_type
attribute_type: value_to_set

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

dn: u > changetype: modify
add: mail
mail: sbrown@example.com
dn: u > changetype: modify
add: mail
mail: jsmith1@example.com
mail: johnsmith@example.com

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

Вы можете обработать изменения с помощью ldapmodify, как обычно. Если изменение находится в файле sbrownaddmail.ldif, вы можете ввести:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f sbrownaddmail.ldif

Замена значения атрибута в записи

Изменение существующего значения для атрибута выполняется с помощью опции replace: под changetype: modify.

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

dn: u > changetype: modify
replace: mail
mail: sbrown2@example.com

Имейте в виду, что это заменит каждый экземпляр mail в записи. Это важно учитывать для многозначных атрибутов, которые для каждой записи могут быть определены более одного раза (например, почта). Если вы хотите заменить только одно вхождение атрибута, вы должны использовать параметр delete: (описанный ниже) в сочетании с опцией add: (описанный выше).

Если изменение хранится в файле sbrownchangemail.ldif, почту можно заменить с помощью:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f sbrownchangemail.ldif

Удаление атрибутов из записи

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

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

dn: u > changetype: modify
delete: description

А это удалит только почтовый адрес:

dn: u > changetype: modify
delete: mail
mail: jsmith1@example.com

Поскольку в этой записи указано два атрибута mail, второй атрибут останется в ней.

Если эти изменения находятся в файлах jsmithrmdesc.ldif и jsmithrmextramail.ldif, вы можете применить их так:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f jsmithrmdesc.ldif
ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f jsmithrmextramail.ldif

Внесение нескольких изменений в атрибуты

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

Например, чтобы удалить оставшийся атрибут email из записи John Smith, изменить его имя на Johnny Smith и добавить его местоположение, нужно создать файл со следующим содержимым:

dn: u > changetype: modify
delete: mail

replace: cn
cn: Johnny Smith

add: l
l: New York

Чтобы применить эти изменения с помощью одной команды, используйте ldapmodify:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f multichange.ldif

Переименование и перемещение записей

Параметр changetype: modrdn позволяет переименовывать или перемещать существующие записи. Для этого после указания целевого dn: нужно добавить параметр changetype: modrdn.

Переименование записи

Предположим, что вы сделали опечатку в имени пользователя, когда вводили его в систему. Поскольку имя используется в DN записи, его нельзя просто заменить параметром changetype: modify и replace:, поскольку RDN записи будет недействительным. Если имя пользователя sbrown200, вы могли бы изменить DN записи, создав все необходимые атрибуты в таком файле LDIF:

dn: u > changetype: modrdn
newrdn: u > deleteoldrdn: 0

Чтобы применить изменение, введите:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f fixsallydn.ldif

Теперь запись будет выглядеть так:

dn: u > objectClass: inetOrgPerson
description: Sally Brown from engineering. Sally is responsibl
e for designing the blue prints and testing the structural int
egrity of the design.
cn: Sally Brown
sn: Brown
uid: sbrown20
uid: sbrown200
mail: sbrown2@example.com

Как видите, теперь DN использует новую пару «ключ-значение». Для этого атрибут был добавлен в запись.

Возможно, в приведенном выше примере вы заметили две вещи. Во-первых, мы устанавливаем в опции deleteoldrdn значение 0. Во-вторых, в результате запись имеет uid: sbrown20 и uid: sbrown200.

Параметр deleteoldrdn устанавливается при изменении DN записи. Установка в deleteoldrdn значения «0» заставляет LDAP сохранить старый атрибут, используемый в DN, вместе с новым атрибутом в записи. Иногда это нужно, но чаще нужно полностью удалить старый атрибут из записи после изменения DN. Вы можете сделать это, установив в deleteoldrdn значение 1.

Предположим, что вы снова допустили ошибку, и имя пользователя должно быть Sally sbrown2. Установите в deleteoldrdn 1, чтобы после переименования удалить из записи экземпляр sbrown200, который в настоящее время используется в DN. Добавьте changetype: modify и delete:, чтобы избавиться от имени пользователя sbrown20, которое сохранилось во время первого переименования:

dn: u > changetype: modrdn
newrdn: u > deleteoldrdn: 1
dn: u > changetype: modify
delete: uid
uid: sbrown20

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f fix2sallydn.ldif

Перемещение записи

Если вам нужно переместить запись в новое место, нужно добавить дополнительную опцию changetype: modrdn и newsuperior:. При использовании этой опции вы можете указать новое местоположение в DIT для перемещения записи. Это поместит запись под указанным родительским DN во время изменения.

Например, чтобы переместить Sally в запись ou=superusers, нужно сделать следующее:

dn: ou=superusers,dc=example,dc=com
changetype: add
objectClass: organizationalUnit
ou: superusers
dn: u > changetype: modrdn
newrdn: u > deleteoldrdn: 0
newsuperior: ou=superusers,dc=example,dc=com

Если это было в файле mksuperuser.ldif, то применить изменения можно так:

ldapmodify -x -D «cn=admin,dc=example,dc=com» -w password -H ldap:// -f mksuperuser.ldif

Это переместит запись (но не скопирует ее).

В этом случае не нужно изменять RDN записи, поэтому мы установили в newrdn: то же значение, которое оно имеет в настоящее время. Вы могли бы легко переименовать запись во время перемещения. В этом случае настройка newsuperior: — единственная строка, которая фактически влияет на состояние записи.

Добавление бинарных данных в запись

LDAP имеет возможность хранить бинарные данные определенных атрибутов. Например, класс inetOrgPerson позволяет использовать атрибут jpegPhoto, который может использоваться для хранения фотографии или значка пользователя. Другим атрибутом objectClass, который может использовать бинарные данные, является атрибут audio.

Чтобы добавить этот тип данных в запись LDAP, вы должны использовать специальный формат. При указании атрибута, непосредственно после двоеточия, используйте символ меньше ( dn: u > changetype: modify
add: jpegPhoto
jpegPhoto:

Обратите внимание на размещение двоеточия, символа меньше и пробела. Если ваш файл находится на диске, можно использовать префикс file://. Путь добавит дополнительную косую черту, чтобы указать корневой каталог, если вы используете абсолютный путь.

Это будет работать аналогичным образом с аудио-файлом:

dn: u > changetype: modify
add: audio
audio:

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

Если вам нужно получить закодированные данные с помощью инструмента ldapsearch, добавьте флаг -t, который позволит записать файл в каталог /tmp. Сгенерированный файл будет указан в результатах. К примеру, вы можете использовать эту команду, чтобы записать бинарные данные во временный файл.

ldapsearch -LLL -x -H ldap:// -t -b «dc=example,dc=com» «u > dn: u > objectClass: inetOrgPerson
sn: Smith
uid: jsmith1
cn: Johnny Smith
l: New York
audio:

Если вы перейдете в каталог /tmp, вы сможете найти файл. По мере необходимости его можно переименовать.

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

The MODIFY operation¶

The Modify operation allows a client to request the modification of an entry already present in the LDAP directory.

To perform a Modify operation you must specify the dn of the entry and the kind of changes requested.

In the ldap3 library the signature for the Modify operation is:

  • dn: distinguished name of the object whose attributes must be modified
  • changes: a dictionary of changes to be performed on the specified entry
  • controls: additional controls to send in the request

For synchronous strategies the modify method returns True if the operation was successful, returns False in case of errors. In this case you can inspect the result attribute of the connection object to get the error description.

For asynchronous strategies the add method returns the message > get_response(message_id) method of the connection object. If you use the get_request=True parameter you get the request dictionary back.

There are 4 different kinds of change:

  • MODIFY_ADD: add values listed to the specified attribute, creating the attribute if necessary.
  • MODIFY_DELETE: delete values listed from the attribute. If no values are listed, or if all current values of the attribute are listed, the entire attribute is removed.
  • MODIFY_REPLACE: replace all existing values of the specified attribute with the new values listed, creating the attribute if it did not already exist. A replace with no values will delete the entire attribute if it exists, and it is ignored if the attribute does not exist.
  • MODIFY_INCREMENT: All existing values of the specified attribute are to be incremented by the listed value. The attribute must be appropriate for the request (e.g., it must have INTEGER or other increment-able values), and the modification must provide one and only one value. (RFC4525)

changes is a dictionary in the form

operation is MODIFY_ADD, MODIFY_DELETE, MODIFY_REPLACE, MODIFY_INCREMENT (import them from the ldap3 namespace)

The entire list of modifications is performed by the server in the order they are listed as a single atomic operation. While individual modifications may violate certain aspects of the directory schema (such as the object class definition and content rules), the resulting entry after the entire list of modifications is performed must conform to the requirements of the directory model and the controlling schema.

The Modify operation cannot be used to remove from an entry any of its distinguished values (the values which form the entry’s relative distinguished name).

Due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify operation.

You perform a Modify operation as in the following example (using the default synchronous strategy):

Extended logging¶

To get an idea of what happens when you perform a Modify operation this is the extended log from a session to an OpenLdap server from a Windows client with dual stack IP:

These are the usage metrics of this session:

LDAP.com

Lightweight Directory Access Protocol

The LDAP Modify Operation

A modify operation can be used to alter the contents of an existing entry in the directory server. A single modify operation can include changes that affect multiple attributes (as long as those attributes are all in the same entry), and all of those changes will be processed atomically, so that they will either all succeed or will all fail as a unit, and the server will not expose the entry in a partially-modified state. It is not possible for a modify operation to make any change that would ultimately remove any attribute value used in the entry’s RDN; a modify DN operation must be used for any change that would alter an entry’s DN.

A modify request includes the DN of the entry to update and a set of one or more modifications. Each modification includes a modification type, the attribute description for the target attribute, and an optional set of values. The following kinds of modifications are supported:

  • If the modification type is “add”, then there must be an attribute description and a set of values. If the specified attribute does not already exist in the target entry, then it will be added with all of the provided values. If the attribute does exist, then the provided values will be added to the existing values for that attribute. Under normal circumstances, a modify operation cannot be used to add a value that already exists in the entry.
  • If the modification type is “delete” and there is an attribute description without any values, then all values for the specified attribute will be removed from the entry. Under normal circumstances, a modify operation cannot be used with the delete modification type to remove an attribute that does not already exist (although the “replace” modification type can be used to accomplish this).
  • If the modification type is “delete” and there is an attribute description with one or more values, then only the specified values will be removed from the entry. Under normal circumstances, a modify operation cannot be used to delete an attribute value that does not already exist in the entry.
  • If the modification type is “replace” and there is an attribute description without any values, then all values for the specified attribute will be removed from the entry. If the specified attribute does not exist in the entry, then this will have no effect.
  • If the modification type is “replace” and there is an attribute description with one or more values, then any existing values for the specified attribute will be removed and replaced with the provided values. If the specified attribute did not previously have any values in the entry, then the attribute will be added with the provided set of values.
  • If the modification type is “increment”, then there must be an attribute description with exactly one value, and that value must be a positive or negative integer. The target attribute must exist in the entry with exactly one value, and that value must be an integer. The increment operation will update the specified attribute so that its new value will be the sum of the provided value and the existing value.

If a modify request includes multiple modifications, then they will be applied in the order that they are listed in the modify request. If one modification depends on another modification in the same request, then it should be listed after the modification on which it depends.

When a modify operation completes, the server will return a basic response that includes a result code, and optional matched DN, diagnostic message, referrals, and/or response controls. Some of the most common types of results for a modify operation include:

Функция ldap_modify через нарушение прав доступа?

Я пытаюсь изменить значение атрибута AD с помощью функции ldap_modify.

но, когда дело доходит до последней строки (. msgstr.

* Необработанное исключение в 0x76f693ac в AD2.exe: 0xC0000005: Доступ к чтению с ошибками 0xcccccccc. *

любезно помогите мне решить это. спасибо заранее.

Я могу догадаться из местоположения 0xcccccccc, что авария происходит из-за неинициализированного указателя. При чтении кода pLdapConnection выглядит как указатель.

Обновить

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

То есть размер массива должен быть больше, чем количество записей, которые вы хотите определить, и последний элемент массива должен быть NULL.

ldap_modify_ext_s function

The ldap_modify_ext_s function changes an existing entry.

Syntax

Parameters

The session handle.

A pointer to a null-terminated string that contains the name of the entry to modify.

A null-terminated array of modifications to make to the entry.

A list of LDAP server controls.

A list of client controls.

Return Value

If the function succeeds, the return value is LDAP_SUCCESS.

If the function fails, it returns an error code. See Return Values for more information.

Remarks

The ldap_modify_ext_s function initiates a synchronous operation to modify an existing entry. If values are being added or replaced in the entry, the function creates the attribute, if necessary. If values are being deleted, and no values remain, the function removes the attribute. All modifications are performed in the order in which they are listed.

The parameters and effects of ldap_modify_ext_s subsume those of ldap_modify_s. The extended routine includes additional parameters to support client and server controls.

Multithreading: Calls to ldap_modify_ext_s are thread-safe.

Что такое код ldap_modify

The LDAP modify DN operation can be used to change the distinguished name of an entry in the Directory Server. It can alter the RDN of the entry and/or it can move the entry below a new parent. If the target entry has subordinate entries, then it may be used to move or rename that subtree.

The modify DN request protocol op is defined as follows:

The modify DN request includes these elements:

The DN of the entry to rename and/or move.

The new RDN to use for the entry. If the entry is simply to be moved below a new parent, then it may be the same as the current RDN.

A flag that indicates whether the current RDN attribute values should be removed from the entry.

An optional DN specifying the new parent for the entry.

The response to an LDAP modify DN operation is an LDAP result as defined as follows:

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)

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

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

    Илон Маск рекомендует:  Передача изображения на сервер через форму, изменение его размера и сохранение на диск
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL