WikiDer > OpenLDAP

Эта статья слишком полагается на Рекомендации к основные источники. Пожалуйста, улучшите это, добавив вторичные или третичные источники. (Октябрь 2014 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

OpenLDAP

Разработчики)	Проект OpenLDAP
изначальный выпуск	26 августа 1998 г.; 22 года назад (1998-08-26)[1]
Стабильный выпуск	2.4.55[2] / 26 октября 2020; 41 дней назад (2020-10-26)
Предварительный выпуск	2.5.0alpha / 14 октября 2020
Репозиторий	мерзавец.openldap.org/ openldap/ openldap.git
Написано в	C
Операционная система	Любой
Платформа	Кроссплатформенность
Тип	LDAP справочная служба
Лицензия	Общественная лицензия OpenLDAP[3]
Интернет сайт	www.openldap.org

OpenLDAP это свободный, Открытый исходный код реализация Легкий протокол доступа к каталогам (LDAP), разработанный OpenLDAP Project. Он выпущен под собственной лицензией в стиле BSD, которая называется OpenLDAP Public License.^[4]

LDAP - это протокол, независимый от платформы. Несколько общих Linux дистрибутивы включают программное обеспечение OpenLDAP для поддержки LDAP. Программное обеспечение также работает на BSD-варианты, а также AIX, Android, HP-UX, macOS, Солярис, Майкрософт Виндоус (NT и производные, например, 2000, XP, Vista, Windows 7 и т. Д.), И z / OS.

История

Проект OpenLDAP^[5] была основана в 1998 году Куртом Зейленга.^[6] Проект начался с клонирования справочного источника LDAP из университет Мичигана где давний проект поддерживал развитие и развитие протокола LDAP до его окончательной версии в 1996 году.

По состоянию на май 2015 г.^{[Обновить]}, в проекте OpenLDAP четыре основных члена команды: Говард Чу (главный архитектор),^[7] Куана Гибсон-Маунт, Халлвард Фурусет и Курт Зейленга. Есть множество других важных и активных участников, включая Люка Ховарда, Райана Тэнди и Гэвина Генри. Среди бывших членов основной команды - Пьеранджело Масарати.^[8]

Составные части

OpenLDAP состоит из трех основных компонентов:

• пощечина - автономный LDAP демон и связанные модули и инструменты
• библиотеки, реализующие LDAP протокол и ASN.1 Основные правила кодирования (BER)
• клиентское программное обеспечение: ldapsearch, ldapadd, ldapdelete и другие

Кроме того, проект OpenLDAP является домом для ряда подпроектов:

• JLDAP - библиотеки классов LDAP для Java
• JDBC-LDAP - Java JDBC - Драйвер моста LDAP
• ldapc ++ - библиотеки классов LDAP для C ++
• Крепость - Java SDK для управления доступом на основе ролей
• LMDB - библиотека базы данных с отображением памяти

Бэкэнды

Общая концепция

Исторически архитектура сервера OpenLDAP (slapd, автономный демон LDAP) была разделена между внешним интерфейсом, который обрабатывает доступ к сети и обработку протоколов, и внутренним интерфейсом, который занимается строго хранением данных. Этот разделенный дизайн был особенностью исходного кода Мичиганского университета, написанного в 1996 году.^[9] и продолжалась во всех последующих выпусках OpenLDAP. Исходный код включал один основной сервер базы данных и два экспериментальных / демонстрационных сервера. Архитектура является модульной, и теперь доступно множество различных серверных модулей для взаимодействия с другими технологиями, а не только с традиционными базами данных.

Примечание. В более старых (1.x) выпусках термины «серверная часть» и «база данных» часто использовались взаимозаменяемо. Если быть точным, «серверная часть» - это класс интерфейса хранилища, а «база данных» - это экземпляр аварийного интерфейса. . Сервер slapd может использовать произвольно много бэкэндов одновременно и может иметь произвольно много экземпляров каждого бэкэнда (то есть произвольно много баз данных), активных одновременно.

