Московский государственный университет имени М.В.Ломоносова
Опубликован: 28.11.2014 | Доступ: свободный | Студентов: 1159 / 85 | Длительность: 23:26:00
ISBN: 978-5-9556-0163-2
Лекция 13:

Протокол LDAP

Распределенное множество серверов LDAP

Протокол LDAP предполагает, что существует один или несколько серверов, которые совместно предоставляют доступ к Информационному Дереву Каталога (DIT).

Пример распределенного множества серверов LDAP

Рис. 13.6. Пример распределенного множества серверов LDAP

Каждый сервер содержит определенное поддерево DIT.

Разработка топологии

Дерево Каталога может быть распределено по нескольким физическим серверам.

Использование распределенной топологии обеспечивает:

  • Улучшение производительности Каталога.
  • Улучшение управляемости Каталогом.
  • Возможность хранения большего числа записей, чем это воз-можно на одном сервере.

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

Распределенная структура Каталогов во многом аналогична распределенной структуре серверов DNS.

Ссылки (Referral)

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

Взаимодействие серверов LDAP

Рис. 13.7. Взаимодействие серверов LDAP

Рассмотрим последовательность запросов при поиске клиентом информации в Каталоге.

  1. Клиент запрашивает информацию у Сервера 1.
  2. Сервер 1 возвращает ссылку на Сервер 2.
  3. Клиент повторно посылает запрос на Сервер 2.
  4. Сервер 2 возвращает информацию Клиенту.

Код результата поиска может указывать, что сервер, с которым осуществляется соединение, не содержит целевой записи. В этом случае сервер присылает ссылку на другой сервер в поле referral. Это поле содержит одну или несколько ссылок на один или несколько серверов или сервисов, которые могут быть доступны по протоколу LDAP или по другим протоколам. Такие ссылки могут быть возвращены в ответе для любого запроса операции (исключая операции unbind и abandon, которые не имеют ответа). По крайней мере один URL должен быть указан в поле referral.

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

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

Имя корневого контекста

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

LDAP-Сервер предоставляет информацию об имени корневого контекста в атрибуте baseDN.

Определение baseDN сервера

Рис. 13.8. Определение baseDN сервера

Корневой контекст является набором атрибутов, который зависит от конкретного сервера. Значения этих атрибутов можно получить, выполнив поиск объекта с фильтром (objectClass=*).

Владимир Романов
Владимир Романов
Россия, Москва, МПУ им Н.К. Крупской
Евгений Кичигин
Евгений Кичигин
Россия