Легкий протокол доступа к каталогам - Lightweight Directory Access Protocol

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

В Легкий протокол доступа к каталогам (LDAP /ˈɛлdæп/) является открытым отраслевым стандартом, не зависящим от поставщиков. протокол приложения для доступа и поддержки распределенных справочно-информационные службы над протокол Интернета (IP) сеть.[1] Справочные службы играют важную роль в развитии интранет и Интернет-приложения, позволяя обмениваться информацией о пользователях, системах, сетях, услугах и приложениях по всей сети.[2] Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, например корпоративный электронное письмо каталог. Аналогично телефонный справочник список подписчиков с адресом и номером телефона.

LDAP указан в серии Инженерная группа Интернета (IETF) Публикации Standard Track, называемые Запрос комментариев (RFC), используя язык описания ASN.1. Последняя спецификация - версия 3, опубликованная как RFC 4511[3] (дорожная карта к техническим характеристикам предоставлена RFC4510 ).

Обычно LDAP используется как центральное место для хранения имен пользователей и паролей. Это позволяет множеству различных приложений и служб подключаться к серверу LDAP для проверки пользователей.[4]

LDAP основан на более простом подмножестве стандартов, содержащихся в X.500 стандарт. Из-за этой связи LDAP иногда называют X.500-lite.[5]

История

Понимание телекоммуникационными компаниями требований к справочникам было хорошо развито после 70 лет создания и управления телефонными справочниками. Эти компании представили концепцию справочных служб информационные технологии и компьютерная сеть, их вклад завершился всесторонним X.500 Технические характеристики,[6] набор протоколов, созданных Международный союз электросвязи (ITU) в 1980-х годах.

Доступ к службам каталогов X.500 традиционно осуществлялся через X.500. Протокол доступа к каталогу (DAP), что требовало Взаимодействие открытых систем (OSI) стек протоколов. Изначально LDAP задумывался как облегченный альтернативный протокол для доступа к службам каталогов X.500 через более простой (и теперь широко распространенный) TCP / IP стек протоколов. Эта модель доступа к каталогам была заимствована из ДИКСИ и Справочная служба поддержки протоколы.

Протокол изначально создавался[7] к Тим Хоуз из университет Мичигана, Стив Килле компании Isode Limited, Колин Роббинс из Nexor и Венгиик Ён из Performance Systems International, около 1993 г., как преемник[8] к ДИКСИ и DAS. Марк Уол из Critical Angle Inc., Тим Хоус и Стив Килле начали работу в 1996 году над новой версией LDAP, LDAPv3, под эгидой Инженерная группа Интернета (IETF). LDAPv3, впервые опубликованный в 1997 году, заменил LDAPv2 и добавил поддержку расширяемости, интегрировал Уровень простой аутентификации и безопасности и лучше согласовал протокол с версией X.500 1993 года. Дальнейшее развитие самих спецификаций LDAPv3 и многочисленных расширений, добавляющих функции LDAPv3, произошло через IETF.

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

LDAP повлиял на последующие Интернет-протоколы, включая более поздние версии X.500, Каталог с поддержкой XML (XED), Язык разметки службы каталогов (DSML), Язык разметки предоставления услуг (SPML), а Протокол определения местоположения службы (SLP). Он также используется в качестве основы для Microsoft с Active Directory.

Обзор протокола

Клиент запускает сеанс LDAP, подключившись к серверу LDAP, который называется Агент системы каталогов (DSA), по умолчанию TCP и UDP порт 389 или на порт 636 для LDAPS (LDAP через SSL, см. Ниже).[9] Затем клиент отправляет серверу запрос операции, а сервер отправляет ответы в ответ. За некоторыми исключениями, клиенту не нужно ждать ответа перед отправкой следующего запроса, и сервер может отправлять ответы в любом порядке. Вся информация передается с использованием Основные правила кодирования (BER).

