ITU (International Telecommunication Union) разработал серию рекомендаций для создания так называемого сервиса Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о различных объектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base - DIB). Информация включает имя объекта, а также различные атрибуты, характеризующие этот объект. Данные рекомендации носят название стандарта Х.500.
Для доступа к объектам этой распределенной базы данных был разработан Протокол Доступа к Каталогу (Directory Access Protocol – DAP).
LDAP (Lightweight Directory Access Protocol) предоставляет большинство возможностей DAP при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.
Однако не существует взаимно однозначного соответствия между операциями протокола LDAP и операциями протокола DAP стандарта Х.500.
LDAP - это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.
Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.
Общая модель данного протокола состоит в том, что сервер выполняет требуемые клиенту операции. Клиент передает запрос, описывающий операцию, которая должна быть выполнена сервером. Сервер выполняет необходимые операции в Каталоге. После завершения операции или нескольких операций сервер возвращает клиенту ответ, содержащий результаты или код ошибки.
Заметим, что хотя требуется, чтобы серверы возвращали ответы всякий раз, когда такие ответы определены в протоколе, не существует требования синхронного поведения клиентов или серверов. Запросы и ответы для нескольких операций могут пересылаться между клиентом и сервером в любом порядке, однако клиенты должны получить ответ на каждый свой запрос.
Информация на сервере LDAP представляет собой совокупность записей, которые содержат набор атрибутов и сгруппированы в древовидную иерархическую структуру.
Запись идентифицируется глобально уникальным именем (Distinguished Name – DN) – подобно имени домена в структуре DNS.
Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS.
Основные причины роста популярности LDAP связаны с тем, что:
Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:
При развертывании серверов LDAP необходимо выполнить следующие задачи:
Основными характеристиками LDAP, которые определяют его свойства, являются:
Рассмотрим информационную модель Каталога LDAP.
Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Инфор-мация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу, используя клиентское ПО. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.
DIB содержит следующие типы информации:
Функция Каталога состоит в том, чтобы хранить информацию об объектах и предоставлять к ней доступ. Объектом может быть все, что может быть идентифицировано (поименовано).
Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики. Каждый объект принадлежит по крайней мере одному классу. Класс объекта может быть подклассом других классов объектов, в этом случае члены первого класса (подкласса) также считаются членами второго класса (суперкласса). Цепочка подклассов может быть произвольной длины.
Запись Каталога – это поименованный набор информации. Она являет-ся основной единицей информации, хранящейся в Каталоге. Существует несколько видов записей Каталога.
Запись содержит информацию о конкретном объекте. Запись типа Alias (Псевдоним) обеспечивает способ альтернативного именования того же самого объекта.
Множество записей имеет иерархическую структуру дерева, которая называется Информационное Дерево Каталога – Directory Information Tree (DIT).
Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и alias-записи.
Информационное дерево Каталога
DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.
Дуги между вершинами определяют отношения между записями. Если существует дуга от Х к Y, то запись Х является родителем Y, и Y непосредственно подчиняется Х. Вышестоящими записями являются записи непосредственного родителя и его родителей. Подчиненными записями являются все записи, непосредственно подчиненные данной, и все их подчиненные.
Пример дерева Каталога:
(рис 13.1) Пример дерева Каталога
В данном случае dc=msu и dc=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.
Способ именования
LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:
Принципы именования следующие:
Относительные уникальные имена
Относительное уникальное имя (Relative Distinguished Name – RDN) является совокупностью некоторого множества записей.
Значения записей RDN должно быть уникальным среди всех непосред-ственных подчиненных вышестоящей записи.
Полные уникальные имена
Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет узел в дереве.
Приведем примеры DN:
(рис 13.2) Примеры DN
В LDAPv3 для представления уникального имени (DN) используется строка UTF-8.
Самым левым элементом является последний элемент в дереве. Далее через запятую перечисляются элементы более высоких уровней.
Уникальные имена имеют две части.
В приведенном выше примере RDN есть CN=olga
Базовое уникальное имя есть CN=Users,DC=olga,DC=oit,DC=cmc,DC=msu,DC=ru
Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.
Запись LDAP
Вся информация в LDAP хранится в записях.
Основные свойства записи:
Запись состоит из множества атрибутов, хранящих информацию об объекте. Некоторые атрибуты хранят пользовательскую информацию и называются пользовательскими атрибутами. Другие атрибуты хранят функциональную и/или административную информацию и называются функциональными атрибутами.
Тип атрибута определяет, может ли атрибут иметь несколько значений, синтаксис и правила соответствия, используемые при создании и сравнении значений данного атрибута, и другие функции.
Два значения атрибута считаются эквивалентными, если эти значения одинаковые в соответствии с правилами эквивалентности для данного типа атрибута. Если для типа атрибута не определено правило эквивалентности, то два значения два значения этого атрибута считаются эквивалентными, если они одинаковые с учетом чувствительности к регистру.
Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они не чувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.
Атрибуты
Атрибут состоит из имени атрибута и одного или более значений дан-ного атрибута.
Примеры имен атрибутов:
uid User id cn Common Name sn Surname l Расположение (Location) ou Организационная единица o Организация dc Контроллер Домена st Штат c Страна
Каждое значение атрибута должно быть уникальным, т.е. дублирова-ние не допускается.
(рис 13.3) Примеры атрибутов LDAP
Описания атрибута
Описание атрибута состоит из типа атрибута и возможно нескольких параметров атрибута.
(рис 13.4) Пример синтаксиса атрибутов LDAP
Тип атрибута определяет, может ли атрибут иметь несколько значений, как используются правила синтаксиса и соответствия при создании и сравнении значений данного атрибута, а также некоторые другие параметры.
Тип атрибута указывает, является атрибут пользовательским или функциональным. Если атрибут является функциональным, тип атрибута определяет его функциональное использование и указывает, может ли данный атрибут модифицироваться пользователем.
Тип атрибута (подтип) может быть получен из другого типа атрибута (прямого супертипа). Подтип наследует правила соответствия и синтаксис супертипа. Тип атрибута не может быть подтипом атрибута для другого применения, т.е. пользовательский подтип не может быть получен из функционального супертипа.
Каждый тип атрибута определяется идентификатором объекта (OID) и возможно одним или несколькими короткими именами (дескрипторами).
Значение атрибута
Значения атрибута должно соответствовать синтаксису, определенному для атрибута.
Когда атрибут используется в качестве имени записи, в RDN присутствует единственное значение данного атрибута. Это значение должно быть уникальным.
Схема
Схема Каталога предназначена для:
Схема содержит следующую информацию:
Схема Каталога представляет собой множество определений и ограничений, касающихся структуры DIT, а также возможных способов именования записей. Схема определяет информацию, которая может храниться в записи, атрибуты, используемые для представления этой информации и способ организации записей в иерархическую структуру, что обеспечивает возможность быстрого поиска.
Схема Каталога состоит из следующего множества определений:
a) Определение типов атрибутов, содержащих OID атрибута, синтаксис атрибута, связанные с ним правила соответствия, является он функциональным или пользовательским атрибу-том, может ли он иметь несколько значений и происходит ли от другого атрибута.
b) Определение классов объектов, описывающих множество обязательных и необязательных атрибутов.
c) Определение правил соответствия.
d) Определение синтаксиса, описывающего используемые правила представления.
(рис 13.5) Описываемые в Схеме определения
Класс объекта
Класс объекта группирует объекты, которые имеют общие характери-стики. Классы определяют необходимые и допустимые атрибуты.
Записи могут состоять из объектов нескольких классов. Необходимые и допустимые атрибуты записи являются объединением атрибутов каждого класса, из объектов которого состоит запись.
Класс объекта может являться наследником другого класса объекта, который в свою очередь может быть получен из более общего класса объекта. В этом случае первый класс называется подклассом, а второй суперк-лассом. Для классов структурных объектов самым общим классом является класс, называемый top. Упорядоченное множество суперклассов от наибо-лее общего класса объекта до данного класса объекта называется цепочкой суперклассов.
Каждый класс объекта определяет множество атрибутов, которые должны присутствовать в записях, принадлежащих классу, и множество атрибутов, которые могут присутствовать в этих записях. Класс объекта наследует множества допустимых и необходимых атрибутов от своих суперклассов.
Каждый класс объекта может быть одним из трех видов: абстрактный (Abstract), структурный (Structural) или вспомогательный (Auxiliary).
Каждый класс объекта идентифицируется своим идентификатором объекта (OID) и возможно одним или более именем.
Абстрактные классы объектов
Абстрактный (Abstract) класс объекта описывает основные характеристики, которыми должны обладать классы объектов, которые являются наследниками абстрактного класса.
Существует специальный класс, называемый top – все структурные и абстрактные классы являются его расширением. Для данного класса необходимым атрибутом является только objectClass. Это гарантирует, что все записи имеют атрибут objectClass.
Абстрактные классы не могут происходить от структурных или вспомогательных классов объектов.
Все структурные классы объектов получены от абстрактного класса top. Вспомогательные классы необязательно получены от top.
Записи могут иметь объекты только структурных и вспомогательных классов.
Структурные классы объектов
Структурный класс является подклассом абстрактного класса top.
Структурные классы не могут быть подклассом вспомогательных классов.
Вспомогательные классы объектов
Объекты вспомогательных классов (Auxiliary) используются для описания дополнительных характеристик записей. Обычно они применяются для расширения множества необходимых и допустимых атрибутов записи.
Объекты вспомогательных классов не могут принадлежать подклассам структурных классов.
Запись может иметь любое количество объектов вспомогательных классов.
Множество объектов вспомогательных классов, которые принадлежат записи, может со временем изменяться.
Наследование классов объектов
Наследование классов объектов обладает следующими свойствами:
Правила синтаксиса
Каждый атрибут, хранящийся в Каталоге, имеет определенный синтаксис. Примером синтаксиса является тип данных. Синтаксис накладывает ограничения на структуру и формат значений атрибута. Сравнение значений не является частью определения синтаксиса, а задается отдельно правилами соответствия. Рассмотрим базовое множество синтаксисов и правил соответствия, которые используются для атрибутов Каталога.
Правила синтаксиса ограничивают возможные значения атрибутов, хранящихся в Каталоге, и определяют представление атрибутов и значений выражений, передаваемых в протоколе LDAP.
Правила соответствия
Правила соответствия используются Каталогом для сравнения значений атрибутов при выполнении операций Search и Compare. Они также используются для поиска DN. При модификации записей правила сравне-ния применяются для нахождения значений, которые должны изменяться или удаляться, и для предотвращения того, чтобы атрибут содержал два одинаковых с точки зрения правил соответствия значения.
LDIF
LDIF (LDAP Data Interchange Format) является форматом обмена данными и обладает следующими свойствами:
Используется для изменений большого количества данных по следующему принципу:
Протокол LDAP предполагает, что существует один или несколько серверов, которые совместно предоставляют доступ к Информационному Дереву Каталога (DIT).
(рис 13.6) Пример распределенного множества серверов LDAP
Каждый сервер содержит определенное поддерево DIT.
Разработка топологии
Дерево Каталога может быть распределено по нескольким физическим серверам.
Использование распределенной топологии обеспечивает:
При использовании распределенной топологии пользователи видят один большой Каталог, хотя каждому серверу делегируется только некоторая его часть.
Распределенная структура Каталогов во многом аналогична распределенной структуре серверов DNS.
Ссылки (Referral)
Для реализации распределенной топологии LDAP-Сервер может содержать ссылки (referral) на другие LDAP-серверы. Эти ссылки используются в операциях поиска, что обеспечивает клиенту возможность получения информации от нескольких серверов.
(рис 13.7) Взаимодействие серверов LDAP
Рассмотрим последовательность запросов при поиске клиентом информации в Каталоге.
Код результата поиска может указывать, что сервер, с которым осуществляется соединение, не содержит целевой записи. В этом случае сервер присылает ссылку на другой сервер в поле referral. Это поле содержит одну или несколько ссылок на один или несколько серверов или сервисов, которые могут быть доступны по протоколу LDAP или по другим протоколам. Такие ссылки могут быть возвращены в ответе для любого запроса операции (исключая операции unbind и abandon, которые не имеют ответа). По крайней мере один URL должен быть указан в поле referral.
Если клиент продолжает выполнение операции, он должен следовать по ссылке для установления соединения с указанным сервером. Если присутствует несколько URL, считается, что для дальнейшего выполнения операции может использоваться любой URL.
В URL для протокола LDAP содержится DN, который указывает имя объекта. Если DN в ответе присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, а если DN в ответе отсутствует, клиент будет использовать то же самое имя, что и в начальном запросе. Некоторые серверы (например, участвующие в распределенном индексировании) могут указать в ссылке различные фильтры для операции поиска. Если фильтр в URL присутствует, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, если фильтр отсутствует, клиент должен использовать тот же фильтр, который он использовал ранее для данного запроса. Другие аспекты нового запроса могут быть как теми же самыми, так и отличаться от запроса, в результате которого была получена ссылка.
Имя корневого контекста
Имя корневого контекста является записью верхнего уровня для каждого сервера. Некоторые серверы могут иметь несколько имен корневого контекста.
LDAP-Сервер предоставляет информацию об имени корневого контекста в атрибуте baseDN.
(рис 13.8) Определение baseDN сервера
Корневой контекст является набором атрибутов, который зависит от конкретного сервера. Значения этих атрибутов можно получить, выполнив поиск объекта с фильтром (objectClass=*).
Основные свойства протокола LDAP:
Для обеспечения расширяемости клиенты и серверы должны игнорировать те элементы, чьи теги они не распознали.
Клиент указывает версию, которую он использует как часть запроса bind. Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны передавать данный атрибут.
(рис 13.9) Параметр baseDN (Base Object) на стороне клиента
В протоколе LDAP определены следующие операции:
bindRequest bindResponse unbindRequest searchRequest searchResEntry searchResDone searchResRef modifyRequest modifyResponse addRequest addResponse delRequest delResponse modDNRequest modDNResponse compareRequest compareResponse abandonRequest extendedReq extendedResp
Все сообщения протокола имеют общий конверт, содержащий поля, необходимые всем операциям протокола. В настоящий момент общими полями являются только MessageID и, возможно, controls.
(рис 13.10) Пример сообщения searchRequest
MessageID из запроса должно иметь ненулевое значение, отличное от значений в любых других запросах для данного LDAP-соединения, частью которого является данное сообщение. Обычно клиенты увеличивают значение MessageID для каждого запроса.
Ответы сервера содержат значение MessageID из соответствующего запроса.
Control представляет собой способ указать дополнительную информацию в LDAP-сообщении. Control только изменяет семантику сообщения, к которому он присоединен.
Результат выполнения операции возвращается в поле resultCode, которое может принимать следующие значения:
Success (0) operationsError (1) protocolError (2) timeLimitExceeded (3) sizeLimitExceeded (4) compareFalse (5) compareTrue (6) authMethodNotSupported (7) strongAuthRequired (8) referral (10) adminLimitExceeded (11) unavailableCriticalExtension (12) confidentialityRequired (13) saslBindInProgress (14) noSuchAttribute (16) undefinedAttributeType (17) inappropriateMatching (18) constraintViolation (19) attributeOrValueExists (20) invalidAttributeSyntax (21) - 22-31 неиспользуются -- noSuchObject (32) aliasProblem (33) invalidDNSyntax (34) -- 35 зарезервировано для неопределенного isLeaf -- aliasDereferencingProblem (36) - 37-47 неиспользуются -- inappropriateAuthentication (48) invalidCredentials (49) insufficientAccessRights (50) busy (51) unavailable (52) unwillingToPerform (53) loopDetect (54) - 55-63 неиспользуются -- namingViolation (64) objectClassViolation (65) notAllowedOnNonLeaf (66) notAllowedOnRDN (67) entryAlreadyExists (68) objectClassModsProhibited (69) - 70 reserved for CLDAP -- affectsMultipleDSAs (71) - 72-79 не используются -- other (80)
Коды результата являются расширяемыми.
В протоколе определено 9 операций:
SearchCompareAddDeleteModifyRenameBindUnbindAbandon
(рис 13.11) Типичные переговоры LDAP
Операция Bind
Операция Bind передает аутентификационную информацию от клиента к серверу.
(рис 13.12) Пример сообщения bindRequest
Параметрами запроса Bind являются:
Version: номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоры о номере версии не ведутся, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в сообщении BindResponce.Name: имя объекта Каталога, от имени которого клиент хочет установить соединение. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного соединения или при использовании SASL-аутентификации.Authentication: информация, используемая для аутентификации имени, указанного в запросе Bind. Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind. Аутентификацию с использованием механизмов SASL мы рассматривать не будем.Ответ Bind определяется следующим образом.
(рис 13.13) Пример сообщения bindResponse
BindResponce содержит статус запроса клиента на аутентификацию.
Если доступ разрешен, то resultCode будет Success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.
Операция Unbind
Назначение операции Unbind состоит в завершении сессии протокола.
Операция Unbind не имеет ответа. После передачи UnbindRequest клиент должен предполагать, что сессия протокола завершена. После получения UnbindRequest сервер должен предполагать, что клиент завершил сессию, и все исходящие ответы сервер сбрасывает и закрывает соединение.
Операция Search
Операция Search позволяет клиенту запрашивать выполнение поиска на сервере. Это может использоваться для чтения атрибутов из единственной записи, из записей, непосредственно следующих за конкретной записью, или из целого поддерева записей.
Сообщение Search Request имеет следующие параметры:
baseObject - LDAPDN,
scope
baseObject (0),
singleLevel (1),
wholeSubtree (2) ,
derefAliases
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- по крайней мере один должен присутствовать,
-- initial и final могут быть указаны только один раз
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue }
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
Перечислим параметры Search Request:
BaseObject: базовый объект, относительно которого будет выполняться поиск.Scope: указание области поиска.
Может существовать три типа области поиска:
baseObject - ограничивается только базовым объектом.singleLevel - ограничивается только непосредственно подчиненными объектами.wholeSubtree - поиск во всем поддереве данной записи.
(рис 13.14) Область baseObject
(рис 13.15) Область singleLevel
(рис 13.16) Область wholeSubtreeDerefAliases: указание того, как выполняется поиск объекта. Семантика возможных значений данного поля следующая:
NeverDerefAliases: не выполняются переходы по ссылкам для aliases при поиске или при размещении базового объекта поиска.DerefInSearching: выполняется переход по ссылкам aliases, подчиненных базовому объекту поиска.DerefFindingBaseObj: выполняется переход по ссылкам aliases, размещенных в базовом объекте по-иска, но не в подчиненных базовому объекту.DerefAlways: выполняется переход по ссылкам aliases как при поиске, так и при размещении базового объекта поиска.SizeLimit: ограничение максимального количества записей, возвращаемых в качестве результата поиска. Значение 0 в данном поле указывает, что при поиске нет ограничения. Сервер сам определяет максимальное количество возвращаемых записей.TimeLimit: ограничение, определяющее максимальное время поиска (в секундах). Значение 0 в данном поле указывает, что ограничений по времени при запросах клиента не существует.TypesOnly: индикатор того, что результаты поиска содержат и типы, и значения атрибутов или только типы атрибутов. При установке данного значения в TRUE будут возвращаться только типы атрибутов. При установке данного значения в FALSE будут возвращаться и типы, и значения атрибутов.Filter: фильтр определяет условия, которые должны быть выполнены. and, or и not используются для комбинирования фильтров. По крайней мере один элемент фильтра должен присутствовать.
Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо "TRUE", либо "FALSE", либо "Undefined". Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined, то данная запись при поиске игнорируется.
Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.
Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.
Правило соответствия для элементов фильтра greaterOrEqual и lessOrEqual определяется правилом соответствия ORDERING для типа атрибута.
Семантика соответствия для элементов фильтра approxMatch определяется реализацией.
Attributes: список атрибутов, возвращаемый для каждой записи, которая соответствует фильтру поиска. Могут использоваться два специальных значения: пустой список без атрибутов и атрибут, описываемый строкой "*". Оба значения говорят о том, что возвращаются все пользовательские атрибуты.Следует заметить, что если запрошены все пользовательские атрибуты, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены.
Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в Search Responses, которые являются LDAP-сообщениями, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.
SearchResultEntry::= SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList
}
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
-- следуетзаметить, что PartialAttributeList может
-- иметь ноль элементов (если ни один из атрибутов затре-бованной записи
-- не может быть возвращен) и что множество vals
-- может также иметь ноль элементов (если запрошены только типы или
-- все значения были исключены из результата)
SearchResultReference::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- по крайней мере один элемент LDAPURL должен присут-ствовать
SearchResultDone ::= [APPLICATION 5] LDAPResult
После получения Search Request сервер будет выполнять необходимый поиск в DIT.
Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).
Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.
(рис 13.17) Пример запроса searchRequest
(рис 13.18) Пример ответа searchResEntry
Операция Modify
Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify имеет следующие параметры:
object LDAPDN,
modification
operation
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
Перечислимпараметрызапроса Modify:
Object: модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не использует никаких alias для определения модифицируемой записи.Modification: список выполняемых изменений. Список из-менений должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные из-менения могут нарушать схему Каталога, результирующая запись, после того как весь список изменений выполнен, должна соответствовать требованиям схемы Каталога. Значения поля operation имеют следующую семантику:
Add: добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.Delete: удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или если удалены все текущие значения атрибута.Replace: замена значений данного атрибута новыми; если атрибута не существует, он создается. Если при замене не указаны новые значения, то атрибут удаляется, если он есть, и игнорируется, если атрибута не существует.Результат изменения, которое пытался выполнить сервер при получении Modify Request, возвращается в Modify Response.
При получении Modify Request сервер выполняет необходимые изменения в DIT.
Сервер возвращает клиенту единственный Modify Response, указывающий либо на успешное завершение изменения DIT, либо на причину неудачного завершения. Заметим, что в силу требования атомарности применения списка изменений в Modify Request, клиент может считать, что ни одно изменение DIT не выполнено, если полученный Modify Response указывает на какую-либо ошибку, и что все запрошенные изменения про-шли успешно, если Modify Response указывает на успешное завершение операции изменения.
Операция Modify не может быть использована для удаления из записи любого полного уникального имени и тех значений, которые формируют относительное уникальное имя записи. Попытка сделать это приведет к тому, что сервер вернет ошибку notAllowedOnRDN. Для переименования записи используется операция Modify DN, которая будет описана ниже.
Операция Add
Операция Add позволяет клиенту запросить добавление записи в Каталог. Add Request имеет следующие параметры:
entry LDAPDN,
attributes AttributeList
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
Параметрами Add Request являются:
Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют RDN записи), атрибут objectClass и значения всех обязательных атрибутов классов объектов данной записи. Клиенты не должны указывать атрибуты, которые не могут модифицироваться пользователем, такие как createTimestamp или creatorName атрибуты, так как сервер создает их автоматически.Запись, указанная в поле entry в AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example,DC=NET, но запись DC=Example, DC=NET не существует, а запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.
Операция Delete
Операция Delete позволяет клиенту запросить удаление записи из Каталога.
Сообщение Delete Request состоит из DN удаляемой записи. Заметим, что сервер не переходит по aliases, и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.
Результат операции удаления, выполненной сервером при получении сообщения Delete Request, возвращается в сообщении Delete Response.
Операция Modify DN
Операция Modify DN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. Сообщение Modify DN Request имеет следующие параметры:
entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDNOPTIONAL
Параметрами Modify DN Request являются:
Entry: DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.Newdn: RDN определяет левый компонент нового имени записи.Deleteoldrdn: Параметр типа boolean, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.newSuperior: если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.Результат попытки изменения имени сервером при получении сообщения Modify DN Request возвращается в сообщении Modify DN Response.
Например, если запись, указанная в параметре entry, была cn=OlgaLaponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция завершится с кодом ошибки entryAlreadyExists.
Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.
Если параметр deleteoldrdn есть TRUE, то значения, формирующие старый RDN, удаляются из записи. Если параметр deleteoldrdn есть FALSE, то значения, формирующие старый RDN, остаются как значения неуникального атрибута записи. Сервер может не выполнить операцию и вернуть код ошибки, если установка параметра deleteoldrdn противоречит Схеме.
Операция Compare
Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. Compare Request имеет следующие параметры:
entry LDAPDN, ava AttributeValueAssertion
Перечислим параметры CompareRequest:
Entry: имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.Ava: утверждение, с которым сравнивается атрибут записи.Результат сравнения, выполненного сервером при получении Compare Request, возвращается в Compare Response.
При получении Compare Request сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.
Заметим, что управление доступом может быть организовано таким образом, чтобы значения некоторых атрибутов (таких как userPassword) сравнивались или запрашивались другими способами.
Операция Abandon
Операция Abandon предоставляет возможность создания запроса на прерывание сервером выполняющейся операции.
MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от идентификатора более ранней операции, для которой был выполнен Abandon.
Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в Abandon Request. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполнив новую операцию bind.
Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, модификации) определяется сервером.
В том случае, если сервер получил Abandon Request для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.
Клиенты не должны несколько раз посылать запросы Abandon для одной и той же операции, но должны обрабатывать полученные результаты прерванных операций (так как они могли быть уже переданы после полу-чения Abandon и не могли быть прерваны).
Серверы сбрасывают запросы Abandon для тех MessageID, которые они не распознали, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.
Дополнительные операции
В версию 3 LDAP добавлен расширенный механизм, позволяющий определять дополнительные операции для сервисов, которые ранее не были доступны в протоколе LDAP, например для операций цифровой подписи.
Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.
requestName LDAPOID, requestValue OCTET STRING OPTIONAL
requestName есть OBJECT IDENTIFIER операции requestValue содержит информацию в том виде, в котором она определена в операции. Данная информация инкапсулирована в строку октетов.
Сервер отвечает LDAPMessage, содержащим ExtendedResponse.
COMPONENTS OF LDAPResult, ResponseName LDAPOID OPTIONAL, Response OCTET STRING OPTIONAL
Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.
ITU (International Telecommunication Union) разработал серию рекомендаций для создания так называемого сервиса Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о различных объектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base - DIB). Информация включает имя объекта, а также различные атрибуты, характеризующие этот объект. Данные рекомендации носят название стандарта Х.500.
Для доступа к объектам этой распределенной базы данных был разработан Протокол Доступа к Каталогу (Directory Access Protocol – DAP).
LDAP (Lightweight Directory Access Protocol) предоставляет большинство возможностей DAP при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.
Однако не существует взаимно однозначного соответствия между операциями протокола LDAP и операциями протокола DAP стандарта Х.500.
LDAP - это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.
Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.
Общая модель данного протокола состоит в том, что сервер выполняет требуемые клиенту операции. Клиент передает запрос, описывающий операцию, которая должна быть выполнена сервером. Сервер выполняет необходимые операции в Каталоге. После завершения операции или нескольких операций сервер возвращает клиенту ответ, содержащий результаты или код ошибки.
Заметим, что хотя требуется, чтобы серверы возвращали ответы всякий раз, когда такие ответы определены в протоколе, не существует требования синхронного поведения клиентов или серверов. Запросы и ответы для нескольких операций могут пересылаться между клиентом и сервером в любом порядке, однако клиенты должны получить ответ на каждый свой запрос.
Информация на сервере LDAP представляет собой совокупность записей, которые содержат набор атрибутов и сгруппированы в древовидную иерархическую структуру.
Запись идентифицируется глобально уникальным именем (Distinguished Name – DN) – подобно имени домена в структуре DNS.
Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS.
Основные причины роста популярности LDAP связаны с тем, что:
Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:
При развертывании серверов LDAP необходимо выполнить следующие задачи:
Основными характеристиками LDAP, которые определяют его свойства, являются:
Рассмотрим информационную модель Каталога LDAP.
Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Инфор-мация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу, используя клиентское ПО. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.
DIB содержит следующие типы информации:
Функция Каталога состоит в том, чтобы хранить информацию об объектах и предоставлять к ней доступ. Объектом может быть все, что может быть идентифицировано (поименовано).
Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики. Каждый объект принадлежит по крайней мере одному классу. Класс объекта может быть подклассом других классов объектов, в этом случае члены первого класса (подкласса) также считаются членами второго класса (суперкласса). Цепочка подклассов может быть произвольной длины.
Запись Каталога – это поименованный набор информации. Она являет-ся основной единицей информации, хранящейся в Каталоге. Существует несколько видов записей Каталога.
Запись содержит информацию о конкретном объекте. Запись типа Alias (Псевдоним) обеспечивает способ альтернативного именования того же самого объекта.
Множество записей имеет иерархическую структуру дерева, которая называется Информационное Дерево Каталога – Directory Information Tree (DIT).
Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и alias-записи.
Информационное дерево Каталога
DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.
Дуги между вершинами определяют отношения между записями. Если существует дуга от Х к Y, то запись Х является родителем Y, и Y непосредственно подчиняется Х. Вышестоящими записями являются записи непосредственного родителя и его родителей. Подчиненными записями являются все записи, непосредственно подчиненные данной, и все их подчиненные.
Пример дерева Каталога:
(рис 13.1) Пример дерева Каталога
В данном случае dc=msu и dc=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.
Способ именования
LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:
Принципы именования следующие:
Относительные уникальные имена
Относительное уникальное имя (Relative Distinguished Name – RDN) является совокупностью некоторого множества записей.
Значения записей RDN должно быть уникальным среди всех непосред-ственных подчиненных вышестоящей записи.
Полные уникальные имена
Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет узел в дереве.
Приведем примеры DN:
(рис 13.2) Примеры DN
В LDAPv3 для представления уникального имени (DN) используется строка UTF-8.
Самым левым элементом является последний элемент в дереве. Далее через запятую перечисляются элементы более высоких уровней.
Уникальные имена имеют две части.
В приведенном выше примере RDN есть CN=olga
Базовое уникальное имя есть CN=Users,DC=olga,DC=oit,DC=cmc,DC=msu,DC=ru
Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.
Запись LDAP
Вся информация в LDAP хранится в записях.
Основные свойства записи:
Запись состоит из множества атрибутов, хранящих информацию об объекте. Некоторые атрибуты хранят пользовательскую информацию и называются пользовательскими атрибутами. Другие атрибуты хранят функциональную и/или административную информацию и называются функциональными атрибутами.
Тип атрибута определяет, может ли атрибут иметь несколько значений, синтаксис и правила соответствия, используемые при создании и сравнении значений данного атрибута, и другие функции.
Два значения атрибута считаются эквивалентными, если эти значения одинаковые в соответствии с правилами эквивалентности для данного типа атрибута. Если для типа атрибута не определено правило эквивалентности, то два значения два значения этого атрибута считаются эквивалентными, если они одинаковые с учетом чувствительности к регистру.
Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они не чувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.
Атрибуты
Атрибут состоит из имени атрибута и одного или более значений дан-ного атрибута.
Примеры имен атрибутов:
uid User id cn Common Name sn Surname l Расположение (Location) ou Организационная единица o Организация dc Контроллер Домена st Штат c Страна
Каждое значение атрибута должно быть уникальным, т.е. дублирова-ние не допускается.
(рис 13.3) Примеры атрибутов LDAP
Описания атрибута
Описание атрибута состоит из типа атрибута и возможно нескольких параметров атрибута.
(рис 13.4) Пример синтаксиса атрибутов LDAP
Тип атрибута определяет, может ли атрибут иметь несколько значений, как используются правила синтаксиса и соответствия при создании и сравнении значений данного атрибута, а также некоторые другие параметры.
Тип атрибута указывает, является атрибут пользовательским или функциональным. Если атрибут является функциональным, тип атрибута определяет его функциональное использование и указывает, может ли данный атрибут модифицироваться пользователем.
Тип атрибута (подтип) может быть получен из другого типа атрибута (прямого супертипа). Подтип наследует правила соответствия и синтаксис супертипа. Тип атрибута не может быть подтипом атрибута для другого применения, т.е. пользовательский подтип не может быть получен из функционального супертипа.
Каждый тип атрибута определяется идентификатором объекта (OID) и возможно одним или несколькими короткими именами (дескрипторами).
Значение атрибута
Значения атрибута должно соответствовать синтаксису, определенному для атрибута.
Когда атрибут используется в качестве имени записи, в RDN присутствует единственное значение данного атрибута. Это значение должно быть уникальным.
Схема
Схема Каталога предназначена для:
Схема содержит следующую информацию:
Схема Каталога представляет собой множество определений и ограничений, касающихся структуры DIT, а также возможных способов именования записей. Схема определяет информацию, которая может храниться в записи, атрибуты, используемые для представления этой информации и способ организации записей в иерархическую структуру, что обеспечивает возможность быстрого поиска.
Схема Каталога состоит из следующего множества определений:
a) Определение типов атрибутов, содержащих OID атрибута, синтаксис атрибута, связанные с ним правила соответствия, является он функциональным или пользовательским атрибу-том, может ли он иметь несколько значений и происходит ли от другого атрибута.
b) Определение классов объектов, описывающих множество обязательных и необязательных атрибутов.
c) Определение правил соответствия.
d) Определение синтаксиса, описывающего используемые правила представления.
(рис 13.5) Описываемые в Схеме определения
Класс объекта
Класс объекта группирует объекты, которые имеют общие характери-стики. Классы определяют необходимые и допустимые атрибуты.
Записи могут состоять из объектов нескольких классов. Необходимые и допустимые атрибуты записи являются объединением атрибутов каждого класса, из объектов которого состоит запись.
Класс объекта может являться наследником другого класса объекта, который в свою очередь может быть получен из более общего класса объекта. В этом случае первый класс называется подклассом, а второй суперк-лассом. Для классов структурных объектов самым общим классом является класс, называемый top. Упорядоченное множество суперклассов от наибо-лее общего класса объекта до данного класса объекта называется цепочкой суперклассов.
Каждый класс объекта определяет множество атрибутов, которые должны присутствовать в записях, принадлежащих классу, и множество атрибутов, которые могут присутствовать в этих записях. Класс объекта наследует множества допустимых и необходимых атрибутов от своих суперклассов.
Каждый класс объекта может быть одним из трех видов: абстрактный (Abstract), структурный (Structural) или вспомогательный (Auxiliary).
Каждый класс объекта идентифицируется своим идентификатором объекта (OID) и возможно одним или более именем.
Абстрактные классы объектов
Абстрактный (Abstract) класс объекта описывает основные характеристики, которыми должны обладать классы объектов, которые являются наследниками абстрактного класса.
Существует специальный класс, называемый top – все структурные и абстрактные классы являются его расширением. Для данного класса необходимым атрибутом является только objectClass. Это гарантирует, что все записи имеют атрибут objectClass.
Абстрактные классы не могут происходить от структурных или вспомогательных классов объектов.
Все структурные классы объектов получены от абстрактного класса top. Вспомогательные классы необязательно получены от top.
Записи могут иметь объекты только структурных и вспомогательных классов.
Структурные классы объектов
Структурный класс является подклассом абстрактного класса top.
Структурные классы не могут быть подклассом вспомогательных классов.
Вспомогательные классы объектов
Объекты вспомогательных классов (Auxiliary) используются для описания дополнительных характеристик записей. Обычно они применяются для расширения множества необходимых и допустимых атрибутов записи.
Объекты вспомогательных классов не могут принадлежать подклассам структурных классов.
Запись может иметь любое количество объектов вспомогательных классов.
Множество объектов вспомогательных классов, которые принадлежат записи, может со временем изменяться.
Наследование классов объектов
Наследование классов объектов обладает следующими свойствами:
Правила синтаксиса
Каждый атрибут, хранящийся в Каталоге, имеет определенный синтаксис. Примером синтаксиса является тип данных. Синтаксис накладывает ограничения на структуру и формат значений атрибута. Сравнение значений не является частью определения синтаксиса, а задается отдельно правилами соответствия. Рассмотрим базовое множество синтаксисов и правил соответствия, которые используются для атрибутов Каталога.
Правила синтаксиса ограничивают возможные значения атрибутов, хранящихся в Каталоге, и определяют представление атрибутов и значений выражений, передаваемых в протоколе LDAP.
Правила соответствия
Правила соответствия используются Каталогом для сравнения значений атрибутов при выполнении операций Search и Compare. Они также используются для поиска DN. При модификации записей правила сравне-ния применяются для нахождения значений, которые должны изменяться или удаляться, и для предотвращения того, чтобы атрибут содержал два одинаковых с точки зрения правил соответствия значения.
LDIF
LDIF (LDAP Data Interchange Format) является форматом обмена данными и обладает следующими свойствами:
Используется для изменений большого количества данных по следующему принципу:
Протокол LDAP предполагает, что существует один или несколько серверов, которые совместно предоставляют доступ к Информационному Дереву Каталога (DIT).
(рис 13.6) Пример распределенного множества серверов LDAP
Каждый сервер содержит определенное поддерево DIT.
Разработка топологии
Дерево Каталога может быть распределено по нескольким физическим серверам.
Использование распределенной топологии обеспечивает:
При использовании распределенной топологии пользователи видят один большой Каталог, хотя каждому серверу делегируется только некоторая его часть.
Распределенная структура Каталогов во многом аналогична распределенной структуре серверов DNS.
Ссылки (Referral)
Для реализации распределенной топологии LDAP-Сервер может содержать ссылки (referral) на другие LDAP-серверы. Эти ссылки используются в операциях поиска, что обеспечивает клиенту возможность получения информации от нескольких серверов.
(рис 13.7) Взаимодействие серверов LDAP
Рассмотрим последовательность запросов при поиске клиентом информации в Каталоге.
Код результата поиска может указывать, что сервер, с которым осуществляется соединение, не содержит целевой записи. В этом случае сервер присылает ссылку на другой сервер в поле referral. Это поле содержит одну или несколько ссылок на один или несколько серверов или сервисов, которые могут быть доступны по протоколу LDAP или по другим протоколам. Такие ссылки могут быть возвращены в ответе для любого запроса операции (исключая операции unbind и abandon, которые не имеют ответа). По крайней мере один URL должен быть указан в поле referral.
Если клиент продолжает выполнение операции, он должен следовать по ссылке для установления соединения с указанным сервером. Если присутствует несколько URL, считается, что для дальнейшего выполнения операции может использоваться любой URL.
В URL для протокола LDAP содержится DN, который указывает имя объекта. Если DN в ответе присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, а если DN в ответе отсутствует, клиент будет использовать то же самое имя, что и в начальном запросе. Некоторые серверы (например, участвующие в распределенном индексировании) могут указать в ссылке различные фильтры для операции поиска. Если фильтр в URL присутствует, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, если фильтр отсутствует, клиент должен использовать тот же фильтр, который он использовал ранее для данного запроса. Другие аспекты нового запроса могут быть как теми же самыми, так и отличаться от запроса, в результате которого была получена ссылка.
Имя корневого контекста
Имя корневого контекста является записью верхнего уровня для каждого сервера. Некоторые серверы могут иметь несколько имен корневого контекста.
LDAP-Сервер предоставляет информацию об имени корневого контекста в атрибуте baseDN.
(рис 13.8) Определение baseDN сервера
Корневой контекст является набором атрибутов, который зависит от конкретного сервера. Значения этих атрибутов можно получить, выполнив поиск объекта с фильтром (objectClass=*).
Основные свойства протокола LDAP:
Для обеспечения расширяемости клиенты и серверы должны игнорировать те элементы, чьи теги они не распознали.
Клиент указывает версию, которую он использует как часть запроса bind. Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны передавать данный атрибут.
(рис 13.9) Параметр baseDN (Base Object) на стороне клиента
В протоколе LDAP определены следующие операции:
bindRequest bindResponse unbindRequest searchRequest searchResEntry searchResDone searchResRef modifyRequest modifyResponse addRequest addResponse delRequest delResponse modDNRequest modDNResponse compareRequest compareResponse abandonRequest extendedReq extendedResp
Все сообщения протокола имеют общий конверт, содержащий поля, необходимые всем операциям протокола. В настоящий момент общими полями являются только MessageID и, возможно, controls.
(рис 13.10) Пример сообщения searchRequest
MessageID из запроса должно иметь ненулевое значение, отличное от значений в любых других запросах для данного LDAP-соединения, частью которого является данное сообщение. Обычно клиенты увеличивают значение MessageID для каждого запроса.
Ответы сервера содержат значение MessageID из соответствующего запроса.
Control представляет собой способ указать дополнительную информацию в LDAP-сообщении. Control только изменяет семантику сообщения, к которому он присоединен.
Результат выполнения операции возвращается в поле resultCode, которое может принимать следующие значения:
Success (0) operationsError (1) protocolError (2) timeLimitExceeded (3) sizeLimitExceeded (4) compareFalse (5) compareTrue (6) authMethodNotSupported (7) strongAuthRequired (8) referral (10) adminLimitExceeded (11) unavailableCriticalExtension (12) confidentialityRequired (13) saslBindInProgress (14) noSuchAttribute (16) undefinedAttributeType (17) inappropriateMatching (18) constraintViolation (19) attributeOrValueExists (20) invalidAttributeSyntax (21) - 22-31 неиспользуются -- noSuchObject (32) aliasProblem (33) invalidDNSyntax (34) -- 35 зарезервировано для неопределенного isLeaf -- aliasDereferencingProblem (36) - 37-47 неиспользуются -- inappropriateAuthentication (48) invalidCredentials (49) insufficientAccessRights (50) busy (51) unavailable (52) unwillingToPerform (53) loopDetect (54) - 55-63 неиспользуются -- namingViolation (64) objectClassViolation (65) notAllowedOnNonLeaf (66) notAllowedOnRDN (67) entryAlreadyExists (68) objectClassModsProhibited (69) - 70 reserved for CLDAP -- affectsMultipleDSAs (71) - 72-79 не используются -- other (80)
Коды результата являются расширяемыми.
В протоколе определено 9 операций:
SearchCompareAddDeleteModifyRenameBindUnbindAbandon(рис 13.11) Типичные переговоры LDAP
Операция Bind
Операция Bind передает аутентификационную информацию от клиента к серверу.
(рис 13.12) Пример сообщения bindRequest
Параметрами запроса Bind являются:
Version: номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоры о номере версии не ведутся, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в сообщении BindResponce.Name: имя объекта Каталога, от имени которого клиент хочет установить соединение. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного соединения или при использовании SASL-аутентификации.Authentication: информация, используемая для аутентификации имени, указанного в запросе Bind. Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind. Аутентификацию с использованием механизмов SASL мы рассматривать не будем.Ответ Bind определяется следующим образом.
(рис 13.13) Пример сообщения bindResponse
BindResponce содержит статус запроса клиента на аутентификацию.
Если доступ разрешен, то resultCode будет Success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.
Операция Unbind
Назначение операции Unbind состоит в завершении сессии протокола.
Операция Unbind не имеет ответа. После передачи UnbindRequest клиент должен предполагать, что сессия протокола завершена. После получения UnbindRequest сервер должен предполагать, что клиент завершил сессию, и все исходящие ответы сервер сбрасывает и закрывает соединение.
Операция Search
Операция Search позволяет клиенту запрашивать выполнение поиска на сервере. Это может использоваться для чтения атрибутов из единственной записи, из записей, непосредственно следующих за конкретной записью, или из целого поддерева записей.
Сообщение Search Request имеет следующие параметры:
baseObject - LDAPDN,
scope
baseObject (0),
singleLevel (1),
wholeSubtree (2) ,
derefAliases
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- по крайней мере один должен присутствовать,
-- initial и final могут быть указаны только один раз
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue }
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
Перечислим параметры Search Request:
BaseObject: базовый объект, относительно которого будет выполняться поиск.Scope: указание области поиска.
Может существовать три типа области поиска:
baseObject - ограничивается только базовым объектом.singleLevel - ограничивается только непосредственно подчиненными объектами.wholeSubtree - поиск во всем поддереве данной записи.
(рис 13.14) Область baseObject
(рис 13.15) Область singleLevel
(рис 13.16) Область wholeSubtreeDerefAliases: указание того, как выполняется поиск объекта. Семантика возможных значений данного поля следующая:
NeverDerefAliases: не выполняются переходы по ссылкам для aliases при поиске или при размещении базового объекта поиска.DerefInSearching: выполняется переход по ссылкам aliases, подчиненных базовому объекту поиска.DerefFindingBaseObj: выполняется переход по ссылкам aliases, размещенных в базовом объекте по-иска, но не в подчиненных базовому объекту.DerefAlways: выполняется переход по ссылкам aliases как при поиске, так и при размещении базового объекта поиска.SizeLimit: ограничение максимального количества записей, возвращаемых в качестве результата поиска. Значение 0 в данном поле указывает, что при поиске нет ограничения. Сервер сам определяет максимальное количество возвращаемых записей.TimeLimit: ограничение, определяющее максимальное время поиска (в секундах). Значение 0 в данном поле указывает, что ограничений по времени при запросах клиента не существует.TypesOnly: индикатор того, что результаты поиска содержат и типы, и значения атрибутов или только типы атрибутов. При установке данного значения в TRUE будут возвращаться только типы атрибутов. При установке данного значения в FALSE будут возвращаться и типы, и значения атрибутов.Filter: фильтр определяет условия, которые должны быть выполнены. and, or и not используются для комбинирования фильтров. По крайней мере один элемент фильтра должен присутствовать.
Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо "TRUE", либо "FALSE", либо "Undefined". Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined, то данная запись при поиске игнорируется.
Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.
Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.
Правило соответствия для элементов фильтра greaterOrEqual и lessOrEqual определяется правилом соответствия ORDERING для типа атрибута.
Семантика соответствия для элементов фильтра approxMatch определяется реализацией.
Attributes: список атрибутов, возвращаемый для каждой записи, которая соответствует фильтру поиска. Могут использоваться два специальных значения: пустой список без атрибутов и атрибут, описываемый строкой "*". Оба значения говорят о том, что возвращаются все пользовательские атрибуты.Следует заметить, что если запрошены все пользовательские атрибуты, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены.
Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в Search Responses, которые являются LDAP-сообщениями, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.
SearchResultEntry::= SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList
}
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
-- следуетзаметить, что PartialAttributeList может
-- иметь ноль элементов (если ни один из атрибутов затре-бованной записи
-- не может быть возвращен) и что множество vals
-- может также иметь ноль элементов (если запрошены только типы или
-- все значения были исключены из результата)
SearchResultReference::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- по крайней мере один элемент LDAPURL должен присут-ствовать
SearchResultDone ::= [APPLICATION 5] LDAPResult
После получения Search Request сервер будет выполнять необходимый поиск в DIT.
Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).
Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.
(рис 13.17) Пример запроса searchRequest
(рис 13.18) Пример ответа searchResEntry
Операция Modify
Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify имеет следующие параметры:
object LDAPDN,
modification
operation
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
Перечислимпараметрызапроса Modify:
Object: модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не использует никаких alias для определения модифицируемой записи.Modification: список выполняемых изменений. Список из-менений должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные из-менения могут нарушать схему Каталога, результирующая запись, после того как весь список изменений выполнен, должна соответствовать требованиям схемы Каталога. Значения поля operation имеют следующую семантику:
Add: добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.Delete: удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или если удалены все текущие значения атрибута.Replace: замена значений данного атрибута новыми; если атрибута не существует, он создается. Если при замене не указаны новые значения, то атрибут удаляется, если он есть, и игнорируется, если атрибута не существует.Результат изменения, которое пытался выполнить сервер при получении Modify Request, возвращается в Modify Response.
При получении Modify Request сервер выполняет необходимые изменения в DIT.
Сервер возвращает клиенту единственный Modify Response, указывающий либо на успешное завершение изменения DIT, либо на причину неудачного завершения. Заметим, что в силу требования атомарности применения списка изменений в Modify Request, клиент может считать, что ни одно изменение DIT не выполнено, если полученный Modify Response указывает на какую-либо ошибку, и что все запрошенные изменения про-шли успешно, если Modify Response указывает на успешное завершение операции изменения.
Операция Modify не может быть использована для удаления из записи любого полного уникального имени и тех значений, которые формируют относительное уникальное имя записи. Попытка сделать это приведет к тому, что сервер вернет ошибку notAllowedOnRDN. Для переименования записи используется операция Modify DN, которая будет описана ниже.
Операция Add
Операция Add позволяет клиенту запросить добавление записи в Каталог. Add Request имеет следующие параметры:
entry LDAPDN,
attributes AttributeList
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
Параметрами Add Request являются:
Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют RDN записи), атрибут objectClass и значения всех обязательных атрибутов классов объектов данной записи. Клиенты не должны указывать атрибуты, которые не могут модифицироваться пользователем, такие как createTimestamp или creatorName атрибуты, так как сервер создает их автоматически.Запись, указанная в поле entry в AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example,DC=NET, но запись DC=Example, DC=NET не существует, а запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.
Операция Delete
Операция Delete позволяет клиенту запросить удаление записи из Каталога.
Сообщение Delete Request состоит из DN удаляемой записи. Заметим, что сервер не переходит по aliases, и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.
Результат операции удаления, выполненной сервером при получении сообщения Delete Request, возвращается в сообщении Delete Response.
Операция Modify DN
Операция Modify DN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. Сообщение Modify DN Request имеет следующие параметры:
entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDNOPTIONAL
Параметрами Modify DN Request являются:
Entry: DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.Newdn: RDN определяет левый компонент нового имени записи.Deleteoldrdn: Параметр типа boolean, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.newSuperior: если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.Результат попытки изменения имени сервером при получении сообщения Modify DN Request возвращается в сообщении Modify DN Response.
Например, если запись, указанная в параметре entry, была cn=OlgaLaponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция завершится с кодом ошибки entryAlreadyExists.
Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.
Если параметр deleteoldrdn есть TRUE, то значения, формирующие старый RDN, удаляются из записи. Если параметр deleteoldrdn есть FALSE, то значения, формирующие старый RDN, остаются как значения неуникального атрибута записи. Сервер может не выполнить операцию и вернуть код ошибки, если установка параметра deleteoldrdn противоречит Схеме.
Операция Compare
Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. Compare Request имеет следующие параметры:
entry LDAPDN, ava AttributeValueAssertion
Перечислим параметры CompareRequest:
Entry: имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.Ava: утверждение, с которым сравнивается атрибут записи.Результат сравнения, выполненного сервером при получении Compare Request, возвращается в Compare Response.
При получении Compare Request сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.
Заметим, что управление доступом может быть организовано таким образом, чтобы значения некоторых атрибутов (таких как userPassword) сравнивались или запрашивались другими способами.
Операция Abandon
Операция Abandon предоставляет возможность создания запроса на прерывание сервером выполняющейся операции.
MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от идентификатора более ранней операции, для которой был выполнен Abandon.
Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в Abandon Request. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполнив новую операцию bind.
Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, модификации) определяется сервером.
В том случае, если сервер получил Abandon Request для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.
Клиенты не должны несколько раз посылать запросы Abandon для одной и той же операции, но должны обрабатывать полученные результаты прерванных операций (так как они могли быть уже переданы после полу-чения Abandon и не могли быть прерваны).
Серверы сбрасывают запросы Abandon для тех MessageID, которые они не распознали, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.
Дополнительные операции
В версию 3 LDAP добавлен расширенный механизм, позволяющий определять дополнительные операции для сервисов, которые ранее не были доступны в протоколе LDAP, например для операций цифровой подписи.
Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.
requestName LDAPOID, requestValue OCTET STRING OPTIONAL
requestName есть OBJECT IDENTIFIER операции requestValue содержит информацию в том виде, в котором она определена в операции. Данная информация инкапсулирована в строку октетов.
Сервер отвечает LDAPMessage, содержащим ExtendedResponse.
COMPONENTS OF LDAPResult, ResponseName LDAPOID OPTIONAL, Response OCTET STRING OPTIONAL
Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.