Облегченный протокол доступа к каталогу

Облегченный протокол доступа к каталогу

Протокол связи
Цель	Служба каталогов
На основе	Х.500
Уровень OSI	Прикладной уровень
Порт(ы)	389 (ldap), 636 (ldaps)
RFC(ы)	RFC 4510, RFC 4511

Облегченный протокол доступа к каталогу ( LDAP / ˈ ɛ l d æ p / ) — это открытый, независимый от поставщика стандартный протокол приложений для доступа и поддержки распределенных информационных служб каталогов по сети Интернет-протокола (IP). Службы каталогов играют важную роль в разработке приложений интрасети и Интернета, позволяя обмениваться информацией о пользователях, системах, сетях, службах и приложениях по всей сети. Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, например каталог корпоративной электронной почты . Точно так же телефонный справочник представляет собой список абонентов с адресом и номером телефона.

LDAP указан в серии публикаций стандартной версии Инженерной группы Интернета (IETF) под названием Request for Comments (RFC) с использованием языка описания ASN.1 . Последней спецификацией является версия 3, опубликованная как RFC 4511. (дорожная карта технических спецификаций представлена ​​в RFC4510 ).

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

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

История

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

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

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

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

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

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

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

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

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

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

Распространенным альтернативным методом защиты связи LDAP является использование SSL туннеля . Порт по умолчанию для LDAP через SSL — 636. Использование LDAP через SSL было обычным явлением в LDAP версии 2 (LDAPv2), но оно никогда не было стандартизировано ни в одной формальной спецификации. Это использование устарело вместе с LDAPv2, поддержка которого была официально прекращена в 2003 году.

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

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

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

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

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

dn  :   cn  =  John Doe  ,  dc  =  example  ,  dc  =  com 
 cn  :   John Doe 
 заданное имя  :   John 
 sn  :   Doe 
 телефонный номер  :   +1 888 555 6789 
 телефонный номер  :   +1 888 555 1232 
 почта  :   [email protected] 
 менеджер  :   cn=Barbara Doe,dc=example,dc=com 
 Объектный класс  :   inetOrgPerson 
 Объектный класс  :   OrganizationPerson 
 объектный класс  :   person 
 объектный класс  :   верхний 

" dn" — отличительное имя записи; оно не является ни атрибутом, ни частью записи. " cn=John Doe" — это RDN записи (относительное отличительное имя) и " dc=example,dc=com" — DN родительской записи, где " dc" обозначает " Компонент домена ". Остальные строки показывают атрибуты в записи. Имена атрибутов обычно представляют собой мнемонические строки, например " cn"для общего имени", dc" для компонента домена " mail" для адреса электронной почты и " sn"для фамилии.

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

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

Операции

Добавить

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

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

dn  :   uid  =  пользователь  ,  ou  =  люди  ,  dc  =  example  ,  dc  =  com 
 тип изменения  :   добавить 
 объектный класс  :  верхний 
 объектный класс  :  человек 
 uid  :   пользователь 
 sn  :   фамилия 
 cn  :   общее имя 
 userPassword  :   пароль 

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

Привязать (аутентифицировать)

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

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

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

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

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

Удалить

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

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

Найдите и сравните

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

базовый объект

Имя записи базового объекта (или, возможно, корня), относительно которого должен выполняться поиск.

объем

Какие элементы ниже базового объекта искать. Это может быть BaseObject (ищите только именованную запись, обычно используется для чтения одной записи), singleLevel (записи сразу под базовым DN) или wholeSubtree (все поддерево, начиная с базового DN).

фильтр