Клиент может запросить следующие операции:

  • StartTLS - используйте LDAPv3 Безопасность транспортного уровня (TLS) расширение для безопасного соединения
  • Связывать - аутентифицировать и укажите версию протокола LDAP
  • Поиск - поиск и / или получение записей каталога
  • Сравнить - проверить, содержит ли указанная запись заданное значение атрибута
  • Добавить новую запись
  • Удалить запись
  • Изменить запись
  • Изменить отличительное имя (DN) - переместить или переименовать запись
  • Abandon - отменить предыдущий запрос
  • Расширенная операция - общая операция, используемая для определения других операций
  • Unbind - закрыть соединение (не обратное Bind)

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

Распространенным альтернативным методом защиты связи LDAP является использование SSL туннель. Порт по умолчанию для LDAP через SSL - 636. Использование LDAP через SSL было обычным явлением в LDAP версии 2 (LDAPv2), но никогда не было стандартизировано в какой-либо формальной спецификации. Это использование устарело вместе с LDAPv2, который был официально удален в 2003 году.[10] Глобальный каталог доступен по умолчанию на портах 3268 и 3269 для LDAPS.[11]

Структура каталогов

Протокол обеспечивает интерфейс с каталогами, которые следуют за версией 1993 г. X.500 модель:

  • Запись состоит из набора атрибутов.
  • Атрибут имеет имя ( тип атрибута или же описание атрибута) и одно или несколько значений. Атрибуты определены в схема (Смотри ниже).
  • Каждая запись имеет уникальный идентификатор: ее Выдающееся имя (DN). Он состоит из Относительное отличительное имя (RDN), состоящий из некоторого атрибута (ов) в записи, за которым следует DN родительской записи. Думайте о DN как о полный путь к файлу и RDN в качестве относительного имени файла в родительской папке (например, если /foo/bar/myfile.txt были DN, то myfile.txt будет RDN).

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

Запись может выглядеть так, если представлена ​​в Формат обмена данными LDAP (LDIF) (LDAP сам по себе двоичный протокол ):

 dn: cn = John Doe, dc = example, dc = com cn: John Doe givenName: John sn: Doe phoneNumber: +1888555 6789 phoneNumber: +1888555 1232 mail: [email protected] менеджер: cn = Barbara Doe, dc = example, dc = com objectClass: inetOrgPerson objectClass: organizationPerson objectClass: person objectClass: вверх

"дн"- отличительное имя статьи; это не атрибут и не часть статьи".cn = Джон Доу"- это RDN (относительное отличительное имя) записи, и"dc = пример, dc = com"- DN родительской записи, где"Округ Колумбия"означает"Компонент домена '. В других строках показаны атрибуты записи. Имена атрибутов обычно представляют собой мнемонические строки, например "сп"для общего имени"Округ Колумбия"для доменного компонента"Почта"для адреса электронной почты и"sn"для фамилии.

Сервер содержит поддерево, начиная с определенной записи, например "dc = пример, dc = com"и его дочерние элементы. Серверы также могут содержать ссылки на другие серверы, поэтому попытка доступа"ou = отдел, dc = пример, dc = com"может вернуть направления или же ссылка на продолжение к серверу, который содержит эту часть дерева каталогов. Затем клиент может связаться с другим сервером. Некоторые серверы также поддерживают цепочка, что означает, что сервер связывается с другим сервером и возвращает результаты клиенту.

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

Операции

Добавлять

Операция ADD вставляет новую запись в базу данных сервера каталогов.[12] Если отличительное имя в запросе на добавление уже существует в каталоге, то сервер не будет добавлять повторяющуюся запись, а установит код результата в результате добавления равным 68, «entryAlreadyExists».[13]

  • Серверы, совместимые с LDAP, никогда не будут разыменовывать отличительное имя, переданное в запросе на добавление, при попытке найти запись, то есть отличительные имена никогда не отменяются.
  • Серверы, совместимые с LDAP, гарантируют, что отличительное имя и все атрибуты соответствуют стандартам именования.
  • Добавляемая запись не должна существовать, а непосредственный руководитель должен существовать.
dn: uid = user, ou = people, dc = example, dc = comchangetype: addobjectClass: topobjectClass: personuid: usersn: last-namecn: common-nameuserPassword: пароль

В приведенном выше примере uid = user, ou = people, dc = example, dc = com не должно существовать, и ou = люди, dc = пример, dc = com должен существовать.

Привязать (подтвердить)