Доступные бэкенды

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

• Бэкэнды хранения данных - они фактически хранят данные
  • back-bdb: первый транзакционный бэкэнд для OpenLDAP, построенный на Berkeley DB
  • back-hdb: вариант back-bdb, который является полностью иерархическим и поддерживает переименование поддеревьев.
  • back-ldif: построен на простом тексте LDIF файлы
  • back-mdb: транзакционный бэкэнд, построенный на OpenLDAP База данных с отображением в память Lightning (LMDB)
  • back-ndb: транзакционный бэкэнд, построенный на кластерном движке MySQL NDB
• Серверные прокси-серверы - они действуют как шлюзы для других систем хранения данных.
  • back-ldap: простой прокси для других серверов LDAP
  • back-meta: прокси с функциями метакаталога
  • back-passwd: использует пароль системы Unix и данные группы
  • back-relay: внутреннее перенаправление на другие серверные части slapd
  • back-sql: общается с произвольными базами данных SQL
• Динамические бэкенды - они генерируют данные на лету
  • back-config: настройка slapd через LDAP
  • back-dnssrv: обнаруживает серверы LDAP через DNS
  • back-monitor: статистика slapd через LDAP
  • back-null: бэкэнд-приемник / без операций, аналог Unix / dev / null
  • back-perl: вызывает произвольные модули Perl в ответ на запросы LDAP
  • back-shell: вызывает сценарии оболочки для запросов LDAP
  • back-sock: перенаправляет запросы LDAP через IPC произвольным демонам

Некоторые бэкенды, доступные в старых версиях OpenLDAP, больше не используются, в первую очередь back-ldbm, унаследованный от исходного кода UMich, и back-tcl, который был похож на back-perl и back-shell.

Скоро будет прекращена поддержка других бэкэндов. back-ndb теперь не рекомендуется, поскольку партнерство с MySQL, которое привело к его разработке, было прекращено Oracle после того, как Oracle приобрела MySQL. back-bdb и back-hdb будут заменены на back-mdb в ближайшее время, поскольку back-mdb превосходит все аспекты производительности, надежности и управляемости.

На практике такие серверы, как -perl, -shell и -sock, позволяют взаимодействовать с любым произвольным языком программирования, тем самым обеспечивая безграничные возможности для настройки и расширения. По сути, сервер slapd становится механизмом RPC с компактным, четко определенным и повсеместным API.

Оверлеи

Общая концепция

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

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

Доступные оверлеи

В настоящее время в основной дистрибутив OpenLDAP входит 21 оверлей, еще 15 оверлеев находятся в разделе кода, добавляемого пользователями, и еще больше ожидают утверждения для включения.

Прочие модули

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

OpenLDAP также поддерживает SLAPI, архитектуру подключаемого модуля, используемую Sun и Netscape / Fedora / Red Hat. В текущих выпусках структура SLAPI реализована внутри наложения slapd. Хотя многие плагины, написанные для Sun / Netscape / Fedora / Red Hatare, совместимы с OpenLDAP, очень немногие члены сообщества OpenLDAP используют SLAPI.

Доступные модули

• Родные модули slapd
  • acl / posixgroup - поддержка членства posixGroup в управлении доступом
  • comp_match - поддержка сопоставления на основе компонентов
  • kinit - поддерживать / обновлять Kerberos TGT для slapd
  • passwd / - дополнительные механизмы хеширования паролей. В настоящее время включает Kerberos, Netscape, РАДИУС, и SHA-2.
• Плагины SLAPI
  • addrdnvalue - добавить значение RDN к записи, если оно было опущено в запросе Add

Сводка выпуска

Основные (функциональные) версии программного обеспечения OpenLDAP включают:

• OpenLDAP Version 1 представляет собой общую очистку последнего выпуска проекта Мичиганского университета (выпуск 3.3) и объединение дополнительных изменений.
• OpenLDAP версии 2.0, выпущенный в августе 2000 года, включал основные улучшения, включая поддержку LDAP версии 3 (LDAPv3), Интернет-протокола версии 6 (IPv6) и множество других улучшений.
• OpenLDAP версии 2.1, выпущенный в июне 2002 г., включал серверную часть транзакционной базы данных (на основе База данных Беркли или BDB), Уровень простой аутентификации и безопасности (SASL), а также экспериментальные серверные части Meta, Monitor и Virtual.
• OpenLDAP версии 2.2, выпущенный в декабре 2003 года, включал механизм синхронизации LDAP с поддержкой репликации (syncrepl), оверлейный интерфейс и многочисленные функциональные улучшения, связанные с базами данных и RFC.
• OpenLDAP версии 2.3, выпущенный в июне 2005 г., включал серверную часть конфигурации (динамическое конфигурирование), дополнительные оверлеи, включая RFC-совместимое программное обеспечение политики паролей, и многочисленные дополнительные усовершенствования.
• OpenLDAP версии 2.4, выпущенный в октябре 2007 года, представил N-стороннюю репликацию MultiMaster, резервный мастер, возможность удалять и изменять элементы схемы на лету, а также многое другое.^[10]

Репликация

OpenLDAP поддерживает репликацию с использованием синхронизации содержимого, как указано в RFC 4533. В дальнейшем эта спецификация именуется «syncrepl». В дополнение к базовой спецификации также поддерживается расширение, известное как delta-syncrepl. Дополнительные улучшения были реализованы для поддержки репликация с несколькими мастерами.

синкрепл

Основная операция синхронизации описана в RFC 4533. Протокол определен таким образом, что постоянная база данных изменений не требуется. Скорее, набор изменений подразумевается посредством информации порядкового номера изменения (CSN), хранящейся в каждой записи и оптимизируемой с помощью дополнительного журнала сеанса, который особенно полезен для отслеживания недавних удалений. Модель работы заключается в том, что клиент репликации (потребитель) отправляет «поиск с синхронизацией контента» на сервер репликации (провайдер). Потребитель может предоставить файл cookie в этом поиске (особенно если он ранее был синхронизирован с поставщиком). В реализации OpenLDAP RFC 4533, этот файл cookie включает в себя последний CSN, полученный от поставщика (называемый contextCSN).

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

Поиск может выполняться либо в режиме обновления, либо в режиме refreshAndPersist, что подразумевает, какие этапы происходят. Этап обновления всегда выполняется первым. На этапе обновления могут происходить две фазы: присутствие и удаление, где всегда присутствует перед удалением. Фазы разделяются ответом с информацией о синхронизации, в котором указывается, какая фаза завершена. Этапы обновления и сохранения также разграничиваются таким ответом с информацией о синхронизации. Необязательная оптимизация для более компактного представления группы записей, которые должны быть представлены или удалены, заключается в использовании ответа с информацией о синхронизации, содержащего syncIdSet, который идентифицирует список значений entryUUID этих записей.

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

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

delta-syncrepl

Этот протокол хранит постоянную базу данных доступов на запись (изменений) и может точно представлять каждое изменение (то есть только те атрибуты, которые изменились). Он по-прежнему основан на стандартной спецификации syncrepl, которая всегда отправляет изменения как полные записи. Но в delta-syncrepl переданные записи фактически отправляются из базы данных журнала, где каждое изменение в основной базе данных записывается как запись журнала. Записи журнала записываются с использованием схемы журнала LDAP.^[11]

Смотрите также

• Список программного обеспечения LDAP

Рекомендации

внешняя ссылка

• Официальный веб-сайт
• Фонд OpenLDAP
• Использование libldap, Учебное пособие по клиентскому API OpenLDAP
• Обновление OpenLDAP Статья Марти Хеймана 13 сентября 2007 г.