Критерии, используемые при выборе элементов в пределах области действия. Например, фильтр (&(objectClass=person)(|(givenName=John)(mail=john*))) выберет «персон» (элементы объектного класса person), где правила соответствия для givenName и mailопределить, соответствуют ли значения этих атрибутов утверждению фильтра. Обратите внимание, что распространенным заблуждением является то, что данные LDAP чувствительны к регистру, тогда как на самом деле правила сопоставления и правила упорядочивания определяют сопоставление, сравнения и отношения относительных значений. Если фильтры примера должны были соответствовать регистру значения атрибута, необходимо использовать расширяемый фильтр соответствия , например: (&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

derefAliases

Следует ли и как следовать записям псевдонимов (записям, которые ссылаются на другие записи),

атрибуты

Какие атрибуты возвращать в записях результатов.

лимит размера, лимит времени

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

типыТолько

Возвращайте только типы атрибутов, а не значения атрибутов.

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

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

Изменить

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

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

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

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

dn  :   dc  =  example  ,  dc  =  com 
 тип изменения  :   изменить 
 добавить  :   cn 
 cn  :   новое-значение-cn-добавленное 
 - 

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

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

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

dn  :   uid  =  user.0  ,  ou  =  люди  ,  dc  =  example  ,  dc  =  com 
 тип изменения  :   изменение 
 приращения  :   номер сотрудника 
 номер сотрудника  :  5 
 - 

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

Изменить DN

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

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

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

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

СтартTLS

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

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

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

Оставить

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

Отвязать

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

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

Схема URI

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

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

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

• хост — это полное доменное имя или 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, содержащий именованные классы, определенные в схеме. Определение схемы классов записи определяет, какой тип объекта может представлять запись — например, человека, организацию или домен. Определения классов объектов также определяют список атрибутов, которые должны содержать значения, и список атрибутов, которые могут содержать значения.

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

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

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

Вариации

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

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

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

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

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

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

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

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

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

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

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

См. также

• Неоднозначное разрешение имени
• Сервер имен CCSO
• Федеративная служба имен
• Гесиод (служба имен)
• Иерархическая модель базы данных
• Сервер ключей (криптографический)
• Интерфейс прикладной программы LDAP
• Список программного обеспечения LDAP
• Простой уровень аутентификации и безопасности (SASL)

Ссылки

Источники

• Рек. МСЭ-Т. X.680 , «Первая абстрактная синтаксическая нотация (ASN.1) — спецификация базовой нотации», 1994 г.
• Базовые правила кодирования (BER) – Рек. МСЭ-Т. X.690, «Спецификация правил кодирования ASN.1: основные, канонические и особые правила кодирования», 1994 г.
• RFC 3641 — Общие правила кодирования строк (GSER) для типов ASN.1
• RFC 4346 — протокол TLS версии 1.1.
• RFC 4422 — простой уровень аутентификации и безопасности ( SASL )
• Механизмы SASL зарегистрированы в IANA

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

• Аркиллс, Б. (2003). Объяснение каталогов LDAP: введение и анализ . Аддисон-Уэсли Профессионал . ISBN  978-0-201-78792-4 .
• Картер, Дж. (2003). Администрирование системы LDAP . О'Рейли Медиа . ISBN  978-1-56592-491-8 .
• Донли, К. (2002). Программирование, управление и интеграция LDAP . Публикации Мэннинга . ISBN  978-1-930110-40-3 .
• Хоуз, Т; Смит, М; Хорошо, Г (2003). Понимание и развертывание служб каталогов LDAP . Аддисон-Уэсли Профессионал . ISBN  978-0-672-32316-4 .
• Ротон, Дж (1999). Руководство программиста по электронной почте в Интернете: SMTP, POP, IMAP и LDAP . Эльзевир. ISBN  978-1-55558-212-8 .
• Фогльмайер, Р. (2003). Азбука LDAP: как установить, запустить и администрировать службы LDAP . Публикации Ауэрбаха. ISBN  978-0-8493-1346-2 .

Внешние ссылки

• Список общедоступных LDAP-серверов (2013 г.): «Ldapwiki: общедоступные серверы LDAP» . ldapwiki.com . 2013 . Проверено 18 января 2020 г.