Когда создается сеанс LDAP, то есть когда клиент LDAP подключается к серверу, состояние аутентификации сеанса установлен на анонимный. Операция BIND устанавливает состояние аутентификации для сеанса.

Simple BIND и SASL PLAIN могут отправлять DN пользователя и пароль в простой текст, поэтому соединения, использующие Simple или SASL PLAIN, должны быть зашифрованы с помощью Безопасность транспортного уровня (TLS). Сервер обычно проверяет пароль на соответствие пользовательский парольатрибут в названной записи. Анонимный BIND (с пустым DN и паролем) сбрасывает соединение в анонимное состояние.

SASL (Простая аутентификация и уровень безопасности) BIND предоставляет услуги аутентификации с помощью широкого диапазона механизмов, например Kerberos или сертификат клиента отправлено с TLS.[14]

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

BIND должен был быть первой операцией в сеансе в LDAPv2, но в LDAPv3 он не требуется. В LDAPv3 каждый успешный запрос BIND изменяет состояние аутентификации сеанса, а каждый неудачный запрос BIND сбрасывает состояние аутентификации сеанса.

Удалить

Чтобы удалить запись, клиент LDAP передает серверу правильно сформированный запрос на удаление.[15]

  • Запрос на удаление должен содержать отличительное имя удаляемой записи.
  • Элементы управления запросами также могут быть прикреплены к запросу на удаление
  • Серверы не разыменовывают псевдонимы при обработке запроса на удаление
  • Только конечные записи (записи без подчиненных) могут быть удалены запросом на удаление. Некоторые серверы поддерживают рабочий атрибут hasSubordinates значение которой указывает, есть ли у записи какие-либо подчиненные записи, и некоторые серверы поддерживают рабочий атрибут numSubordinates[16] с указанием количества записей, подчиненных записи, содержащей numSubordinates атрибут.
  • Некоторые серверы поддерживают управление запросами на удаление поддерева, разрешающее удаление DN и всех объектов, подчиненных DN, при условии контроля доступа. Запросы на удаление подлежат контролю доступа, то есть будет ли разрешено соединение с данным состоянием аутентификации удалить данную запись, регулируется механизмами контроля доступа, зависящими от сервера.

Искать и сравнивать

Операция поиска используется как для поиска, так и для чтения записей. Его параметры:

baseObject
Имя записи базового объекта (или, возможно, корня), относительно которого должен выполняться поиск.
объем
Какие элементы ниже baseObject искать. Это может быть BaseObject (поиск только по названной записи, обычно используется для чтения одной записи), singleLevel (записи непосредственно под базовым DN) или целое поддерево (все поддерево, начиная с базового DN).
фильтр
Критерии для использования при выборе элементов в рамках. Например, фильтр (& (objectClass = человек) (| (givenName = John) (mail = john *))) выберет «лиц» (элементы objectClass человек) где правила сопоставления для собственное имя и Почта определить, соответствуют ли значения этих атрибутов утверждению фильтра. Обратите внимание, что распространенное заблуждение состоит в том, что данные LDAP чувствительны к регистру, тогда как на самом деле правила сопоставления и правила упорядочения определяют сопоставление, сравнения и отношения относительных значений. Если в примерах фильтров требовалось соответствие регистру значения атрибута, расширяемый фильтр соответствия необходимо использовать, например, (& (objectClass = человек) (| (givenName: caseExactMatch: = John) (mail: caseExactSubstringsMatch: = john *)))
derefAliases
Следует ли и как следить за записями псевдонимов (записями, которые относятся к другим записям),
атрибуты
Какие атрибуты возвращать в записях результатов.
sizeLimit, timeLimit
Максимальное количество возвращаемых записей и максимальное время для запуска поиска. Эти значения, однако, не могут отменять какие-либо ограничения, налагаемые сервером на ограничение размера и время.
typesOnly
Возвращает только типы атрибутов, но не значения атрибутов.

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

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

Изменить

Операция MODIFY используется клиентами LDAP, чтобы запросить сервер LDAP внести изменения в существующие записи.[17] Попытки изменить несуществующие записи потерпят неудачу. Запросы MODIFY подлежат контролю доступа, реализованному на сервере.

Операция MODIFY требует, чтобы было указано отличительное имя (DN) записи и последовательность изменений. Каждое изменение в последовательности должно быть одним из:

  • добавить (добавить новое значение, которого еще не должно быть в атрибуте)
  • удалить (удалить существующее значение)
  • заменить (заменить существующее значение новым значением)

LDIF пример добавления значения к атрибуту:

dn: dc = example, dc = comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added-

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

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

Также есть расширение Modify-Increment[18] который позволяет увеличивать значение атрибута на заданную величину. Следующий пример с использованием приращений LDIF количество сотрудников к 5:

dn: uid = user.0, ou = people, dc = example, dc = comchangetype: modifyincrement: employeeNumberemployeeNumber: 5-

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

Изменить DN

Modify DN (перемещение / переименование записи) принимает новое RDN (Relative Distinguished Name), необязательно DN нового родителя и флаг, который указывает, следует ли удалять значения в записи, соответствующие старому RDN. Сервер может поддерживать переименование целых поддеревьев каталогов.

Операция обновления является атомарной: другие операции будут видеть либо новую запись, либо старую. С другой стороны, LDAP не определяет транзакции, состоящие из нескольких операций: если вы читаете запись, а затем изменяете ее, другой клиент тем временем мог обновить эту запись. Серверы могут реализовывать расширения[20] которые поддерживают это.

Расширенные операции

Расширенная операция - это общая операция LDAP, которая может определять новые операции, которые не были частью исходной спецификации протокола. StartTLS - одно из самых значительных расширений. Другие примеры включают «Отмена» и «Изменение пароля».

StartTLS

Операция StartTLS устанавливает Безопасность транспортного уровня (потомок SSL ) о подключении. Он может обеспечивать конфиденциальность данных (для защиты данных от наблюдения третьими сторонами) и / или защиту целостности данных (которая защищает данные от подделки). Во время согласования TLS сервер отправляет свой X.509 сертификат, подтверждающий его личность. Клиент также может отправить сертификат для подтверждения своей личности. После этого клиент может использовать SASL /ВНЕШНИЙ. Используя SASL / EXTERNAL, клиент запрашивает у сервера свою идентичность из учетных данных, предоставленных на более низком уровне (например, TLS). Хотя технически сервер может использовать любую идентификационную информацию, установленную на любом более низком уровне, обычно сервер будет использовать идентификационную информацию, установленную TLS.

Серверы также часто поддерживают нестандартный протокол «LDAPS» («Безопасный LDAP», широко известный как «LDAP через SSL») на отдельном порту, по умолчанию 636. LDAPS отличается от LDAP двумя способами: 1) при подключении клиент и сервер устанавливают TLS перед передачей любых сообщений LDAP (без операции StartTLS) и 2) соединение LDAPS должно быть закрыто после закрытия TLS.

Некоторые клиентские библиотеки LDAPS только шифруют обмен данными; они не сверяют имя хоста с именем в предоставленном сертификате.[21]

Покидать

Операция Abandon требует, чтобы сервер прервал операцию, названную идентификатором сообщения. Серверу не нужно выполнять запрос. Ни «Отказ», ни успешно прерванная операция не отправляют ответа. Аналогичная расширенная операция Cancel отправляет ответы, но не все реализации это поддерживают.

Развязать

Операция Unbind отменяет все невыполненные операции и закрывает соединение. Нет ответа. Название имеет историческое происхождение и является нет противоположность операции привязки.[22]

Клиенты могут прервать сеанс, просто закрыв соединение, но они должны использовать Unbind.[23] Unbind позволяет серверу корректно закрыть соединение и освободить ресурсы, которые в противном случае он оставил бы в течение некоторого времени, пока не обнаружит, что клиент отказался от соединения. Он также дает серверу команду отменить операции, которые можно отменить, и не отправлять ответы для операций, которые нельзя отменить.[24]

Схема URI

LDAP унифицированный идентификатор ресурса (URI) существует схема, которую клиенты поддерживают в той или иной степени, и серверы возвращаются в отсылках и ссылках на продолжение (см. RFC 4516 ):

ldap: // хост: порт / DN? атрибуты? область? фильтр? расширения

Большинство компонентов, описанных ниже, не являются обязательными.

  • хозяин это FQDN или IP-адрес сервера LDAP для поиска.
  • порт это сетевой порт (порт по умолчанию 389) сервера LDAP.
  • DN отличительное имя для использования в качестве базы поиска.
  • атрибуты - это список извлекаемых атрибутов, разделенных запятыми.
  • объем указывает область поиска и может быть «базовой» (по умолчанию), «единичной» или «дополнительной».
  • фильтр это поисковый фильтр. Например, (objectClass = *) как определено в RFC 4515.
  • расширения являются расширениями формата URL LDAP.

Например, "ldap: //ldap.example.com/cn=John%20Doe,dc=example,dc=com"относится ко всем атрибутам пользователя в записи Джона Доу в ldap.example.com, пока "ldap: /// dc = example, dc = com ?? sub? (givenName = John)"выполняет поиск записи на сервере по умолчанию (обратите внимание на тройную косую черту, опуская хост, и двойной вопросительный знак, опуская атрибуты). Как и в других URL, специальные символы должны быть закодированный в процентах.

Есть аналогичный нестандартный ldaps Схема URI для LDAP через SSL. Не следует путать LDAP с TLS, который достигается с помощью операции StartTLS с использованием стандартного ldap схема.

Схема

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

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

  • Синтаксис атрибутов. Предоставляет информацию о типе информации, которая может храниться в атрибуте.
  • Правила сопоставления - предоставьте информацию о том, как проводить сравнения со значениями атрибутов.
  • Использование правила сопоставления - укажите, какие типы атрибутов могут использоваться вместе с конкретным правилом сопоставления.
  • Типы атрибутов - определение идентификатор объекта (OID) и набор имен, которые могут относиться к заданному атрибуту, и связывает этот атрибут с синтаксисом и набором правил сопоставления.
  • Классы объектов. Определите именованные коллекции атрибутов и классифицируйте их на наборы обязательных и дополнительных атрибутов.
  • Формы имени. Определите правила для набора атрибутов, которые должны быть включены в RDN для записи.
  • Правила содержимого - определяют дополнительные ограничения для классов и атрибутов объектов, которые могут использоваться вместе с записью.
  • Правило структуры - Определите правила, которые управляют видами подчиненных статей, которые может иметь данная статья.

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

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

Схема определяет классы объектов. Каждая запись должна иметь атрибут objectClass, содержащий именованные классы, определенные в схеме. Определение схемы классов записи определяет, какой тип объекта может представлять запись - например, человек, организация или домен. Определения класса объектов также определяют список атрибутов, которые должны содержать значения, и список атрибутов, которые могут содержать значения.

Например, запись, представляющая человека, может принадлежать к классам «верхний» и «человек». Членство в классе «person» потребует, чтобы запись содержала атрибуты «sn» и «cn», а также позволило бы записи также содержать «userPassword», «phoneNumber» и другие атрибуты. Поскольку записи могут иметь несколько значений ObjectClasses, каждая запись имеет комплекс необязательных и обязательных наборов атрибутов, сформированных из объединения классов объектов, которые она представляет. ObjectClasses могут быть унаследованы, и одна запись может иметь несколько значений ObjectClasses, которые определяют доступные и обязательные атрибуты самой записи. Параллельно схеме объектного класса является учебный класс определение и пример в Объектно-ориентированного программирования, представляющие объектный класс LDAP и запись LDAP соответственно.

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

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

Вариации

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

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

Большинство частей LDAP являются расширяемыми. Примеры: можно определять новые операции. Управление может изменять запросы и ответы, например для запроса отсортированных результатов поиска. Можно определить новые области поиска и методы привязки. Атрибуты могут иметь опции это может изменить их семантику.

Другие модели данных

По мере того, как LDAP набирает обороты, поставщики предоставляют его в качестве протокола доступа к другим службам. Затем реализация изменяет данные, чтобы имитировать модель LDAP / X.500, но степень соблюдения этой модели варьируется. Например, есть программное обеспечение для доступа SQL базы данных через LDAP, даже если LDAP не сразу поддается этому.[25] Серверы X.500 также могут поддерживать LDAP.

Точно так же данные, ранее хранившиеся в других типах хранилищ данных, иногда перемещаются в каталоги LDAP. Например, информация о пользователях и группах Unix может храниться в LDAP и доступна через PAM и НСС модули. LDAP часто используется другими службами для аутентификации и / или авторизации (какие действия данный уже аутентифицированный пользователь может выполнять в какой службе). Например, в Active Directory Kerberos используется на этапе аутентификации, а LDAP - на этапе авторизации.

Примером такой модели данных является схема GLUE,[26] который используется в распределенной информационной системе на основе LDAP, позволяющей пользователям, приложениям и службам обнаруживать, какие службы существуют в инфраструктуре Grid, и получать дополнительную информацию об их структуре и состоянии.

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

Сервер LDAP может возвращать ссылки на другие серверы для запросов, которые он не может выполнить сам. Для этого требуется структура именования для записей LDAP, чтобы можно было найти сервер, содержащий заданное отличительное имя (DN), концепцию, определенную в Справочнике X.500, а также используемую в LDAP. Другой способ найти серверы LDAP для организации - это DNS. запись сервера (СРВ).

Организация с доменом example.org может использовать DN LDAP верхнего уровня. dc = пример, dc = org (куда Округ Колумбия означает компонент домена). Если сервер LDAP также называется ldap.example.org, URL-адрес LDAP верхнего уровня организации становится ldap: //ldap.example.org/dc=example,dc=org.

Как в X.500 [2008], так и в LDAPv3 используются в основном два общих стиля именования. Они задокументированы в спецификациях ITU и RFC IETF. Исходная форма принимает объект верхнего уровня как объект страны, например c = США, c = FR. Модель компонентов предметной области использует модель, описанную выше. Примером названия страны может быть l = Населенный пункт, ou = Некоторая организационная единица, o = Некоторая организация, c = FR, или в США: cn = Общее название, l = Населенный пункт, ou = Некоторая организационная единица, o = Некоторая организация, st = CA, c = США.

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

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

  1. ^ «Сетевая рабочая группа RFC 4511». IETF.org. 2006-06-01. Получено 2014-04-04.
  2. ^ "Службы каталогов LDAP". Oracle.com. Получено 2014-04-04.
  3. ^ Что такое LDAP?. Gracion.com. Проверено 17 июля 2013.
  4. ^ «Введение в службы каталогов OpenLDAP». OpenLDAP. Получено 1 февраля 2016.
  5. ^ «LDAP - облегченный протокол доступа к каталогам». Webopedia.com. Получено 2014-04-05.
  6. ^ В X.500 серия - Рек. МСЭ-Т Рек. X.500 - X.521
  7. ^ Хоуз, Тим. «Облегченный протокол доступа к каталогам: X.500 Lite» (PDF). Получено 26 декабря 2012.
  8. ^ «Предыстория LDAP». Кибер-вопросы. 2013-04-09. Получено 5 октября 2014.
  9. ^ «Реестр имени службы и номера порта транспортного протокола». IANA. Получено 7 мая 2014.
  10. ^ RFC3494
  11. ^ «Глобальный каталог и поиск LDAP». 2014-08-05. Получено 2014-08-05.
  12. ^ Добавить раздел RFC4511
  13. ^ Коды результатов LDAP
  14. ^ Механизмы SASL в IANA
  15. ^ RFC4511: запрос на удаление
  16. ^ Проект Борхэма (numSubordinates)
  17. ^ Изменить раздел RFC4511
  18. ^ Зейленга, К. Расширение LDAP Modify-Increment. Дои:10.17487 / RFC4525. RFC 4525.
  19. ^ Зейленга, К. Элементы управления записью чтения облегченного протокола доступа к каталогам (LDAP). IETF. Дои:10.17487 / RFC4527. RFC 4527.
  20. ^ ИНТЕРНЕТ-ПРОЕКТ LDAP-транзакций draft-zeilenga-ldap-txn-15.txt
  21. ^ Предупреждение системы безопасности Shibboleth 20120227
  22. ^ Tools.ietf.org
  23. ^ Tools.ietf.org
  24. ^ Tools.ietf.org
  25. ^ Openldap.org
  26. ^ Форум Open Grid: главная страница проекта

Примечания

дальнейшее чтение

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